XID 154 und XID 62 bei NVIDIA-GPUs: GPU-Reset, Knoten leeren oder Server-Neustart

Was XID 154 und XID 62 bedeuten

XID 154 sagt Ihnen, was die GPU braucht, um sich von einem anderen Fehler zu erholen: nichts, einen GPU-Reset, einen Neustart des Knotens, das Leeren des Peer-to-Peer-Verkehrs oder ein Leeren mit anschließendem Reset. NVIDIAs XID-Katalog nennt ihn „GPU Recovery Action Changed“ und schreibt, er „will be seen in conjunction with other Xids and summarizes the recovery action required for other Xids“. XID 62 ist einer dieser anderen Fehler, der Halt eines internen Mikrocontrollers auf der GPU, für den der Katalog einen GPU-Reset als Sofortmaßnahme und einen Supportfall als nächsten Schritt nennt.

Der Katalog, zuletzt aktualisiert am 9. September 2026 (Release 615), zeigt eine Beispielzeile: „Xid 154 GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required)“. Der Bucket für 154 ist XID_154, definiert als „Follow XID 154 reported guidance“, und seine Maßnahme zur Untersuchung lautet „N/A Informational only regarding another Xid“. Die Spalte zu XID 154 im Katalog markiert die Codes, die ihn ab „CUDA 12.7; GPU driver R565“ auslösen, darunter 48, 62, 63, 64, 74, 94, 95 und 120.

Die Codes 13, 31, 43 und 45, die Anwendungsfehler, behandelt unser Artikel zu XID 13, 31, 43 und 45, Speicherfehler unser Leitfaden zu XID 94, 95, 48 und 63, die vollständige Liste unsere Übersicht der NVIDIA-XID-Fehlercodes. Dieser Artikel behandelt die Entscheidung nach dem Fehler: die GPU zurücksetzen, den Knoten leeren oder ihn neu starten.

Die fünf Recovery Actions und was jede von Ihnen verlangt

NVIDIA definiert die Maßnahmen in seinem Dokument zur Behandlung von GPU-Speicherfehlern und führt dieselben fünf Werte für das Feld GPU Recovery Action im nvidia-smi-Handbuch auf.

NVIDIA, nvidia-smi-Handbuch, NVIDIA XID Catalog (Namen der Werte bei XID 154) und NVIDIA, Behandlung von GPU-Speicherfehlern, „Error Recovery and Response Flags“, aktualisiert am 9. September 2026, alle gelesen am 24. Oktober 2026; die Spalte Schritt ist unsere Zusammenfassung von NVIDIAs Beschreibungen. Unsere anderen XID-Artikel verwenden die Namen aus der ersten Spalte.

Drei Details ändern, was Sie tun. Reset bedeutet nach NVIDIAs Worten „Terminate all GPU processes, reset the GPU using “nvidia-smi -r”“ und danach neue Prozesse starten. Reboot gilt für einen Fehler, der das Betriebssystem in einem inkonsistenten Zustand hinterlassen haben kann; laut nvidia-smi-Handbuch genügt ein Warmstart des Betriebssystems, ein Aus- und Einschalten der Stromversorgung ist nicht nötig. Drain P2P verlangt, Prozesse mit Peer-to-Peer-Verkehr zu beenden und den UVM-Persistenzmodus abzuschalten; danach liefert eine neue Abfrage eine der anderen Maßnahmen, und zeigt sie weiter Drain P2P, ist laut nvidia-smi-Handbuch die GPU zurückzusetzen. Drain and Reset kennzeichnet eine GPU mit verringerter Kapazität, etwa mit teilweise offline genommenem Speicher oder ausgefallenen MIG-Partitionen, auf der bestehende Arbeit, „that didn't get affected“, vor dem Reset enden darf.

NVIDIAs Katalog zeigt 0x0 für None und 0x2 für Node Reboot Required. Die Zeilen mit XID 154 in den unten beschriebenen Forumsberichten lauten „from 0x0 (None) to 0x1 (GPU Reset Required)“. Die für diesen Artikel gelesenen Seiten nennen für die beiden anderen Maßnahmen keine Hexadezimalwerte, lesen Sie also den Text in Klammern, nicht die Zahl.

Das nvidia-smi-Handbuch ergänzt, das Feld sei „not intended for determining which fault triggered recovery action“. Lesen Sie die Ursache in den XID-Zeilen des Kernel-Logs und den Schritt in der Recovery Action. Monitoring-Software liest den Wert über NVML als NVML_FI_DEV_GET_GPU_RECOVERY_ACTION. Da der Treiber bei jeder Änderung der Maßnahme einen 154 protokolliert, sagt ein Alarm auf XID 154 mit dem Text in Klammern der Bereitschaft, welche Art Wartungsfenster nötig ist, bevor sich jemand anmeldet. Die Alarmierung behandelt unser Leitfaden zum Monitoring von GPU-Servern mit DCGM.

XID 62: ein angehaltener Mikrocontroller

Der Katalog nennt XID 62 „Internal micro-controller halt (newer drivers)“, mit RESET_GPU als Sofortmaßnahme und CONTACT_SUPPORT als Maßnahme zur Untersuchung, und gibt keinen Auslösetext an. NVIDIAs GPU Debug Guidelines, aktualisiert am 4. Oktober 2026, fassen ihn mit XID 61 zusammen: „Report a GPU Issue and Reset GPU(s) reporting the XID.“ Der Katalog führt einen zweiten Halt-Code, XID 169, ebenfalls als „Internal micro-controller halt“ beschrieben, ohne Maßnahmen.

Zwei unbestätigte Nutzerberichte in NVIDIAs Entwicklerforum, eröffnet im März und Juli 2026, beschreiben XID 62 auf einer RTX PRO 6000 Blackwell Workstation Edition in einer Workstation mit zwei Karten und Treiber 595.58.03, während vLLM 0.17.1 ein Mixture-of-Experts-Modell in FP8 über zwei Karten bediente. Das gepostete Log zeigt die Zeile mit XID 62, eine GSP-Meldung, dass „PMU has halted“, und einen XID 154, der die Maßnahme auf „GPU Reset Required“ ändert; ein früherer Absturz auf derselben Karte meldete XID 120. Der Verfasser schrieb, die GPU habe sich erst nach einem vollständigen Aus- und Einschalten erholt. Ein anderer Nutzer berichtete, ein zu schwaches Netzteil in seiner eigenen Workstation habe ähnliche Abstürze verursacht und eine Begrenzung der Kartenleistung habe sie beendet. Stand 24. Oktober 2026 hat keiner der beiden Threads eine Antwort von NVIDIA, eine bestätigte Ursache oder eine korrigierte Treiberversion.

Das sind Berichte von Workstations, keine Aussagen von NVIDIA, und sie zeigen nicht, dass XID 62 für die Karte typisch ist. Sie zeigen die Reihenfolge der Arbeit: der Recovery Action folgen, die der Treiber meldet, Belege sammeln, die Stromversorgung gegen die Vorgaben des Systemherstellers prüfen und Treiber und Firmware aktualisieren, bevor Sie einen Fall eröffnen. Die Befehle zur Leistungsbegrenzung stehen in unserem Leitfaden zum Power Limit der RTX PRO 6000, GSP-Fehler wie XID 120 in unserem Artikel zu XID 119 und 120, GSP-Timeouts.

GPU-Reset mit nvidia-smi: Voraussetzungen und Grenzen

nvidia-smi -r, in Langform --gpu-reset, „can be used to clear GPU HW and SW state in situations that would otherwise require a machine reboot“, so das Handbuch. Die Bedingungen sind streng:

• Er braucht Root-Rechte.
• Keine Anwendung darf die GPU nutzen; das Handbuch nennt CUDA-Anwendungen, Grafikanwendungen und Monitoring-Anwendungen „like other instance of nvidia-smi“.
• -i wählt eine oder mehrere GPUs; „Without this option, all GPUs are reset.“
• Ist ein einzelner Reset nicht möglich, darf auch auf keiner anderen GPU im System eine Rechenanwendung laufen.
• Ab Ampere lassen sich GPUs mit NVLink-Verbindungen einzeln zurücksetzen; ohne Fabric Manager oder vor Ampere müssen verbundene GPUs im selben Befehl zurückgesetzt werden.

NVIDIA schreibt außerdem, dass ein Reset nicht in jedem Fall gelingt und „It is not recommended for production environments at this time“, und ergänzt: „If any GPU is not healthy a complete reset should be instigated by power cycling the node.“ Die GPU Debug Guidelines fügen den Fall der virtuellen Maschine hinzu: „GPU reset not supported in VMs. Restart the VM.“ Für eine per Passthrough an eine VM durchgereichte GPU ist der Neustart der VM der Reset.

Ein Reset einer GPU auf einem laufenden Server, in der Reihenfolge, der wir folgen würden:

1. Lassen Sie nvidia-bug-report.sh als Root laufen, solange der Fehlerzustand noch sichtbar ist; NVIDIAs Guidelines zählen seine Ausgabe zu dem, was eine Meldung braucht.
2. Leeren Sie den Knoten oder nehmen Sie die Last dieser GPU aus Scheduler und Load Balancer, und warten Sie, bis laufende Arbeit endet.
3. Prüfen Sie mit nvidia-smi -q -d PIDS, dass kein Prozess die GPU nutzt, und stoppen Sie Monitoring-Agenten, die sie offen halten.
4. Setzen Sie die GPU mit nvidia-smi -r -i 2 zurück, wobei 2 ihr Index ist.
5. Lesen Sie nvidia-smi -q: Die GPU Recovery Action sollte None zeigen und bei Speicherfehlern der Row Remapper Pending: No.
6. Lassen Sie dcgmi diag -r 3 auf der GPU laufen, bevor sie in den Betrieb zurückkehrt; unser Leitfaden zum Abnahmetest erklärt, welche Stufen für RTX-PRO-Karten gelten.

Scheitert der Reset oder lautet die Maßnahme Reboot, starten Sie den Knoten neu; bleibt die Karte danach fehlerhaft, schalten Sie den Server vollständig aus, wie das Handbuch sagt.

Wir liefern die RTX PRO 6000 Server Edition und bauen Server mit zwei, vier oder acht dieser Karten; nennen Sie uns Ihren Scheduler und die Zahl Ihrer Knoten, und unser Team antwortet mit einer Aufteilung, in der sich ein Knoten leeren lässt, ohne den Dienst anzuhalten.

Den Knoten leeren: Slurm und Kubernetes

Ein Reset oder Neustart verläuft nur dann ruhig, wenn keine neue Arbeit eintrifft, während Sie auf die laufenden Jobs warten. Beide verbreiteten Scheduler haben dafür einen dokumentierten Weg.

Slurm, Handbuch zu scontrol, Version 26.05, und Kubernetes, Referenz zu kubectl drain, gelesen am 24. Oktober 2026; n01 ist ein Beispielname eines Knotens.

In Slurm bedeutet scontrol update NodeName=n01 State=DRAIN mit einem Reason wie „xid 154 reset GPU 2“ laut Handbuch, dass „no new jobs may be started on this node. Existing jobs are allowed to run to completion, leaving the node in a DRAINED state once all the jobs have completed.“ Für einen Neustart setzt scontrol reboot mit ASAP das Flag DRAIN und startet den Knoten neu, sobald er leer ist; mit nextstate=DOWN „will remain in a down state after rebooting“, er kehrt also erst zurück, wenn Sie ihn geprüft haben.

In Kubernetes markiert kubectl drain den Knoten als nicht planbar und verdrängt seine Pods. Er „will not delete any daemon set-managed pods“ und bricht ab, solange solche Pods existieren, wenn --ignore-daemonsets fehlt. Monitoring-Agenten, die als DaemonSet laufen, etwa ein DCGM Exporter, bleiben also auf dem geleerten Knoten; stoppen Sie den Agenten auf dieser GPU vor nvidia-smi -r, wenn er das Gerät offen hält. Die Zustandsprüfung von NVIDIAs Device Plugin im Main-Zweig, gelesen am 24. Oktober 2026, markiert eine GPU bei kritischen XIDs als „unhealthy“, und ihr Code enthält keinen Pfad, der sie wieder als „healthy“ markiert; prüfen Sie daher nach der Reparatur in den zuteilbaren Ressourcen des Knotens, dass die GPU wieder da ist.

In einem Slurm-Cluster aus Knoten mit je acht RTX PRO 6000 Server Edition meldet GPU 5 auf Knoten n07 XID 62, dann XID 154 mit GPU Reset Required. Der Betreiber leert n07 mit einer Begründung, sammelt den Bug Report und lässt die laufenden Jobs enden. Nach dem Reset zeigt die Maßnahme None, und die Diagnose der Stufe 3 besteht, also kehrt n07 mit State=RESUME zurück. Hätte der 154 Node Reboot Required gelautet, hätte der Betreiber scontrol reboot ASAP nextstate=DOWN n07 genutzt und den Knoten erst nach der Diagnose wieder freigegeben.

Wann Wiederholungen einen Supportfall rechtfertigen

Die Maßnahme zur Untersuchung für XID 62 ist CONTACT_SUPPORT, ein Wiederauftreten auf derselben GPU oder ein Reset, der die Maßnahme nicht auf None zurückbringt, ist also ein Fall für den Hersteller. NVIDIAs Guidelines führen auf, was die Meldung braucht: Angaben zu Betriebssystem und Treiber, die wichtigsten Logmeldungen, die unternommenen Schritte, die Ausgabe von nvidia-bug-report.sh und die Logs der DCGM-Diagnose, eingereicht „to your system vendor“. Ergänzen Sie Seriennummer, Steckplatz, die eingestellte Leistungsbegrenzung und die Last zum Zeitpunkt des Fehlers.

Schließen Sie vor dem Fall aus, was Sie selbst ändern können. Vergleichen Sie den Treiber mit der aktuellen Version Ihres Zweigs, wie unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen beschreibt, und vBIOS, BIOS und BMC mit den aktuellen Versionen des Systemherstellers, wie in unserem Leitfaden zu Firmware-Updates am GPU-Server. NVIDIAs Felddiagnose ist „usually required before an RMA can be started“, und wann und wie sie läuft, sagt der Systemhersteller. Fehler, die mit der Karte den Steckplatz wechseln, deuten auf die Karte, wie der Tausch der Steckplätze in unserem Artikel zu XID 79 zeigt.

Für Karten, die Sie bei uns gekauft haben, wird die Herstellergarantie über uns abgewickelt und der Support durch das Service-Team unseres Engineering-Partners. Senden Sie uns die XID-Zeilen, die Recovery Action und die Seriennummer, und wir antworten innerhalb eines Werktages mit dem nächsten Schritt.

Was wir liefern

Wir liefern die RTX PRO 6000 Server Edition, die Max-Q und die Workstation Edition und bauen KI-Server nach Auftrag mit zwei bis acht Karten der Server Edition, vor der Lieferung montiert und getestet, mit Herstellergarantie auf jede Komponente und Ersatz bei DOA, auf einem EU-Vertrag und einer Rechnung. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch.

FAQ