Defekte GPU im Multi-GPU-Server finden: Index, PCI-Bus-ID, Steckplatz und Seriennummer

Vom Alarm auf „GPU 3“ zur Karte im Gehäuse

Um eine defekte GPU in einem Server mit vier oder acht Karten zu finden, beginnen Sie mit der PCI-Bus-ID, nicht mit der GPU-Nummer. Entnehmen Sie die Bus-ID der XID-Zeile oder dem Monitoring-Alarm, ermitteln Sie mit nvidia-smi Seriennummer und UUID zu dieser Bus-ID, finden Sie mit lspci oder der Redfish-Schnittstelle des BMC den Steckplatz und bestätigen Sie ihn im Slotplan des Serverherstellers. Vergleichen Sie vor dem Ausbau die Seriennummer auf dem Etikett der Karte mit der, die nvidia-smi meldet.

Die GPU-Nummer ist die Schwachstelle, weil auf demselben Host zwei Zählweisen existieren. nvidia-smi nummeriert die GPUs in „the natural enumeration returned by the driver“, deren Reihenfolge sich laut NVIDIA von einem Start zum nächsten ändern kann. CUDA zählt nach einer eigenen Regel. Ein Dashboard, ein Job-Log und eine nvidia-smi-Ausgabe können mit „GPU 3“ also drei verschiedene Karten meinen. Die Kennungen unten haben dieses Problem nicht.

NVIDIA-Dokumentation zu nvidia-smi und CUDA Programming Guide 13.4.2 (Umgebungsvariablen, Stand 10. September 2026), gelesen am 24. Oktober 2026.

Die Bus-ID folgt dem Steckplatz, UUID und Seriennummer folgen der Karte. Wandert eine Karte in einen anderen Steckplatz, ändert sich ihre Bus-ID, die Seriennummer bleibt; genau darauf beruht der Slottausch-Test in unserem Artikel zu XID 79.

Warum „GPU 0“ in CUDA nicht GPU 0 in nvidia-smi sein muss

NVIDIAs CUDA Programming Guide definiert CUDA_DEVICE_ORDER mit zwei Werten. FASTEST_FIRST, der Standard, zählt die Geräte „from fastest to slowest using a simple heuristic“. PCI_BUS_ID zählt sie „by PCI bus ID in ascending order“. Auf einem Server mit gleichen Karten hat die Heuristik nichts, wonach sie ordnen könnte, und der Leitfaden sagt nicht, wie sie dann entscheidet. Gehen Sie also nicht davon aus, dass CUDA-Gerät 3 und nvidia-smi-Index 3 dieselbe Karte sind.

Drei Einstellungen räumen den Zweifel aus:

• setzen Sie CUDA_DEVICE_ORDER=PCI_BUS_ID in der Umgebung jedes Jobs und Dienstes, dann zählt CUDA in Bus-Reihenfolge;
• übergeben Sie in CUDA_VISIBLE_DEVICES UUIDs statt Nummern, was der Leitfaden im Format von nvidia-smi -L erlaubt;
• protokollieren Sie beim Jobstart UUID oder Bus-ID jeder GPU, damit sich ein Fehler im Job-Log später einer Karte zuordnen lässt.

Bei einer mit MIG geteilten GPU adressiert CUDA eine Instanz als MIG-<GPU-UUID>/<gi>/<ci>, also die GPU-UUID gefolgt von der ID der GPU-Instanz und der Compute-Instanz. Die defekte Hardware ist dann die übergeordnete GPU; ordnen Sie daher den UUID-Teil der GPU zu, nicht die Instanz. In einer virtuellen Maschine sind die PCI-Adressen jene, die der Hypervisor dem Gast zeigt; die Zuordnung zum Steckplatz erfolgt deshalb auf dem Host. Unser Leitfaden zur NVLink-Brücke der H200 NVL zeigt, warum CUDA_DEVICE_ORDER auch bei der Auswahl der Karten eines NVLink-Satzes zählt.

Schritt 1: die PCI-Bus-ID aus dem Alarm entnehmen

NVIDIAs XID-Dokumentation zeigt das Format in zwei Zeilen. Vor der ersten XID in einem Log steht eine Zeile mit PCI-Adresse und UUID, in NVIDIAs Beispiel NVRM: GPU at 0000:03:00: gefolgt von GPU-b850f46d-d5ea-c752-ddf3-c4453e44d3f7. Die XID-Zeile wiederholt dann die Adresse: NVRM: Xid (0000:03:00): 14 und die Fehlerdaten.

NVIDIA bezeichnet „0000:03:00“ als PCI-Express-Bus-, Geräte- und Funktions-ID und die Zeichenfolge GPU- als „a globally unique, immutable identifier for each GPU“. Durchsuchen Sie das Kernel-Log mit journalctl -k | grep 'NVRM: Xid', so wie NVIDIA empfiehlt, nach „NVRM: Xid“ zu suchen. nvidia-smi schreibt die Adresse als domain:bus:device.function in Hexadezimal, mit der Funktionsnummer am Ende; vergleichen Sie deshalb die Ziffern für Bus und Gerät.

Kam der Alarm aus dem Monitoring, nutzen Sie statt der GPU-Nummer Bus-ID oder UUID aus dem Alarm, sofern Ihr Exporter seine Metriken damit kennzeichnet. Unser Leitfaden zum Monitoring von GPU-Servern mit DCGM behandelt die XID-Felder und Alarmregeln, und die Übersicht der NVIDIA-XID-Fehlercodes sagt, was jeder Code verlangt, bevor die Karte ausgebaut wird.

Schritt 2: Bus-ID zu UUID und Seriennummer zuordnen

nvidia-smi nimmt die Bus-ID direkt an. Laut Handbuch akzeptiert -i den 0-basierten Index, „the GPU's board serial number, the GPU's UUID, or the GPU's PCI bus ID (as domain:bus:device.function in hex)“. nvidia-smi -q -i 0000:03:00.0 zeigt also den vollständigen Datensatz genau der Karte aus der XID-Zeile. Wichtig sind diese Felder:

• Serial Number: „This number matches the serial number physically printed on each board“; „a globally unique immutable alphanumeric value“.
• GPU UUID: „The globally unique immutable alphanumeric identifier of the GPU.“
• Bus Id: „PCI bus id as "domain:bus:device.function", in hex“.
• Board Part Number und GPU Part Number, nach denen der Garantiegeber fragen kann.

Für alle Karten auf einmal listet nvidia-smi -L jede GPU mit ihrer UUID, und --query-gpu mit --format=csv gibt gewählte Felder je Karte aus; nvidia-smi --help-query-gpu listet die Feldnamen, die Ihr Treiber kennt, und NVIDIAs CUDA Programming Guide nutzt nvidia-smi --query-gpu=name,pci.bus_id, um die Bus-IDs aufzulisten. Eine Einschränkung nennt das Handbuch: Die „board serial number might be shared between multiple GPUs on the same board“. Die PCIe-Karten in unseren Servern tragen je eine GPU pro Platine, die Seriennummer bezeichnet also genau eine Karte.

Aufbau der Inventartabelle, den wir vorschlagen; die Bus-IDs sind Platzhalter, keine Werte eines realen Servers.

Schritt 3: den Steckplatz zur Bus-ID finden

Drei Quellen verbinden auf dem Host eine Bus-Adresse mit einem Steckplatz. Nutzen Sie mindestens zwei und vergleichen Sie.

lspci. lspci -vmm -s 0000:3d:00.0 gibt für dieses Gerät einen Datensatz im maschinenlesbaren Format aus. Zu den Feldern gehören PhySlot, „The physical slot where the device resides (optional, Linux only)“, und NUMANode, der NUMA-Knoten, an dem das Gerät hängt. lspci -t zeichnet den Baum aus Bussen und Brücken und zeigt so, hinter welchem PCIe-Switch die Karte sitzt. PhySlot ist optional, weil die Server-Firmware den Wert liefert, und er enthält den Slotnamen der Firmware, der nicht mit der Beschriftung am Riser übereinstimmen muss.

sysfs. Die ABI-Dokumentation des Kernels beschreibt je PCI-Gerät ein Attribut label, das „the firmware given name (SMBIOS type 41 string or ACPI _DSM string) of the PCI device“ liefert. Wo der Hersteller es befüllt, ist das der lesbarste Name, den der Host bietet, zu finden unter /sys/bus/pci/devices/ und der Adresse der Karte.

Redfish über den BMC. Das PCIeDevice-Schema der DMTF (v1_23_0) gibt jedem Gerät eine SerialNumber, eine PartNumber und ein Slot-Objekt, dessen Location „part location information, including a ServiceLabel property“ enthält. Die ältere Ressource PCIeSlots ist seit v1_6_0 „deprecated in favor of the PCIeDevice schema“. Ein BMC, der diese Felder füllt, verbindet die Seriennummer aus Schritt 2 mit einer Slot-Bezeichnung, ohne dass der Server geöffnet wird; was die BMCs der Hersteller zu GPUs zeigen, steht in unserem Artikel zur Out-of-Band-Überwachung von GPUs über BMC und Redfish.

nvidia-smi kennt zwar ein Feld „Slot Number“, das Handbuch führt es aber unter Platform Info, „compute tray platform specific information“, zusammen mit Seriennummer des Chassis und Tray-Index. Es beschreibt Tray-Systeme im Rack-Maßstab, nicht die PCIe-Steckplätze eines üblichen GPU-Servers.

Wir bauen KI-Server mit 2, 4 oder 8 Karten RTX PRO 6000 Server Edition oder H200 NVL; nennen Sie uns das Servermodell und die geplante Zahl der Karten, und unser Team antwortet innerhalb eines Werktages mit einer Konfiguration.

Schritt 4: den Slotplan des Serverherstellers prüfen

Das letzte Glied ist die Dokumentation des Herstellers, denn nur sie sagt, welche Slotnummer am Gehäuse zu welchem Prozessor und Switch gehört. Dells technischer Leitfaden zum PowerEdge XE7740 (Rev. A04, April 2026) ist ein Beispiel. Er nummeriert die GPU-Steckplätze 21 bis 36, verbindet 21 bis 28 mit Prozessor 0 und 29 bis 36 mit Prozessor 1 und ordnet jeden Steckplatz einem von vier PCIe-Switches zu. Doppelt breite Karten wie die H200 NVL und die RTX PRO 6000 bestückt er in der Reihenfolge 25, 27, 29, 31, 21, 23, 33, 35.

Dell PowerEdge XE7740 Technical Guide, Rev. A04 (April 2026), Tabellen 19, 20 und 21 (Erweiterungssteckplätze, Bestückungsreihenfolge für doppelt breite GPUs, GPU-Slot-Zuordnung), gelesen am 24. Oktober 2026.

Aus einer solchen Tabelle folgen zwei Gegenproben. Der NUMA-Knoten, den lspci meldet, muss zum Prozessor des gefundenen Steckplatzes gehören; bei einem NUMA-Knoten je Sockel kann eine Karte an Knoten 1 nicht in Steckplatz 25 sitzen. Und die Karten hinter einem Switch in lspci -t müssen in Steckplätzen desselben Switches laut Tabelle stecken. In diesem Server kann „GPU 3“ in Bus-Reihenfolge nicht in einem Steckplatz mit der Nummer 3 sitzen, denn kein GPU-Steckplatz trägt diese Nummer; der Steckplatz ergibt sich aus dem Plan, nicht aus dem Index.

Schritt 5: vor dem Ausbau bestätigen

Schreiben Sie vor dem Ausschalten den erwarteten Steckplatz und die Seriennummer auf den Arbeitsauftrag. Folgen Sie dann dem Serviceablauf des Herstellers für dieses Gehäuse, mit gezogenen Netzkabeln, wo das Handbuch es verlangt, und lesen Sie das Seriennummernetikett der Karte, bevor sie den Steckplatz verlässt. Stimmen Etikett und nvidia-smi nicht überein, brechen Sie ab: Entweder stimmt die Zuordnung nicht, oder der Server wurde seit der Inventur verändert.

Bei Servern mit NVLink-Brücken kommt zuerst die Brücke ab, mit den Werkzeugen, die der Hersteller nennt; unser Artikel zu XID 74 und H200-NVL-Brücken zitiert Dells Vorgabe von zwei Ausbauwerkzeugen je Brücke. Führen Sie nach dem Tausch erneut nvidia-smi -q aus: Die neue Karte zeigt an der alten Bus-ID eine neue Seriennummer und UUID, und die Inventartabelle braucht diese Änderung.

Was Sie für den Garantiefall festhalten

NVIDIAs GPU Debug Guidelines listen, was ein Bericht über ein GPU-Problem enthalten soll, und schließen mit „Submit a ticket to your system vendor“. Die Schritte oben liefern die Angaben, die den Bericht mit einer physischen Karte verbinden.

NVIDIA GPU Debug Guidelines, GPU Node Triage, „Reporting a GPU Issue“, Stand 4. Oktober 2026, gelesen am 24. Oktober 2026; die Zeilen zu Seriennummer, Steckplatz und Teilenummern sind unsere Empfehlung.

NVIDIA ergänzt, seine Felddiagnose sei „usually required before an RMA can be started“; wann und wie sie läuft, sagt der Systemhersteller. Welcher Code einen Fall rechtfertigt, steht je Code in eigenen Artikeln: XID 119 und 120, GSP-Timeouts, ECC-Fehler und Row Remapping sowie GPU-Reset oder Neustart nach XID 154 und 62.

Die Zuordnung vom ersten Tag an führen

Am schnellsten geht die Zuordnung, wenn sie schon existiert. Sichern Sie bei der Abnahme je Server nvidia-smi -q und eine lspci-Ausgabe und füllen Sie die Inventartabelle aus Schritt 2 mit der Steckplatzspalte aus dem Herstellerplan; unser Leitfaden zum Abnahmetest gleicht an derselben Stelle die Seriennummern mit den Etiketten ab. Setzen Sie CUDA_DEVICE_ORDER=PCI_BUS_ID im Basis-Image oder in den Service-Units, versehen Sie Metriken mit UUID und Bus-ID und aktualisieren Sie die Tabelle nach jedem Kartentausch. Dann lässt sich der nächste Alarm auf „GPU 3“ aus der Tabelle zuordnen. Planen Sie neue Server, behandelt unser Leitfaden dazu, wie viele GPUs in einen Server passen, die Slotbelegung je Gehäuse; beschreiben Sie Ihre Flotte und ihre Überwachung, und wir schlagen eine Konfiguration vor.

FAQ