Aws ha risolto un problema che aveva creato

La scarsità artificiale di GPU nel cloud pubblico e la risposta di Amazon dopo anni di errori manuali

C’è qualcosa di paradossale nell’annuncio che AWS ha pubblicato ieri sul suo blog di machine learning. Secondo il post ufficiale di Amazon SageMaker AI sugli instance pools, la nuova funzionalità permette di definire una lista prioritaria di tipi di istanza e lascia che SageMaker AI gestisca automaticamente la capacità — durante la creazione, lo scale-out e lo scale-in. In altre parole: AWS ha appena annunciato una soluzione a un problema che esiste da anni e che AWS stessa ha creato. Il problema si chiama InsufficientCapacity, ed è l’errore che ottieni quando AWS semplicemente non ha abbastanza GPU on-demand per completare la tua richiesta. Non è un bug. È una caratteristica strutturale del cloud pubblico. E fino a ieri, l’unica risposta ufficiale era: riprova a mano con un altro tipo di istanza, un’altra regione, un’altra zona di disponibilità.

Il paradosso della scarsità artificiale

Vale la pena fermarsi su questo punto, perché è facile farsi trascinare dall’entusiasmo tecnico e perdere di vista la sostanza. L’errore InsufficientCapacity esiste — come documentato nella knowledge base di AWS SageMaker sul problema — almeno dal novembre 2022, quando AWS stessa ha pubblicato una guida per gestirlo. La soluzione ufficiale dell’epoca era esplicita: tentare manualmente con diversi tipi di istanza, regioni o zone di disponibilità. Un’azienda che fattura centinaia di miliardi di dollari l’anno chiedeva ai suoi clienti enterprise di fare retry a mano. Nel 2022. Su un servizio di machine learning gestito.

Questo non è un dettaglio tecnico minore. Chi gestisce endpoint di inferenza in produzione sa che un errore di capacità non è un inconveniente — è un’interruzione di servizio. È un modello che non risponde, un’applicazione che va offline, un cliente che vede un errore. E per anni, AWS ha scaricato questo rischio sugli utenti, implicitamente ammettendo che la capacità GPU non poteva essere garantita on-demand. La scarsità di GPU è reale — questo va detto — ma la gestione di quella scarsità era, fino a ieri, completamente delegata all’utente. Chi pagava il costo di quella scarsità? Non AWS, che incassava comunque. L’utente, che doveva costruire logiche di retry, monitorare manualmente la disponibilità, e sperare che il tipo di istanza alternativo fosse disponibile. Una situazione che solleva una domanda scomoda: se AWS sapeva del problema dal 2022 (almeno), perché ci ha messo anni per offrire una soluzione automatica?

Una risposta possibile — e nessuno la dirà apertamente — è che la scarsità gestita crea dipendenza. Finché il cliente non ha alternative semplici al retry manuale, è incentivato a prenotare capacità riservata, a pagare di più per avere garanzie che in un cloud on-demand dovrebbero essere implicite. Non è un’accusa di malafede, ma è un meccanismo che vale la pena tenere a mente mentre si legge di training plans — disponibili già da piani di training SageMaker AI per capacità GPU riservata — che permettono di riservare capacità di calcolo per periodi definiti, estesi ora anche agli endpoint di inferenza. Riservare capacità costa. Gli instance pool sono gratis. La differenza è che i pool non garantiscono nulla: spostano il problema, non lo eliminano.

Come funziona (e cosa nasconde)

Il meccanismo degli instance pool è tecnicamente pulito. Si può specificare un elenco ordinato di pool di istanze eterogenee per endpoint SageMaker AI , fino a cinque tipi di istanza per variante di produzione. SageMaker AI tenta il provisioning partendo dal tipo con priorità più alta (priorità 1) e scende automaticamente verso le alternative quando la capacità non è disponibile. Nessun retry manuale, nessuna logica da implementare lato client. In questo senso, è un passo avanti reale.

Ma la priorità è un ordine di fallback, non una garanzia. Se tutti i tipi nella lista sono indisponibili, l’errore torna. Il sistema raccomanda anche di abilitare il routing Least Outstanding Requests (LOR), configurando RoutingConfig nella ProductionVariant, per distribuire le richieste in modo intelligente tra istanze eterogenee. E ora le metriche CloudWatch includono una nuova dimensione InstanceType — latenza del modello, richieste concorrenti, utilizzo GPU, conteggio istanze, invocazioni per istanza, tutto suddiviso per tipo di hardware all’interno di un singolo endpoint. Il monitoraggio migliora. La visibilità migliora. Ma la capacità sottostante rimane quella che è: contingente, non garantita, gestita da AWS secondo criteri che l’utente non controlla. Il routing LOR e le metriche CloudWatch aggiungono strati di osservabilità su un problema che non è di osservabilità. È di infrastruttura.

Il nodo irrisolto della capacità

Vale la pena guardare cosa fa la concorrenza. Azure OpenAI ha una funzionalità chiamata spillover che, secondo la documentazione Microsoft sulla gestione del traffico in eccesso, instrada il traffico in eccesso verso distribuzioni standard quando la capacità dedicata è saturata. Il principio è simile — fallback automatico — ma il contesto è diverso: Azure lo applica a un livello di astrazione superiore, sulle distribuzioni, non sui tipi di istanza hardware. Non è necessariamente meglio, ma mostra che il problema è noto nell’industria e che le soluzioni prendono forme diverse.

La domanda che rimane aperta, però, è più fondamentale: gli instance pool sono una soluzione o una toppa? Automatizzano il retry, riducono il carico operativo, migliorano l’osservabilità. Ma non cambiano la natura del problema: la GPU che serve potrebbe non esserci. AWS continua a essere l’arbitro della capacità, e l’utente continua a dipendere dalla sua disponibilità. La funzionalità è gratuita, disponibile in tutte le regioni commerciali — questo va detto. Ma gratuita non significa neutrale. Significa che AWS ha deciso che il costo di offrire questo strumento è inferiore al costo di continuare a spiegare perché i suoi clienti ottengono errori di capacità in produzione. Quando AWS smetterà di scaricare sugli utenti il rischio della scarsità di GPU? Gli instance pool non rispondono a questa domanda. La spostano solo di qualche livello verso il basso.