Fehlerbehandlung in KI-Clustern: Was wirklich ausfällt und wie Sie es wiederherstellen

Verteiltes Training ist der eine Workload, bei dem Hardwareausfälle kein seltenes Ärgernis sind – sie sind eine Betriebssteuer, die Sie laufend zahlen. Metas veröffentlichtes Post-mortem zu Llama 3.1 405B verzeichnet 419 unerwartete Unterbrechungen in 54 Tagen auf einem Cluster mit 16,384 GPUs: ein Ereignis alle drei Stunden, wobei GPU- und HBM-Fehler für rund die Hälfte verantwortlich waren. So sieht der Dauerbetrieb aus, wenn man Tausende GPUs hart fährt.

Die meisten Kentino Kunden werden solche Zahlen nie sehen. Fine-Tunes auf einem einzelnen Knoten mit 8 GPUs sind statistisch ruhig. Die Fehlerbilder, Diagnosewerkzeuge und Wiederanlaufmuster sind aber dieselben. Dieser Artikel ist der ehrliche Katalog: Was ausfällt, wie Sie es bemerken, was Sie dagegen tun – und wo sich der technische Aufwand in unserer Größenordnung tatsächlich lohnt.

Die tatsächlichen Fehlerbilder

Zwei Kategorien zählen: Hardware-Ereignisse (GPU, Netzteil, NIC oder Datenträger tun etwas Physisches) und Software-Ereignisse (CUDA, NCCL, das Framework oder das Betriebssystem reagieren schlecht auf eine Störung). Nachfolgend grob in der Reihenfolge, wie häufig das jeweilige Problem auf einer Multi-GPU-Workstation oder einem kleinen Cluster zuschlägt.

GPU-XID-Fehler

Die Kernel-Logs (dmesg, journalctl -k) sind die maßgebliche Quelle. NVIDIA gibt bei jedem GPU-Fehler eine XID-Zeile aus. Die, die Ihnen tatsächlich begegnen:

Zwei Anmerkungen aus der Praxis:

• XID 79 ist der Fehler, wegen dem Kunden in Panik anrufen. „Die GPU ist verschwunden.“ Bei einem Aufbau mit 4× oder 8× Riser ist XID 79 fast immer ein Riser-Problem, ein Stromstecker, der sich durch thermische Wechsellast gelöst hat, oder eine thermische Notabschaltung – keine defekte GPU. Neu stecken, neu verkabeln, erneut testen, bevor Sie eine RMA auslösen.
• XID 48 und 63 sind echt. ECC-Defekte nehmen bei stark genutzten Karten über Monate zu. Die GPU nimmt Speicherseiten automatisch außer Betrieb, bis ihr die Ersatzzeilen ausgehen. Danach ist die Karte für Training unsicher; die meisten Betreiber tauschen sie aus.

CUDA Out-of-Memory mitten im Lauf

Der mit Abstand häufigste Trainingsfehler auf unserer Hardware – und fast immer die Schuld des Betreibers, nicht der Hardware. Typisches Muster: Das Training läuft 200 Schritte sauber, dann stürzt es ab mit CUDA error: out of memory. Die Ursache ist meist:

1. Der Aktivierungsspeicher wächst mit der Sequenzlänge – längere Samples später in der Epoche sprengen das Budget.
2. Ein weiterer Prozess auf derselben GPU. nvidia-smi zeigt zwei PIDs; einer hätte beendet werden sollen und wurde es nicht.
3. Speicherfragmentierung. Der Caching-Allocator von PyTorch verweigert einen großen zusammenhängenden Block, obwohl genug Speicher frei ist. Abhilfe: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.

Die GPU zu verdoppeln hilft nicht. Die richtige Antwort ist eine kleinere Micro-Batch-Größe, aktiviertes Gradient Checkpointing oder ein geshardeter Optimizer (siehe K02).

NCCL-Timeouts und Netzwerkaussetzer

NCCL-Kollektive (all_reduce, all_gather, reduce_scatter) laufen über alle Ranks synchron. Bleibt ein Rank hängen – defekte NIC, überlasteter Switch, Aussetzer im Kernel-Scheduler, eine einzelne langsame GPU –, warten alle anderen Ranks am nächsten Kollektiv, und der gesamte Job blockiert. Ohne asynchrone Fehlerbehandlung bleibt der Stillstand unbemerkt; der Job scheint zu „hängen“, bis ein Watchdog-Timeout greift (standardmäßig 30 Minuten).

Die Abhilfe ist eine einzige Umgebungsvariable:

export TORCH_NCCL_ASYNC_ERROR_HANDLING=1
export TORCH_NCCL_TRACE_BUFFER_SIZE=20000  # für die Post-mortem-Analyse

PyTorch bricht dann bei einem Kollektiv mit Timeout mit SIGABRT ab. Zusammen mit torchelastic startet der Job vom letzten Checkpoint neu. Hinweis: Das ältere NCCL_ASYNC_ERROR_HANDLING ist veraltet.

Knotenausfälle und Netzteildefekte

In Multi-Node-Clustern kann ein Knoten durch einen NIC-Reset, einen flatternden Switch-Port, eine Kernel-Panic, den OOM-Killer oder ein Stromereignis ausfallen. Die Erkennung entspricht der beim NCCL-Timeout. Für Single-Node-Aufbauten mit 8 GPUs – die Mehrheit unserer Kunden – ist diese Kategorie irrelevant.

Ein defektes Netzteil ist ein harter Ausfall. Bei einem 8-GPU-Server mit zwei ATX-Netzteilen in Split-Rail-Konfigurationbedeutet ein Netzteilausfall keine Redundanz. Netzteil A versorgt GPU 0–3, Netzteil B die GPUs 4–7. Fällt Netzteil B aus, verschwinden vier GPUs innerhalb von Millisekunden mit XID 79. Die Wiederherstellung erfordert physischen Austausch. Echte Redundanz verlangt CRPS-Einheiten in 1+1-Hot-Swap – das ist ein Aufbau in Serverklasse, keine Workstation mit Consumer-GPUs.

Schreibfehler beim Checkpoint

Seltener, aber schmerzhaft. Der Job läuft zehn Stunden, erreicht einen Checkpoint, und der Schreibvorgang scheitert, weil der NFS-Server voll ist, die lokale NVMe ihr DWPD-Budget überschritten hat und in den Nur-Lese-Modus geht, ein Inode-Limit erreicht wurde oder sich Berechtigungen geändert haben. Der Schaden ist proportional zum Checkpoint-Intervall; wenn Sie es erst beim nächsten Versuch bemerken, verlieren Sie eine Stunde oder mehr.

Schleichende ECC-Defekte

Der stille Killer. Eine GPU meldet zunächst einmal pro Woche XID 92 (Single-Bit-ECC), dann täglich, dann stündlich. Jedes Ereignis gilt als „eingegrenzt“, der Job läuft weiter, aber die Genauigkeit driftet und der Trainingsverlust entwickelt eine langsame Aufwärtstendenz. Bis es jemand bemerkt, sind Hunderte Speicherseiten außer Betrieb und die Karte steuert auf XID 48 zu. Genau deshalb ist der Abschnitt zum Monitoring wichtiger als der zur Wiederherstellung.

Erkennung – worauf Sie achten sollten

Drei Ebenen: Kernel-Ebene (XID-Zeilen in dmesg), GPU-Hersteller (DCGM-Exporter nach Prometheus, dcgmi diag für aktive Prüfungen) und Framework-Ebene (PyTorch-Watchdog, NCCL-Trace-Buffer, Alarme auf Loss und Durchsatz).

Die Alarme, auf die es ankommt:

• Jede Zeile XID 48 / 63 / 79 / 92 in dmesg → sofortige Benachrichtigung
• GPU-Temperatur > 85 °C länger als 5 Minuten → sofortige Benachrichtigung
• Steigender Zähler für flüchtige ECC-Fehler → Ticket, kein Sofortalarm
• DCGM dcgm_thermal_violation ungleich null → Kühlungsproblem, Luftführung prüfen
• Trainingsverlust sinkt über >100 Schritte nicht → einen Blick wert

Beispiele echter Fehlerprotokolle

Das sehen Sie tatsächlich in journalctl -k , wenn XID 79 auslöst (RTX 5090, Riser-Kabel hatte sich durch thermische Wechsellast gelöst):

Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: Xid (PCI:0000:c1:00): 79, pid='<unknown>', name=<unknown>, GPU has fallen off the bus.
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: GPU 0000:c1:00.0: GPU is on Board .
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: A GPU crash dump has been created. If possible, please run
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: nvidia-bug-report.sh as root to collect this data before
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: the NVIDIA kernel module is unloaded.

So sieht ein NCCL-Timeout aus, gekürzt:

[E ProcessGroupNCCL.cpp:475] [Rank 3] Watchdog caught collective operation timeout:
WorkNCCL(SeqNum=842, OpType=ALLREDUCE, NumelIn=268435456, NumelOut=268435456,
Timeout(ms)=1800000) ran for 1800321 milliseconds before timing out.
[E ProcessGroupNCCL.cpp:489] [Rank 3] Some NCCL operations have failed or timed out.
terminate called after throwing an instance of 'std::runtime_error'

Rank 3 meldet es, aber Rank 3 ist fast nie das eigentliche Problem. Der langsame Rank ist der, der nicht angekommen ist. Der NCCL-Trace-Buffer gibt aus, welche Ranks bei welchem Aufruf blockiert waren – so finden Sie den wahren Verursacher.

Wiederanlaufmuster

Checkpoints so häufig, dass ein Neustart billig ist

Für ein 7B-Fine-Tuning auf 8× RTX 5090 mit Checkpoints auf lokaler NVMe: ~14 GB geschrieben mit ~3 GB/s ≈ 5 s pro Checkpoint; alle 30 Minuten sind 0.3% Overhead, und der Worst-Case-Verlust liegt bei 15 Minuten. Für einen geshardeten 70B-FSDP-Checkpoint auf derselben Box: ~140 GB parallel über 8 GPUs verteilt, vergleichbarer Overhead. Günstig – also tun.

Ein vollständiger Pretrain-Checkpoint von Llama 70B über Netzwerkspeicher umfasst ~520 GB und kann 20+ Minuten dauern; genau dort führen Häuser vom Meta-Kaliber asynchrones, gestuftes Checkpointing ein (schnell lokal schreiben, langsam auf dauerhaften Speicher abfließen lassen). In Kentino Größenordnung gilt: alle 15–30 Minuten auf lokale NVMe sichern und am Ende des Laufs auf das NAS synchronisieren. Alles Aufwendigere ist Over-Engineering.

Automatischer Neustart mit torchelastic

torchrun unterstützt elastisches Training ab Werk:

torchrun \
    --nnodes=1:1 \
    --nproc-per-node=8 \
    --max-restarts=3 \
    --rdzv-backend=c10d \
    --rdzv-endpoint=localhost:29500 \
    train.py --checkpoint-dir /mnt/nvme/ckpt

Mit TORCH_NCCL_ASYNC_ERROR_HANDLING=1lautet die Kette: NCCL-Kollektiv hängt → PyTorch-Watchdog schlägt an → Prozess bricht mit SIGABRT ab → torchelastic beendet die Geschwister-Ranks und startet neu ab latest_checkpoint.pt. Der gesamte Ablauf dauert meist 60–120 Sekunden. Kurzzeitige Aussetzer werden so überbrückt. Ein dauerhafter Defekt (GPU auf XID 79) verbraucht das Budget aus --max-restarts und dann ist ein Mensch gefragt.

Die betriebliche Praxis

Der größte Hebel auf die Ausfallkosten ist nicht der Wiederherstellungscode – es ist das, was Sie tun, bevor der Job startet.

Pre-Flight-Checks

Bevor Sie etwas starten, das länger als ein paar Stunden läuft, führen Sie die Validierungssequenz aus:

# 1. Stresstest je GPU — findet stille Thermik-/ECC-Probleme
gpu-burn 600                        # 10 Minuten pro GPU unter Volllast

# 2. DCGM-Diagnose — deckt latente Hardwarefehler auf
sudo dcgmi diag -r 3                # Stufe 3 = gründlich, ~15 Min.

# 3. NCCL-Fabric-Test — prüft die Bandbreite zwischen den GPUs der Box
mpirun -np 8 ./build/all_reduce_perf -b 8 -e 1G -f 2 -g 1

# 4. PyTorch-Trockenlauf — ein Schritt, volle Batch-Größe, alle Ranks
torchrun --nproc-per-node=8 dryrun.py

Auf einem sauberen Server mit 8× RTX 5090 sollte all_reduce_perf je nach PCIe-Topologie bei einer Busbandbreite von 50–80 GB/s landen. Deutlich darunter heißt Riser- oder Topologieproblem – das beheben Sie vor dem Training. Wir lassen gpu-burn im Rahmen der Vorversand-QA bei jedem Aufbau, der Kentino verlässt, eine volle Stunde laufen.

Achten Sie auf schleichende Lecks

Echte Codebasen sammeln Speicher an: Ein Logging-Hook hält eine Tensor-Referenz, ein Exception-Pfad vergisst, einen Puffer zu leeren, ein LR-Scheduler leakt eine Closure. Das Ergebnis ist ein OOM bei Schritt 5000 eines Laufs über 10000 Schritte. Günstigste Gegenmaßnahme: Geben Sie torch.cuda.memory_allocated() alle N Schritte im Trainingslog aus. Wenn der Wert wächst, sollte er das nicht.

Die statistische Realität in Kentino Größenordnung

Hier zahlt sich Ehrlichkeit über die Größenordnung aus. Ausfallraten skalieren mit GPU-Stunden; große Cluster fallen ständig aus, weil dort viele GPUs viele Stunden laufen.

Schätzungen kalibriert an den Meta-Daten (ein Ausfall je ~50,000 beobachtete GPU-Stunden). Die realen Zahlen schwanken je nach GPU-Modell – Consumer-Karten wie 4090 und 5090 an Risern fallen häufiger aus als L40 aus dem Rechenzentrum in ihrem nativen Chassis, vor allem durch Verschleiß an PCIe- und Stromsteckern.

Fazit: In der Größenordnung eines Einzelknotens mit 8 GPUs sollten Sie mit einem Hardware-Ereignis pro Jahr intensiver Nutzung rechnen, nicht mit einem pro Woche. Die meisten Fine-Tunes laufen durch, ohne je eines zu sehen. Kunden, die welche sehen, trainieren durchgehend – und das dominierende Fehlerbild liegt auf der Riser-/Netzteilseite, nicht im GPU-Silizium.

Was ein Neustart kostet

Die Kosten eines Neustarts bestehen aus verlorener Trainingszeit plus Diagnosezeit eines Ingenieurs. Bei einem Aufbau mit 8× RTX 5090 und sagen wir €300/Tag amortisiert kosten zusätzliche 30 Minuten €6. Die Arbeitszeit für Diagnose, erneutes Stecken eines Kabels und Neustart beträgt ein bis drei Stunden. Der Rechenverlust ist ein Rundungsfehler; die Arbeitszeit ist der Kostenblock. Genau deshalb ist die richtige Investition Monitoring und Pre-Flight, nicht exotische Wiederherstellungsinfrastruktur.

Die meisten Inhalte zum Umgang mit Ausfällen sind für die Hyperscale-Ebene geschrieben. In Kentino Größenordnung ist das Meiste davon Over-Engineering. Die 80/20-Regel lautet: Kernel-Logs überwachen, auf lokale NVMe sichern, TORCH_NCCL_ASYNC_ERROR_HANDLING=1setzen und vor großen Jobs gpu-burn laufen lassen.

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Kommentare und Korrekturen willkommen unter info@kentino.com.