NVIDIA Attribution: Open-Source-Tool zur Diagnose verteilter KI-Ausfälle

NVIDIA hat NVIDIA Attribution als Open-Source-Projekt veröffentlicht, um Ingenieure bei der Diagnose von Ausfällen in verteilten KI-Workloads zu unterstützen. Das am 2. November 2026 vorgestellte Tool adressiert die Komplexität beim Debugging großer GPU-Cluster, indem es disparate Datenquellen in einer strukturierten Diagnose zusammenführt. Es geht über einfache Fehlermeldungen hinaus und erklärt, warum ein Workload fehlgeschlagen ist.

Was passiert ist

Verteilte Trainingsjobs scheitern oft an kaskadierenden Fehlern, bei denen ein einzelnes Hardware- oder Netzwerkproblem Tausende von nachgelagerten Symptomen auslöst. Ein Defekt auf einer GPU kann sich als Kommunikations-Timeouts über viele andere Ranks hinweg manifestieren, was es schwierig macht, die Ursache vom resultierenden Rauschen zu unterscheiden. Herkömmliche Monitoring-Tools melden typischerweise, wo der Workload angehalten hat, nicht aber, wo der Fehler seinen Ursprung hatte, was zu langen Untersuchungszeiten führt.

Um dies zu lösen, hat NVIDIA sein internes, workload-zentriertes System zur Fehlerursachenzuweisung (Failure-Attribution) als Open Source bereitgestellt. Das Tool, das seit Jahren produktiv in der NVIDIA-KI-Infrastruktur eingesetzt wird, analysiert wöchentlich Millionen von Workloads auf Hunderttausenden von GPUs. Durch die Korrelation von workload-spezifischen Logs, Metriken, Telemetrie und Scheduler-Status erzeugt es eine reproduzierbare Diagnose, die Ergebnis, Ursache, betroffene Knoten und einen Nachweisstrang (Evidence Trail) umfasst.

Die Veröffentlichung enthält zwei wesentliche komponenten: den Attribution Service und den Attribution Blueprint. Der Service stellt die Kern-Engine für die Zuweisung über eine REST-API bereit, während der Blueprint als Python-Referenz-Orchestrator fungiert. Der Blueprint verbindet Cluster-Scheduler und Telemetrie-Quellen mit dem Service, sodass Teams das Tool in ihre bestehende Infrastruktur integrieren können, ohne die Kernlogik neu aufbauen zu müssen.

Wie es funktioniert

Der Prozess der Fehlerursachenzuweisung folgt vier deterministischen Phasen, um Reproduzierbarkeit sicherzustellen. Zunächst definiert der Blueprint den Kontext des Workloads, indem er den spezifischen Versuch anhand von Scheduler-Identifikatoren oder Ausführungsfenstern identifiziert. Anschließend sammelt er Beobachtungen aus verschiedenen Connectors, darunter Anwendungslogs, Syslogs, GPU-Treiber-Meldungen und Netzwerkmetriken. Diese Eingaben werden in strukturierte Beobachtungsdatensätze normalisiert.

Danach extrahiert und korreliert der Service Ereignisse mithilfe einer Regel-Engine. Er identifiziert signifikante Ereignisse wie GPU-XIDs, NCCL-Fehler und Scheduler-Übergänge. Deterministische Regeln bewerten das Timing und die Interaktion dieser Ereignisse, um nachgelagerte Symptome von der primären Ursache zu trennen. Wenn beispielsweise eine GPU ein Problem mit der Signalintegrität meldet und andere Ranks Kommunikationsfehler berichten, identifiziert das System den Hardware-Defekt als Ursache und die Kommunikationsfehler als unterstützende Symptome.

Abschließend gibt das System ein strukturiertes Ergebnis zurück, das den Endzustand, die zugewiesene Domäne und die betroffenen Knoten enthält. Die Ausgabe unterscheidet zwischen eindeutigen Ursachen und mehrdeutigen Situationen, in denen die Beweislage unvollständig ist. Dieses strukturierte Format ermöglicht es nachgelagerten Systemen, wie Incident-Management-Tools oder automatisierten Wiederherstellungslösungen, die Diagnose zu nutzen, ohne rohe, produktspezifische Logs parsen zu müssen.

Wichtige Details

• Das System arbeitet mit zwei Komponenten: dem Attribution Service für die Analyse und dem Attribution Blueprint für die Orchestrierung und Datensammlung.
• Es unterstützt Execution-Context-Connectors für Slurm, Kueue und statische Eingaben sowie Log- und Metrik-Connectors für Loki, lokale Dateien, Kubernetes-Pod-Logs und PromQL.
• Im Produktiveinsatz hat das System Muster von Fabric-Ausfällen rund um bestimmte Host- und Switch-Ports identifiziert, indem es Port-Fehler und Verbindungsresets korrelierte.
• Die Attribution-Engine nutzt deterministische Regeln zur Bewertung des Ereignis-Timings, was sicherstellt, dass Ergebnisse reproduzierbar sind und für verschiedene Umgebungen angepasst werden können.
• Die Ausgabe enthält einen Qualitätsindikator, der Unsicherheit widerspiegelt, wenn mehrere Ursachen zur Beweislage passen, um falsches Vertrauen in unvollständige Diagnosen zu vermeiden.
• Entwickler können das System erweitern, indem sie neue Regeln für Fehlermodi hinzufügen oder Connectors für eigene Scheduler und Telemetrie-Backends implementieren.

Warum es wichtig ist

Für Software-Ingenieure und Leiter der ML-Infrastruktur ist die Reduzierung der mittleren Zeit bis zur Lösung (MTTR) entscheidend, um die hohe Auslastung teurer GPU-Ressourcen aufrechtzuerhalten. Das manuelle Debugging verteilter Ausfälle ist zeitaufwendig und fehleranfällig und erfordert oft Experten, die durch Gigabytes von Logs sichten. NVIDIA Attribution automatisiert diese Korrelation, sodass Teams sich auf die Behebung von Infrastrukturproblemen konzentrieren können, statt nach ihnen zu suchen. Durch die Bereitstellung eines klaren Nachweisstrangs fördert es zudem die Kommunikation zwischen Software-Teams und Hardware-Betrieb.

Der Open-Source-Charakter des Projekts ermöglicht es Organisationen, das Tool an ihren spezifischen Stack anzupassen. Da die Kernlogik von der Integrationsschicht getrennt ist, können Teams dieselben Attribution-Regeln auf verschiedenen Clustern anwenden, während sie die Art der Datenerfassung und -speicherung individuell gestalten. Diese Flexibilität unterstützt diverse Umgebungen, von kleinen Forschungsclustern bis hin zu massiven Produktionsflotten, und ermöglicht konsistente Praktiken zur Fehleranalyse innerhalb einer Organisation.

Was Sie tun können

• Klonen Sie das NVIDIA-Attribution-Repository von GitHub, um auf den Quellcode und Beispiel-Workloads zuzugreifen.
• Folgen Sie dem Quickstart-Guide, um den Beispiel-Workflow unter Verwendung von Docker und dem Paketmanager uv auszuführen.
• Prüfen Sie die generierten Diagnosen im lokalen Dashboard, um zu verstehen, wie das System Ereignisse korreliert und Ursachen identifiziert.
• Lesen Sie die Referenz zur Blueprint-Konfiguration, um Ihre eigenen Scheduler- und Telemetrie-Backends, wie Slurm oder Kubernetes, anzubinden.
• Untersuchen Sie die enthaltenen deklarativen und Python-Regeln, um zu lernen, wie Sie neue Fehlermuster für Ihren spezifischen Hardware- oder Software-Stack kodieren.
• Integrieren Sie das Attribution-Blueprint-Ergebnis in Ihre bestehenden Incident-Management- oder Flotten-Wiederherstellungssysteme, um Reaktionen auf häufige Ausfälle zu automatisieren.