Wie kann KI-Infrastruktur Trainingsjobs nach einem GPU- oder Server-Ausfall automatisch wiederherstellen?

KI-Infrastruktur kann einen Trainingsjob nach einem GPU- oder Server-Ausfall automatisch wiederherstellen, indem sie vier Dinge kombiniert: zuverlässige Fehlererkennung, einen brauchbaren Checkpoint, gesunde Ersatzkapazität und einen orchestrierten Neustart. Fehlt eines davon, wird aus „automatischer Wiederherstellung" meist ein manueller Incident.

Das wichtigste Designprinzip ist, den Trainingsfortschritt zu schützen, bevor man über die Neustartgeschwindigkeit nachdenkt. Einen Job neu zu starten ist einfach. Ihn von einem bekannt guten Zustand aus neu zu starten, ohne ihn wieder auf eine defekte Karte zu setzen, ist das eigentliche operative Problem.

Was muss passieren, wenn eine GPU während des Trainings ausfällt?

Das Recovery-System muss den Ausfall erkennen, den betroffenen Job verstehen, die defekte Ressource isolieren, gesunde Kapazität finden, den Trainingszustand wiederherstellen und verifizieren, dass der neu gestartete Job normal voranschreitet.

Eine praktische Abfolge sieht so aus:

1. Ein GPU-, Prozess-, Node- oder Server-Ausfall wird erkannt.
2. Die Plattform identifiziert den Trainingsjob, der diese Ressource nutzt.
3. Die ausgefallene Karte oder der Node wird aus dem neuen Scheduling entfernt.
4. Der jüngste gültige Checkpoint wird ausgewählt.
5. Ersatzressourcen werden zugewiesen.
6. Die Trainingsprozesse starten neu.
7. Modell- und Optimizer-Zustand werden wiederhergestellt.
8. Der Job setzt an der gespeicherten Trainingsposition fort.
9. Die Plattform verifiziert, dass alle Worker gesund sind und voranschreiten.
10. Ein Reparatur-Workflow wird für die ausgefallene Hardware eröffnet.

Die Reihenfolge ist wichtig.

Bleibt die ausgefallene GPU für das Scheduling verfügbar, kann der neu gestartete Job wieder auf demselben defekten Gerät landen und erneut fehlschlagen.

Ist der Checkpoint beschädigt oder unvollständig, kann der Job neu starten, aber nicht korrekt fortfahren.

Ist die Ersatztopologie ungeeignet, läuft der Job vielleicht, aber mit schlechter Leistung.

Wiederherstellung ist daher ein koordinierter Infrastruktur-Workflow, kein einzelner „Neustart"-Knopf.

Was ist ein Trainings-Checkpoint?

Ein Trainings-Checkpoint ist eine gespeicherte Darstellung von genug Trainingszustand, um den Job später fortzusetzen.

Mindestens umfasst das oft die Modellparameter.

Für brauchbare Fehlerwiederherstellung kann das außerdem Optimizer-Zustand, Scheduler-Zustand, Trainingsschritt oder Epoche, Zufallszahlengenerator-Zustand, Gradient-Scaler-Zustand, Datenposition und weiteren frameworkspezifischen Zustand umfassen.

PyTorchs Tutorial zu fehlertolerantem verteiltem Training beschreibt den Neustart aller Prozesse nach einem Ausfall von einem gespeicherten Snapshot aus und merkt an, dass der Snapshot Modellzustand, Epochen, Optimizer-Zustand und weitere für die Kontinuität nötige zustandsbehaftete Attribute enthalten kann.

Je näher der Checkpoint am Ausfall liegt, desto weniger Arbeit geht verloren.

Das erzeugt einen Zielkonflikt.

Zu selten checkpointen, und ein Ausfall kann Stunden an Trainingsfortschritt auslöschen.

Zu häufig checkpointen, und Checkpoint-I/O kann Storage-Bandbreite verbrauchen und das Training unterbrechen.

Das richtige Intervall hängt von der Checkpoint-Größe, der Storage-Geschwindigkeit, der Ausfallrate, der Job-Dauer und davon ab, wie teuer wiederholtes Rechnen ist.

Wie sollte die Checkpoint-Frequenz gewählt werden?

Wählen Sie die Checkpoint-Frequenz, indem Sie den Checkpoint-Overhead gegen die erwarteten Kosten verlorener Rechenleistung abwägen.

Es gibt kein universelles Intervall.

Ein kurzer Entwicklungsjob braucht vielleicht kein aggressives Checkpointing.

Ein mehrtägiger verteilter Trainingslauf mit einer großen Zahl teurer Accelerator verdient meist stärkeren Schutz.

Messen Sie, wie lange ein Checkpoint dauert.

Dauert das Speichern des Zustands mehrere Minuten, ist diese Zeit Teil der Workload-Kosten.

Messen Sie, wie viele Daten geschrieben werden.

Prüfen Sie, ob gleichzeitige Checkpoints mehrerer Jobs eine Storage-Überlastung erzeugen.

Vergleichen Sie diesen Overhead dann mit dem erwarteten Verlust, falls der Job zwischen zwei Checkpoints ausfällt.

Die Operations-Plattform sollte Checkpoint-Alter und Erfolgsstatus protokollieren.

Ein Job, der „Checkpoint aktiviert" anzeigt, ist nicht geschützt, wenn sein letzter erfolgreicher Checkpoint sechs Stunden alt ist.

Das Recovery-System muss den letzten gültigen Checkpoint kennen, nicht nur das konfigurierte Checkpoint-Intervall.

Wie erkennt man einen GPU-Ausfall?

Erkennen Sie GPU-Ausfälle anhand von Kartenzustand, Prozessfehlern, Scheduler-Zustand und Workload-Symptomen zusammen.

Hardware-Signale können ECC-Ereignisse, Geräte-Resets, verlorene Geräte, PCIe- oder Fabric-Probleme, Temperaturfehler und anhaltendes Throttling umfassen.

Software-Signale können Worker-Prozessabbrüche, CUDA- oder Runtime-Fehler, Kommunikations-Timeouts und ein vom Node verschwindendes Gerät umfassen.

Die Cluster-Schicht zeigt möglicherweise, dass der Node nicht mehr verfügbar wird.

Das Trainings-Framework zeigt möglicherweise einen ausfallenden Rank.

Die Operations-Schicht sollte diese Signale zu einem Incident verknüpfen.

Ein verteilter Trainingsjob kann viele Worker umfassen. Fällt ein Rank aus, kann das die gesamte verteilte Prozessgruppe zum Stillstand bringen.

Die Infrastruktur muss daher identifizieren, welche physische Karte und welcher Server den ausgefallenen Worker beherbergt hat.

Für Erkennung und Isolation auf Kartenebene lesen Sie wie Unternehmen GPU-Zustand, ECC-Fehler, Temperatur, Stromverbrauch und degradierte Accelerator-Karten überwachen können.

Wie erkennt man einen Server-Ausfall?

Erkennen Sie Server-Ausfälle sowohl durch In-Band- als auch durch Out-of-Band-Belege.

Der In-Band-Pfad kann zeigen, dass Betriebssystem, Node-Agent oder Container-Runtime verschwinden.

Der Out-of-Band-Pfad kann zeigen, ob der Server noch Strom hat, ob ein Hardware-Alarm aufgetreten ist und ob das BMC erreichbar ist.

Diese Unterscheidung hilft der Wiederherstellung.

Ist das Betriebssystem abgestürzt, aber die Hardware gesund, lässt sich der Node möglicherweise mit einem Neustart wiederherstellen.

Meldet das BMC einen Hardware-Fehler, ist die sicherere Aktion möglicherweise, den Server zu isolieren und die Workload woandershin zu verschieben.

Verschwinden sowohl Produktions- als auch Management-Pfad, untersuchen Sie Rack-Strom, Netzwerk oder Facility-Abhängigkeiten.

Eine Job-Recovery-Engine sollte nicht annehmen, dass jedes „Node verloren"-Ereignis dieselbe Ursache hat.

Die Ursache beeinflusst, ob die Ressource in den Pool zurückkehren sollte.

Wie sollten ausgefallene Ressourcen isoliert werden?

Ausgefallene Ressourcen sollten aus dem Scheduling entfernt werden, bevor der Trainingsjob neu gestartet wird.

Das kann auf Kartenebene geschehen, wenn Scheduler und Gerätemodell es unterstützen.

In anderen Fällen muss möglicherweise der gesamte Node cordoned, gedraint oder als nicht mehr planbar markiert werden.

Verwenden Sie einen Quarantäne-Zustand, wenn der Ausfall noch nicht verstanden ist.

Der Zweck ist, wiederholte Zuweisung zu verhindern.

Ein häufiges Ausfallmuster ist:

Karte fällt aus.
Job stoppt.
Scheduler sieht den Node nach dem Reset wieder online.
Job startet auf derselben Karte neu.
Karte fällt erneut aus.

Das ist keine Fehlertoleranz. Das ist eine automatisierte Fehlerschleife.

Der Recovery-Workflow braucht eine von der Job-Neustart-Entscheidung getrennte Ressourcen-Zustandsentscheidung.

Wie hilft PyTorch-Fehlertoleranz?

PyTorch bietet elastische und fehlertolerante Tools für verteilte Ausführung, die Worker-Prozesse bei Ausfällen neu starten können.

Das torchrun-Fehlertoleranz-Tutorial beschreibt ein Modell, bei dem Fehler geloggt, Worker neu gestartet und das Training von einem gespeicherten Snapshot fortgesetzt wird.

Torch Distributed Elastic ist für fehlertolerantes und elastisches verteiltes Training konzipiert.

Das löst einen wichtigen Teil des Problems, aber die Infrastruktur drumherum zählt weiterhin.

Das Framework kann Worker neu starten.

Es repariert keine ausgefallene GPU.

Es entscheidet nicht, ob ein Server basierend auf dem BMC-Zustand unter Quarantäne gestellt werden sollte.

Es stellt nicht automatisch ein gesundes Ersatz-Rack, einen Netzwerkpfad oder einen Storage-Pfad bereit.

Es entscheidet nicht, ob das Rechenzentrum einen Hardware-Wartungsauftrag eröffnen sollte.

Framework-Fehlertoleranz und Infrastruktur-Fehlertoleranz müssen daher zusammenarbeiten.

Was, wenn der Ersatz-Cluster eine andere Anzahl an GPUs hat?

Ob ein Job mit einer anderen World Size fortgesetzt werden kann, hängt vom Framework, dem Trainingscode, dem Checkpoint-Format und dem Algorithmus ab.

Gehen Sie nicht davon aus, dass Elastizität bedeutet, dass jeder Trainingsjob die Worker-Anzahl sicher ändern kann.

Manche Workloads benötigen eine feste Anzahl an Ranks.

Andere können sich anpassen.

Änderungen bei der Datenparallelität können Batch-Größe, Annahmen zur Lernrate, Daten-Sharding und Reproduzierbarkeit beeinflussen.

Die Recovery-Plattform sollte die deklarierte Elastizitäts-Policy des Jobs kennen.

Benötigt der Job acht GPUs, weisen Sie vor dem Neustart acht gesunde GPUs zu.

Unterstützt er einen Bereich, kann der Scheduler den Job möglicherweise mit einer anderen Ressourcenanzahl fortsetzen.

Das sollte eine explizite Workload-Fähigkeit sein, keine Vermutung während eines Incidents.

Wie beeinflusst Storage die Wiederherstellung?

Storage ist Teil des Fehlertoleranzpfads, weil Checkpoints nur nützlich sind, wenn sie erfolgreich geschrieben werden und nach einem Ausfall schnell gelesen werden können.

Verfolgen Sie Checkpoint-Schreibdauer, Erfolg, Größe, Pfad und Alter.

Schützen Sie den Checkpoint-Speicher wo möglich vor derselben Fehlerdomäne wie den Compute-Node.

Liegt der einzige Checkpoint auf der lokalen Platte des ausgefallenen Servers, kann ein Serververlust sowohl Compute- als auch Recovery-Zustand entfernen.

Beobachten Sie bei verteiltem Storage Durchsatz und Latenz während der Checkpoint-Fenster.

Auch ein Recovery-Storm kann Druck erzeugen.

Wenn mehrere große Jobs nach einem Facility-Ereignis neu starten, lesen sie möglicherweise alle gleichzeitig Checkpoints.

Das kann „automatische Wiederherstellung" viel langsamer machen als erwartet.

Die Beziehung zwischen Netzwerk und Storage wird behandelt in wie RDMA, RoCE, InfiniBand, Paketverlust und Storage-Performance das KI-Training beeinflussen.

Wie sollten Ersatzressourcen ausgewählt werden?

Ersatzressourcen sollten zu den Hardware-, Speicher-, Software-, Topologie- und Zustandsanforderungen der Workload passen.

Eine freie GPU ist nicht automatisch ein gültiger Ersatz.

Prüfen Sie das Accelerator-Modell oder die kompatible Ressourcenklasse.

Prüfen Sie die Speicherkapazität.

Prüfen Sie die Treiber- und Runtime-Kompatibilität.

Prüfen Sie die Netzwerktopologie bei verteilten Jobs.

Prüfen Sie, dass die Karte gesund ist.

Prüfen Sie Mandanten-Quota und Priorität.

Prüfen Sie, ob der Checkpoint in der Zielumgebung wiederhergestellt werden kann.

Bei einem homogenen Cluster kann das unkompliziert sein.

Bei einer heterogenen Flotte werden Ressourcenklassen und Capability-Labels wichtig.

Die Recovery-Engine sollte eine kompatible Spezifikation anfordern, statt einen einzelnen Servernamen fest zu codieren.

Woher weiß man, dass der wiederhergestellte Job wirklich gesund ist?

Erklären Sie die Wiederherstellung nicht für erfolgreich, sobald der Prozess startet.

Erklären Sie sie für erfolgreich, wenn die Workload wieder brauchbaren Fortschritt macht.

Prüfen Sie, dass alle Worker beigetreten sind.

Prüfen Sie, dass der Checkpoint fehlerfrei wiederhergestellt wurde.

Prüfen Sie, dass die Trainingsschritt-Zähler voranschreiten.

Prüfen Sie, dass Loss oder andere Modellmetriken sich plausibel verhalten.

Prüfen Sie die GPU-Auslastung.

Prüfen Sie die Netzwerkkommunikation.

Prüfen Sie, dass keine neuen Hardware-Fehler auftreten.

Vergleichen Sie den fortgesetzten Job wo praktikabel mit seiner Baseline von vor dem Ausfall.

Das ist besonders wichtig nach einem Netzwerk- oder Storage-Incident. Der Job startet möglicherweise neu, während der zugrunde liegende Flaschenhals bestehen bleibt.

Ein Neustart ohne Validierung kann aus einem Incident wiederholt verschwendete Rechenleistung machen.

Was sollte für die Post-Incident-Review protokolliert werden?

Protokollieren Sie die Ausfall-Zeitleiste, betroffene Ressourcen, den letzten erfolgreichen Checkpoint, die Menge verlorener Arbeit, die Anzahl der Neustarts, Ersatzressourcen, die Wiederherstellungszeit und die Reparaturmaßnahme.

Diese Aufzeichnungen beantworten später nützliche Operations-Fragen.

Wie oft fallen Jobs wegen Hardware aus?

Welche Kartenmodelle verursachen die meisten unterbrochenen Trainingsstunden?

Wie viel Rechenleistung geht zwischen Checkpoints verloren?

Wie hoch ist die durchschnittliche Wiederherstellungszeit?

Wie oft gelingt der erste Neustart?

Werden Checkpoint-Schreibvorgänge langsamer?

Erzeugt ein bestimmtes Rack oder eine Netzwerkdomäne mehr Ausfälle?

Das macht Fehlertoleranz zu einer messbaren operativen Fähigkeit.

Was sollte automatisiert werden, und was sollte eine Genehmigung erfordern?

Automatisieren Sie Aktionen, die vorhersehbar und reversibel sind. Behalten Sie destruktive oder ungewisse Aktionen unter Policy-Kontrolle.

Einen ausgefallenen Worker zu erkennen, eine bekannt defekte Karte unter Quarantäne zu stellen, Ersatzkapazität zuzuweisen und von einem genehmigten Checkpoint neu zu starten, sind starke Kandidaten für Automatisierung.

Einen Server per Power-Cycle neu zu starten, Firmware zu ändern, die Netzwerkkonfiguration zu verändern oder einen Job mit unbekannter Ursache wiederholt neu zu versuchen, erfordert möglicherweise zusätzliche Kontrollen.

Das Quell-Betriebsmodell betont außerdem die Autorisierung für Rescheduling- und Infrastrukturaktionen.

Ein Plattform-Beispiel, das Hardware-Zustand, Scheduling, Checkpoints und Workflows verknüpft, ist Sensaka.

Würde ich automatische Trainings-Wiederherstellung entwerfen, würde ich auf ein Ergebnis optimieren: Der Ausfall einer einzelnen Karte sollte nur die Arbeit seit dem letzten gültigen Checkpoint kosten, und die ausgefallene Karte sollte keinen weiteren Produktionsjob erhalten, bevor sie die Validierung besteht. Das ist eine viel bessere Definition von Fehlertoleranz, als Prozesse einfach schnell neu zu starten.