The Pulse
NVIDIA rende open source il suo strumento per attribuire le cause dei guasti nell’IA distribuita
NVIDIA ha reso open source Attribution, uno strumento che correla log dei workload, metriche e stato dello scheduler per diagnosticare i guasti nell’IA distribuita. Il sistema restituisce un risultato strutturato con la probabile causa prin
AI.info Team · Scritto con l’IA · verificato ·
NVIDIA ha pubblicato il suo sistema open source per l’attribuzione delle cause dei guasti nei workload il 2 novembre 2026. Attribution è progettato per individuare dove ha avuto origine il guasto di un workload distribuito, anziché trattare ogni errore segnalato nel cluster come un problema indipendente. Gli eventi relativi alle GPU e al fabric di rete possono innescare errori su altri rank, cambiamenti nello scheduler e una valanga di messaggi; l’eccezione che arresta un job potrebbe non identificare il problema iniziale.
Una diagnosi dalle evidenze sparse del workload
Lo strumento correla log, metriche, dati di telemetria e stato dello scheduler relativi al workload, quindi restituisce un risultato strutturato con un esito, la causa principale, i nodi interessati, i sintomi a supporto e le evidenze raccolte. NVIDIA afferma che Attribution è in uso in produzione da anni nella sua infrastruttura di IA e analizza milioni di workload ogni settimana su centinaia di migliaia di GPU. In un grande cluster basato su RDMA, il sistema ha correlato errori delle porte, reset delle connessioni ed eventi dello scheduler per individuare schemi ricorrenti relativi a specifiche porte di host e switch, aiutando i team a intervenire sulle riparazioni del fabric e sulla regolazione della congestione.
Attribution ha due componenti che possono essere distribuiti. Attribution Service espone il motore di analisi tramite un’API HTTP, mentre Attribution Blueprint, basato su Python, collega gli scheduler del cluster e le fonti di telemetria al Service, ne arricchisce il risultato e lo scrive in una destinazione di output. La separazione consente ai team di usare la stessa logica di attribuzione adattando le integrazioni ai propri cluster.
Come il processo in quattro fasi risale a un guasto
Il Blueprint identifica innanzitutto un tentativo di esecuzione di un workload usando gli identificativi dello scheduler oppure una finestra di esecuzione esplicita e un’allocazione dei nodi. I suoi collettori raccolgono poi le osservazioni specifiche del workload dai log delle applicazioni, dai log di sistema, dai messaggi dei driver GPU e di Fabric Manager, dalla cronologia dello scheduler e dalle metriche dei nodi e della rete. Il Service estrae gli eventi, tra cui gli XID delle GPU, i guasti NCCL, le transizioni dello scheduler e le condizioni rilevate dalle metriche, e applica regole deterministiche per distinguere una causa dai sintomi che ne sono derivati.
Il Blueprint restituisce il verdetto insieme allo stato terminale del workload, al dominio a cui è attribuita la causa, ai sintomi, ai nodi interessati e a un resoconto della copertura dei collettori e degli errori. Nell’esempio di NVIDIA, un workload di addestramento su più rank presenta un guasto XID 149 su una GPU, seguito da errori NCCL su altri rank. Attribution identifica come causa un problema di integrità del segnale NVLink su node-02, mantiene le segnalazioni NCCL come sintomi a supporto e classifica il job come un guasto hardware.
I connettori coprono le fonti di dati più comuni dei cluster
Il Blueprint include connettori per il contesto di esecuzione per Slurm, Kueue e input statici, oltre a connettori per log e metriche per Loki, file locali, log dei pod Kubernetes e PromQL. Le opzioni di output includono stdout e SQLite. I team possono collocare i Blueprint vicino alle fonti di dati dei cluster e usare un Attribution Service dedicato per ogni Blueprint oppure un servizio condiviso per più Blueprint.
La guida pratica di NVIDIA esegue il Service e una dashboard locale in Docker, quindi usa il Blueprint per elaborare le evidenze di un workload di esempio incluso nel repository. L’esempio consente agli utenti di esaminare diagnosi, nodi interessati, sintomi ed evidenze prima di collegare un cluster operativo. NVIDIA afferma che i team possono aggiungere regole per nuove modalità di guasto, creare connettori per i propri scheduler e la propria telemetria e inviare i risultati ai sistemi di gestione degli incidenti, ripristino e gestione del parco macchine.
Evidenze incomplete possono lasciare aperta la questione della causa
NVIDIA avverte che la qualità dell’attribuzione dipende dalla qualità e dalla completezza della telemetria. Quando più cause sono compatibili con le evidenze, il risultato indica il dominio a cui è attribuita la causa come ambiguo, anziché trasformare evidenze incomplete in una diagnosi definitiva. Anche il catalogo delle regole presenta un vincolo di distribuzione: le regole vengono caricate all’avvio del Service e le modifiche devono essere registrate e distribuite con il Service, anziché caricate dinamicamente tramite la sua API HTTP.