DGX Spark, eine RTX PRO 6000 oder ein Server mit H200 NVL: womit ein erstes KI-Projekt startet

Die vier Fragen, die die Entscheidung tragen

Die meisten ersten KI-Projekte landen bei derselben engeren Auswahl: ein NVIDIA DGX Spark auf dem Schreibtisch, eine RTX PRO 6000 Blackwell in einer Workstation oder einem Server, oder ein Server mit einer oder zwei H200-NVL-Karten. Das sind nicht drei Größen derselben Maschine, und die Wahl ergibt sich aus vier Fragen, die mit den Produktseiten nichts zu tun haben.

Wie groß ist das Modell, und in welcher Genauigkeit? Eine Parameterzahl allein entscheidet nichts. Dieselben 70 Milliarden Parameter belegen 141,2 GB in BF16, 70,6 GB in FP8 und 35,3 GB in NVFP4; die Antwort auf der Hardwareseite ändert sich also um den Faktor vier durch eine Entscheidung, die noch niemand getroffen hat.

Wie viele Menschen nutzen es gleichzeitig? Ein Entwickler, der an Prompts feilt, ist eine Batchgröße von eins, und genau so misst NVIDIA einen Spark. Zwanzig Leute in einem Assistenten sind zwanzig gleichzeitige Sequenzen, von denen jede ihren eigenen Key-Value-Cache hält, und auf einer einzelnen Karte geht der Cache vor den Gewichten aus.

Wo steht die Maschine physisch? Ein DGX Spark misst 150 mm im Quadrat, ist 50,5 mm hoch und wiegt 1,2 kg, will 5 bis 30 °C und zieht gemessene höchstens 233,2 W aus einer gewöhnlichen Steckdose. Eine H200 NVL ist eine passiv gekühlte Dual-Slot-Karte, die ein namentlich genanntes Lüfterkit, einen namentlich genannten Luftkanal, einen bestimmten Riser und die richtige Teilenummer des 16-poligen Kabels für genau diesen Steckplatz braucht, in einem Server auf der Supportliste des Herstellers. Verschiedene Projekte, verschiedene Menschen.

Was passiert nach dem Pilot? Jeder Startpunkt wächst anders, und zwei der drei tragen eine harte Grenze in der Hardware. Die gehört jetzt in die Entscheidung.

Die drei Optionen nebeneinander

Alles Folgende stammt von NVIDIAs Produktseiten, Datenblättern, User Guides und Product Briefs sowie aus den OEM-Handbüchern dort, wo ein Hersteller NVIDIA überschreibt. Lesen Sie die Zeile zur Bandbreite zweimal; sie entscheidet, wie sich die Maschine anfühlt.

NVIDIA-Produktseite und User Guide zum DGX Spark; Datenblätter der RTX PRO 6000 und das Architektur-Whitepaper zu Blackwell PRO; Product Brief PB-12128-001 und Datenblatt zur H200 NVL; Produkthandbücher von Dell, HPE und Lenovo. September 2026.

Eine Zeile wird häufiger falsch zitiert als jede andere. Die Zahl 1.792 GB/s, die zur RTX PRO 6000 kursiert, gehört zur Workstation Edition und zur Max-Q. Die Server Edition, die einzige passiv gekühlte für ein Gehäuse und die einzige auf NVIDIAs vGPU-Liste, läuft mit 1.597 GB/s, etwa 11 Prozent darunter; ein Rack-Deployment auf 1.792 GB/s zu bemessen überschätzt seine Token-Generierung also um rund 12 Prozent. Unser Editionsvergleich deckt den Rest ab.

Auch der Lizenzanspruch unterscheidet sich. Die H200 NVL wird mit einem Fünf-Jahres-Abonnement NVIDIA AI Enterprise verkauft, pro GPU lizenziert und gegen die Seriennummer der GPU aktiviert; notieren Sie die Seriennummern also, bevor die Karten ins Rack gehen. Der DGX Spark bringt keinen solchen Anspruch mit: NVIDIA schreibt, er bestehe nur, wenn er gekauft, als Evaluierung angefordert oder per Zertifikat gewährt wurde, und der kostenlose Weg ist eine Lizenz über 90 Tage mit Support allein durch die Community.

Der Speicher ist das erste Tor, die Bandbreite das zweite

Gewichte sind Parameter mal Byte je Parameter: zwei in BF16 oder FP16, eines in FP8, ein halbes Byte in NVFP4 oder MXFP4. Diese Rechnung, und sonst nichts, entscheidet, ob ein Modell überhaupt lädt.

Nur Gewichte, aus den nominalen Parameterzahlen 8,03B, 32,8B und 70,6B. Cache, Aktivierungen und Framework-Overhead kommen obendrauf; der VRAM-Leitfaden hat die Formel.

Ein 70B-Modell in BF16 braucht 141,2 GB: Es passt auf eine H200 NVL mit 141 GB und lässt nichts übrig, und es passt weder auf die 96 GB der RTX PRO 6000 noch in die 128 GB des Spark. NVIDIAs NIM-Supportmatrix sagt dasselbe mit eigenen Worten: Auf der RTX PRO 6000 Server Edition läuft ein 70B-Modell in FP8 und NVFP4 auf einer Karte, und BF16 braucht vier oder acht Karten.

Die 128 GB des Spark werden auf zwei Arten falsch gelesen. Es ist gemeinsamer Systemspeicher, den sich eine Arm-CPU mit 20 Kernen, DGX OS und die Desktop-Sitzung teilen, kein Framebuffer: nvidia-smi gibt auf dieser Plattform „Memory-Usage: Not Supported“ aus, und NVIDIA warnt, dass cudaMemGetInfo weniger meldet, als sich tatsächlich belegen lässt. NVIDIA veröffentlicht keine Angabe zur nutzbaren Kapazität; die eigenen Playbooks setzen 0,8 des Speichers in vLLM und 0,80 bis 0,9 in TensorRT-LLM als Standard, was ein Arbeitsbudget von rund 102 bis 115 GB ergibt. Das ist unsere Rechnung aus NVIDIAs Voreinstellungen, keine Spezifikation.

Die zweite Fehllesung ist die Schlagzeile. NVIDIA schreibt, ein Spark könne „KI-Modelle mit bis zu 200 Milliarden Parametern testen, validieren und inferenzieren“. Das stimmt, und es ist eine 4-Bit-Aussage: 200 Milliarden × 0,5 Byte sind 100 GB Gewichte, es bleiben zehn bis achtundzwanzig Gigabyte für Cache, Aktivierungen und Betriebssystem. In FP8 erreicht dieselbe Box rund 110 Milliarden Parameter und in BF16 rund 55 Milliarden. Wer „200B auf dem Schreibtisch“ als BF16-Aussage liest, bemisst das Projekt um das Vierfache falsch.

Zu passen ist nur das erste Tor. Die Token-Generierung liest für jedes ausgegebene Token jedes Gewicht erneut aus dem Speicher, die Rate je Nutzer bei kleiner Batchgröße ist also Bandbreite geteilt durch die Byte der Gewichte, nicht FLOPS.

Unsere Rechnung: Bandbreite geteilt durch 70,6 GB. Eine Obergrenze, die reale Systeme nicht erreichen, keine Messung. In NVFP4 ist dasselbe Modell 35,3 GB, und jede Obergrenze verdoppelt sich ungefähr.

Drei Komma neun Token pro Sekunde ist die schärfste Zahl hier. Stilles Lesen von Sachtexten liegt im Mittel bei 238 Wörtern pro Minute, was bei etwa 0,75 Wörtern je Token rund 5,3 Token pro Sekunde entspricht. Ein dichtes 70B-Modell in FP8 erreicht auf einem Spark nicht einmal theoretisch Lesegeschwindigkeit, und die Theorie ist großzügig: NVIDIAs eigene Spark-Messungen nennen Llama 3.1 8B in NVFP4 mit 38,65 Token pro Sekunde gegen eine Obergrenze von 68 und Qwen3 14B mit 22,71 gegen 39, beide nahe 57 Prozent der Obergrenze, was das dichte 70B-Modell eher bei zwei als bei vier ansiedelt. Jeder Spark-Benchmark, den NVIDIA veröffentlicht, ist 4 Bit bei Batchgröße eins.

Darum führen die FLOPS-Schlagzeilen in die Irre, und beide, denen ein Ingenieur begegnet, sind nach den Fußnoten des Herstellers Sparsity-Werte. NVIDIAs Spark-Seite druckt „bis zu 1 PFLOP FP4“ unter der Fußnote „theoretische FP4-TOPS unter Nutzung der Sparsity-Funktion“ und veröffentlicht nirgends einen dichten Wert für GB10. Die Seite der RTX PRO 6000 Server Edition druckt 4 PFLOPS FP4, 2 PFLOPS FP8 und 1 PFLOP FP16 ohne Angabe der Basis, aber das Architektur-Whitepaper nennt für die Workstation Edition Paare aus dicht und Sparsity, 2.015,2 gegen 4.030,4 TFLOPS in FP4, mit der Fußnote „effektive TOPS/TFLOPS unter Nutzung der Sparsity-Funktion“, und diese dichten Werte skalieren auf die veröffentlichten Zahlen der Server Edition. Halbieren Sie sie. Jede Tensor-Angabe im Datenblatt der H200 NVL trägt ebenfalls „mit Sparsity“. Übliches LLM-Serving nutzt keine strukturierte 2:4-Sparsity, und keine dieser Zahlen sagt Token pro Sekunde bei Batchgröße eins voraus. Die Bandbreite tut es.

Gleichzeitigkeit ändert die Antwort

Ein Entwickler und zwanzig Angestellte sind verschiedene Maschinen, und der Grund ist der Key-Value-Cache. Jedes aktive Gespräch hält Keys und Values für jedes Token, das es gesehen hat, bemessen als 2 × Schichten × Key-Value-Köpfe × Kopfdimension × Byte je Element × Sequenzlänge. Grouped-Query-Attention macht das Serving auf einer Karte überhaupt möglich: Llama 3.1 70B hat 80 Schichten, 64 Query-Köpfe und 8 Key-Value-Köpfe, kostet also 320 KiB je Token in FP16 statt der 2.560 KiB, die es ohne GQA kosten würde.

Rechnen Sie das gegen eine 96-GB-Karte, bei vLLMs Standard von 90 Prozent der Karte abzüglich etwa 3 GiB für Aktivierungen und CUDA-Graphen.

Maximale gleichzeitige Sequenzen, die jeweils einen Kontext voller Länge halten, mit einem FP16-Cache / einem FP8-Cache. Eher eine Untergrenze als eine Obergrenze, da PagedAttention Blöcke nach Bedarf zuteilt, aber es entscheidet, ob eine Anfrage angenommen oder eingereiht wird.

Lesen Sie die beiden 70B-Zeilen zusammen. In FP8 lässt das Modell 17,6 GiB Cache übrig, sieben volle 8K-Sitzungen oder eine mit 32K; in NVFP4 sind es 50,5 GiB und zwanzig. Die Entscheidung über die Quantisierung kauft auf einer Karte mehr Gleichzeitigkeit, als eine zweite Karte es täte. Langer Kontext lässt die Gleichzeitigkeit schneller einbrechen als die Modellgröße, und darum lautet die erste Frage nicht, wie viele Nutzer es sind, sondern wie lang die Gespräche werden.

Eine ehrliche Lücke gehört hierher. NVIDIA veröffentlicht für keine Edition der RTX PRO 6000 eine absolute LLM-Angabe in Token pro Sekunde, und eine von MLCommons verifizierte MLPerf-Einreichung für die Karte gibt es nicht; die eigene Seite zur Inferenzleistung führt diese GPU nur mit Vision- und Bildgenerierungsmodellen. Die veröffentlichten LLM-Aussagen sind relativ, gegen eine L40S als Basis, ohne genannte Genauigkeit und ohne genannte Batchgröße. Die Messung, die es gibt, ist die auf Ihrer eigenen Karte, wo vLLM beim Start GPU KV cache size und Maximum concurrency ausgibt.

Für die Größenordnung der Antwort bemisst NVIDIAs Referenzarchitektur eine einzelne H100 NVL mit 137 gleichzeitigen Nutzern auf Llama 3.1 8B in FP8, bei 2.977 Token pro Sekunde und einer Zeit bis zum ersten Token nahe 987 ms: anderes Silizium mit HBM3, also kein Ersatzwert, aber es zeigt die Größenordnung. Die Branche liefert interaktive Dienste gegen etwa 50 Token pro Sekunde je Nutzer und eine Zeit bis zum ersten Token von höchstens 250 ms aus, acht- bis zehnmal echte Lesegeschwindigkeit. Der Artikel zur Gleichzeitigkeit rechnet es durch.

Kommen die Nutzer als virtuelle Maschinen statt als API-Clients, kehrt die Frage nach der Edition zurück. vGPU läuft auf der RTX PRO 6000 Server Edition ab vGPU 19.0; die Workstation Edition und die Max-Q stehen überhaupt nicht auf NVIDIAs Liste der unterstützten Karten. MIG teilt jede der drei in vier Instanzen zu 24 GB, zwei zu 48 GB oder eine zu 96 GB, und für Compute-Profile liegt die Obergrenze bei 12 zeitgeteilten virtuellen Maschinen zu 8 GB. Unser Leitfaden zu MIG und vGPU hat die Tabellen.

Wo jede der drei scheitert

Jede der drei ist für manche Projekte richtig und für andere falsch. Das sind die Fehlschläge, die uns tatsächlich begegnen, und was gegen jeden hilft.

Der DGX Spark scheitert an der Geschwindigkeit, nicht an der Größe. Er lädt ein Modell, das er anschließend zu langsam bedient, um es vor einen Menschen zu stellen, und das geht schlechter aus, als es gar nicht erst zu laden: 273 GB/s liegen um den Faktor 6,6 unter einer RTX-PRO-6000-Workstation-Karte und um den Faktor 17,6 unter einer H200 NVL. NVIDIA positioniert ihn als Maschine, auf der prototypisiert, feinabgestimmt und validiert wird, bevor die Arbeit in ein Rechenzentrum wandert. Kaufen Sie ihn also für die Leute, die den Code schreiben, und entscheiden Sie die Serving-Hardware, sobald der Prototyp Modell, Genauigkeit und Kontextlänge geklärt hat. Achten Sie auch auf die Umgebung: 5 bis 30 °C sind für ein Büro eng, und GPUDirect RDMA wird wegen des Modells mit gemeinsamem Speicher nicht unterstützt. Wirklich stark ist die Box beim Fine-Tuning, und NVIDIAs dokumentierte Leiter auf einem Gerät ist ein volles Fine-Tuning bei 3B, LoRA bei 8B und QLoRA bei 70B, gemessen mit 13.519,54, 6.969,59 und 759,79 Token pro Sekunde in der Spitze. Der Benchmark-Artikel hat die Tabelle.

Die RTX PRO 6000 scheitert an der Edition und an der Kontextlänge. Eine Workstation Edition, die für ein Rack bestellt wurde, ist eine 600-W-Karte mit Double-Flow-Through-Kühlung, die kein Server annimmt, und ohne vGPU; eine Server Edition, die für eine Workstation bestellt wurde, ist eine passive Karte ohne Lüfter. Dann der Speicher: 96 GB sind für ein 70B-Modell in NVFP4 bequem und in FP8 knapp, und geleert werden sie von langen Gesprächen, nicht von Parameterzahlen. Eine Karte ist außerdem eine Fehlerdomäne, und daran ändern weder MIG noch vGPU etwas, da beide eine einzelne physische GPU aufteilen. Legen Sie die Edition danach fest, wo die Karte stehen wird, quantisieren Sie, bevor Sie eine zweite Karte kaufen, und wenn der Dienst zählt, setzen Sie die zweite Karte in einen zweiten Host.

Die H200 NVL scheitert am Gehäuse, nicht an der Karte. Der Support gilt je Konfiguration und nicht je Server, und die Hürden sind allesamt Blocker für die Nachrüstung. Dell führt die Karte nur auf Systemen der 17. Generation, höchstens zwei in einem R770 oder R7725, und nicht in den Tabellen zu 15G oder 16G; ein Server, den Sie bereits besitzen, kann also fehlen. Lenovo unterstützt sie im SR650a V4 und schreibt, sie sei „auf dem SR650 V4 nicht unterstützt“, zwei Maschinentypen dessen, was wie eine einzige 2U-Familie aussieht. Jenseits der Modellnummer stehen benannte Teile: Dells HPR-Platinum-Lüfter, die Riser-Kits und je Steckplatz eine andere Teilenummer für das Stromkabel; Lenovos Lüftermodul für 600 W, der vordere Luftkanal in doppelter Breite, ausschließlich die Steckplätze 21 und 23 und eine Umgebungsgrenze von 30 °C. Die Laufwerks-Backplane kann die GPU für sich allein ausschließen, weil sie den Luftwiderstand vor der Karte bestimmt. Und der Fehler, der ein Wartungsfenster kostet: Das 16-polige Hilfskabel muss für die Klasse 451 bis 600 W kodiert sein, sonst bootet die Karte gar nicht, statt gedrosselt zu laufen. Prüfen Sie Maschinentyp, Backplane, Riser, Lüfterkit, Luftkanal und die Teilenummer des Kabels vor der Bestellung: Weder NVIDIA noch die Hersteller veröffentlichen eine Luftmengenangabe, gegen die sich ein Gehäuse prüfen ließe, die Liste der unterstützten Konfigurationen ist also die thermische Spezifikation. Die Nachrüst-Checkliste ist die lange Fassung.

Wie der Ausbauweg von jedem Startpunkt aussieht

Die drei Startpunkte skalieren auf drei verschiedene Arten, und nur einer davon skaliert, indem Sie eine weitere Box derselben Art danebenstellen.

Nehmen Sie den Spark-Weg zuerst, denn eine Aussage dazu ist veraltet. Der DGX Spark hört nicht bei zwei Geräten auf: NVIDIAs Clustering-Dokumentation unterstützt bis zu drei Systeme, die direkt über Kabel verbunden sind, und bis zu vier über einen Switch. Die beiden veröffentlichten Angaben zur Modellgröße widersprechen sich auf NVIDIAs eigenen Seiten, 405 Milliarden über zwei Geräte und 700 Milliarden über vier, und beide gelten nur bei 4 Bit: 405 Milliarden × 0,5 Byte sind etwa 203 GB gegen 256 GB in zwei Geräten, und 700 Milliarden × 0,5 sind etwa 350 GB gegen 512 GB in vier Geräten. NVIDIAs Tabelle der validierten Modelle markiert genau einen Eintrag als Multi-Node, Qwen3-235B-A22B in NVFP4, gemessen mit 11,73 Token pro Sekunde über zwei Sparks. Wachstum kauft hier Kapazität, keine Geschwindigkeit. Der Artikel zum Clustering behandelt die Verkabelung.

Der Weg über die RTX PRO 6000 trägt die Einschränkung, die die meisten überrascht: Es gibt in keiner Edition NVLink, weder bei den Workstation-Karten noch bei der Server Edition. Lenovos Produkthandbuch schreibt es nüchtern hin, NVIDIAs Spezifikationstabellen lassen es aus, und die Referenzarchitektur beschreibt die Platzierung der GPUs rein in PCIe-Begriffen. Der Abstand zu einer Karte mit Bridge beträgt etwa das Siebenfache, 128 GB/s gegen 900 GB/s. Die Leiter lautet also: erst quantisieren, bevor Sie in die Breite gehen, denn Gewichte in FP8 oder NVFP4 auf einer Karte schlagen BF16, verteilt über zwei Karten ohne schnelle Verbindung; dann unabhängige Repliken ergänzen, eine Modellinstanz je Karte hinter einem Load Balancer, was keinen Verkehr zwischen GPUs erzeugt und die Verfügbarkeit verdoppelt; und erst, wenn das Modell wirklich nicht passt, es aufteilen, mit Pipeline-Parallelismus vor Tensor-Parallelismus, was vLLMs eigene Empfehlung für Knoten ohne NVLink ist.

Der Weg über die H200 NVL ist der für Wachstum gebaute, mit einem Vorbehalt zur Geometrie. Jede Karte trägt genau eine Bridge, die größte Änderung gegenüber der H100 NVL mit ihren dreien, ein vorhandener Bridge-Satz lässt sich also nicht übernehmen. Die Karten müssen physisch benachbart sein und an derselben CPU hängen, was in einem Server, dessen Riser die GPUs zwei und zwei auf die Sockel verteilen, die 4-Wege-Bridge wie vorgesehen unmontierbar macht. Planen Sie die Steckplatzbelegung vor der Bestellung. Unser direkter Vergleich führt diese beiden Karten weiter.

Ist die Antwort wirklich unklar, gibt es eine vertretbare Reihenfolge. Starten Sie auf einem Spark, solange Modell, Genauigkeit und Kontextlänge noch in Bewegung sind. Wechseln Sie auf eine RTX PRO 6000, wenn ein Team die Sache täglich nutzt und die Bandbreite zur Beschwerde wird. Wechseln Sie auf die H200 NVL, wenn Latenz, langer Kontext oder ein Modell, das über GPUs verteilt werden muss, die Bridge und die 4,8 TB/s zum Sinn des Kaufs machen.

Was wir liefern

Eurokommerz liefert alle drei, in jeder Stückzahl, auf einem europäischen Vertrag: DGX-Spark-Geräte, RTX PRO 6000 Blackwell-Karten in allen drei Editionen samt Workstation oder Server darum herum und H200-NVL-Karten mit den Bridges, Kabeln, Lüfterkits und Gehäusen, welche die Herstellerdokumentation verlangt. Der schnellste Weg zur richtigen Antwort führt über drei Angaben: welches Modell Sie betreiben wollen und in welcher Genauigkeit, wie viele Menschen es gleichzeitig nutzen und wo die Maschine physisch stehen wird. Damit liefern wir die Speicherrechnung, die Bandbreitenobergrenze und die Teileliste.

FAQ