The Pulse
Ai2 sostituisce le priorità sulle GPU con budget di tempo per la ricerca
Ai2 afferma che il suo nuovo sistema di pianificazione delle GPU ha ridotto da cinque minuti a 24 secondi l’attesa mediana in coda sul suo cluster H100 più grande, mantenendo il tasso di utilizzo al 98%. Il sistema assegna budget di tempo G
AI.info Team · Scritto con l’IA ·
Ventiquattro secondi: è l’attesa mediana in coda sul cluster H100 più grande di Ai2 dopo che l’istituto ha cambiato il modo in cui assegna il tempo GPU, rispetto ai cinque minuti precedenti. Il nuovo sistema di pianificazione sostituisce un sistema basato sulle priorità con budget per i progetti, una ripartizione equa gerarchica e regole che consentono di interrompere e rimettere in coda i carichi di lavoro idonei. Ai2 ha pubblicato il resoconto del cambiamento il 9 ottobre 2026, insieme ai risultati di un test di 30 giorni.
Perché Ai2 ha abbandonato il sistema di priorità
Ai2 afferma di gestire migliaia di GPU NVIDIA H100, B200 e B300 in cluster che vanno da 88 a 1.024 GPU, al servizio di circa 150 ricercatori interni. Secondo l’organizzazione, i carichi di lavoro inviati richiedono una capacità GPU da due a tre volte superiore a quella disponibile. «In qualsiasi momento abbiamo richieste in sospeso per un numero di GPU 2-3 volte superiore a quello disponibile», scrive Kyle Wiggers, indicato nel post come Ai2Comms.
Con il vecchio sistema, gli utenti potevano scegliere di proteggere i carichi di lavoro dalle interruzioni, mentre le etichette di priorità determinavano quali job venivano eseguiti per primi. Ai2 afferma che, col tempo, ogni carico di lavoro pianificato aveva raggiunto la priorità HIGH, lasciando senza risorse i livelli inferiori. I ricercatori tenevano inoltre occupate le GPU con carichi di lavoro inattivi, no-op, per potervisi collegare rapidamente quando ne avevano bisogno: un comportamento che il post definisce «occupazione».
I budget stabiliscono le quote; il sistema di pianificazione gestisce la coda
Ora i responsabili assegnano budget di tempo GPU attraverso una gerarchia di programmi di ricerca, progetti e ricercatori. Le assegnazioni garantiscono ai gruppi una quota definita della capacità nel tempo, senza riservare GPU specifiche che potrebbero restare inutilizzate quando un progetto non ha job pronti. Ogni richiesta di esecuzione protetta viene conteggiata nel budget pertinente, così i job inattivi pesano sul gruppo che li ha inviati.
Il sistema di pianificazione confronta il recente utilizzo delle GPU da parte di ciascun gruppo con la quota assegnata, considerando per impostazione predefinita i sette giorni precedenti, e favorisce i carichi di lavoro dei gruppi che hanno usato meno della propria quota. I job inviati devono inoltre indicare un tempo minimo di esecuzione, quello necessario per compiere progressi significativi. Sono protetti dalle interruzioni per quel periodo; in seguito possono continuare a essere eseguiti oppure, se possono riprendere, essere interrotti e rimessi in coda.
Ai2 fissa a otto ore il limite massimo del tempo minimo di esecuzione protetto. I job che dichiarano un tempo minimo di esecuzione pari a zero restano interrompibili e non vengono conteggiati nel budget del gruppo. Secondo l’organizzazione, il cambiamento consente anche di rimuovere i carichi di lavoro dagli host malfunzionanti al termine dei rispettivi periodi di esecuzione protetti, riducendo del 74% le riparazioni che richiedono l’intervento di una persona.
Le attese in coda sono diminuite, mentre l’utilizzo è rimasto al 98%
Nel test di 30 giorni, secondo Ai2, i gruppi hanno ricevuto il 98% delle ore GPU loro spettanti, conteggiando ciascuna assegnazione solo fino a concorrenza della domanda effettiva del gruppo. Tredici delle 15 assegnazioni ai gruppi hanno ottenuto almeno il 95% del tempo spettante; quella con il risultato più basso ha ottenuto il 90%. L’utilizzo del cluster è rimasto al 98% prima e dopo il cambiamento, e il 18% del tempo GPU erogato è andato ad attività senza una quota assegnata quando i progetti dotati di budget non erano pronti per l’esecuzione.
Sul cluster H100 più grande, l’attesa mediana in coda è scesa da cinque minuti a 24 secondi, mentre l’attesa al 90° percentile è passata da 2,8 ore a 1,8 ore. Per i carichi di lavoro di debug — piccoli job usati per verificare se il codice si avvia o fallisce nelle prime fasi — l’attesa al 90° percentile è scesa da due ore a 30 secondi. Ai2 avverte che nel periodo di riferimento iniziale c’erano meno job di questo tipo, il che rende il confronto più variabile.
Le sessioni interattive mettono in luce il compromesso
Non tutti i ricercatori ne hanno beneficiato. Con il vecchio sistema, le sessioni interattive per l’analisi dei dati e i test del codice potevano restare attive fino a una settimana; con le nuove regole, se superano la quota assegnata possono diventare interrompibili una volta raggiunto il limite di otto ore di protezione. Ai2 afferma che talvolta gli utenti hanno dovuto ricostruire lo stato della sessione dopo un’interruzione.
L’organizzazione afferma di progettare un cluster con sole CPU vicino al proprio sistema di archiviazione locale per le sessioni di sviluppo e preparazione dei dati, oltre a sessioni ripristinabili che possano essere spostate altrove dopo un’interruzione. Sta inoltre esaminando se le protezioni basate sul tempo minimo di esecuzione possano rendere più difficile riunire un numero sufficiente di GPU per i job più grandi: un possibile problema di frammentazione della capacità che, afferma, sta verificando in simulazione e in produzione.