H200 NVL und RTX PRO 6000 in einer Plattform: welche Workloads auf welche Server gehören

Welche Workloads auf die H200 NVL gehören und welche auf die RTX PRO 6000

In einem gemischten GPU-Cluster aus zwei bis vier Servern gehört die H200 NVL dorthin, wo ein Job viel schnellen Speicher an einer Stelle braucht: Modelle, die größer sind als eine Karte mit 96 GB, lange Kontexte mit vielen gleichzeitigen Nutzern, Fine-Tuning und Berechnungen mit doppelter Genauigkeit. Die RTX PRO 6000 Blackwell Server Edition gehört dorthin, wo die Plattform viele mittelgroße Modelle gleichzeitig betreibt: Chat- und Coding-Modelle, die auf eine Karte passen, Vision-Language-Modelle, Embedding- und Reranking-Dienste, NVFP4-Checkpoints, virtuelle Desktops und Rendering.

Laut NVIDIAs Produktseiten kommen beide als luftgekühlte Dual-Slot-Karten für PCIe Gen5 mit bis zu 600 W, konfigurierbar; die RTX PRO 6000 Server Edition wird außerdem als flüssigkeitsgekühlte Single-Slot-Karte geführt. Strom und Kühlung werden daher in beiden Pools pro Karte auf dieselbe Weise geplant, und die beiden Pools können eine Treiberversion, einen Kubernetes-Cluster und ein Betriebsverfahren teilen. Der größte Teil der Planungsarbeit besteht darin, jeden Workload auf dem Pool zu halten, für den er dimensioniert wurde.

Die Spezifikationen Karte für Karte und veröffentlichte Benchmarks finden Sie in unserem Vergleich von RTX PRO 6000 und H200 NVL für LLM-Inferenz. Dieser Artikel behandelt, wie die beiden die Arbeit aufteilen, wenn ein Unternehmen beide betreibt.

Die Karteneigenschaften, die über die Platzierung entscheiden

Speicher und Bandbreite kommen zuerst. Die H200 NVL hat 141 GB HBM3e mit 4,8 TB/s, die RTX PRO 6000 Server Edition 96 GB GDDR7 mit 1.597 GB/s. Die H200 NVL koppelt außerdem 2 oder 4 Karten über NVLink-Bridges mit 900 GB/s pro GPU, gegenüber 128 GB/s bei PCIe Gen5, was zählt, sobald ein Modell über mehrere Karten verteilt ist. NVIDIA gibt sie mit 30 TFLOPS FP64 für Simulation und anderen Code mit doppelter Genauigkeit an. Die Seite der RTX PRO 6000 Server Edition nennt keinen FP64-Wert.

Die RTX PRO 6000 bringt mit, was der Hopper-Karte fehlt. NVIDIA nennt für sie 4 PFLOPS FP4-Tensor-Leistung, während die Tabelle der H200 NVL bei FP8 und INT8 endet; FP4-Arithmetik läuft also nur im Blackwell-Pool nativ. FP4-Gewichte lassen sich auf Hopper trotzdem bereitstellen, ohne FP4-Arithmetik: OpenAIs gpt-oss-120b mit MXFP4-Expertengewichten nennt die H100 unter den GPUs, auf die es passt. Unser Leitfaden zu FP8, NVFP4 und MXFP4 erklärt die Formate. Die Karte hat 188 RT-Kerne sowie vier Engines für Video-Encoding und vier für Video-Decoding. NVIDIAs MIG-Leitfaden ergänzt +gfx-Profile, neu in dieser Generation, die „Grafikunterstützung in MIG-Instanzen aktivieren“. Die H200 NVL führt nur Decoder, sieben NVDEC und sieben JPEG.

Beide Karten unterstützen MIG, in unterschiedlichen Größen. Die RTX PRO 6000 teilt sich in bis zu vier Instanzen zu 24 GB. Die H200 NVL teilt sich nach NVIDIAs Produktseite in bis zu sieben zu 16,5 GB, ein Profil, das die Tabelle des MIG-Leitfadens für die H200 141GB als 1g.18gb bezeichnet.

Platzierung der Workloads: welche Karte für welchen Job

Produktseiten von NVIDIA zur H200 und zur RTX PRO 6000 Blackwell Server Edition, NVIDIAs MIG-Benutzerhandbuch (11. September 2026) und die Liste der von vGPU unterstützten GPUs (2. Oktober 2026), abgerufen am 10. Oktober 2026; die Platzierung ist unsere Lesart dieser Eigenschaften.

Qwen3-235B-A22B-Instruct-2507 in FP8 zeigt, warum große Modelle in den H200-Pool gehören. Qwens FP8-Checkpoint dieses Modells belegt laut seiner Dateiliste auf Hugging Face 236,4 GB (220,2 GiB), und seine Model Card stellt es mit --tensor-parallel-size 4 bereit. Seine config.json nennt 94 Schichten und 4 KV-Heads der Dimension 128, sodass eine Konversation mit 32K Token in einem FP8-Cache (--kv-cache-dtype fp8 in vLLM) 2,94 GiB belegt. Unsere Dimensionierungsregel gibt dem Cache das 0,9-Fache des Speichers, den der Treiber meldet (95,6 GiB auf der RTX PRO 6000, 140,4 GiB auf der H200 NVL), abzüglich 3 GiB pro Karte, abzüglich der Gewichte.

Nach dieser Regel fassen vier per Bridge gekoppelte H200 NVL neben den Gewichten etwa 93 solcher Konversationen. Vier RTX PRO 6000 fassen etwa 38, wobei der Verkehr zwischen den Karten über PCIe läuft, und zwei H200 NVL etwa 9. Bei Tensor-Parallelität über vier Karten behält jede Karte einen der vier KV-Heads, denn vLLMs Blog vom 7. August 2026 stellt fest, dass „TP den KV-Cache zuerst nach diesen Heads aufteilt“. Für acht Karten warnt derselbe Blog: „Sobald TP die Zahl der KV-Heads übersteigt, beginnt sich der Cache über die GPUs hinweg zu duplizieren.“

Ein Modell, das auf eine Karte passt, läuft in beiden Pools. OpenAIs Model Card ordnet gpt-oss-120b Einsatzfällen zu, die „in eine einzelne 80-GB-GPU passen“; eine Kopie pro RTX PRO 6000 bedient es also, während der H200-NVL-Pool für die Jobs frei bleibt, die nur er übernehmen kann. Die Generierung für einen einzelnen Nutzer ist durch die Speicherbandbreite begrenzt, die auf der H200 NVL dreimal so hoch ist; wo diese Latenz Teil eines Service-Levels ist, gehört das Modell stattdessen dorthin. Fine-Tuning vergleicht im Detail unser Leitfaden zu H200 NVL und RTX PRO 6000 für Fine-Tuning.

Wir liefern beide Karten, die H200 NVL mit ihren 2-fach- und 4-fach-NVLink-Bridges, als Karten oder in nach Auftrag gebauten KI-Servern. Schicken Sie uns Ihre Liste der Modelle und Workloads über das Formular unten, und wir antworten mit einer Konfiguration.

Beispielflotten mit zwei bis vier Servern

Beispielaufteilungen, keine Dimensionierung; die Zahlen hängen von den Modellen, der Kontextlänge und der Spitzenparallelität ab. Kopplung nach NVIDIAs Produktseite zur H200: 2 oder 4 Karten pro NVLink-Domäne.

In der Flotte mit zwei Servern steht das große Modell still, wenn sein einziger Server stillsteht, sei es durch einen Ausfall, einen Neustart oder ein Treiber-Update. Die Flotte mit drei Servern hält die mittelgroßen Modelle am Laufen, wenn ein RTX-Host ausfällt, nicht aber das große Modell. In der Flotte mit vier Servern hält jeder H200-Server eine Kopie eines Modells wie Qwen3-235B-A22B-Instruct-2507, nach der Schätzung oben etwa 93 Konversationen mit je 32K, sodass ein ausgefallener Host diese Kapazität halbiert, statt den Dienst zu stoppen. Unser Artikel ein Server mit 8 GPUs oder zwei Server mit je 4 GPUs behandelt diese Wahl der Ausfalldomäne ausführlich.

Fine-Tuning und Serving auf denselben H200-Karten konkurrieren um Speicher. In der Flotte mit vier Servern belegt ein Trainingslauf in einem vereinbarten Zeitfenster einen H200-Server, während der andere das große Modell allein bereitstellt, und der Lauf muss in das Zeitfenster passen.

Scheduling für einen gemischten, heterogenen GPU-Cluster in Kubernetes

Beide Karten erscheinen in Kubernetes als dieselbe Extended Resource, nvidia.com/gpu; ein Pod, der eine GPU anfordert, landet deshalb auf einem beliebigen Node mit einer freien GPU, solange nichts ihn einschränkt. GPU Feature Discovery, das NVIDIAs GPU Operator installiert, versieht jeden Node mit Labels: das Kartenmodell in nvidia.com/gpu.product, den Speicher in MiB in nvidia.com/gpu.memory und die Compute Capability in nvidia.com/gpu.compute.major. NVIDIAs Tabelle der Compute Capabilities führt die H200 mit 9.0 und die RTX PRO 6000 Server Edition mit 12.0, sodass dieses Label die Pools trennt.

1. Installieren Sie den GPU Operator auf jedem GPU-Node; GPU Feature Discovery versieht jeden Node mit Labels für Kartenmodell, Speicher und Compute Capability.
2. Versehen Sie die H200-NVL-Nodes mit einem Taint, zum Beispiel gpu-pool=h200:NoSchedule, damit dort nur Pods mit passender Toleration platziert werden; die Kubernetes-Dokumentation nennt GPU-Nodes als Beispiel für Nodes mit spezieller Hardware. Tragen Sie dieselbe Toleration in daemonsets.tolerations des GPU Operator und beim Worker von Node Feature Discovery ein, dessen Standardwerte nur den Schlüssel nvidia.com/gpu tolerieren; sonst werden die Pods für Treiber, Device-Plugin und Labels auf diesen Nodes nicht eingeplant.
3. Geben Sie jedem GPU-Workload eine Node-Affinität auf eines der Labels, als verpflichtende Regel (requiredDuringScheduling​IgnoredDuringExecution), für die gilt: „Der Scheduler kann den Pod nicht einplanen, solange die Regel nicht erfüllt ist.“
4. Lassen Sie MIG auf den RTX-PRO-6000-Nodes aktiv, die kleine Modelle bedienen, und ganze Karten auf den Nodes, die große bedienen; mit der MIG-Strategie „mixed“ erscheinen die Instanzen als eigene Ressource, nvidia.com/mig-1g.24gb, nicht als nvidia.com/gpu.
5. Testen Sie jedes Container-Image in beiden Pools, bevor es in beiden laufen darf.

Der Taint hält allgemeine GPU-Arbeit vom H200-Pool fern, und die Affinität hält ein NVFP4-Modell oder ein großes tensorparalleles Deployment auf den richtigen Karten. MIG-Aufteilungen und die Sharing-Methoden in jedem Pool behandelt unser Leitfaden zum GPU-Sharing in Kubernetes.

Eine Treiberversion und Container-Images für beide Pools

Die beiden Karten brauchen keine getrennten Treiber-Branches. Die Seite zur Plattformunterstützung von NVIDIAs GPU Operator, aktualisiert am 23. September 2026, führt sowohl die H200 NVL als auch die RTX PRO 6000 Blackwell Server Edition und nennt Treiber 595.91.07 als empfohlen und Standard für die Releases 26.7, neben Treibern der Branches 580, 610 und 615. Ihre Hinweise zur RTX PRO 6000 Server Edition besagen, dass diese Treiber 575.57.08 oder neuer braucht, dass MIG auf 575.57.08 selbst nicht unterstützt wird und dass Heterogeneous Memory Management in UVM unter Umständen deaktiviert werden muss, wo die CUDA-Initialisierung fehlschlägt.

Eine Treiberversion bedeutet einen Test und ein Rollout-Verfahren für den ganzen Cluster. Der Rollout läuft trotzdem Pool für Pool in Wartungsfenstern, sodass das große Modell und die Chat-Kopien nie gleichzeitig ausfallen.

Container-Images brauchen mehr Sorgfalt als der Treiber. NVIDIAs Release Notes zu CUDA 12.8 ergänzen „Compiler-Unterstützung“ für SM_120, die Architektur der RTX PRO 6000, während die H200 SM_90 ist. Ein Image für beide Pools muss kompilierten Code oder PTX für beide Architekturen enthalten, und ein für FP4 gebauter Kernel läuft nur im Blackwell-Pool. Binden Sie solche Deployments an nvidia.com/gpu.compute.major 12.

Virtuelle Maschinen und virtuelle Desktops auf einer gemischten Plattform

Virtuelle Desktops und virtuelle Workstations gehören in den RTX-PRO-6000-Pool. NVIDIAs Liste der von seiner vGPU-Software unterstützten GPUs, aktualisiert am 2. Oktober 2026, enthält die RTX PRO 6000 Blackwell Server Edition ab Release 19.0 und führt die H200 NVL nicht. Beide Karten erscheinen unter den unterstützten diskreten GPUs der Support-Matrix von NVIDIA AI Enterprise 8.2 vom 2. September 2026, die Bare-Metal- und virtualisierte Deployments abdeckt, diese aber nicht den einzelnen Karten zuordnet. Ein Unternehmen kann daher die Desktops auf RTX-PRO-6000-Hosts halten und die H200 NVL unter NVIDIA AI Enterprise für Rechenaufgaben betreiben; bevor Sie H200-NVL-Karten in virtuelle Maschinen setzen, prüfen Sie den Modus in der Dokumentation des Releases, das Sie einsetzen.

Lizenzen über beide Pools

NVIDIAs Lizenzierungsleitfaden, aktualisiert am 2. September 2026, stellt fest, dass NVIDIA AI Enterprise „pro GPU lizenziert wird“ und dass „jede NVIDIA H200 NVL Tensor Core GPU ein fünfjähriges Abonnement für NVIDIA AI Enterprise enthält“, das aktiviert werden muss. Für die RTX PRO 6000 Server Edition nennt der Leitfaden kein enthaltenes Abonnement. Wo der RTX-Pool Software betreibt, die NVIDIA AI Enterprise braucht, benötigt jede seiner Karten eine eigene Lizenz, während jede H200 NVL ihr eigenes fünfjähriges Abonnement mitbringt.

Lizenzen für NVIDIA AI Enterprise und vGPU kommen auf dieselbe Rechnung wie die Hardware. Nennen Sie uns, welcher Pool welche Software betreibt, und wir nehmen die Lizenzen, die jede Karte braucht, in das Angebot auf.

Was wir liefern

Wir liefern die H200 NVL mit ihren 2-fach- und 4-fach-NVLink-Bridges und die RTX PRO 6000 Blackwell Server Edition, als GPUs für Server, die Sie bereits betreiben, oder in nach Auftrag gebauten KI-Servern, unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie. Wir bauen Trainings- und Fine-Tuning-Knoten mit H200-NVL-Karten und NVLink-Bridges oder mit der RTX PRO 6000 Server Edition sowie Inferenz-Knoten mit 2 bis 8 GPUs, montiert und im Burn-in getestet, auf Wunsch mit installiertem Betriebssystem, Treibern, CUDA und Container-Runtime. Rack, Strom und Luftstrom prüfen wir vor dem Angebot, und Konfiguration und Angebot schicken wir innerhalb eines Werktages. Die Plattform darauf, Modelle, RAG und MLOps, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ