The Pulse

Together AI illustra la riparazione automatica dei nodi GPU con controlli per ogni guasto

Together AI afferma che il suo sistema di riparazione automatica dei cluster GPU è disponibile a tutti, con controlli dello stato di salute, raccomandazioni per le riparazioni e criteri di approvazione impostati dai clienti. Il sistema pass

AI.info Team · Scritto con l’IA · verificato · 2026-10-28

«La parte difficile è tutto ciò che accade tra il guasto e il ritorno a un nodo funzionante».

Pavneet Ahluwalia, Dongsheng Zhang e Barbara Kazanowska

Together AI ha pubblicato questa valutazione il 27 ottobre 2026, descrivendo nel dettaglio come il suo sistema di riparazione automatica gestisce i guasti nei Together GPU Clusters. L’azienda afferma che sono disponibili a tutti i controlli passivi dello stato di salute, le raccomandazioni per le riparazioni, i criteri di intervento correttivo dei clienti, i controlli per attendere che i carichi di lavoro siano inattivi, le misure di sicurezza e la possibilità di avviare riparazioni tramite console e API. Il sistema è progettato per affrontare guasti che possono bloccare l’addestramento distribuito o mettere fuori servizio le repliche di inferenza, tra cui errori NVIDIA Xid, errori ECC a doppio bit, GPU che scompaiono dal bus PCIe e collegamenti InfiniBand instabili.

Perché un nodo NotReady non basta

Il sistema di Together non considera un nodo Kubernetes contrassegnato come NotReady un motivo sufficiente per intervenire. Un nodo può diventare brevemente irraggiungibile senza essere guasto, e un evento relativo allo storage o alla rete può far fallire contemporaneamente lo stesso controllo di disponibilità a molti nodi. L’azienda afferma che ogni riparazione deve essere giustificata da un controllo dello stato di salute fallito e da elementi di riscontro.

Il rilevamento avviene sia all’interno delle macchine virtuali dei clienti sia sull’host sottostante. Gli exporter GPU all’interno della macchina virtuale esaminano i log del kernel e i dati DCGM alla ricerca di problemi come errori Xid, perdita della connessione PCIe, errori ECC, errori nella rimappatura delle righe, tassi di ritrasmissione PCIe e limitazioni delle prestazioni dovute alla temperatura; Node Problem Detector monitora i guasti del filesystem, del kernel e dei servizi. Nei cluster Slurm, un exporter segnala i nodi contrassegnati come DOWN o DRAIN, mentre i controlli sul lato host monitorano i collegamenti InfiniBand e la raggiungibilità dell’host.

Gli avvisi contengono una descrizione in linguaggio naturale e dati di riscontro leggibili dalle macchine. Together afferma che questi dati possono includere un codice Xid e il relativo nome mnemonico NVIDIA, oppure la temperatura massima raggiunta e il numero di volte in cui le prestazioni sono state limitate per motivi termici. Le stesse informazioni sugli avvisi sono disponibili nella console, tramite API e nelle notifiche ai clienti.

I clienti stabiliscono le regole per le riparazioni senza intervento umano

Together sceglie la riparazione raccomandata per ciascun guasto, puntando all’intervento meno invasivo in grado di risolverlo. I clienti decidono se le raccomandazioni debbano attendere un’approvazione o essere eseguite automaticamente e possono impostare il consenso in base al guasto e al nodo. L’azienda presenta l’approvazione automatica dei riavvii legati ai codici Xid 119 e 95, mantenendo invece le migrazioni soggette ad approvazione, come una possibile configurazione e non come impostazione predefinita universale.

I clienti controllano anche per quanto tempo una riparazione attende che le attività finiscano. L’attesa massima predefinita è di due ore, con un limite massimo di 24 ore; un’opzione separata per evitare di interrompere i job in esecuzione elimina il limite di tempo. Su Kubernetes, il sistema attende finché nessun pod in esecuzione sul nodo richiede una GPU; su Slurm, verifica se lo scheduler segnala un’allocazione.

Per i team che dispongono di propri sistemi di rilevamento, le richieste di riparazione possono arrivare anche tramite API o console. I contratti di intervento correttivo basati sulle etichette dei nodi, che consentono a uno strumento come NVSentinel o a un controller personalizzato di richiedere una riparazione, restano in anteprima. Together afferma che anche queste richieste sono sottoposte ai controlli del sistema sugli elementi di riscontro, sulla capacità e sui limiti delle riparazioni.

Dai riavvii si passa a interventi più incisivi; le migrazioni attivano un test dell’hardware

La sequenza della riparazione consiste nel bloccare la pianificazione di nuovi carichi sul nodo, attendere secondo i criteri del cliente, rimuovere i carichi dal nodo, eseguire la riparazione e rimetterlo in servizio. Gli interventi disponibili vanno dal riavvio della macchina virtuale, che conserva i dati locali temporanei e di lavoro, alla sua ricreazione su un host funzionante o alla migrazione su hardware diverso. La rimozione di un nodo per inviarlo al produttore per assistenza resta un intervento umano.

I guasti ripetuti fanno salire la raccomandazione lungo una scala di interventi: dopo che lo stesso intervento è stato tentato due volte per un guasto ricorrente, la raccomandazione successiva passa dal riavvio alla ricreazione del nodo, oppure dalla ricreazione alla migrazione. I tentativi risalenti a più di una settimana prima non vengono conteggiati. La migrazione richiede inoltre la prova di un avviso critico sul nodo, attivo in quel momento o registrato sulla stessa macchina nei dieci giorni precedenti; senza questa prova, la richiesta diventa una rapida ricreazione del nodo.

Dopo una migrazione o una rimozione, Together sottopone automaticamente la macchina fisica liberata a una verifica prima di reinserirla nel pool. Una macchina virtuale di test esegue controlli su GPU, NCCL, InfiniBand e storage. Se supera i test, la macchina torna in servizio; un esito esplicitamente negativo genera un ticket per l’hardware e la mantiene fuori dal pool; se il test viene interrotto, la macchina torna allo stato precedente senza essere giudicata guasta.

Le misure di sicurezza puntano a contenere i guasti correlati

I controlli di Together sono progettati per limitare le riparazioni quando molti avvisi hanno una causa comune. I segnali devono persistere per una durata configurata prima di generare raccomandazioni; un nodo riparato ha un periodo di attesa di circa 30 minuti e il sistema esegue una sola riparazione alla volta per ciascun pool di nodi. Un meccanismo di arresto può fermare una raffica di riparazioni automatiche correlate, poiché sostituire i nodi uno per uno non risolverebbe un problema di storage o di rete che interessa l’intero cluster.

Il post descrive come il sistema prende le decisioni, ma non fornisce tempi di ripristino misurati, riduzioni dei tempi di inattività o prezzi. La scelta operativa centrale è separare il rilevamento dall’autorizzazione: Together identifica il guasto e raccomanda l’intervento, mentre i clienti decidono quali guasti possono attivare una riparazione senza approvazione e quanto a lungo la piattaforma debba attendere prima di intervenire.