Wie wir GPUs in der gesamten Databricks AI zuverlässig halten

Verteiltes GPU-Training ist in der gesamten Branche zur Routine geworden. Teams trainieren heute Foundation-Modelle, feintunen Modelle auf Frontier-Niveau, bauen große Vision-Systeme und betreiben tiefe Recommender-Netzwerke in Dimensionen, die einst nur führenden Forschungslaboren vorbehalten waren.

Der Aufbau einer GPU-Infrastruktur, die den heutigen Anforderungen gerecht wird, erfordert viele richtige Entscheidungen: das Erkennen von Fehlern, die einen Durchlauf abbrechen, das Aufdecken schleichender Leistungsminderungen, die sich nie von selbst ankündigen, das Überprüfen der Fabric-Integrität über Tausende von Verbindungen hinweg, das Planen um Hardware herum, die irgendwann ausfallen wird, und die saubere Wiederherstellung, wenn dies geschieht. Viele dieser Aspekte sind grundlegend, und die schwierigeren Probleme weiter oben im Stack hängen von ihnen ab.

Bei Databricks AI führen wir jede Woche Trainings-Workloads in massivem Umfang aus, bei denen kontinuierlich Fehler in Hardware, Fabric und Software auftreten. Diese Serie befasst sich damit, was nötig ist, um GPUs in dieser Größenordnung zuverlässig zu betreiben, beginnend mit den Grundlagen in diesem ersten Beitrag: den Fehlermodi, auf die Sie beim Betrieb von GPUs stoßen, den vielfältigen Workloads, die diese aufdecken, und dem mehrstufigen Health-Check-System, das sie abfängt. Das Training ist die anspruchsvollste Workload-Klasse und steht hier im Mittelpunkt, obwohl dieselbe Technik auch für die Inference und andere GPU-Workloads bei Databricks eingesetzt wird.

Wie GPUs unter Trainingslast ausfallen

Die meisten GPU-Ausfälle in großem Maßstab lassen sich in drei Kategorien einteilen: abgebrochene Jobs, schleichende Verlangsamungen (Silent Slowdowns) und numerische Verfälschungen. Abgebrochene Jobs sind der einfache Fall, da man sofort merkt, wenn einer auftritt. Die schwierigeren Ausfälle sind Workloads, die mit falschen Werten im Modell abgeschlossen werden oder stundenlang mit beeinträchtigter Leistung laufen, ohne dass es jemand bemerkt.

Abgebrochene Jobs. Verteilte Trainings-Jobs stürzen aus vielen Gründen ab: Eine GPU baut ab oder verliert die Verbindung zum Bus, RDMA-Fabric-Probleme, ein Hänger im I/O-System oder ein CPU-seitiger Rank, der von den anderen abweicht. Aus Sicht des Workloads äußern sich fast alle diese Probleme auf dieselbe Weise: Der Job stürzt mit der gefürchteten Meldung NCCL watchdog timeout in den Logs ab. Jeder Rank blockiert bei derselben Collective-Operation, der Watchdog bricht den Job schließlich ab und Sie starten vom letzten Checkpoint neu. Der Timeout selbst sagt jedoch fast nichts über die Ursache aus. Die Diagnose, was tatsächlich schiefgelaufen ist, erfordert oft die Rückverfolgung über Hardware-, Fabric-, Dateisystem- und Softwareschichten hinweg anhand eines Stack-Trace, der nur das Symptom zeigt.

Schleichende Verlangsamungen. Eine unbemerkt beeinträchtigte GPU kann das Training fortsetzen, wobei die Logs normal aussehen und der Loss-Wert weiterhin sinkt. Der Durchsatz wird jedoch durch die langsamste GPU gedrosselt, was Rechenleistung und Geld verschwendet. Diese Verlangsamungen resultieren aus Hardware, die in einem beeinträchtigten Zustand läuft, in dem Temperatursensoren unter dauerhafter Last auslösen, Interconnect-Verbindungen nach anhaltenden Fehlern herabgestuft werden oder die Speicherbandbreite mit zunehmenden Fehlern sinkt. Jedes dieser Probleme zeigt sich in unterschiedlichen Signalen auf Hardware-Ebene, z. B. in DCGM-Drosselungsgründen wie HW_SLOWDOWN oder HW_THERMAL_SLOWDOWN für thermische Probleme oder dem Verbindungsstatus (Link Health) für Interconnects.

Numerische Verfälschungen. Moderne GPUs verwenden Error Correction Code (ECC), um viele vorübergehende Speicherfehler ohne Unterbrechung des Trainings zu erkennen und automatisch zu korrigieren. Es können jedoch nicht alle Fehler behoben werden. Verfälschungen können im Speicher, in Interconnects, Kerneln oder Softwareschichten entstehen und sich ausbreiten, bevor sie erkannt oder eingegrenzt werden. In diesen Fällen kann das Training sofort stoppen oder mit fehlerhaften Werten fortgesetzt werden. Fehler können sich als NaN-Losses, instabile Konvergenz oder Verschlechterungen der Modellqualität äußern, die erst später entdeckt werden.

Unser Ansatz zur GPU-Zuverlässigkeit

Die Ausfallraten von GPU-Hardware können um eine Größenordnung höher sein als bei CPUs. Als vorsichtige Faustformel nehmen wir an, dass jede GPU eine jährliche Ausfallrate von 1 % aufweist. Für einen Job, der N GPUs über T Tage hinweg nutzt, beträgt die Wahrscheinlichkeit für mindestens einen Ausfall ungefähr:

Ein Job mit 256 GPUs, der 30 Tage lang läuft, hat eine Wahrscheinlichkeit von etwa 19 %, dass ein Fehler auftritt. Bei 1.024 GPUs steigt diese Wahrscheinlichkeit auf 57 %. In dieser Größenordnung sind Ausfälle während eines Durchlaufs zu erwarten und keine Ausnahme. Als Grundlage sorgen zwei technische Investitionen dafür, dass das Training trotz dieser Ausfälle zuverlässig bleibt: Belastungstests mit vielfältigen, hochmodernen Workloads, die Fehler frühzeitig aufdecken, und ein mehrstufiges Health-Check-System, das sie flottenweit abfängt.

Belastungstests der Plattform mit hochmodernen Workloads

Databricks AI führt eine Reihe anspruchsvoller Trainings-Workloads auf derselben Plattform aus, die auch von Kunden genutzt wird: Reinforcement-Learning-Training für Modelle wie KARL, agentenbasierte Codierungsmodelle, Document-Intelligence-Systeme wie das hinter PDFs in der Produktion und mehr. Dies sind keine typischen Trainings-Jobs. RL-Workloads kombinieren Training, Inference und Reward-Berechnung in engen Schleifen über viele GPUs hinweg. Agentenbasierte Codierungsmodelle führen neben dem Training rechenintensive Inference-Evaluierungen durch. Document-Intelligence-Pipelines kombinieren das Modelltraining mit intensivem bildbasiertem Laden von Daten.

Jeder dieser Workloads beansprucht die Plattform auf unterschiedliche Weise. Dadurch lassen sich betriebliche Probleme wie Fabric-Instabilitäten, thermische Hotspots und Grenzfälle bei der kollektiven Kommunikation effektiv aufdecken, bevor sie allgemeinere Produktions-Workloads beeinträchtigen.

So sah beispielsweise ein kürzlich aufgetretenes Problem aus. Ein Trainingslauf brach sieben Stunden nach dem Start mit einem NCCL-Timeout ab. Die Untersuchung ergab, dass ein einzelner InfiniBand-Port, der für RDMA-NCCL-Collectives verwendet wurde, einmal ausgefallen war und sich wieder erholt hatte. Danach trat kein Flapping mehr auf. Unsere kontinuierlichen Health-Checks überwachen das Flapping von IB-Ports, aber ein einzelnes, isoliertes Flapping deutet normalerweise nicht auf einen fehlerhaften Port hin, sodass der Schwellenwert allein dadurch nicht überschritten worden wäre.

Der Absturz hing davon ab, welcher von zwei NCCL-Timeouts zuerst ausgelöst wird. Die meisten Diskussionen über die NCCL-Konfiguration konzentrieren sich auf den PyTorch-NCCL-Watchdog-Timeout, der über init_process_group(timeout=...) konfiguriert werden kann und eine hängende Collective-Operation nach einer konfigurierbaren Dauer (normalerweise 10 Minuten) abbricht. Ein zweiter Timeout liegt tiefer im Stack und wird lange davor ausgelöst: NCCL_IB_TIMEOUT auf der InfiniBand-Transportschicht steuert, wie lange eine Verbindung auf die Erholung eines ausgefallenen Ports wartet, bevor sie getrennt wird. Der effektive Standardwert liegt unter Berücksichtigung von Wiederholungsversuchen bei etwa sieben Sekunden – viel kürzer, als den meisten Teams bewusst ist. Sobald ein einzelner Port-Ausfall dieses Zeitfenster überschreitet, ist die Verbindung unterbrochen und die Collective-Operation bereits fehlgeschlagen, unabhängig davon, wie der PyTorch-Watchdog-Timeout eingestellt ist. Bis der Watchdog den Hänger bemerkt, ist der Absturz des Laufs bereits unvermeidlich.

Das Signal, das für die Auswirkungen auf das Training entscheidend ist, ist die kumulierte Ausfallzeit, nicht die Anzahl der Flaps. Ein einziger, ausreichend langer Flap kann einen mehrtägigen Trainingslauf ebenso zum Absturz bringen wie wiederholtes Flapping über Stunden hinweg. Wir haben unsere Standardwerte für NCCL_IB_TIMEOUT angepasst, um sie widerstandsfähiger zu machen. Dasselbe Port-Down-Signal ermöglicht es uns, den Job abzubecken und von einem Checkpoint neu zu starten, ohne dass GPUs ungenutzt bleiben, bis der Watchdog auslöst. Diese Untersuchung ist eine von vielen, die in das Health-Check-System einfließen, das im weiteren Verlauf dieses Beitrags beschrieben wird.

Health-Checks über den gesamten Node-Lebenszyklus

Wir haben gpu-monitor als mehrstufigen Health-Check- und Observability-Dienst entwickelt, der auf jedem GPU-Node läuft und den gesamten Node-Lebenszyklus abdeckt. Verschiedene Kategorien von Prüfungen werden in unterschiedlichen Phasen ausgeführt, da verschiedene Fehlerbilder unter unterschiedlichen Bedingungen erkannt werden können.

Aktive Bootstrap-Prüfungen werden ausgeführt, wenn ein Node zum ersten Mal bereitgestellt wird, und erneut jedes Mal, wenn er zwischen den Workloads verschiedener Kunden bereinigt wird. Jeder Workload startet auf einem Node, der gerade die gesamte Test-Suite erfolgreich durchlaufen hat. Diese fangen deterministische Fehler ab – also Probleme, die sich im Vorfeld durch einen gezielten Test zuverlässig aufdecken lassen. Eine repräsentative Auswahl dessen, was gpu-monitor ausführt:

• Validierung von GPU-Rechengeschwindigkeit und Burn-in
• GPU-zu-GPU-Peer-Konnektivität, verifiziert für jedes Paar (NVLink- und NVSwitch-Integrität)
• Korrektheit und Bandbreite von Intra-Node-NCCL-All-Reduce
• RDMA-NIC-Bandbreite über hostlokalen Loopback
• ECC- und HBM-Speicherintegrität, einschließlich Row-Remap-Headroom
• PCIe-Topologie und Link-Integrität
• NVIDIA-DCGM-Diagnose auf Level 2

Ein Node, der eine aktive Prüfung nicht besteht, wird sofort aus der Flotte entfernt, bevor Workloads darauf ausgeführt werden. Fehlerhafte Nodes werden unter Quarantäne gestellt, zurückgesetzt und gründlich getestet, bevor sie entweder in die Flotte zurückkehren oder dauerhaft entfernt werden.

Passive kontinuierliche Prüfungen überwachen nicht-deterministische Fehlermuster aus den vorherigen Abschnitten – Fehler, die erst unter anhaltender Workload-Last auftreten. Für diese führt gpu-monitor eine zweite Ebene von Prüfungen auf jedem aktiven Node aus, wie zum Beispiel:

• NVLink-Lane-Status (jeder Ausfall einer Lane wird markiert)
• Gründe für GPU-Taktdrosselung (HW_SLOWDOWN, HW_THERMAL_SLOWDOWN, HW_POWER_BRAKE)
• Erkennung von RDMA-Fabric-Port-Ausfällen (basierend auf einem Schwellenwert für die kumulierte Ausfallzeit, nicht auf der Flap-Anzahl)
• Kritische XID-Fehler aus Kernel-Protokollen
• Nicht korrigierbare PCIe AER-Fehler
• Temperaturgradient zwischen GPU-Kern und HBM
• NVSwitch-Fehlerzustände

Nodes, bei denen Fehler bei kontinuierlichen Prüfungen auftreten, werden gesperrt (cordoned), geleert (drained) und durchlaufen denselben Quarantäneprozess wie bei Fehlern der aktiven Bootstrap-Prüfung.

Periodische aktive Multi-Node-Prüfungen validieren das Verhalten des Inter-Node-Fabrics, das kein einzelner Node für sich genommen aufdecken kann. Sie werden regelmäßig auf inaktiven Nodes zwischen Kunden-Workloads ausgeführt, um Inter-Node-Fabric-Probleme von Beeinträchtigungen einzelner Nodes zu isolieren, die bereits von der Bootstrap-Ebene erfasst werden. Da diese auf ungenutzten Nodes laufen und unterbrochen werden können, wenn Kunden-Workloads die Nodes benötigen, können sie aufwendiger sein als das, was bei der Bereitstellung in eine aktive Prüfung passt.

Die Tests selbst umfassen kollektive NCCL-Bandbreitenmessungen über Node-Gruppen hinweg, wobei die Payload-Größen von 8 Byte bis 2 GiB variieren. Unterschiedliche Payload-Größen sind wichtig, da NCCL verschiedene Codepfade auslöst. Kleine Nachrichten im KB-Bereich laufen über Low-Latency-Protokolle wie LL und LL128 und sind latenzdominiert, was die p95-Latenz zum nützlichen Erfolgskriterium macht. Mittlere Nachrichten im MB-Bereich überschreiten Schwellenwerte, bei denen NCCL die Algorithmen von Tree auf Ring umstellt. Große Nachrichten beanspruchen Chunking und Pipelining, wenn Bandbreitengrenzen erreicht werden, was BusBW (Bus-Bandbreite) zum nützlichen Erfolgskriterium macht. Hardwareprobleme treten oft nur in einem dieser Codepfade auf. Eine repräsentative Ausgabe der Bedingungen, die wir für die All-Reduce-Bandbreite in unserem Health Check prüfen:

AlgBW (Algorithmus-Bandbreite) misst den Durchsatz aus Sicht des Workloads. BusBW (Bus-Bandbreite) berücksichtigt, dass ein Kollektiv wie All-Reduce jedes Byte mehrmals über das Fabric überträgt, und spiegelt daher die tatsächliche Link-Auslastung und den Hardware-Zustand besser wider.

Zusammen verifizieren die drei Ebenen die Hardware, bevor Workloads starten, überwachen sie während der Ausführung und validieren dazwischen das übergeordnete Fabric. Wenn neue Fehlermuster auftreten, integrieren wir neue Health Checks und verteilen gpu-monitor auf die gesamte Flotte.

Fazit

GPU-Zuverlässigkeit ist ein sich selbst verstärkendes System. Neue Hardware-Generationen und Workload-Muster bringen immer wieder Fehlermuster zum Vorschein, die in die Prüfungen einfließen müssen, und jedes einzelne macht das System robuster. Dieser Beitrag hat das Fundament behandelt, auf dem alles andere aufbaut. Zukünftige Beiträge in dieser Serie bauen darauf auf und befassen sich mit der Arbeit, die das Training zuverlässig hält, wenn die Durchläufe größer werden, sich Architekturen ändern und RL-Workloads Training und Inferenz in derselben Schleife kombinieren.

Eine zuverlässige GPU-Infrastruktur in dieser Größenordnung macht die nächste Generation von KI-Produkten erst möglich. Wenn die Zuverlässigkeit von GPUs im großen Maßstab genau die Art von Problem ist, an der Sie arbeiten möchten, wir stellen ein!

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag