The Pulse
NVIDIA aggiunge il ripristino automatico per i job di addestramento Slurm
NVIDIA afferma che il suo servizio di ripristino ha registrato circa 8.550 rilevamenti di anomalie su un cluster di addestramento tra il 9 luglio e il 9 ottobre. Lo strumento open source automatizza il ripristino dei job di addestramento Sl
AI.info Team · Scritto con l’IA · verificato ·
Un cluster ha registrato 8.550 anomalie
NVIDIA afferma che il suo servizio di ripristino ha registrato circa 8.550 rilevamenti di anomalie su un cluster di addestramento tra il 9 luglio e il 9 ottobre. Nello stesso periodo di monitoraggio sono stati esaminati quasi 200 job al giorno, con una latenza media di rilevamento di 69 secondi e una latenza media delle azioni di ripristino di 94 secondi. NVIDIA precisa che quest’ultima misurazione termina quando viene eseguita l’azione automatica; sono la pianificazione e il ripristino del checkpoint a determinare quando riprende l’addestramento.
I dati provengono dalle osservazioni di NVIDIA in produzione su NVIDIA Recovery, un servizio open source che coordina il ripristino dei carichi di lavoro di addestramento di un cluster. L’azienda afferma che il servizio rileva le interruzioni attraverso i log delle applicazioni, le metriche delle GPU e i segnali dello scheduler, quindi usa l’attribuzione dei guasti per guidare le decisioni di isolamento e riavvio. Fa parte di NVIDIA DSX OS, il portafoglio software dell’azienda per la gestione delle fabbriche di IA.
Quattro fasi dal guasto al riavvio
NVIDIA descrive il processo come un ciclo in quattro fasi: rilevare, attribuire, isolare e infine riavviare o fermare. Il sistema di rilevamento cerca arresti anomali, blocchi e processi in ritardo, inclusi guasti di PyTorch e NCCL, errori CUDA e schemi di guasto delle interconnessioni. La mancanza di segnali di avanzamento o il riconoscimento di schemi di blocco delle comunicazioni possono indicare un blocco, mentre un calo prolungato della produttività rispetto a un riferimento recente può indicare un processo in ritardo.
Durante l’attribuzione, NVIDIA Recovery classifica l’interruzione usando i segnali dello scheduler e i log delle applicazioni. Un’integrazione opzionale con NVIDIA Attribution può aggiungere diagnosi che distinguono tra guasti hardware, problemi del software di sistema e bug delle applicazioni; gli operatori possono anche collegare un proprio servizio di attribuzione. Le evidenze così raccolte guidano l’esclusione dei nodi e possono essere aggiunte al registro di audit permanente.
Il componente di correzione può escludere i nodi coinvolti dai successivi tentativi di riavvio o fermare un carico di lavoro quando è improbabile che ulteriori tentativi siano utili. Un watchdog consente alla normale pianificazione di proseguire se una decisione di ripristino richiede troppo tempo o fallisce. Quando lo scheduler riavvia un job, l’applicazione usa la propria logica di riavvio esistente per riprendere dall’ultimo checkpoint salvato; gli operatori possono configurare un limite ai tentativi che non riescono a salvare un nuovo checkpoint.
Il supporto a Slurm parte in modalità di monitoraggio
NVIDIA Recovery viene eseguito come servizio del piano di controllo e comunica con un’integrazione dello scheduler attraverso un’API HTTP o gRPC. La versione attuale supporta Slurm; il supporto a Kubernetes è previsto nella roadmap. Per Slurm, NVIDIA fornisce un Advisor Controller di riferimento che può essere distribuito con un chart Helm all’interno del cluster oppure in modalità SSH, che si connette da remoto senza aggiungere un servizio al cluster.
Le nuove installazioni partono in modalità di monitoraggio. Il servizio registra le raccomandazioni ma non esegue azioni sullo scheduler, consentendo agli operatori di confrontare i suoi suggerimenti con le proprie decisioni di ripristino prima di abilitare la modalità di azione per un cluster. IBM Research ha usato questo approccio sul proprio cluster Slurm, convalidando le raccomandazioni prima di attivare le azioni autonome.
Un registro di audit traccia ogni decisione
NVIDIA Recovery registra ogni raccomandazione prima che il controller dello scheduler agisca. Il suo registro di audit permanente include lo schema di rilevamento corrispondente, l’azione, la marca temporale, l’identificativo del carico di lavoro e l’eventuale verdetto di NVIDIA Attribution. Le azioni registrate possono includere l’interruzione o il reinserimento in coda di un job, il suo rilascio o l’esclusione di un nodo.
La Recovery Console mostra in tempo reale lo stato dei carichi di lavoro per i diversi tipi di scheduler, segnala le anomalie e fornisce una cronologia degli eventi di rilevamento e delle azioni di ripristino per ciascun carico di lavoro. NVIDIA afferma che le azioni del motore delle policy e del watchdog compaiono nello stesso registro. Se il controller si riavvia durante il ripristino, prima di proseguire controlla lo stato attuale dello scheduler, per evitare di ripetere azioni già completate.
Distribuzione e limiti della versione
NVIDIA pubblica il codice nel repository GitHub dsx-ai-factory/NVIDIA-Recovery con licenza Apache 2.0. Un unico chart Helm principale installa il servizio e il sub-chart MySQL incluso consente un avvio rapido in locale senza una GPU fisica; NVIDIA raccomanda un servizio MySQL gestito per la produzione. Gli operatori collegano il chart a un endpoint Loki o Victoria Logs esistente e a un target di raccolta Prometheus, quindi eseguono un configuratore che verifica se la telemetria corrisponde al formato previsto dal servizio.
Per includere un carico di lavoro, un operatore aggiunge una direttiva al suo script di invio sbatch. Le istruzioni di NVIDIA prevedono poi di esaminare le raccomandazioni nella Recovery Console e di passare il servizio alla modalità di azione dopo averle convalidate. La versione attuale gestisce i job Slurm, incluso Slurm su Kubernetes tramite slurm-operator; gli array di job e il ripristino nativo su Kubernetes per JobSet e Kubeflow PyTorchJob sono indicati come sviluppi futuri.
Secondo NVIDIA, Verda, un fornitore neocloud, ha distribuito il servizio con Victoria Logs e ha contribuito con un connettore al repository. IBM Research sta inoltre collaborando con NVIDIA per affinare gli schemi di guasto ricavati dai propri carichi di lavoro di addestramento. L’ambito immediato del servizio è quindi chiaro: coordina il ripristino dei job Slurm per i quali è stato attivato, mentre sono ancora lo scheduler del cluster e la logica dei checkpoint a determinare quando l’addestramento torna produttivo.