Abnahmetest für GPU-Server: Burn-in, DCGM-Diagnose und was bei der Lieferung zu prüfen ist

Was bei der Lieferung eines GPU-Servers zu prüfen ist

Ein Abnahmetest für einen GPU-Server prüft mit einem Burn-in vier Dinge, bevor der Server in Produktion geht. Bestätigen Sie zuerst seine Identität, also dass jede bestellte Karte mit der erwarteten Seriennummer, dem erwarteten VBIOS und dem erwarteten PCIe-Link vorhanden ist. Prüfen Sie dann seinen Zustand mit NVIDIAs DCGM-Diagnose, seine Leistungsaufnahme und Temperatur unter anhaltender Last und, auf Servern, deren Karten Daten austauschen, die Bandbreite zwischen den GPUs. Die Tabelle nennt jede Prüfung, ihr Werkzeug und das Abnahmekriterium.

Dokumentation von nvidia-smi und Diagnosedokumentation von DCGM 4.6, abgerufen am 10. Oktober 2026; Zeilen mit „unser Kriterium“ sind unsere Beispiele, keine Abnahmeschwellen von NVIDIA.

Wir haben kein NVIDIA-Dokument gefunden, das eine Burn-in-Dauer festlegt oder DCGM als Abnahmetest bezeichnet. Die Dokumentation von DCGM nennt unter ihren Zielen ein Werkzeug, „um den Bereitschaftsgrad eines Clusters zu beurteilen, bevor ein Workload bereitgestellt wird“, also die Frage, die ein Abnahmetest stellt.

Kartenidentität, Seriennummern und Firmware

nvidia-smi -L listet jede GPU im System mit ihrer UUID, und nvidia-smi -q liefert die Details je Karte. Die Seriennummer in dieser Ausgabe „stimmt mit der Seriennummer überein, die physisch auf jede Karte gedruckt ist“; vergleichen Sie sie also mit dem Lieferschein, bevor der Server ins Rack kommt und die Etiketten schwer zu erreichen sind. Halten Sie die VBIOS-Version, die Inforom-Versionen und mit -d GSP_FIRMWARE_VERSION die GSP-Firmware fest. Identische Karten, die zusammen gekauft wurden, sollten identische Versionen melden; klären Sie eine abweichende Karte mit dem Lieferanten, bevor Sie den Server abnehmen.

Installieren Sie vor dem Test den Treiberzweig, mit dem der Server in Produktion laufen wird; die Wahl behandelt unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen. Der mit nvidia-smi -pm gesetzte Persistence Mode „bleibt über Neustarts hinweg nicht erhalten“; starten Sie stattdessen den Persistence-Daemon nvidia-persistenced beim Booten.

Breite und Geschwindigkeit des PCIe-Links

Eine Karte, die ihren Link mit einer niedrigeren Generation oder Breite ausgehandelt hat, besteht eine schnelle Prüfung trotzdem und verliert Bandbreite, bis die Ursache gefunden ist. nvidia-smi meldet eine maximale und eine aktuelle Link-Generation und -Breite; das Maximum ist das, was „mit dieser GPU und Systemkonfiguration möglich“ ist, und die aktuellen Werte „können reduziert sein, wenn die GPU nicht genutzt wird“. Lesen Sie sie ab, während ein Test läuft, nicht auf einem Server im Leerlauf.

NVIDIA führt PCIe Gen5 für die RTX PRO 6000 Server Edition und die H200 NVL und PCIe Gen4 x16 für die L40S und die L4. Unter Last sollten die aktuellen Werte dem Maximum entsprechen, und das Maximum sollte zur Karte passen, sofern die Steckplatzspezifikation des Servers keine niedrigere Generation oder Breite angibt. Halten Sie auch „Replays Since Reset“ fest und vergleichen Sie den Wert nach dem Burn-in; ein Rollover nach vier aufeinanderfolgenden Replays „führt zu einem erneuten Training des Links“.

nvidia-smi topo -m zeigt die Verbindungen zwischen allen GPUs und NICs und ihre CPU-Affinität. Prüfen Sie, dass jede Karte an dem Prozessor hängt, den die Konfiguration vorgesehen hat. Auf H200-NVL-Karten mit Brücke zeigt nvidia-smi nvlink -s den Zustand jedes Links und nvidia-smi nvlink -e die Fehlerzähler. Was jeder Steckplatz, jeder Riser und jedes Kabel erfüllen muss, bevor die Karte eingebaut wird, behandelt unsere Checkliste zum Nachrüsten der H200 NVL.

DCGM-Diagnose: dcgmi diag, Stufen 1 bis 4

dcgmi diag -r nimmt eine Stufe von 1 bis 4 an, und jede Stufe enthält die Tests der darunterliegenden. Der Softwaretest prüft, ob CUDA-Anwendungen laufen können, und schlägt bei Seiten fehl, deren Stilllegung aussteht, sowie bei ausstehenden oder gescheiterten Row Remappings. Der Speichertest belegt standardmäßig 75 Prozent des GPU-Speichers und prüft geschriebene Muster. Der PCIe-Test prüft die Korrektheit von Peer-to-Peer-Übertragungen und lässt standardmäßig 80 Replays je GPU zu.

Diagnosedokumentation von NVIDIA DCGM, Version 4.6, abgerufen am 10. Oktober 2026; Laufzeiten, wie NVIDIA sie auf Systemen mit Hopper-GPUs gemessen hat. NVIDIAs GPU Debug Guidelines, aktualisiert am 4. Oktober 2026, geben für den langen Test etwa 30 Minuten an.

Mit -j erhalten Sie eine JSON-Ausgabe mit einem Status je Test; speichern Sie sie mit den Unterlagen des Servers. Der Exit-Code 226 bedeutet, dass die Diagnose gelaufen ist und einen Fehler gemeldet hat. NVIDIA beschreibt aktive Health Checks als invasiv, da sie „exklusiven Zugriff auf die Ziel-GPUs erfordern“; führen Sie sie also aus, bevor ein Workload eingeplant wird.

Welche Stufen laufen, hängt von der Karte ab. DCGMs Funktionstabelle nutzt NVIDIAs alte Markennamen und gibt alle Stufen nur Tesla, der Rechenzentrumslinie, die nach unserer Lesart die H200 NVL, die L40S und die L4 umfasst; Quadro-, Titan- und GeForce-Karten bekommen Stufe 1. Die Tabelle nennt keine RTX-PRO-Blackwell-Karte, und die Release Notes nehmen Modelle stattdessen über die Device-ID auf. DCGM 4.4.2 hat den Pulse Test, einen Test der Stufe 4, für „PG153 SKU 210 (devId 2bb5)“ ergänzt, die PCI-ID, die Canonicals Ubuntu-Hardwarezertifizierung für die RTX PRO 6000 Server Edition führt, und 4.5.3 hat die RTX PRO 6000 Max-Q ergänzt. Wir haben kein NVIDIA-Dokument gefunden, das angibt, welche Stufen auf der Server Edition bestehen. Seit 4.6.0 lässt -p "generic_mode=True" die Stufen 3 und 4 auf GPUs ohne SKU-spezifische Kalibrierung laufen, als Stabilitätsprüfung ohne kalibrierte Schwellwerte für Rechenleistung oder Leistungsaufnahme. Führen Sie Stufe 3 auf der gelieferten Karte mit dem aktuellen DCGM aus, Stand Oktober 2026 Version 4.7.0, und lesen Sie, welche Tests es meldet.

Zwei Tests der Stufe 3 hängen außerdem von der Einrichtung ab. Der NCCL-Test läuft nur innerhalb eines Knotens und braucht installiertes NCCL und nccl-tests, wobei DCGM_NCCL_TESTS_BIN_PATH auf die Test-Binärdateien zeigen muss, bevor der Dienst nvidia-dcgm startet; ohne die Variable überspringt DCGM den Test. Der nvbandwidth-Test läuft nur auf den GPUs, die DCGM dafür führt, darunter die L40S, „PG153 SKU 210“ und die H200 unter der Device-ID 233b, der ID, die NVIDIAs Treiberliste der H200 NVL zuordnet. Die L4 steht nicht auf dieser Liste.

Burn-in unter anhaltender Leistungsaufnahme und Temperatur

Für einen Burn-in passt von den DCGM-Tests Targeted Power. Sein Ziel ist laut NVIDIA, „eine GPU in Richtung TDP-Leistungsaufnahme zu treiben und diese während des gesamten Tests zu halten“. Er schlägt fehl, wenn er 75 Prozent des Ziels nicht erreicht, und läuft standardmäßig 120 s. NVIDIAs eigenes Beispiel verlängert ihn mit -p targeted_power.test_duration=600.0, und --iterations wiederholt eine Testsuite, um den Lauf zu verlängern. Unser Beispiel, nicht das von NVIDIA, ist ein Lauf der Stufe 3, gefolgt von mehreren Iterationen von Targeted Power mit je 600 s, damit die Lüfter im Gehäuse und der Raum einen stabilen Zustand erreichen.

Achten Sie während des Laufs auf drei Werte. Die Leistungsgrenze sollte dem Nennwert der Karte entsprechen, sofern keine niedrigere Begrenzung bestellt wurde: bis 600 W bei der RTX PRO 6000 Server Edition und der H200 NVL, 350 W bei der L40S und 72 W bei der L4. Meldet eine Karte der Server Edition eine Grenze von 450 W, läuft sie an einem Kabel oder in einem Steckplatz für 450 W, was manche Server absichtlich so vorsehen; gleichen Sie das mit der Bestellung ab, wie unser Leitfaden zu Servern, die mit der RTX PRO 6000 Server Edition kompatibel sind, erklärt. Die Clocks Event Reasons in nvidia-smi -q -d PERFORMANCE sollten weder HW Slowdown noch SW Thermal Slowdown zeigen; SW Power Cap unter Volllast bedeutet nur, dass die Karte an ihrer Leistungsgrenze arbeitet. Die Temperatur sollte unter der Slowdown Temp bleiben, die die Karte meldet, „der Temperatur, bei der die GPU-Hardware beginnt, die Takte wegen thermischer Bedingungen zu optimieren“.

Führen Sie den Burn-in im Rack durch, bei der Ansauglufttemperatur, bei der der Server arbeiten wird, nicht auf einem offenen Prüftisch. Wird ein DCGM-Test auf der Karte übersprungen oder nicht unterstützt, lassen Sie die Serving-Engine oder den Trainingsjob, den Sie einsetzen werden, für denselben Zeitraum unter einem Lastgenerator laufen und beobachten Sie dieselben Zähler.

ECC, Row Remapping und Xid-Logs nach dem Lauf

nvidia-smi führt flüchtige ECC-Zählerstände „seit dem letzten Laden des Treibers“ und aggregierte Zählerstände, die „unbegrenzt erhalten bleiben“; vergleichen Sie nach dem Burn-in also beide mit den Werten, die Sie vor dem Test festgehalten haben. nvidia-smi -q -d ECC,ROW_REMAPPER zeigt außerdem, ob ein Row Remapping aussteht, das erst nach einem GPU-Reset wirksam wird.

Durchsuchen Sie dann das Kernel-Log nach Xid-Meldungen, zum Beispiel mit journalctl -k | grep -i xid. NVIDIA definiert einen Xid als „einen Fehlerbericht des NVIDIA-Treibers, der in das Kernel-Log des Betriebssystems ausgegeben wird“. Ein sauberer Abnahmelauf sollte keinen hinterlassen. Was jeder Xid bedeutet und welche einen Reset oder einen geleerten Knoten erfordern, steht in unserem Artikel zu DCGM-Metriken und XID-Fehlern.

Bei GPUs, die wir liefern, läuft die Herstellergarantie über uns, und DOA-Geräte werden ersetzt. Schreiben Sie uns die Karte, ihre Seriennummer und die Diagnoseausgabe, wenn eine gelieferte GPU eine dieser Prüfungen nicht besteht.

Multi-GPU-Bandbreite: nvbandwidth und nccl-tests

nvbandwidth ist NVIDIAs „Werkzeug für Bandbreitenmessungen auf NVIDIA-GPUs“ und wird mit cmake . und make aus dem Quellcode gebaut. Es gibt eine Matrix in GB/s für jedes GPU-Paar aus, mit Varianten der Tests über die Copy Engine (CE) und über die Streaming-Multiprozessoren (SM); -l listet die Tests, und -t führt einen davon aus. Jedes Paar identischer Karten an identischen Links sollte vergleichbare Werte zeigen, und eine Zeile, die zurückbleibt, deutet auf einen Link oder Steckplatz hin.

nccl-tests prüfen „sowohl die Leistung als auch die Korrektheit von NCCL-Operationen“. Bauen Sie sie mit make, wobei Sie CUDA_HOME und NCCL_HOME setzen, wenn CUDA und NCCL nicht in den Standardpfaden liegen, und führen Sie dann auf einem Server mit acht GPUs all_reduce_perf -b 8 -e 128M -f 2 -g 8 im Build-Verzeichnis aus. Die Option -c legt fest, wie viele Iterationen auf korrekte Ergebnisse geprüft werden, und ihr Standardwert 1 prüft bereits jeden Lauf. Die Spalte busbw wendet bei All-Reduce den Faktor 2 × (n − 1) / n auf die Algorithmusbandbreite an, sodass sie sich „mit der Spitzenbandbreite der Hardware vergleichen lässt, unabhängig von der Zahl der verwendeten Ranks“.

H200-NVL-Karten mit Brücke tauschen Daten nach NVIDIAs Angaben über NVLink mit 900 GB/s je GPU aus, gegenüber 128 GB/s bei PCIe Gen5, beides Summen über beide Richtungen. Eine Brücke verbindet höchstens vier Karten, sodass bei acht Karten die PCIe-Strecken zwischen den NVLink-Domänen den All-Reduce-Wert begrenzen. RTX-PRO-6000-, L40S- und L4-Karten haben kein NVLink und nutzen PCIe.

Fallen die PCIe-Peer-to-Peer-Werte auf Bare Metal weit unter die übrigen, prüfen Sie die PCI-Brücken. NVIDIAs NCCL-Leitfaden schreibt, dass IO-Virtualisierung Peer-to-Peer-Verkehr „zum Root Complex der CPU umleiten kann, was zu einer erheblichen Leistungsminderung oder sogar zu einem Hängen führt“, und dass ACS aktiviert sein könnte, wo die ACSCtl-Zeilen von sudo lspci -vvv SrcValid+ zeigen. Virtuelle Maschinen benötigen ACS, deshalb gilt das nur für Bare-Metal-Hosts.

Abnahme Schritt für Schritt

1. Vergleichen Sie vor dem Einschalten die Lieferung mit der Bestellung: Gehäusemodell, Zahl und Typ der Karten, GPU-Stromkabel je Steckplatz und, falls angefordert, den Testbericht.
2. Installieren Sie den Treiberzweig für die Produktion, starten Sie nvidia-persistenced beim Booten und installieren Sie DCGM mit gesetztem DCGM_NCCL_TESTS_BIN_PATH für den Dienst nvidia-dcgm.
3. Speichern Sie nvidia-smi -q -x je Server; prüfen Sie die Seriennummern gegen die Etiketten und die Firmware-Versionen über identische Karten hinweg.
4. Prüfen Sie die Platzierung der GPUs mit nvidia-smi topo -m und auf H200-NVL-Karten mit Brücke jeden Link mit nvidia-smi nvlink -s.
5. Halten Sie ECC-Zählerstände, den Status des Row Remappers und die PCIe-Replays als Ausgangswerte fest.
6. Führen Sie dcgmi diag -r 3 -j aus und bewahren Sie die JSON-Ausgabe auf; jeder Test sollte bestehen.
7. Lassen Sie Targeted Power über einen längeren Zeitraum laufen und lesen Sie dabei Link-Generation und -Breite, Leistungsgrenze, Clocks Event Reasons und Temperaturen ab.
8. Führen Sie auf Multi-GPU-Servern nvbandwidth und all_reduce_perf aus.
9. Vergleichen Sie ECC-Zählerstände, Remappings und Replays mit den Ausgangswerten und durchsuchen Sie das Kernel-Log nach Xid-Meldungen. Bewahren Sie die Ausgaben als Ausgangswerte für das spätere Monitoring auf.

Unsere KI-Server werden vor dem Versand montiert und unter Last getestet; einen Testbericht erhalten Sie auf Wunsch. Nennen Sie uns die Karten, die Zahl der Server und die Prüfungen, die Ihr Abnahmeprotokoll verlangt, im Formular unten.

Was wir liefern

Wir bauen KI-Server auf Bestellung rund um den Workload, montiert und im Burn-in getestet. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch. Außerdem liefern wir die professionellen NVIDIA-GPUs, die diese Prüfungen abdecken, die RTX PRO 6000 Server Edition, die H200 NVL mit ihren NVLink-Brücken, die L40S und die L4, für Server, die Sie bereits betreiben, mit Herstellergarantie unter einem EU-Vertrag und auf einer Rechnung. Wir prüfen Rack, Stromversorgung und Luftstrom vor dem Angebot, und Konfiguration und Angebot folgen innerhalb eines Werktages.

FAQ