Come Ai2 ha risolto lo scheduling di migliaia di GPU H100 e B200
L'Allen Institute for AI racconta come ha riorganizzato la gestione delle code su migliaia di GPU NVIDIA H100, B200 e B300 dopo il collasso dei vecchi sistemi.
👁 115 letture
L’Allen Institute for AI (Ai2) ha pubblicato un’analisi dettagliata sulla completa ricostruzione del sistema di accodamento dei task sui propri cluster di GPU. Il report illustra un caso classico di come un’infrastruttura ben progettata possa cedere sotto il peso dell’utilizzo reale.
Ai2 gestisce migliaia di schede NVIDIA H100, B200 e B300, suddivise in cluster di dimensioni variabili tra 88 e 1024 GPU. Questa infrastruttura serve circa 150 ricercatori interni impegnati in ambiti molto eterogenei: dall’addestramento di modelli linguistici di grandi dimensioni (LLM) e modelli visuo-linguistici (VLM), alle simulazioni di reinforcement learning per la robotica, fino al post-training per agenti scientifici. Si tratta di un carico di lavoro che richiede contemporaneamente sessioni di addestramento lunghe e stabili, ma anche un accesso rapido per il debugging in tempo reale: due necessita difficili da conciliare con un unico meccanismo basato su priorita.
Google · Le tue fontiPiù in alto su Google con un solo clicAggiungi alle fonti preferite →La tragedia dei beni comuni nel calcolo computazionale
La criticita non era nuova: la domanda di tempo computazionale superava l’offerta da tempo. In qualsiasi momento la coda conteneva richieste per un numero di schede pari a 2 o 3 volte quelle realmente disponibili. In pratica, per ogni ora di calcolo libera competevano due o tre progetti di ricerca diversi.
Il vecchio sistema si basava su priorita rigide e consentiva ai task di disattivare la prelazione (preemption), ossia l’interruzione forzata per fare spazio a lavori piu importanti. Ogni team disponeva di una quota di GPU protette dall’interruzione; i task interrompibili potevano invece sfruttare le schede inattive oltre tale soglia. Sulla carta il meccanismo appariva equilibrato, ma nell’uso quotidiano ha generato comportamenti distorsivi prevedibili.
Il primo e stato il cosiddetto GPU squatting: i ricercatori lanciavano task vuoti (no-op workloads) per “parcheggiare” le risorse e collegarsi al volo al momento di fare debug, poiche avviare un nuovo job con una latenza accettabile era diventato impossibile. Il secondo e stata l’inflazione delle priorita: a un certo punto il 100% dei task pianificati utilizzava il livello massimo (HIGH), togliendo completamente risorse ai livelli inferiori. Il terzo problema, forse il piu gravoso a livello operativo, costringeva gli ingegneri reperibili a impiegare gran parte del tempo nel negoziare manualmente lo stop di task non interrompibili su nodi che presentavano guasti hardware.
Ai2 ha ammesso di non aver compreso subito la causa profonda del problema. I primi tentativi di correzione puntavano a regolamentare meglio le priorita, per poi aggirare lo scheduler assegnando interi cluster in monopolio a specifici progetti. Solo in seguito il team ha riconosciuto le dinamiche tipiche della tragedia dei beni comuni: una situazione in cui ogni utente, agendo in modo del tutto razionale nel proprio interesse, finisce per degradare una risorsa condivisa a danno di tutti.
La soluzione ha previsto la sostituzione del vecchio scheduler con un sistema basato su tre pilastri: budget di ore GPU assegnati a monte a ciascun progetto, un modello gerarchico di fair-share allocation e un vero e proprio contratto di time-slicing, che definisce in modo esplicito le finestre temporali di accesso alle risorse. Il cambiamento determinante non e stato solo tecnico, ma organizzativo: stabilire quante ore GPU spettassero a un gruppo non e piu oggetto di trattativa quotidiana sul campo, ma fa parte di un processo trasparente di pianificazione e allocazione del budget.
Se gestisci o condividi risorse hardware dedicate al machine learning, questo caso offre una lezione fondamentale: l’intoppo di Ai2 non dipendeva da un algoritmo di scheduling errato, ma da incentivi disallineati. Quando puoi bloccare una GPU senza costi visibili, lo farai sempre; se alzare la priorita non comporta alcuna rinuncia, tutti selezioneranno il massimo. Il nuovo modello assegna a ogni scelta un impatto di bilancio misurabile e visibile all’intera organizzazione, modificando i comportamenti piu efficacemente di qualsiasi algoritmo di prelazione.
More on this from NITIDO
stato dell'ia·Gemini Agent vs ChatGPT vs Claude: quale scegliere in aziendaConfronto tra agenti AI aziendali: Gemini agent, ChatGPT Business e Claude Team. Prezzi ufficiali, integrazioni, gestione dei dati e quale scegliere.