NVIDIA RTX PRO 6000 Blackwell Max-Q in VMs: Passthrough, MIG und warum es kein vGPU gibt

Was NVIDIA für die Max-Q in virtuellen Maschinen unterstützt

Die NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition läuft in einer virtuellen Maschine nur als ganze Karte, die per Passthrough einem Gast zugewiesen ist. NVIDIA führt sie nicht für vGPU, sie hat also keine Time-sliced- oder MIG-basierten vGPU-Profile; NVIDIAs MIG-Leitfaden erlaubt einem Linux-Gast, eine durchgereichte Karte für seine eigenen Container in MIG-Instanzen zu teilen. Für mehrere VMs je Karte, vGPU auf vSphere oder Support für NVIDIA AI Enterprise ist die RTX PRO 6000 Blackwell Server Edition die Edition, die NVIDIA führt.

NVIDIAs Liste der von vGPU-Software unterstützten GPUs (aktualisiert am 2. Oktober 2026), NVIDIA vGPU Product Support Matrices für vSphere, RHEL mit KVM und Ubuntu (29. September 2026), NVIDIA MIG User Guide (13. Oktober 2026), Support-Matrix NVIDIA AI Enterprise 8.2, NVIDIAs Seite zur RTX PRO 6000-Familie; alles gelesen am 24. Oktober 2026.

Die Serverhersteller ziehen dieselbe Grenze. Lenovos Produktleitfaden LP2364 zur Max-Q, aktualisiert am 8. Mai 2026, nennt als „vGPU software support“ „No support“ und vermerkt, dass Lenovo die Teilenummern für NVIDIA vGPU Software entfernt hat, weil die GPU keine vGPUs unterstützt. Als Option führt er die Karte nur für zwei Server, die ThinkSystem SR655 V3 und SR665 V3. Die drei Editionen nebeneinander zeigt unser Vergleich von RTX PRO 6000 Server, Workstation und Max-Q.

Passthrough der ganzen Karte unter KVM und Proxmox

Beim Passthrough übergibt der Hypervisor das ganze PCIe-Gerät an eine VM, unter KVM über den VFIO-Treiber, und der Gast lädt den normalen NVIDIA-Treiber wie auf Bare Metal. Der Gast sieht alle 96 GB, die volle Rechenleistung und, falls eingeschaltet, die vier DisplayPort-Ausgänge. Geteilt wird nichts: eine Karte, eine VM; ein Host mit vier Max-Q betreibt höchstens vier GPU-VMs, oder weniger, wenn eine VM zwei oder vier Karten für ein verteiltes Modell bekommt.

NVIDIAs eigene Dokumente sagen zu diesem Fall wenig. Eine NVIDIA-Seite, die einen Hypervisor als unterstützt für das Passthrough dieser Edition nennt, haben wir nicht gefunden. Die Seite „Supported Configurations“ im MIG User Guide nennt für MIG-fähige GPUs „GPU pass-through virtualization to Linux guests on top of supported hypervisors“, und ihre GPU-Tabelle führt die „RTX PRO 6000 Blackwell Max-Q Workstation Edition“ mit vier Instanzen. In der Praxis stützt sich das Passthrough der Max-Q auf die PCIe-Durchreichung des Hypervisors, ohne Support-Matrix von NVIDIA.

Aus den weiter unten genannten Quellen folgen drei praktische Punkte.

• Eine VM je Karte, passend zum Modell. Eine VM, die ein 70B-Modell in FP8 auf einer Karte bereitstellt, braucht ohnehin die ganzen 96 GB. Nach unserer Regel für Nutzer je Karte bleiben auf einer Karte 83,0 GiB für Gewichte und Cache (0,9 × 95,6 GiB − 3 GiB), genug für 12 Gespräche mit 8.192 Token bei Llama 3.3 70B in FP8.
• Mehrere Karten in einer VM. Eine VM mit zwei oder vier Karten für Tensor-Parallelismus verliert einen Teil des Peer-to-Peer-Pfads. NVIDIAs NCCL-Leitfaden zur Fehlersuche hält fest, dass virtuelle Maschinen ACS brauchen und das Abschalten von ACS deshalb keine Option ist; ACS kann den Verkehr zwischen GPUs über den Prozessor leiten. Unser Leitfaden zu P2P, IOMMU und ACS unter Linux zeigt, wie Sie messen, was davon übrig bleibt.
• Keine Live-Migration. Eine durchgereichte Karte ist an ihren Host gebunden; Wartung am Host heißt, die VM herunterzufahren. Auf vSphere erlaubt Broadcoms Knowledge-Base-Artikel 428701 Snapshots von Passthrough-VMs nur im ausgeschalteten Zustand.

Welche Edition und wie viele Karten zu Ihren virtuellen Maschinen passen, hängt vom Hypervisor und von der Zahl der VMs je Karte ab; schicken Sie uns Ihren Hypervisor und die geplanten VMs, und unser Team antwortet mit Edition und Konfiguration.

Reset-Probleme mit mehreren Karten unter Proxmox und KVM

Der ausführlichste öffentliche Bericht ist ein Thread im Proxmox-Supportforum mit dem Titel „Passthrough RTX 6000/5090 CPU Soft BUG lockup, D3cold to D0, after guest shutdown“. Er begann am 13. Juli 2025 und umfasst 57 Beiträge, der letzte vom Dezember 2025. Die Hosts darin trugen zwei bis acht Karten; ein Nutzer betrieb drei Knoten mit je acht Karten.

Die gemeldeten Symptome sind einheitlich. Nach dem Herunterfahren eines Gasts meldet der Kernel des Hosts Soft Lockups, während er die Karte aus dem Energiezustand D3cold zurückholen will, schreibt Zeilen wie „vfio-pci ... not ready 32767ms after FLR; waiting“ ins Log und friert in manchen Fällen ein. Ein Nutzer mit acht Karten je Host sah Karten nach einigen VM-Neustarts vom Host verschwinden, jedes Mal eine andere. Nutzer mit der Max-Q beschrieben sie als die am stärksten betroffene Edition: Einer berichtete, dass eine udev-Regel 600-W-Karten reparierte, die Max-Q aber nicht, und ersetzte seine Max-Q später durch 600-W-Karten. Ein anderer sah Abstürze der Max-Q auf zwei älteren Workstations mit zwei Xeon-Prozessoren und auf einem Threadripper-Board, nicht aber auf einem älteren Intel-Desktop-Board.

Auch die Server Edition ist beim Passthrough nicht frei von Problemen. Im selben Thread berichtete ein Nutzer mit acht Server Edition zu 600 W je Knoten von Gästen, deren BARs nie gemappt wurden, und veröffentlichte die VM-Einstellungen, die er danach empfahl, darunter ein größeres 64-Bit-PCI-Fenster. Laut einem Nutzer hatte NVIDIA den Bericht „an die Entwickler“ weitergegeben; weder NVIDIA noch Proxmox-Mitarbeiter veröffentlichten im Thread eine Lösung. Es handelt sich um Berichte einzelner Systeme, nicht um Messungen, und sie stammen von Proxmox-Kerneln 6.14 bis 6.18 aus der zweiten Jahreshälfte 2025.

Gemeldete Workarounds und was sie ändern

Nutzer im Thread meldeten diese Änderungen; jede half auf einigen Systemen und auf anderen nicht.

Thread im Proxmox-Supportforum „Passthrough RTX 6000/5090 CPU Soft BUG lockup, D3cold to D0, after guest shutdown“, Beiträge von Juli bis Dezember 2025, gelesen am 24. Oktober 2026. Ergebnisse wie von Nutzern einzelner Systeme gemeldet.

Jede Änderung hat ihren Preis. Hält man die Karte aus D3cold und Idle-D3 heraus, erreicht sie diese Stromsparzustände nicht mehr, solange keine VM sie nutzt; ein Host im Leerlauf nimmt also mehr Leistung auf, nach unserem Verständnis der Einstellungen. Ein neuerer Kernel als der Ihrer Proxmox- oder RHEL-Version bringt den Host aus der vom Hersteller getesteten Konfiguration. Abgeschaltetes Kernel-Modesetting im Gast passt zu Compute-VMs und kostet die grafische Konsole des Gasts auf dieser Karte. Firmware-Updates kommen von NVIDIA oder vom Serverhersteller; bringen Sie alle Karten eines Hosts auf denselben Stand.

Testen Sie auf einem neuen Max-Q-Host vor dem Produktivbetrieb genau den Zyklus, der den Fehler auslöst: jede VM mit belasteten Karten viele Male hintereinander starten und herunterfahren und das Host-Log auf FLR- und D3cold-Meldungen prüfen. Ein Host, der diesen Zyklus bei der Abnahme übersteht, braucht dieselbe Prüfung nach jedem Kernel- oder Treiber-Update. Unser Leitfaden zu Burn-in und Abnahmetest beschreibt den Rest der Abnahme.

MIG auf dem Host oder im Gast

Die Max-Q unterstützt MIG mit bis zu vier Instanzen: NVIDIAs Datenblatt nennt 4 × 24 GB, 2 × 48 GB oder 1 × 96 GB. Wie unser Leitfaden zum Einrichten von MIG auf RTX PRO Blackwell erklärt, braucht MIG auf der RTX PRO 6000 Linux, Treiber 575.51.03 oder neuer, aktuelle Karten-Firmware und die Umstellung der Karte in den Compute-Modus mit NVIDIAs DisplayModeSelector, der die Displayausgänge abschaltet.

Es gibt zwei Orte, an denen Sie MIG nutzen können.

1. Auf einem Linux-Host ohne Virtualisierung. Der Host teilt jede Karte in Instanzen und weist sie Containern oder Kubernetes-Pods zu, im MIG-Leitfaden als „Bare-metal, including containers and MIG with Kubernetes“ geführt. So bekommen vier Teams je einen Slice zu 24 GB ohne virtuelle Maschinen. Unser Artikel zum GPU-Sharing in Kubernetes behandelt das Scheduling.
2. In einer VM mit Passthrough. NVIDIAs MIG-Leitfaden hält fest, dass Linux-Gäste auf unterstützten Hypervisoren mit der GPU im Passthrough dieselben Abläufe, Werkzeuge und Profile wie auf Bare Metal nutzen können. Die VM besitzt die ganze Karte und teilt sie für ihre eigenen Arbeitslasten.

Was MIG auf der Max-Q nicht kann: ihre Instanzen auf verschiedene virtuelle Maschinen verteilen. Die Virtualisierungsseite des MIG-Leitfadens nennt MIG-basierte vGPU als den Weg, mehrere VMs parallel auf einer MIG-GPU zu betreiben, und die Max-Q hat keinen vGPU-Support. Eine VM je 24-GB-Slice wie auf der Server Edition braucht vGPU. Die vier Instanzen und ihre Engines stehen in unserem Leitfaden zu den MIG-Profilen der RTX PRO 6000.

Wann Sie die RTX PRO 6000 Server Edition brauchen

Die Max-Q ist eine Workstation-Karte. Laut NVIDIA ermöglicht sie „bis zu vier GPUs in einem einzigen System“, und die Server Edition der Familie beschreibt NVIDIA als „für Multi-GPU-Server mit passiver Kühlung“ ausgelegt. Für virtuelle Maschinen sprechen fünf Anforderungen für die Server Edition.

• Mehrere VMs je Karte. NVIDIA führt für die Server Edition Time-sliced- und MIG-basierte vGPU-Typen, bis zu vier MIG-Slices zu 24 GB und 12 Compute-VMs zu 8 GB je Karte, wie unser Leitfaden zu den vGPU-Profilen der RTX PRO 6000 Server Edition zeigt.
• VMware vSphere mit vGPU. NVIDIAs vSphere-Matrix führt die Server Edition für VCF 9.1, VCF 9.0.1 oder neuer und ESXi 8.0 ab Update 3g; die Max-Q steht nicht darin.
• Support für NVIDIA AI Enterprise. Die Support-Matrix 8.2 führt unter ihren diskreten Blackwell-GPUs die RTX PRO 6000 Blackwell Server Edition und die RTX PRO 4500 Blackwell Server Edition in Servern aus NVIDIAs Liste zertifizierter Systeme; die Max-Q fehlt.
• Ein langes Supportfenster. Die Server Edition steht auf vGPU 19, dem Zweig mit Langzeitsupport, den NVIDIA bis Juli 2028 unterstützt.
• Ein Rack-Server im Dauerbetrieb. Für den Dauerbetrieb im Rack empfehlen wir die Server Edition. Viele Serverhersteller führen die Max-Q für ihre GPU-Server nicht: In einem dichten Gehäuse liegt die Ansaugöffnung jedes Radiallüfters an der nächsten Karte, und der Luftstrom ist für passive Karten ausgelegt; unsere Checkliste zur Max-Q im Rack-Server geht die Fälle durch, in denen ein Hersteller sie doch führt.

Die Max-Q bleibt eine gute Wahl, wo eine Workstation oder eine VM jede Karte für sich hat: eine Maschine am Arbeitsplatz mit zwei bis vier Karten für ein Team, ein Labor-Host, auf dem die VM jedes Forschers eine ganze Karte bekommt, oder ein Linux-Rechner ohne Virtualisierung, der Karten per MIG zwischen Containern aufteilt. Unsere Seiten zu zwei Max-Q in einer Workstation und vier in einer Workstation legen diese Systeme aus.

Wir liefern die RTX PRO 6000 in allen drei Editionen, als Karten oder in Workstations und Servern, die wir auf Bestellung bauen, und die Server Edition mit Lizenzen für vGPU oder NVIDIA AI Enterprise im selben Angebot. Nennen Sie uns, wie viele VMs sich jede Karte teilen, und wir sagen vor der Bestellung, welche Edition passt.

Lizenzen für Passthrough, MIG und vGPU

Die Lizenzierung folgt der Edition. Die Max-Q hat keine vGPU-Profile, vGPU-Lizenzen betreffen ihre virtuellen Maschinen also nicht. Für die Server Edition ordnet NVIDIAs Client Licensing User Guide vGPUs der Q-Serie RTX vWS zu, die der B-Serie vPC oder vWS und die der A-Serie vApps, und hält fest, dass eine physische GPU im Passthrough unter Linux eine vWS-Lizenz braucht. Compute-vGPUs erfordern NVIDIA AI Enterprise, das NVIDIA je GPU lizenziert. Unsere Seite zu NVIDIA AI Enterprise und vGPU-Lizenzen nennt die Editionen, die wir liefern.

FAQ