H200 NVL oder RTX PRO 6000 für Fine-Tuning und Training: Speicher, Bandbreite, Tensor-Raten und die Verbindung zwischen den Karten

Zwei 600-W-Karten mit unterschiedlichem Speicher

Die H200 NVL und die luftgekühlte RTX PRO 6000 Server Edition sind passive Karten, die auf die Lüfter des Servers angewiesen sind; NVIDIA führt außerdem eine flüssigkeitsgekühlte Server Edition im Single-Slot-Format auf. Die Workstation Edition hat denselben Chip und 96 GB mit eigenen Lüftern, für den Schreibtisch, und die Max-Q-Version ist für 300 W ausgelegt. Was sie beim Training unterscheidet, sind Speicher, Tensor-Durchsatz und die Verbindung zwischen den Karten.

NVIDIA-Produktseite zur H200; Datenblätter zur RTX PRO 6000 und Produktseite der Server Edition; NVIDIAs MIG-Leitfaden vom 11. September 2026. Sichtbarer Speicher, wie ihn nvidia-smi meldet. Die NVLink-Rate ist NVIDIAs Summe für beide Richtungen.

Welche Läufe in 141 und 96 GB passen

Unser Leitfaden zum GPU-Speicher beim Fine-Tuning berechnet die Modellzustände, also Gewichte, Gradienten und Optimiererzustände, für Llama 3.1 8B, Qwen3-32B und Llama 3.3 70B. Dem Speicher gegenübergestellt, den der Treiber anzeigt, 150,8 GB auf der H200 NVL und 102,6 GB auf der RTX PRO 6000, lassen sie so viel für Aktivierungen frei.

Unsere Rechnung, GB = 10⁹ Byte: Adapter mit Rang 16 auf allen linearen Schichten, 16 Byte pro trainiertem Parameter, eine BF16-Basis für LoRA und, für QLoRA, lineare Schichten in NF4 mit Embeddings und Ausgabeschicht in BF16; vollständiges Fine-Tuning mit 16 Byte pro Parameter bei 32-Bit-Adam und 10 bei 8-Bit-Adam, nach der ZeRO-Zählung. Was frei bleibt, muss Aktivierungen, den CUDA-Kontext und temporäre Puffer aufnehmen.

LoRA bis 32B und QLoRA bis 70B passen auf beide Karten, mit Platz für Aktivierungen; für diese Läufe bringen die zusätzlichen 48 GB der H200 NVL also längere Sequenzen und größere Batches, keinen Lauf, den die RTX PRO 6000 nicht schafft. In zwei Fällen entscheidet die Kapazität. Die Modellzustände eines vollständigen Fine-Tunings von 8B mit 32-Bit-Adam passen auf eine H200 NVL, aber nicht auf eine RTX PRO 6000, es sei denn, 8-Bit-Adam senkt sie auf etwa 80 GB. Ein 70B-LoRA auf einer BF16-Basis lässt selbst auf der H200 NVL etwa 6 GB frei, zu wenig, um damit zu planen, und braucht zwei Karten, gleich welchen Typs. Damit verlagert sich die Frage auf die Verbindung zwischen ihnen.

Warum die Bandbreite beim Training weniger zählt

Beim Serving gibt die Bandbreite den Ausschlag: Um ein Token für einen Nutzer zu erzeugen, wird jedes Gewicht eines dichten Modells gelesen, deshalb geben die 4,8 TB/s der H200 NVL gegenüber 1.792 GB/s bei der Workstation Edition und 1.597 GB/s bei der Server Edition, das 2,7- und 3,0-Fache, das Tempo vor, wie unser Inferenzvergleich zeigt. Training verhält sich dagegen wie die Prefill-Phase. NVIDIAs Performance-Leitfaden definiert die arithmetische Intensität als Operationen pro Byte Speicherverkehr und sagt, ein Algorithmus sei „auf einem gegebenen Prozessor rechenlimitiert, wenn die arithmetische Intensität des Algorithmus höher ist als das ops:byte-Verhältnis des Prozessors“. In NVIDIAs eigenen Beispielen kommt eine lineare Schicht bei Batchgröße 512 auf 315 FLOPS pro Byte und ist rechenlimitiert; dieselbe Schicht kommt bei Batchgröße 1 auf 1 FLOPS pro Byte und ist speicherlimitiert.

Ein Trainingsschritt schiebt Tausende Token auf einmal durch jede Schicht. Nach derselben Formel erreicht die Up-Projektion von Llama 3.1 8B, von 4.096 auf 14.336, bei einer Sequenz von 2.048 Token in BF16 nach unserer Rechnung etwa 1.250 FLOPS pro Byte. Das ops:byte-Verhältnis beträgt 174 auf der H200 NVL, 835,5 dichte BF16-TFLOPS durch 4,8 TB/s, und 281 auf der RTX PRO 6000 Workstation Edition, 503,8 durch 1,792 TB/s. Die großen Matrixmultiplikationen sind daher auf beiden Karten rechenlimitiert, und für sie zählt die Tensor-Rate: das 1,66-Fache zugunsten der H200 NVL, nicht das 2,7-Fache. Die Bandbreite zählt weiterhin für die Operationen, die NVIDIA als speicherlimitiert aufführt, etwa Aktivierungsfunktionen und Layer-Normalisierung, und, nach unserer Überlegung, für drei weitere: den Optimiererschritt, der auf jeden Zustand einmal zugreift, mit wenig Rechenaufwand; die Multiplikationen der Rang-16-Adapter, nach derselben Formel mit etwa 16 FLOPS pro Byte; und, bei QLoRA, die Dequantisierung jedes 4-Bit-Gewichts vor jeder Multiplikation. Bei diesen Teilen liegt die H200 NVL um das Verhältnis der Bandbreiten vorn, nicht um das der Tensor-Raten. Wir haben keinen veröffentlichten Fine-Tuning-Benchmark gefunden, der beide Karten unter denselben Bedingungen testet, und nennen daher kein gemessenes Verhältnis.

Tensor-Raten, Präzision für Präzision

TFLOPS, sofern nicht anders angegeben. NVIDIA-Produktseite zur H200, Raten „With sparsity“, von uns für die dichten Werte halbiert; NVIDIAs Whitepaper zur RTX-PRO-Blackwell-GPU-Architektur v1.0, Tabelle 4, Workstation Edition bei ihrem Boost-Takt von 2.617 MHz; Produktseite der RTX PRO 6000 Server Edition, die nicht angibt, ob ihre Werte Sparsity einschließen.

Raten mit Sparsity gelten nur für Gewichte, die auf NVIDIAs 2:4-Muster ausgedünnt sind, bei dem gilt: „In jedem zusammenhängenden Block aus vier Werten müssen zwei Werte null sein.“ Ein normales Fine-Tuning erzeugt dichte Gewichte, vergleichen Sie also die dichten Raten. Die BF16- und FP8-Werte der RTX PRO 6000 sind die, die NVIDIA mit FP32-Akkumulation angibt; NVIDIAs H200-Seite nennt den Akkumulationsmodus nicht, aber NVIDIAs Blogbeitrag zur Hopper-Architektur gibt die BF16-Tensor-Raten von Hopper mit FP32-Akkumulation an. Bei den dichten Spitzenraten liegt die H200 NVL vor der Workstation Edition, 835,5 zu 503,8 TFLOPS in BF16 und 1.670,5 zu 1.007,6 in FP8, in beiden Fällen das 1,66-Fache. Gegenüber der Max-Q mit 300 W, die NVIDIAs RTX-PRO-Whitepaper mit 438,9 dichten BF16-TFLOPS angibt, beträgt das Verhältnis 1,90; für die Server Edition haben wir von NVIDIA keine dichte Rate gefunden. Die 1, 2 und 4 PFLOPS der Server Edition entsprechen gerundet den Werten der Workstation Edition mit Sparsity. QLoRA dequantisiert seine 4-Bit-Gewichte für jede Multiplikation nach BF16, also gilt die BF16-Zeile auch dafür.

FP8- und FP4-Training. Beide Karten trainieren in FP8 mit NVIDIAs Transformer Engine, deren README, Stand September 2026, „Unterstützung für FP8 auf NVIDIA-GPUs der Generationen Hopper, Ada und Blackwell“ nennt. MXFP8 und NVFP4 sind nur für Blackwell-GPUs aufgeführt, keines von beiden ist also auf der H200 NVL eine Option; auf der RTX PRO 6000 ist es nur NVFP4, weil die eigene Support-Prüfung der Transformer Engine MXFP8 auf Compute Capability 12.0 und höher weiterhin ablehnt, „not supported on 12.0+ architectures yet“. Transformer Engine 2.19, veröffentlicht am 11. September 2026, hat stochastisches Runden für NVFP4 auf SM120- und SM121-GPUs ergänzt, zu denen die RTX-PRO-Blackwell-Karten und DGX Spark gehören.

Mehr als eine Karte: NVLink gegen PCIe

Beim datenparallelen Training hat jede Karte eine Kopie des Modells, und die Gradienten dessen, was trainiert wird, werden bei jedem Schritt per All-Reduce zusammengeführt; für ein Modell mit Ψ Parametern, die alle trainiert werden, zählt die ZeRO-Arbeit „2Ψ Datenbewegung während jedes Trainingsschritts“. Die Methode bestimmt also den Verkehr. Ein LoRA mit Rang 16 auf Llama 3.1 8B trainiert 41,9 Millionen Parameter, etwa 190-mal weniger als die 8,03 Milliarden eines vollständigen Fine-Tunings, und sein All-Reduce ist auf jeder Verbindung klein. Ein vollständiges Fine-Tuning führt beim selben Modell nach unserer Rechnung pro Schritt 16 GB BF16-Gradienten per All-Reduce zusammen. Sharding kommt noch hinzu: FSDP führt die verteilten Gewichte vor dem Vorwärts- und vor dem Rückwärtsdurchlauf per All-Gather zusammen, und für ein vollständiges Fine-Tuning setzt die ZeRO-Arbeit den gesamten Verkehr mit dem 1,5-Fachen des Verkehrs bei reinem Datenparallelismus an.

Bei einem 70B-LoRA, das per Sharding auf zwei Karten verteilt ist, wird die eingefrorene Basis zusammengeführt: Jede Karte speichert die Hälfte der 141 GB der Basis und empfängt die andere Hälfte, Schicht für Schicht, im Vorwärtsdurchlauf und erneut im Rückwärtsdurchlauf, der die Gewichte braucht, um Gradienten an die Adapter früherer Schichten zurückzureichen. Nach unserer Rechnung sind das etwa 141 GB pro Karte für jeden Vorwärts- und Rückwärtsdurchlauf, also für jeden Micro-Batch, unabhängig von seiner Größe. Mit mehr Karten speichert jede einen kleineren Anteil und empfängt mehr: etwa 212 GB bei vier und 247 GB bei acht. Allein nach den nominalen Verbindungsraten, wieder nach unserer Rechnung, brauchen 141 GB mindestens 2,2 Sekunden über PCIe Gen5 mit 64 GB/s pro Richtung und mindestens 0,3 Sekunden über eine 2-fach-NVLink-Brücke mit 450 GB/s pro Richtung; FSDP verbirgt einen Teil davon hinter der Berechnung.

Hier unterscheiden sich die beiden Karten am stärksten. Die H200 NVL lässt sich über eine 2- oder 4-fach-NVLink-Brücke mit 900 GB/s pro GPU koppeln, gegenüber 128 GB/s bei PCIe Gen5 nach NVIDIAs Angaben, beides Summen für beide Richtungen, also 450 und 64 GB/s pro Richtung. Eine Brücke verbindet höchstens vier Karten, deshalb hat ein Server mit acht per Brücke verbundenen Karten mindestens zwei NVLink-Domänen, mit PCIe dazwischen. Die RTX PRO 6000 hat kein NVLink und tauscht Daten über PCIe aus, bestenfalls Peer-to-Peer. NVIDIAs NCCL-Dokumentation warnt, dass unter Linux auf Bare Metal „CUDA und der NVIDIA-Treiberstack keine PCIe-Peer-to-Peer-Speicherübertragung bei aktivierter IOMMU unterstützen“ und dass ACS auf PCIe-Switches deaktiviert werden muss, auf manchen Systemen im BIOS: Prüfen Sie beides, bevor Sie den Karten die Schuld geben. Google Cloud beschreibt einen „erweiterten PCIe-basierten P2P-Datenpfad“, der in seinen G4-Maschinen mit der Server Edition All-Reduce beschleunigt, mit Zuwächsen, die für tensorparalleles Serving angegeben werden (Oktober 2025).

MIG: mehrere Experimente auf einer Karte

MIG teilt die H200 NVL in bis zu sieben Instanzen vom Typ 1g.18gb, laut NVIDIAs Produktseite je 16,5 GB, oder in vier zu 35 GB, und die RTX PRO 6000 in vier zu 24 GB oder zwei zu 48 GB. Ein 8B-QLoRA mit 6,4 GB Modellzuständen passt in jede dieser Instanzen; ein 8B-LoRA auf einer BF16-Basis mit 16,7 GB lässt in einer 24-GB-Instanz etwa 7 GB frei und in einer 1g.18gb-Instanz keinen Arbeitsspielraum. NVIDIAs MIG-Leitfaden stellt fest, dass „NCCL derzeit nicht mit MIG unterstützt wird“; eine Instanz führt also einen Job für eine einzelne GPU aus, nie einen Teil eines Laufs über mehrere Karten. Bei der Workstation Edition und der Max-Q verlangt NVIDIA, dass der Anzeigemodus auf Compute umgestellt wird, bevor sich MIG aktivieren lässt, was die Displayausgänge der Karte abschaltet.

Welche Karte für welchen Lauf

LoRA auf Modellen mit 8B bis 32B. Die RTX PRO 6000 fasst beide und lässt 86 bzw. 35 GB frei, die Workstation Edition am Schreibtisch und die Server Edition im Rack. Die H200 NVL führt dieselben Jobs mit höherer Tensor-Spitzenrate aus, was zählt, wenn Läufe Schlange stehen.

QLoRA auf einem 70B-Modell. Jede der beiden Karten, mit 60 GB Reserve auf der RTX PRO 6000 und 108 GB auf der H200 NVL.

Vollständiges Fine-Tuning eines 8B-Modells. Mit 32-Bit-Adam fasst eine H200 NVL die 128 GB Modellzustände, wobei 22 GB frei bleiben; die RTX PRO 6000 braucht eine zweite Karte und FSDP, mit 64,2 GB pro Karte, oder 8-Bit-Adam, mit etwa 80 GB auf einer Karte.

Mehrere Karten. Vollständiges Fine-Tuning mit Sharding und ein 70B-LoRA mit Sharding bewegen pro Vorwärts- und Rückwärtsdurchlauf Dutzende bis Hunderte GB, und dort sind die NVLink-Domänen der H200 NVL aus zwei oder vier Karten die stärkere Plattform. Jenseits von vier Karten läuft der Verkehr zwischen den Domänen bei beiden über PCIe. Wo ein LoRA- oder QLoRA-Lauf auf eine Karte passt, umgeht ein Job pro Karte die Frage der Verbindung ganz.

Was wir liefern

Eurokommerz liefert die H200 NVL und die RTX PRO 6000 Workstation Edition und Max-Q EU-weit mit Herstellergarantie, als Karten oder in Workstations, die für Training konfiguriert sind, und baut KI-Server nach Auftrag. Nennen Sie uns die geplanten Läufe, und wir legen die Karten und ihre Zahl gemeinsam mit Ihnen fest.

FAQ