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. Das eigentliche operative Problem ist, ihn von einem bekannt guten Zustand aus neu zu starten, ohne ihn wieder auf eine defekte Karte zu setzen.

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, startet der Job zwar neu, fährt aber nicht korrekt fort. Und ist die Ersatztopologie ungeeignet, läuft der Job vielleicht mit schlechter Leistung weiter. Wiederherstellung ist daher ein koordinierter Infrastruktur-Workflow und 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 können außerdem Optimizer-Zustand, Scheduler-Zustand, Trainingsschritt oder Epoche, Zufallszahlengenerator-Zustand, Gradient-Scaler-Zustand, Datenposition und weiterer frameworkspezifischer Zustand hinzukommen.

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, und daraus entsteht ein Zielkonflikt. Checkpointen Sie zu selten, kann ein Ausfall Stunden an Trainingsfortschritt auslöschen. Checkpointen Sie zu häufig, verbraucht die Checkpoint-I/O Storage-Bandbreite und unterbricht das Training. 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. Ein universelles Intervall gibt es dafür nicht. Ein kurzer Entwicklungsjob braucht vielleicht kein aggressives Checkpointing, während ein mehrtägiger verteilter Trainingslauf mit einer großen Zahl teurer Accelerator meist stärkeren Schutz verdient.

Messen Sie also, wie lange ein Checkpoint dauert. Dauert das Speichern des Zustands mehrere Minuten, ist diese Zeit Teil der Workload-Kosten. Messen Sie ebenso, wie viele Daten geschrieben werden, und 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 also den letzten gültigen Checkpoint kennen und 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. Auf der Hardware-Seite können das ECC-Ereignisse, Geräte-Resets, verlorene Geräte, PCIe- oder Fabric-Probleme, Temperaturfehler und anhaltendes Throttling sein. Auf der Software-Seite können Worker-Prozessabbrüche, CUDA- oder Runtime-Fehler, Kommunikations-Timeouts und ein vom Node verschwindendes Gerät dazukommen. Die Cluster-Schicht zeigt dabei möglicherweise, dass der Node nicht mehr verfügbar wird, und das Trainings-Framework einen ausfallenden Rank.

Die Operations-Schicht sollte diese Signale zu einem Incident verknüpfen. Ein verteilter Trainingsjob kann viele Worker umfassen, und 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 eher, 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 also nicht annehmen, dass jedes „Node verloren"-Ereignis dieselbe Ursache hat, denn 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 in jedem Fall, wiederholte Zuweisung zu verhindern.

Ein häufiges Ausfallmuster geht so: Die Karte fällt aus, der Job stoppt, der Scheduler sieht den Node nach dem Reset wieder online, der Job startet auf derselben Karte neu, und die Karte fällt erneut aus. Das Ergebnis ist eine automatisierte Fehlerschleife und keine Fehlertoleranz. Der Recovery-Workflow braucht deshalb eine Ressourcen-Zustandsentscheidung, die von der Job-Neustart-Entscheidung getrennt ist.

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, während die Infrastruktur drumherum weiterhin zählt. 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, und 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 und 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, und 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, und das macht die „automatische Wiederherstellung" viel langsamer 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, denn eine freie GPU ist nicht automatisch ein gültiger Ersatz. Prüfen Sie das Accelerator-Modell oder die kompatible Ressourcenklasse, die Speicherkapazität sowie die Treiber- und Runtime-Kompatibilität. Prüfen Sie bei verteilten Jobs die Netzwerktopologie, prüfen Sie, dass die Karte gesund ist, prüfen Sie Mandanten-Quota und Priorität, und 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, und 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 erst dann für erfolgreich, wenn die Workload wieder brauchbaren Fortschritt macht, und nicht schon, sobald der Prozess startet. Prüfen Sie, dass alle Worker beigetreten sind und der Checkpoint fehlerfrei wiederhergestellt wurde. Prüfen Sie, dass die Trainingsschritt-Zähler voranschreiten und Loss oder andere Modellmetriken sich plausibel verhalten. Prüfen Sie GPU-Auslastung und Netzwerkkommunikation, und 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, weil der Job möglicherweise neu startet, 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, und welche Kartenmodelle verursachen die meisten unterbrochenen Trainingsstunden? Wie viel Rechenleistung geht zwischen Checkpoints verloren, wie hoch ist die durchschnittliche Wiederherstellungszeit, und wie oft gelingt der erste Neustart? Werden Checkpoint-Schreibvorgänge langsamer, und erzeugt ein bestimmtes Rack oder eine Netzwerkdomäne mehr Ausfälle? Antworten darauf machen 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.