NVIDIA stellt Attribution-Tool als Open Source bereit: Ursachen von Ausfällen bei KI-Workloads aufspüren

Ein Fehler, viele Symptome

Bei verteilten KI-Workloads kann ein einzelner Fehler eine ganze Kaskade auslösen. Laut NVIDIA kann sich ein GPU- oder Fabric-Ereignis als NCCL-Fehler auf anderen Ranks, als Statuswechsel im Scheduler und als Tausende nachgelagerte Meldungen zeigen. Die gemeldete Exception verrät, wo der Workload stehen geblieben ist, nicht, wo der Ausfall begonnen hat.

NVIDIA Attribution soll diese Lücke schließen. Das Tool analysiert Ausfälle im Kontext eines Workloads statt als isolierte Knotenereignisse und liefert eine strukturierte Diagnose mit Ergebnis, Grundursache, betroffenen Knoten, begleitenden Symptomen und einer Beweiskette. Die verwendeten Regeln sind deterministisch, wodurch die Ergebnisse laut NVIDIA reproduzierbar und anpassbar sind. Die strukturierte Ausgabe soll in bestehende Health- und Recovery-Systeme einfließen.

NVIDIA sieht das Tool als Ergänzung zu Readiness-Checks, kontinuierlichem Health-Monitoring und den Systemen, die Infrastruktur reparieren und Workloads neu starten. Es erklärt, warum ein Workload gescheitert ist, und liefert Belege für den nächsten Schritt.

Zwei Komponenten und vier Stufen

Die Veröffentlichung umfasst zwei einsetzbare Komponenten, die beide auf einer zentralen Attribution-Engine aufbauen. Der NVIDIA Attribution Service stellt die Attribution über eine REST-API bereit. Der NVIDIA Attribution Blueprint ist ein Python-Referenzorchestrator, der Cluster-Scheduler und Telemetriequellen mit dem Service verbindet und das Ergebnis schreibt. Er enthält Konnektoren für den Ausführungskontext von Slurm, Kueue und statische Eingaben sowie Log- und Metrik-Konnektoren für Loki, lokale Dateien, Kubernetes-Pod-Logs und PromQL-Metriken.

Der Service analysiert jeweils einen Workload-Versuch in vier Stufen:

• Workload eingrenzen: Der Blueprint identifiziert den Versuch anhand von Scheduler-Kennungen oder anhand eines expliziten Ausführungsfensters samt Knotenzuweisung.
• Beobachtungen sammeln: Konnektoren erzeugen workload-bezogene Datensätze aus Anwendungslogs, Syslogs, Meldungen von GPU-Treiber und Fabric Manager, Scheduler-Verlauf sowie Knoten- und Netzwerkmetriken.
• Ereignisse extrahieren und korrelieren: Die Engine identifiziert signifikante Ereignisse wie GPU-XIDs, NCCL-Fehler, Scheduler-Übergänge und Metrikbedingungen und wendet dann deterministische Regeln an, um nachgelagerte Symptome von der Ursache zu trennen.
• Strukturiertes Ergebnis zurückgeben: Die Ausgabe enthält das Ergebnis des Workloads (terminal_state), die zugeordnete Domäne (sub_domain), Symptome, betroffene Knoten sowie einen Nachweis zu Abdeckung und Fehlern der Collectors.

Ein Praxisbeispiel: NVLink-Signalintegrität

NVIDIAs Beitrag geht ein synthetisches Multi-Rank-Training durch. Eine GPU erleidet einen schweren Fehler, XID 149, und auf anderen Ranks folgen NCCL-Fehler. Die Anwendungslogs enthalten drei verschiedene NCCL-Fehler, während die Systemlogs auf node-02 XID 149 mit Error Words enthalten, die sich als Problem mit der NVLink-Signalintegrität dekodieren lassen.

Die Extraktion wandelt die rohen Logs zunächst in typisierte Ereignisse um. Eine frühe Filterregel, HandleXidBurstEvents, dekodiert die Error Words und erzeugt ein Attribution-Ereignis für das Signalintegritätsproblem auf node-02, während die drei NCCL-Ereignisse unverändert bleiben. In der abschließenden Verfeinerung behalten Regeln wie Xid149AndNvlinkFiltering und Gb200PriorityRootCause das Signalintegritätssymptom bei und stufen die übrigen Knotensymptome herab. Die Ergebniszuordnung führt schließlich zu einer Hardwarefehler-Attribution.

Die NCCL-Meldungen werden nicht verworfen. Die Herabstufung bewahrt ihre ursprünglichen Quellen als „interessant“ auf, sodass sie weiterhin untersucht werden können. Der Workload wird als Hardwarefehler gemeldet und nicht als Sammlung unabhängiger Kommunikationsfehler.

NVIDIA weist zudem darauf hin, dass die Qualität der Attribution von Qualität und Vollständigkeit der zugrunde liegenden Telemetrie abhängt. Passen mehrere Ursachen zur Beweislage, wird sub_domain als mehrdeutig markiert. Die Diagnose spiegelt also die Unsicherheit wider, statt unvollständige Belege in eine definitive Antwort zu verwandeln.

Produktiver Einsatz und nächste Schritte

Laut NVIDIA analysiert das System jede Woche Millionen von Workloads auf Hunderttausenden GPUs. In einem großen RDMA-basierten Cluster korrelierte es Portfehler, Verbindungsabbrüche und Scheduler-Ereignisse und erkannte so Muster rund um bestimmte Host- und Switch-Ports. Das half den Teams, Fabric-Reparaturen und Congestion-Tuning gezielt anzugehen.

Für Teams, die eigene Cluster betreiben, nennt NVIDIA drei Schritte: das NVIDIA-Attribution-Repository klonen, um Quellcode und Beispiel-Workloads zu erhalten, dem Quickstart folgen, um den Beispiel-Workflow auszuführen und Diagnosen im lokalen Dashboard zu prüfen, und die Konfigurationsreferenz des Blueprints durchgehen, um die eigenen Scheduler- und Telemetrie-Backends anzubinden.