GPU-Server im vSphere-8- oder VCF-9-Cluster: Host-Versionen, Kompatibilität, Lizenz, CPUs

Was ein GPU-Host braucht, bevor er in den Cluster kommt

Ein GPU-Server kommt wie jeder andere Host in einen vSphere-8- oder VCF-9-Cluster, wenn er drei Bedingungen erfüllt: eine ESX-Version, die NVIDIA für die Karte führt (für die RTX PRO 6000 und RTX PRO 4500 Blackwell Server Edition ESXi 8.0 Update 3g oder neuer, VCF 9.0.1 oder neuer oder VCF 9.1), für NVIDIA vGPU die vSphere-Foundation-Edition oder eine Enterprise-Plus-Lizenz und den NVIDIA vGPU Manager eines aktuellen Branches. Die VMware-Lizenz bestimmen dann die Prozessoren, weil Broadcom die CPU-Kerne je Host zählt; GPUs zählen nicht mit.

Dieser Artikel behandelt die Host-Seite: Versionen, Listen, Lizenzen und den Platz der GPU-Hosts im Cluster. Wie eine VM ihre GPU bekommt, per Passthrough oder vGPU, mit vMotion und DRS für beide Wege, steht in unserem Leitfaden zu GPUs in VMware vSphere, der vollständige Private-AI-Stack auf VCF in VMware Private AI Foundation with NVIDIA.

Anforderungen mit Stand Oktober 2026. NVIDIA vGPU Product Support Matrix für VMware vSphere (29. September 2026), NVIDIAs vGPU-Release-Tabelle, Support-Matrix NVIDIA AI Enterprise 8.2 (2. September 2026), Broadcoms Hardware­anforderungen für ESX 9.0 (19. Oktober 2026) und KB 313548, alle gelesen am 24. Oktober 2026; CVE-Stand nach NVIDIAs Security Bulletin vom 30. September 2026, wie in unserem Leitfaden zu den Treiber-Branches zitiert.

ESX-Versionen je Karte

NVIDIAs Support-Matrix führt für vSphere drei Hypervisor-Zeilen: VCF 9.1, VCF 9.0 und ESXi 8.0. Für die 8.0-Zeile lautet die Fußnote: „Requires VMware vSphere Hypervisor (ESXi) 8.0u3 P06 and later updates to release 8.0 unless explicitly stated otherwise.“ Die Blackwell-Karten haben zusätzlich eigene Fußnoten: VCF 9.0.1 oder neuer auf der 9.0-Linie und ESXi 8.0 Update 3g oder ein späteres 8.0-Update. Auf der 8.0-Linie ist das derselbe Build, denn 8.0 Update 3 P06 wurde als 8.0 Update 3g (Build 24859861) veröffentlicht, wie unser Leitfaden zu GPUs in VMware vSphere festhält; was die Blackwell-Karten von L40S und L4 unterscheidet, ist die Fußnote zu VCF 9.0.1.

NVIDIA vGPU Product Support Matrix für VMware vSphere, zuletzt aktualisiert am 29. September 2026, gelesen am 24. Oktober 2026. Auch die Workstation- und Max-Q-Edition der RTX PRO 6000 und die RTX PRO 5000 stehen nicht auf der Matrix.

Die H200 NVL braucht einen eigenen Hinweis. Sie steht in der GPU-Liste von NVIDIA AI Enterprise 8.2, das vSphere 8.0 und 9.0 und neuer unterstützt, aber nicht in NVIDIAs vGPU-Matrix für vSphere, Stand 24. Oktober 2026. Planen Sie einen H200-NVL-Host unter vSphere mit DirectPath I/O, ganzen Karten je VM und gemeinsam zugewiesenen NVLink-Paaren, und lassen Sie sich von NVIDIA schriftlich bestätigen, bevor ein Design von Compute-vGPU auf dieser Karte abhängt. Unsere MIG-Profile der H200 NVL zeigen, was die Karte auf Bare Metal bietet.

Unter vSphere unterscheiden sich die MIG-Funktionen je Version. Time-Slicing innerhalb einer MIG-Instanz und mehrere MIG-basierte vGPUs in einer VM brauchen VCF 9.1; ein Host mit ESXi 8.0 oder VCF 9.0 plant seine VMs auf der RTX PRO 6000 Server Edition deshalb mit Profilen, die eine ganze GPU-Instanz füllen, wie unsere vGPU-Profile der RTX PRO 6000 Server Edition je Version darstellen.

Drei Listen, die Sie vor der Bestellung prüfen

Drei Listen von zwei Herstellern entscheiden, ob ein GPU-Server ein unterstützter vSphere-Host ist.

Zuerst der Broadcom Compatibility Guide. Broadcoms Hardware­anforderungen für ESX 9.0, aktualisiert am 19. Oktober 2026, verweisen dorthin für „a list of supported platforms“, für unterstützte Prozessoren und für Netzwerkadapter; unser Leitfaden zu den Hardware­anforderungen von ESX 9 zeigt, wie man jeden Host prüft. Ein GPU-Server ist oft ein anderes Modell eines anderen Herstellers als die vorhandenen Hosts, und seine Listung für Ihre ESX-Version ist das Erste, was zu bestätigen ist. Für Private AI Foundation verlangt Broadcom zusätzlich, die GPUs in seinem Compatibility Guide für AI/ML-Compute zu prüfen.

An zweiter Stelle steht NVIDIAs vGPU-Support-Matrix: Karte und Hypervisor-Version, wie in der Tabelle oben. An dritter Stelle NVIDIAs Liste der NVIDIA-Certified Systems, wenn NVIDIA AI Enterprise geplant ist: Die Support-Matrix 8.2 hält fest, dass ihre GPUs „are supported with servers listed on the NVIDIA-Certified Systems“. Ein Server, der die ersten beiden Listen erfüllt, die dritte aber nicht, betreibt vGPU, hat aber keinen NVIDIA-Supportweg für das AI-Enterprise-Abonnement darauf.

Die Konfigurationen hinter diesen Listen zählen so viel wie der Modellname. Serverhersteller listen eine Karte für einen bestimmten Riser, Steckplatz, ein Stromkabel und ein Lüfterkit; unsere Liste der mit der RTX PRO 6000 Server Edition kompatiblen Server nennt diese Details für die gängigen Zwei-Sockel-Plattformen. Wir liefern GPU-Server für vSphere-Hosts und legen sie für die eingesetzte Version aus; senden Sie uns Ihre vSphere- oder VCF-Version und die geplante Karte, und unser Team antwortet mit einer Konfiguration und den Listungen, auf denen sie beruht.

Lizenzierung eines GPU-Hosts: Die Kerne zählen, die GPUs nicht

Broadcoms KB 313548 legt die Regel fest: zu lizenzieren ist ein „minimum of 16 physical cores for each CPU (physical processor)“ in jedem ESXi-Host. Der Artikel zählt nur Prozessorkerne und erwähnt keine GPUs; vier Karten erhöhen die VMware-Lizenz eines Hosts also nicht, die Prozessoren dahinter schon. Derselbe Artikel nennt die enthaltene vSAN-Kapazität, 1 TiB je VCF-Kern und 0,25 TiB je Kern von vSphere Foundation, aufgerundet auf das nächste TiB; ein GPU-Host in einem vSAN-Cluster bringt mit seinen Kernen also seinen Anteil an Kapazitätsberechtigung mit.

Die zweite Lizenzfrage ist die Edition. NVIDIAs Matrix verlangt für vGPU die vSphere-Foundation-Edition von ESXi oder eine vSphere-Enterprise-Plus-Lizenz („Support for NVIDIA vGPU software requires the vSphere Foundation edition …“). Broadcoms Produktvergleich für vSphere 9.1 führt Dynamic DirectPath I/O in allen drei vSphere-Editionen und NVIDIA GRID vGPU in zweien davon und hält fest, dass vSphere Standard und Enterprise Plus nur in Versionen bis 8 Update 3 erhältlich sind („only available as versions up to the 8 Update 3 release“). Ein vGPU-Host unter vSphere 9 läuft also mit vSphere Foundation oder VCF. Welche Stufe zu einer Umgebung passt, behandelt unser Leitfaden zur Verlängerung: Standard, VVF oder VCF.

Unsere Rechnung. VMware-Kerne: physische Kerne, mindestens 16 je CPU (Broadcom KB 313548). NVIDIA-Minimum: sechs Kerne je GPU, Konfigurations­leitfaden für NVIDIA-Certified Systems (30. September 2026). Letzte Spalte: sieben Kerne je GPU plus zwei je GPU für den Hypervisor und, bei der RTX PRO 6000 Server Edition, zwei je MIG-Instanz bei vier Instanzen je Karte, nach NVIDIAs Referenzarchitekturen, wie in unserem CPU-Leitfaden hergeleitet.

Der Einstiegshost liegt genau auf dem Minimum: Zwei Prozessoren mit 16 Kernen ergeben 32 lizenzierte Kerne, und ein Prozessor mit weniger Kernen würde ebenfalls mit 16 Kernen zählen. Darüber wird jeder Kern für die ganze Laufzeit des Abonnements lizenziert. Ein Host mit vier Karten für einen einzelnen Inferenzdienst braucht nach NVIDIAs Leitfaden 24 Kerne, zwei EPYC 9355 bringen 64; der Spielraum lohnt sich, sobald der Host viele VMs trägt, denn jede vGPU-VM bringt ihre eigenen vCPUs mit, und NVIDIAs Referenzarchitektur für MIG rechnet zwei Kerne je Instanz dazu. Legen Sie die Kerne nach den VMs aus, die der Host tragen wird, und lesen Sie die Lizenz am Ergebnis ab. Unser Leitfaden zur CPU für einen GPU-Server enthält die Regeln je GPU vollständig.

Zwei Fallen auf der Lizenzseite. Broadcoms KB warnt, dass im BIOS deaktivierte Kerne zu ungenauen Ergebnissen des Skripts führen können, und verlangt, dass beim Zählen „all physical CPU cores“ aktiv sind; Kerne abzuschalten ist also kein Weg, eine kleinere Zahl zu planen. Unser Leitfaden zum Broadcom-Skript für die Kernzählung zeigt, wie gezählt wird. Und die Kerne im Verlängerungsangebot sollten zu dem passen, was die Hosts melden: Prüfen Sie die Zahl je Host, bevor die GPU-Server ins Abonnement kommen.

Eigener GPU-Cluster oder GPU-Hosts im bestehenden Cluster

Mehrere Regeln auf Hostebene sprechen für einen eigenen Cluster für GPU-Server.

1. CPU-Hersteller. vMotion verlangt Prozessoren derselben Herstellerklasse, und Broadcoms KB 313545 hält fest: „An EVC-enabled cluster only allows CPUs from a single vendor“. GPU-Hosts mit AMD EPYC können also nicht in einen Intel-Cluster mit Live-Migration dazwischen, wie unser Leitfaden zum VMware-Host-Refresh erklärt.
2. Cluster-Image. Mit Images von vSphere Lifecycle Manager wird der vGPU Manager Teil des Cluster-Images, und Broadcoms KB 424294, im selben Leitfaden zitiert, unterstützt Images für Cluster mit heterogener Hardware erst ab ESX 9. Unter ESXi 8 braucht ein GPU-Server eines anderen Herstellers als die übrigen Hosts deshalb einen Cluster mit eigenem Image.
3. Mobilität. Eine vGPU-VM wandert nur auf einen Host mit demselben GPU-Typ, und die DRS-Einstellungen für die vGPU-Migration sind Cluster-Optionen, die für jede VM im Cluster gelten.
4. HA. In Broadcoms HA-Zugangskontrolle, die mit CPU und Arbeitsspeicher rechnet, haben wir nichts zu GPUs gefunden; die freie GPU-Kapazität für einen ausgefallenen oder gepatchten Host muss deshalb von Hand geplant werden.
5. Private AI Foundation. Broadcoms Anforderungen verlangen mindestens drei GPU-fähige ESX-Hosts im ersten Cluster der Workload-Domain, wie unser Leitfaden zu Private AI Foundation zitiert.

Daraus folgt für die meisten Umgebungen: ein eigener Cluster mit mindestens drei gleichen GPU-Hosts, wenn vGPU genutzt oder Private AI Foundation geplant wird, ein Kartentyp je Cluster und freie GPUs im Umfang eines Hosts für die Wartung. Ein einzelner Passthrough-Host für ein Team kann in einem bestehenden Cluster desselben CPU-Herstellers stehen; seine VMs werden heruntergefahren, bevor der Host in den Wartungsmodus geht, weil VMs mit DirectPath I/O nicht migrieren. Die Cluster-Größe jenseits der GPUs folgt unserem Leitfaden zur Host-Konsolidierung bei Lizenzierung nach Kernen.

Treiber-Branches über die Lebensdauer des Hosts

NVIDIAs vGPU-Release-Tabelle, gelesen am 24. Oktober 2026, nennt zwei aktive Branches: vGPU 19 auf dem Treiber-Branch R580, Langzeitsupport bis Juli 2028, aktuelles Release 19.6; und vGPU 20 auf R595, ein Produktions-Branch bis März 2027, aktuelles Release 20.2. Release 20.2 kombiniert den vGPU Manager 595.91.04 mit den Gasttreibern 595.91.07 für Linux und 596.86 für Windows. Die RTX PRO 4500 Server Edition und die flüssiggekühlte RTX PRO 6000 Server Edition kamen mit 20.0 und sind nicht in vGPU 19 enthalten.

Die VMware-Termine laufen parallel. Broadcom beendet den General Support für vSphere 8 am 11. Oktober 2027 (KB 459135), wie unser Artikel zum Ende des General Support für vSphere 8 ausführt. Ein GPU-Host, der jetzt mit ESXi 8.0 Update 3g gekauft wird, erreicht dieses Datum, während vGPU 19 noch unterstützt ist; die Planung für den Host sollte deshalb den Schritt zu VCF 9 innerhalb der Lebensdauer der Hardware enthalten. Das Vorgehen beschreiben unsere Schritte von vSphere 8 zu VCF 9. Aktualisieren Sie den Host-Treiber vor den Gasttreibern und verschieben Sie vGPU-VMs nur auf Hosts mit demselben oder einem neueren Release, wie es NVIDIAs Migrationsregeln verlangen.

Strom und Rackplätze für GPU-Hosts

GPU-Hosts ziehen mehr Strom als die Virtualisierungshosts um sie herum. Nach unserer Schätzung, Karten plus Prozessoren plus 15 Prozent für den Rest, zieht ein Host mit zwei RTX PRO 6000 Server Edition rund 1,8 kW, ein Host mit vier Karten rund 3,4 kW bei 600 W je Karte oder 2,7 kW mit der 450-W-Begrenzung und ein Host mit acht Karten rund 6,3 kW; Dell nennt als Richtwert rund 8 kW je Knoten mit acht Karten, und die Anschlüsse sollten nach der Angabe des Herstellers geplant werden. Bei 80 Prozent eines 230-V-Anschlusses mit 16 A, also 2,94 kW, braucht ein Host mit vier Karten unter Volllast schon 32 A oder Drehstrom. Eine Messung am gelieferten System bestätigt oder ersetzt diese Schätzungen. Unser Leitfaden zu Strom und Kühlung im GPU-Rack behandelt Anschlüsse und Luftstrom je Rack.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration passend zu Ihrer Last und Ihrem Budget aus und antwortet innerhalb eines Werktages. Wir bauen KI-Server nach Auftrag mit RTX PRO 6000 Server Edition, RTX PRO 4500 Server Edition, L40S, L4 oder H200 NVL, vor der Lieferung montiert und getestet, mit Herstellergarantie auf jede Komponente, mit einem EU-Vertrag und einer Rechnung, und nehmen die Lizenzen für NVIDIA AI Enterprise und vGPU ins selbe Angebot auf. VMware- und Broadcom-Lizenzen gehören zu dem, was wir liefern und implementieren, wie unsere Software-Seite festhält, und für den Cluster selbst liefert unser Engineering-Partner Vixen.UNO VMware-Optimierung: ein Audit der Umgebung und ihrer Lizenzen, Editionen passend zu den tatsächlichen Lasten und eine Modernisierung mit Rollback-Plan. Senden Sie uns die Zahl Ihrer Hosts, die Version und den Verlängerungstermin, und wir schlagen GPU-Hosts vor, die zu Cluster und Lizenz passen.

FAQ