Defekter VRAM: GPU am KI-Server prüfen

Q: Reicht nvidia-smi ohne DCGM?

nvidia-smi -q zeigt Zähler und Remap-Flags. Es schreibt keine Testmuster. Ohne ECC-Felder bleibt das Plugin der aktive Test.

Q: Wohin mit dem Bug-Report?

nvidia-bug-report.log.gz an NVIDIA oder den Hardware-Vendor, je nach Verdacht in der Xid-Tabelle (Driver vs. Hardware).

TL;DR

Defekter VRAM ist ein Hardwarefehler im Grafikspeicher, kein zu kleines Modell. Unter Linux stehen die Meldungen im Kernel-Log: grep nach NVRM: Xid. Xid 48 ist ein Double-Bit-ECC-Fehler; zum Löschen verlangt der Katalog GPU-Reset oder Node-Reboot. nvidia-smi -q listet ECC-Zähler und, ab Ampere, Row-Remap-Statistiken. Aktive Prüfung: dcgmi diag -r memory -p "memory.is_allowed=True". Gelesen in der NVIDIA-Doku am 2026-10-19. Kein Anbieter-Ranking.

Was die Query meint — und was nicht

IT-Leiter suchen „defekter VRAM“, wenn Artefakte, CUDA-Abstürze oder steigende ECC-Zähler den KI-Server unsicher machen — nicht, wenn das Modell nicht in den Speicher passt. Zu wenig VRAM bleibt VRAM erhöhen. Was VRAM überhaupt ist: Video RAM vs. VRAM. Ob nvidia-smi überhaupt antwortet: NVIDIA-Treiber CUDA Ubuntu.

Xid-Meldungen sind Treiberberichte an das Kernel-Log. NVIDIA schreibt: Ursache kann falsche GPU-Programmierung, korrupte Kommandos, Hardware, NVIDIA-Software oder die Anwendung sein. Ein Xid ist also kein automatisches RMA.

Kernel-Log: NVRM Xid

Unter Linux landet der Text im Kernel-Puffer, typisch in Journal, /var/log/messages oder /var/log/syslog. Die Doku:

grep "NVRM: Xid" /var/log/syslog

Beispiel aus der Xid-Seite:

[...] NVRM: GPU at 0000:03:00: GPU-b850f46d-d5ea-c752-ddf3-c4453e44d3f7
[...] NVRM: Xid (0000:03:00): 14, Channel 00000001

Die erste Zeile trägt die GPU-GUID. Danach: PCI-Adresse, Xid-Code, code-spezifische Daten. Code 14 ist nur das Beispiel der Doku, kein VRAM-Befund. Den Code nach dem Doppelpunkt in den Xid-Katalog legen.

Xid	Bezeichnung laut Katalog / Memory-Doku	Sofort laut Katalog
48	Double Bit ECC (`ROBUST_CHANNEL_GPU_ECC_DBE`)	Reset laut Workflow; `nvidia-smi` für ECC-Zähler
63	Memory remapping event (InfoROM)	IGNORE
64	Memory remapping failure	RESET_GPU, CONTACT_SUPPORT
92	High single-bit ECC error rate	IGNORE, investigatory CONTACT_SUPPORT
94	Contained memory error (ab A100)	RESTART_APP
95	Uncontained memory error (ab A100)	RESET_GPU
140	ECC unrecovered error	RESET_GPU, CONTACT_SUPPORT

Xid 171 ergänzt 48 um DRAM, Xid 172 um SRAM. Xid 160 heißt in der Memory-Doku: Speicher ist zur Reparatur markiert. Kein Code in dieser Tabelle ist ein Kaufargument.

Bei vermuteter Hardware: Hardware-Vendor und dessen Diagnose. Bei vermutetem Treiber: sudo nvidia-bug-report.sh, Ausgabe nvidia-bug-report.log.gz. Die Doku erlaubt bis zu einer Stunde; bei Hänger --safe-mode --extra-system-data.

nvidia-smi -q: Zähler, nicht Muster

nvidia-smi kommt mit dem Treiber. Die Xid-Seite: ECC-Zähler (zu Xid 48), abgefallenes Stromkabel (Xid 54), Recovery Action (Xid 154). Grundausgabe:

nvidia-smi -q

Die Memory-Error-Doku listet in NVML/nvidia-smi für Ampere und später:

Anzahl remapped rows, korrekturfähig und unkorrigierbar — das sind InfoROM-Einträge, nicht zwingend schon in Hardware umgeschriebene Zeilen
Boolean Row remapping pending
Boolean Row remapping failure

Pending braucht laut Row-Remapping-Seite einen GPU-Reset, bevor die Reparatur greift. Failure (Xid 64) ist Kontakt zum Support, kein „einfach weiterrechnen“.

Fehlen ECC-Felder oder stehen sie auf N/A, liefert diese Karte keine ECC-Zähler. Dann bleiben Xid-Log und das DCGM-Memory-Plugin. Das ist keine Bewertung der Karte, nur die sichtbare Statistik.

Gebrauchte Consumer-GPUs ohne diese Zähler: Testlauf vor dem Dauerbetrieb, siehe RTX 3090 gebraucht.

Row-Remap (Ampere+) und Page Retirement (älter)

Ab Ampere ersetzt Row-Remapping das ältere Page Retirement. Spare Rows sitzen in jeder DRAM-Bank. Software sieht danach keine Löcher in der Adresse. Die Umschreibung bleibt über die Lebensdauer der GPU.

Merkmal	Page Retirement (älter)	Row-Remapping (Ampere und später)
Kapazität Framebuffer	höchstens 64 Retirements	bis 512 Remappings
Rücknahme	Retirement bleibt	korrekturfähige Remaps können weichen, wenn Reserve-Zeilen der Bank leer sind
Wirksamkeit	Modul-Reload, Driver-Reinit oder GPU-Reset	GPU-Reset Pflicht

RMA-Schwellen stehen in einer eigenen NVIDIA-Policy; hier stehen sie nicht. Die Tabelle ist Kapazität, kein Austauschauftrag.

DCGM Memory-Plugin: Muster schreiben und lesen

DCGM-Diagnose prüft GPU-Gesundheit inklusive ECC, PCIe, Bandbreite und CUDA-Läufe. Das Memory-Plugin ist der Speicher-Selbsttest.

Default memory.is_allowed ist false, wenn keine GPU-Config greift. Deshalb den Parameter setzen. Default-Allokation: 75 Prozent des GPU-Speichers. Fünf Muster: 0x00, 0xAA, 0x55, 0xFF, 0x00. CUDA-Kernel schreiben, zurücklesen, vergleichen.

dcgmi diag -r memory -p "memory.is_allowed=True"

L1-Cache zusätzlich (l1_is_allowed=True) nur bei Compute Capability 7.0 oder höher und L1 höchstens 256 KB je SM. Download und Doku: developer.nvidia.com/dcgm.

Fehlercodes der Plugin-Doku:

Code	Bedeutung
`DCGM_FR_MEMORY_ALLOC`	Mindestanteil ließ sich nicht allokieren
`DCGM_FR_MEMORY_MISMATCH`	Geschriebenes und Gelesenes weichen ab
`DCGM_FR_CUDA_DBE`	unkorrigierbarer Double-Bit-ECC in CUDA
`DCGM_FR_L1TAG_MISCOMPARE`	L1-Cache-Test findet Korruption

Mismatch oder DBE ist ein Speicherbefund, kein Modell-OOM. OOM beim Start bleibt VRAM erhöhen.

75 Prozent Allokation braucht freien VRAM. Laufende Inferenz (Ollama, vLLM) vorher beenden, sonst schlägt schon die Allokation fehl — das ist kein Defekt.

Typische Brüche

CUDA out of memory, sauberes Log. Speicher zu klein oder Fragment, nicht defekt. Quantisierung, kleineres Modell oder andere GPU: VRAM-Rechner.

Xid 48, Zähler steigen. Unkorrigierbarer ECC. Katalog: Reset. Danach nvidia-smi -q und Memory-Plugin. Bleibt 48 nach Reset, Vendor.

Xid 63 ohne 64. Remap-Eintrag in der InfoROM. Reset, wenn das Wartungsfenster es zulässt, damit Pending wirksam wird.

Xid 64 oder Remapping Failure. Katalog: CONTACT_SUPPORT. Kein Dauerbetrieb „bis es wieder geht“.

Xid 94 vs. 95. 94: eine Anwendung, neu starten, Reset später. 95: mehrere Anwendungen, GPU-Reset vor dem nächsten Start.

Plugin-Allokation schlägt fehl. GPU nicht frei oder Anteil zu hoch. Zuerst Workloads stoppen, erst dann max_free_memory_mb aus der Plugin-Doku setzen.

Kein Xid, aber schiefe Antworten. Das Log allein beweist keinen Defekt. Memory-Plugin und, bei ECC-Karten, die Zähler. Dauerbeobachtung ist Monitoring, nicht dieser Test: Ollama Monitoring.

FAQ

Ist jedes Xid ein defekter VRAM?

Nein. NVIDIA nennt Hardware, Treiber, Anwendung und korrupte Kommandos. Erst Katalog plus nvidia-smi -q plus Memory-Plugin trennen Speicher von Software.

Reicht nvidia-smi ohne DCGM?

nvidia-smi -q zeigt Zähler und Remap-Flags. Es schreibt keine Testmuster. Ohne ECC-Felder bleibt das Plugin der aktive Test.

Muss ich nach Xid 63 sofort tauschen?

Der Katalog setzt Immediate Action auf IGNORE. Der Eintrag liegt in der InfoROM. Wirksamkeit nach GPU-Reset. Tausch folgt der Vendor-Diagnose, nicht diesem Xid allein.

Was ist der Unterschied zu zu wenig VRAM?

Zu wenig: Allokation scheitert, Modell passt nicht. Defekt: Muster stimmen nicht, Double-Bit-ECC, Remap-Failure, Xid 48/94/95 nach Katalog. Kauf und Größe bleiben der KI-Server Hardware-Guide.

Wohin mit dem Bug-Report?

nvidia-bug-report.log.gz an NVIDIA oder den Hardware-Vendor, je nach Verdacht in der Xid-Tabelle (Driver vs. Hardware).

Fazit

„Defekter VRAM“ prüft man am KI-Server in drei Schritten: Kernel-Log auf NVRM: Xid, nvidia-smi -q auf ECC und Remap, DCGM Memory-Plugin auf Muster. Ampere repaired per Row-Remap nach Reset, ältere Karten per Page Retirement. Kein zweiter Hardware-Kaufguide, keine Preisliste.