Diagnose von Fehlern bei verteilt arbeitenden KI-Arbeitslasten mit NVIDIA Attribution

Diagnose von Fehlern bei verteilter KI-Arbeitlast mit NVIDIA Attribution

Im Bereich der verteilten künstlichen Intelligenz kann ein einziger Hardwarefehler eine Kettenreaktion von Symptomen auslösen, die die wahre Ursache eines Fehlers verschleiern. Wenn eine GPU auf einen schwerwiegenden Fehler stößt, können nachgelagerte Komponenten Kommunikationsfehler melden, der Zustand des Schedulers kann sich ändern, und Tausende von Protokollnachrichten können im ganzen Cluster auftauchen. Die gemeldete Ausnahme weist oft darauf hin, wo die Arbeitlast gestoppt hat, nicht jedoch, wo der Fehler begonnen hat. NVIDIA Attribution bewältigt diese Komplexität, indem es Arbeitslast-bezogene Protokolle, Metriken, Telemetriedaten sowie den Scheduler-Zustand miteinander verknüpft, um eine strukturierte Diagnose zu erzeugen.

Laut NVIDIA ermöglicht dieses Open-Source-Tool Infrastrukturteams, Rohdaten der Arbeitslasten in eine reproduzierbare Diagnose für ihre eigenen Cluster umzuwandeln. Das System arbeitet mit zwei einsetzbaren Komponenten: dem Attribution Service, der eine REST-API für den Kern des Attribution-Engines bereitstellt, und dem Attribution Blueprint, einem Python-basierten Referenzorchestrator, der Cluster-Schedulers sowie Telemetriedatenquellen mit dem Service verbindet.

Architektur und Kernkomponenten

Die Architektur von NVIDIA Attribution ist so konzipiert, dass die Kernlogik von umgebungsspezifischen Integrationen getrennt wird. Der Attribution Service analysiert jeweils nur einen Versuch einer Arbeitslast und stellt die Attribution über eine REST-API zur Verfügung. Der Attribution Blueprint hingegen kümmert sich um die integrationsspezifischen Aspekte des Clusters. Er entdeckt Arbeitslasten, bestimmt den Ausführungskontext, startet Sammlerprozesse, ruft den Service auf, ergänzt die Ergebnisse und schreibt diese in Ausgabekanäle – einschließlich eines nur zum Lesen zugänglichen Dashboards.

Durch diese Trennung können Teams dieselbe Attribution-Logik auf verschiedenen Clustern anwenden, während sie die Scheduler, Telemetriedatenquellen sowie Ausgabekonverter für jede Umgebung anpassen. Der Blueprint enthält Konverter für den Ausführungskontext von Slurm, Kueue sowie statische Eingaben. Zudem gibt es Konverter für Protokolle und Metriken von Loki, lokalen Dateien, Kubernetes-Pod-Protokollen und PromQL-Metriken.

NVIDIA weist darauf hin, dass das System seit Jahren in der Produktion innerhalb der NVIDIA AI-Infrastruktur eingesetzt wird. In einem großen Cluster, der auf RDMA basiert, wurden Portfehler, Verbindungsabbrüche sowie Scheduler-Ereignisse miteinander in Beziehung gesetzt, um Muster bezüglich bestimmter Host- und Switch-Ports zu erkennen. Diese Fähigkeit hilft Teams dabei, Reparaturen an der Netzwerkinfrastruktur sowie Anpassungen zur Entlastung effektiv durchzuführen.

Der vierstufige Zuordnungsprozess

Der Zuordnungsprozess folgt einem deterministischen Vier-Stufen-Ablauf, der darauf abzielt, nachgelagerte Symptome vom ursächlichen Fehler zu trennen.

1. Arbeitslast einrahmen: Der Blueprint ermittelt den Versuch der Arbeitslast anhand von Scheduler-Identifikatoren oder einer expliziten Ausführungszeitfenster- und Knotenzuweisung.
2. Beobachtungen sammeln: Log- und Metrikverbindungen erzeugen beobachtungsorientierte Aufzeichnungen, die auf der Arbeitslast basieren und aus Anwendungslogs, Syslogs, Nachrichten des GPU-Treibers sowie des Fabric Managers, Scheduler-Historie sowie Knoten- und Netzwerkmetriken stammen.
3. Ereignisse extrahieren und miteinander in Beziehung setzen: Der Service ruft den Zuordnungsmechanismus auf, um bedeutende Ereignisse wie GPU-XIDs, NCCL-Fehler, Scheduler-Übergänge sowie Metrikbedingungen zu identifizieren. Deterministische Regeln bewerten deren zeitlichen Ablauf und gegenseitige Wechselwirkung.
4. Gestraffenes Ergebnis zurückgeben: Der Blueprint kombiniert das Urteil mit dem Ergebnis der Arbeitslast (terminalstate), dem zugeordneten Bereich (subdomain), den Symptomen, den betroffenen Knoten sowie einer Aufzeichnung zur Abdeckung durch die Sammelkomponenten und zu auftretenden Fehlern.

Durch diesen Prozess werden reproduzierbare und anpassbare Ergebnisse gewährleistet. Die strukturierte Ausgabe ermöglicht die Integration in bestehende Überwachungs- und Wiederherstellungssysteme, sodass nachgelagerte Systeme terminalstate und subdomain verwenden können, anstatt produktspezifische Logs zu analysieren.

Interpretation von Beweismitteln: Ein konkretes Beispiel

Um zu veranschaulichen, wie das System funktioniert, betrachte man eine synthetische, mehrstufige Trainingsarbeitslast, bei der eine GPU auf einen schwerwiegenden Fehler stößt. In diesem Szenario enthalten die Anwendungslogs drei verschiedene NCCL-Fehler, während die Systemlogs auf node-02 den XID 149 enthalten, wobei die darin enthaltenen Fehlerbeschreibungen auf ein Problem mit der Signalintegrität von NVLink hindeuten.

Die Extraktionsphase wird zunächst auf den Rohdaten-Logs durchgeführt und erzeugt strukturierte Ereignisse, die von späteren Schritten verarbeitet werden. Wie in der Dokumentation von NVIDIA beschrieben, liest die EARLY-stage HandleXidBurstEvents-Regel die XID-Burst-Daten, decodiert die Fehlermeldungen und erzeugt ein Attributionsereignis für ein Signalintegritätsproblem auf node-02.. In diesem Schritt bleiben die drei NCCL-Ereignisse unverändert.

Anschließend wandelt das Framework die Ereignisse in pro-Node-Symptome um und führt eine pro-Node-Reinigung durch. Im bereitgestellten Beispiel behält die Xid149AndNvlinkFiltering-Regel das Signalintegritäts-Symptom bei und degradiert die Symptome der anderen Knoten. Die Gb200PriorityRootCause-Regel verringert das aktive Symptomset für den gesamten Job weiter. Schließlich erzeugt die Ergebnismapping-Funktion die Attribuierung der Hardwarefehler.

Wichtig ist, dass das System die NCCL-Berichte als „interessante“ Beweise beibehält. Obwohl sie zur Unterstützung der primären Diagnose degradiert werden, bleiben ihre ursprünglichen Quellen erhalten, sodass sie weiterhin überprüft werden können. Dieser Ansatz stellt sicher, dass die Diagnose das vollständige Bild widerspiegelt: Die Ursache ist der Hardwarefehler auf node-02, während die NCCL-Fehler als unterstützende Symptome beibehalten werden, die die verteilt auftretende Natur des Fehlers erklären.

Umgang mit Unsicherheit und Qualität

Wenn mehrere Ursachen zu den Beweismitteln passen, kann der Subdomänenbereich unklar sein. NVIDIA Attribution spiegelt diese Unsicherheit korrekt wider, anstatt unvollständige Beweise in eine endgültige Diagnose umzuwandeln. Die Qualität der Attribuierung hängt von der Qualität und Vollständigkeit der zugrunde liegenden Telemetriedaten ab.

Das System unterscheidet implizit zwischen Prätrainings- und Feinabstimmungskontexten, indem es die spezifischen Ereignisse und Logs analysiert, die mit der Arbeitslast verbunden sind. Es ist jedoch wichtig zu beachten, dass eine Modellvorführung keine unabhängig überprüfte Messung darstellt. Die Diagnose dokumentiert diese Unterscheidung, damit Teams das Vertrauensniveau der Attribuierung verstehen.

Erweiterung der Attribuierung auf Infrastruktur

Open Source NVIDIA Attribution ermöglicht es Infrastrukturteams, ein Fehlermuster einmal zu kodieren und es auf verschiedene Arbeitslasten sowie Clustern anzuwenden. Entwickler können Regeln für neue Fehlerarten hinzufügen sowie Anbindungen für ihre Scheduler und Telemetrie-Backends implementieren. Da die Erweiterungen dieselben ExecutionContext-, Observation- und Ergebnisverträge verwenden, fließen neue Integrationen in denselben Diagnoseprozess ein.

Das Attribution Blueprint dient als Referenzimplementierung, damit Praktiker die Lösung an ihre Umgebung anpassen können. Blueprints können nahe den Datenquellen jedes Clusters ausgeführt werden – entweder mit einem dedizierten Attribution Service pro Blueprint oder mit einem gemeinsamen Service für mehrere Blueprints. Es besteht Flexibilität bei der Anpassung der Bereitstellung, beispielsweise bei der Wahl einer eins-zu-eins- oder eins-zu-vielen-Konfiguration.

Fazit

NVIDIA Attribution bietet ein robustes Framework zur Diagnose von Fehlern in verteilten KI-Arbeitslasten, indem es über isolierte Knotenevents hinaus zu einer auf die Arbeitslast ausgerichteten Analyse geht. Durch das Korrelieren von Logs, Metriken und Scheduler-Zuständen mithilfe deterministischer Regeln identifiziert das System Ursachen wie Hardwarefehler, während die darauffolgenden Symptome als Beweismittel erhalten bleiben.

Teams können den Attribution Service und das Blueprint nutzen, um Einblicke in Fehlermuster zu gewinnen, gezielte Reparaturen durchzuführen und die Widerstandsfähigkeit ihrer KI-Infrastruktur zu verbessern. Egal ob es um die Analyse von NCCL-Fehlern oder Problemen mit der Signalintegrität von NVLink geht – das Tool bietet einen strukturierten Weg von Rohdaten bis hin zu handlungsorientierten Diagnosen.

Quelle: https://developer.nvidia.com/blog/diagnose-distributed-ai-workload-failures-with-nvidia-attribution