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

Vier Fragen, die über die Hardware entscheiden

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. Zwischen ihnen entscheiden vier Fragen zum Projekt.

Wie groß ist das Modell, und in welcher Genauigkeit? Die Parameterzahl allein ergibt noch nicht den Speicherbedarf. Dieselben 70 Milliarden Parameter belegen 141,1 GB in BF16, etwa 72,7 GB in FP8 und etwa 42,7 GB in NVFP4; die Wahl der Genauigkeit, die in dieser Phase oft noch nicht getroffen ist, verändert die Hardware also um mehr als den Faktor drei.

Wie viele Menschen nutzen es gleichzeitig? Ein Entwickler, der an Prompts feilt, ist eine Batchgröße von eins, und genau so hat NVIDIA seine Spark-Inferenzwerte vom Oktober 2025 gemessen. Zwanzig Personen, die einen Assistenten nutzen, sind zwanzig gleichzeitige Sequenzen, von denen jede ihren eigenen Key-Value-Cache hält, und auf einer einzelnen Karte bestimmt eher der Cache als die Gewichte, wie viele davon Platz finden.

Wo wird die Hardware installiert? Ein DGX Spark misst 150 mm im Quadrat, ist 50,5 mm hoch, wiegt 1,2 kg, arbeitet idealerweise bei 5 bis 30 °C und zieht nach NVIDIAs Angabe 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 ihren Steckplatz braucht, in einem Server auf der Supportliste des Herstellers. Das erste ist eine Anschaffung für den Schreibtisch, das zweite ein Serverprojekt für das Rechenzentrumsteam.

Was passiert nach dem Pilotprojekt? Jede Option wächst anders, und zwei der drei haben eine Grenze, die in der Hardware liegt; der Ausbauweg gehört deshalb schon in die erste 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 deren Vorgaben die von NVIDIA ersetzen. Die Zeile zur Bandbreite ist die wichtigste, denn sie bestimmt die Geschwindigkeit der Token-Generierung.

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.

Die am häufigsten zitierte Bandbreite der RTX PRO 6000, 1.792 GB/s, ist der Wert der Workstation Edition und der Max-Q. Die Server Edition, die einzige Edition mit passiver Kühlung für den Einbau in ein Gehäuse und die einzige auf NVIDIAs vGPU-Liste, läuft mit 1.597 GB/s, etwa 11 Prozent weniger. Wer ein Rack-Deployment mit 1.792 GB/s bemisst, überschätzt dessen Token-Generierung deshalb um rund 12 Prozent. Unser Editionsvergleich behandelt den Rest.

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 NVIDIAs Testlizenz über 90 Tage.

Speicherkapazität, Bandbreite und Token pro Sekunde

Gewichte sind Parameter mal Byte je Parameter: zwei in BF16 oder FP16, eines in FP8 und in NVFP4 ein halbes Byte plus ein FP8-Skalierungsfaktor je 16 Gewichte, wobei Embeddings und Ausgabeschicht in FP8- wie in NVFP4-Checkpoints meist in BF16 bleiben. NVIDIAs NVFP4-Checkpoint von Llama 3.3 70B hat 42,7 GB, etwa 0,61 Byte je Parameter. Bei MXFP4-Checkpoints kommt dasselbe hinzu: ein gemeinsamer Skalierungsfaktor je Block von Gewichten und einige Schichten in höherer Genauigkeit. Ob ein Modell überhaupt lädt, ergibt sich aus dieser Rechnung.

Nur Gewichte. BF16 aus den Parameterzahlen 8,03B, 32,76B und 70,55B; FP8 aus den veröffentlichten FP8-Checkpoints (NVIDIAs für die Llama-Modelle, Qwens für Qwen3-32B), die Embeddings und Ausgabeschicht in BF16 halten; NVFP4 aus NVIDIAs Checkpoints von Qwen3-32B und Llama 3.3 70B (dieselbe Architektur wie 3.1 70B), für das 8B-Modell nach unserer Rechnung, mit 0,5625 Byte je Gewicht für die linearen Schichten und 2 Byte für Embeddings und Ausgabeschicht. Cache, Aktivierungen und Framework-Overhead kommen obendrauf; der VRAM-Leitfaden hat die Formel.

Ein 70B-Modell in BF16 braucht 141,1 GB, das sind 131,4 GiB. Es lädt auf einer H200 NVL, deren Treiber 140,4 GiB meldet, mit etwa 9 GiB Rest und ohne Platz für Nutzer, und es passt weder auf die 96 GB der RTX PRO 6000 noch in die 128 GB des Spark. NVIDIAs NIM-Dokumentation führte ein 70B-Modell auf der RTX PRO 6000 Server Edition in FP8 ab einer Karte und in BF16 nur auf vier oder acht Karten; die aktuelle Supportmatrix von NIM 2 (Stand Oktober 2026) listet ihre Profile ohne Kartenzahlen je GPU auf.

Für die Bemessung gelten bei den 128 GB des Spark zwei Vorbehalte. Es handelt sich um gemeinsamen Systemspeicher, den sich eine Arm-CPU mit 20 Kernen, DGX OS und die Desktop-Sitzung teilen, nicht um einen 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. NVIDIAs vLLM-Startskript für einen Spark, auf das das Playbook auf build.nvidia.com verweist, setzt 0,7 des Speichers; das vLLM-Playbook auf GitHub setzt auf einem Spark bis zu 0,8 und auf zwei Spark-Systemen 0,8 oder 0,9, und der KV-Cache von TensorRT-LLM erhält 0,80 bis 0,9 des Speichers, der nach dem Laden der Gewichte noch frei ist. Auf den gesamten Speicher bezogen, ergeben die Einstellungen 0,8 und 0,9 ein Arbeitsbudget von rund 102 bis 115 GB und 0,7 von rund 90 GB. Das ist unsere Rechnung aus NVIDIAs Playbook-Einstellungen, keine Spezifikation.

Der zweite Vorbehalt betrifft die Zahl, mit der NVIDIA wirbt. NVIDIA schreibt, ein Spark mit 128 GB könne „KI-Modelle mit bis zu 200 Milliarden Parametern testen, validieren und inferenzieren“. Das gilt bei 4 Bit, mit wenig Spielraum. Bei 4,25 bis 4,5 Bit je Gewicht mit den Blockskalierungen belegen 200 Milliarden Parameter 106 bis 112 GB, es bleiben 16 bis 22 GB der 128 GB für Cache, Aktivierungen und Betriebssystem. In FP8 erreicht dasselbe System rund 110 Milliarden Parameter und in BF16 rund 55 Milliarden. Wer „200B auf dem Schreibtisch“ als BF16-Aussage liest, bemisst das Projekt um fast das Vierfache falsch.

Passt ein Modell, hängt seine Geschwindigkeit von der Speicherbandbreite ab. 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.

Die Werte sind unsere Rechnung, Bandbreite geteilt durch die 70,6 GB Gewichte, die je Token gelesen werden; es sind Obergrenzen, die reale Systeme nicht erreichen, keine Messungen. In NVFP4 werden je Token etwa 40,6 GB gelesen, die 4-Bit-Schichten plus die Ausgabeschicht in BF16, und jede Obergrenze steigt um etwa drei Viertel.

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 mit einer Obergrenze von 3,9 Token pro Sekunde nicht einmal theoretisch Lesegeschwindigkeit. Gemessene Raten liegen unter der Obergrenze. NVIDIAs Spark-Messungen nennen Llama 3.1 8B in NVFP4 mit 38,65 Token pro Sekunde gegen eine Obergrenze von etwa 55 und Qwen3 14B mit 22,71 gegen etwa 30. Nach unserer Rechnung aus den je Token gelesenen Bytes laufen beide bei rund 70 bis 75 Prozent der Obergrenze, was das dichte 70B-Modell eher bei drei als bei vier Token pro Sekunde ansiedelt. NVIDIAs Spark-Inferenzwerte vom Oktober 2025 sind alle 4 Bit bei Batchgröße eins; sein Test in FP8 mit vLLM vom März 2026 endet bei vier gleichzeitigen Aufgaben.

Aus demselben Grund führen die FLOPS-Schlagzeilen in die Irre, und beide Schlagzeilenwerte in diesem Vergleich sind nach der Dokumentation des jeweiligen Herstellers Sparsity-Werte. NVIDIAs Hardware-Handbuch zum DGX Spark nennt „bis zu 1 PFLOP (PetaFLOP) bei FP4-Genauigkeit mit Sparsity“, und wir haben bei NVIDIA für GB10 weder einen dichten Wert noch einen Wert für FP8 oder BF16 gefunden. Die Seite der RTX PRO 6000 Server Edition nennt 4 PFLOPS FP4, 2 PFLOPS FP8 und 1 PFLOP FP16 ohne Angabe der Basis. Das Architektur-Whitepaper nennt für die Workstation Edition Paare aus dichtem Wert und Sparsity-Wert, 2.015,2 gegen 4.030,4 TFLOPS in FP4, mit der Fußnote „effektive TOPS/TFLOPS unter Nutzung der Sparsity-Funktion“, und seine Sparsity-Werte entsprechen den veröffentlichten Zahlen der Server Edition; die dichten Raten betragen also die Hälfte der Schlagzeilenwerte. Jede Tensor-Angabe der H200 NVL von TF32 bis INT8 trägt ebenfalls „mit Sparsity“: 3.341 TFLOPS in FP8 und 1.671 TFLOPS in BF16, einen FP4-Wert führt die Seite nicht. Nach NVIDIAs eigenen Angaben erreicht keine der drei Optionen 4 PFLOPS in FP8, auch nicht mit Sparsity, denn die 4 PFLOPS der RTX PRO 6000 sind ihr FP4-Wert. Der FP8-Wert nahe 4 PFLOPS auf NVIDIAs H200-Seite, 3.958 TFLOPS mit Sparsity, gehört zum H200-SXM-Modul und nicht zur H200-NVL-Karte. Ein Server erreicht nach NVIDIAs Werten je Karte 4 PFLOPS in FP8 mit zwei RTX PRO 6000 Server Edition, mit Sparsity gerechnet, oder mit vier, ohne Sparsity gerechnet, wie im Inferenzknoten mit vier Karten auf unserer Seite KI-Server; unser Vergleich der GPU-TFLOPS rechnet den 4-PFLOPS-FP8-Server durch. Übliches LLM-Serving nutzt keine strukturierte 2:4-Sparsity, und keine dieser Zahlen sagt die Token pro Sekunde bei Batchgröße eins voraus, die von der Bandbreite abhängen.

Gleichzeitige Nutzer und der KV-Cache auf einer 96-GB-Karte

Für zwanzig Angestellte braucht es wegen des Key-Value-Cache eine andere Maschine als für einen Entwickler. 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.

Die Tabelle wendet das auf eine 96-GB-Karte an: 90 Prozent der 95,6 GiB, die der Treiber meldet, was bis Release 0.19 der Standard von vLLM war (0,92 seit 0.20.0 vom April 2026) und unser Planungswert ist, 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. Die Zahlen sind eher eine Untergrenze als eine Obergrenze, da PagedAttention Blöcke nach Bedarf zuteilt, aber sie entscheiden, ob eine Anfrage angenommen oder eingereiht wird. FP8-Gewichte sind die veröffentlichten FP8-Checkpoints, die Embeddings und Ausgabeschicht in BF16 halten.

In den 70B-Zeilen lassen FP8-Gewichte 15,3 GiB Cache übrig, sechs volle 8K-Sitzungen oder eine mit 32K; mit NVFP4-Gewichten sind es 43,2 GiB und siebzehn Sitzungen. Die Wahl der Quantisierung bringt auf einer Karte mehr Gleichzeitigkeit als eine zweite Karte mit einer zweiten Modellkopie. Die Kontextlänge senkt die Gleichzeitigkeit schneller als die Modellgröße; fragen Sie deshalb zuerst, wie lang die Gespräche werden, und erst dann, wie viele Nutzer es sein werden.

Nennen Sie uns Ihr Modell und die Länge der Gespräche, und wir rechnen diese Tabelle für Ihren Fall durch und ermitteln die Zahl der Karten, die sich daraus ergibt.

In den veröffentlichten Daten gibt es eine Lücke. NVIDIAs absolute LLM-Angaben für die Karte sind Werte zum maximalen Durchsatz der Server Edition in der Performance-Übersicht zu TensorRT-LLM, gemessen mit der eigenen Engine; so erreicht etwa Qwen3-30B-A3B in FP4 auf einer GPU 9.938 Ausgabe-Token pro Sekunde und GPU bei 1.000 Token Eingabe und 1.000 Token Ausgabe. Wir haben bei NVIDIA keine Angabe je Nutzer gefunden. Die von MLCommons verifizierten Ergebnisse für die Karte in MLPerf® Inference v6.0 vom April 2026 sind Durchsätze von Servern mit mehreren GPUs, keine Raten je Nutzer. NVIDIAs Seite zur Inferenzleistung führt diese GPU nur mit Vision-, Bild- und Videogenerierungsmodellen, und die übrigen LLM-Aussagen, die NVIDIA veröffentlicht, sind relativ, gegen eine L40S als Basis, ohne genannte Genauigkeit und ohne genannte Batchgröße. Für Ihr Modell und Ihren Kontext kommt der verlässliche Wert von Ihrer eigenen Karte, auf der vLLM beim Start GPU KV cache size und Maximum concurrency ausgibt.

Beispiel: Eintrag 6.0-0004, MLPerf® Inference v6.0 Datacenter, Closed Division, Kategorie Available, Llama 2 70B (llama2-70b-99), Szenario Interactive, acht Karten RTX PRO 6000 Blackwell Server Edition, 6.238,12 Token pro Sekunde mit FP4-Gewichten, abgerufen von mlcommons.org am 24. September 2026. Ergebnis von der MLCommons Association verifiziert. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

Das Szenario Interactive von MLPerf® Inference v6.0 für Llama 2 70B verlangt zum Vergleich das erste Token innerhalb von 450 ms und danach höchstens 40 ms je Token, also 25 Token pro Sekunde je Nutzer, rund das Fünffache der mittleren stillen 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.

Grenzen jeder Option und wie Sie damit planen

Jede Option hat ihr typisches Fehlerbild, und für jedes gibt es einen Ausweg.

Den DGX Spark begrenzt die Speicherbandbreite. Er lädt Modelle, mit denen er anschließend für die interaktive Nutzung zu langsam generiert: Ein dichtes 70B-Modell in FP8 bleibt unter 4 Token pro Sekunde. Seine 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. Als ideale Betriebstemperatur nennt NVIDIA 5 bis 30 °C, und GPUDirect RDMA wird wegen des Modells mit gemeinsamem Speicher nicht unterstützt. Beim Fine-Tuning ist der DGX Spark stark. NVIDIA dokumentiert auf einem DGX Spark 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.

Bei der RTX PRO 6000 entstehen Probleme durch die falsche Edition und durch lange Kontexte. Eine Workstation Edition, die für ein Rack bestellt wurde, ist eine 600-W-Karte mit Double-Flow-Through-Kühlung, die kein Server aufnimmt, und sie unterstützt kein vGPU; eine Server Edition, die für eine Workstation bestellt wurde, ist eine passive Karte ohne Lüfter. Ihre 96 GB sind für ein 70B-Modell in NVFP4 bequem und in FP8 knapp, und gefüllt werden sie eher vom Cache langer Gespräche als von der Parameterzahl. Eine Karte ist außerdem eine Fehlerdomäne, und daran ändern weder MIG noch vGPU etwas, da beide eine einzelne physische GPU aufteilen. Wählen Sie die Edition nach dem Einbauort der Karte, quantisieren Sie, bevor Sie eine zweite Karte kaufen, und wenn der Dienst wichtig ist, setzen Sie die zweite Karte in einen zweiten Host.

Bei der H200 NVL entscheidet das Servergehäuse. Der OEM-Support gilt je Konfiguration und nicht je Servermodell, und jede einzelne Anforderung kann eine Nachrüstung verhindern. 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 allein kann die GPU ausschließen, weil sie den Luftwiderstand vor der Karte bestimmt. Außerdem muss das 16-polige Hilfskabel für die Klasse 451 bis 600 W kodiert sein; sonst bootet die Karte gar nicht, statt gedrosselt zu laufen, und das Wartungsfenster ist verloren. Prüfen Sie Maschinentyp, Backplane, Riser, Lüfterkit, Luftkanal und die Teilenummer des Kabels vor der Bestellung: Wir haben weder bei NVIDIA noch bei den Herstellern eine Luftmengenangabe gefunden, 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.

Steht der Server bereits in Ihrem Rack, teilen Sie uns den genauen Maschinentyp und die Konfiguration mit; wir prüfen Strom und Luftstrom, bevor Sie die H200 NVL bestellen, und nicht erst danach.

Wie der Ausbauweg von jedem Startpunkt aussieht

Der DGX Spark wächst um weitere Systeme, die RTX PRO 6000 um weitere Karten über PCIe und die H200 NVL um weitere Karten, je zwei oder vier per Bridge verbunden.

NVIDIAs Clustering-Dokumentation unterstützt bis zu drei Systeme, die direkt über Kabel verbunden sind, und bis zu vier über einen Switch, und NVIDIA hat die Unterstützung von Clustern mit bis zu acht Sparks in manueller Konfiguration angekündigt (NVIDIA-Blog, 21. Oktober 2026). NVIDIAs Produktseite nennt inzwischen bis zu 400 Milliarden Parameter über zwei Spark-Systeme und 700 Milliarden über vier (das Hardware-Handbuch nennt für zwei weiterhin 405 Milliarden), und beide Angaben gelten nur bei 4 Bit. Bei 4,5 Bit je Gewicht sind 405 Milliarden Parameter etwa 228 GB gegen die 256 GB von zwei Spark-Systemen und 700 Milliarden etwa 394 GB gegen die 512 GB von vier. NVIDIAs Tabelle der validierten Modelle markiert genau einen Eintrag als Multi-Node, Qwen3-235B-A22B in NVFP4, den NVIDIA im Oktober 2025 mit 11,73 Token pro Sekunde auf zwei Spark-Systemen gemessen hat. Zusätzliche Spark-Systeme erweitern in erster Linie die Speicherkapazität und erhöhen die Geschwindigkeit je Anfrage höchstens teilweise. Der Artikel zum Clustering behandelt die Verkabelung.

Die RTX PRO 6000 hat in keiner Edition NVLink, weder bei den Workstation-Karten noch bei der Server Edition. Lenovos Produkthandbuch sagt das ausdrücklich, NVIDIAs Spezifikationstabellen lassen es aus, und die Referenzarchitektur beschreibt die Platzierung der GPUs rein in PCIe-Begriffen. Gegenüber einer Karte mit Bridge beträgt der Abstand etwa das Siebenfache, 128 GB/s gegen 900 GB/s. Daraus ergibt sich die Reihenfolge der Schritte. Quantisieren Sie zuerst, denn Gewichte in FP8 oder NVFP4 auf einer Karte sind BF16-Gewichten überlegen, die ohne schnelle Verbindung über zwei Karten verteilt sind. Ergänzen Sie dann unabhängige Repliken, eine Modellinstanz je Karte hinter einem Load Balancer, was keinen Verkehr zwischen GPUs erzeugt und die Verfügbarkeit verdoppelt. Teilen Sie ein Modell nur dann auf, wenn es nicht auf eine Karte passt oder wenn lange Gespräche mehr Cache brauchen, als eine Kopie je Karte übrig lässt, und bevorzugen Sie dann Pipeline-Parallelismus vor Tensor-Parallelismus, was vLLMs 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. NVIDIAs Product Brief schreibt, per Bridge verbundene Karten sollten in derselben CPU-Domäne sitzen, und führt eine Bridge über CPUs hinweg als zulässig, aber nicht empfohlen; in einem Server, dessen Riser die GPUs zwei und zwei auf die Sockel verteilen, würde eine 4-Wege-Bridge beide Sockel überspannen, was NVIDIA nicht empfiehlt. Planen Sie die Steckplatzbelegung vor der Bestellung. Unser direkter Vergleich führt diese beiden Karten weiter. Unser Vergleich von DGX Spark und H200 NVL behandelt den Schritt von der Entwicklung in die Produktion.

Ist die Wahl noch offen, bietet sich diese Reihenfolge als Standardweg an. Starten Sie auf einem Spark, solange sich Modell, Genauigkeit und Kontextlänge noch ändern. Wechseln Sie auf eine RTX PRO 6000, wenn ein Team den Dienst täglich nutzt und die Generierungs­geschwindigkeit zur Grenze wird. Teilen sich mehrere Teams einen Dienst, betreibt ein Server mit vier RTX PRO 6000 Server Edition vier unabhängige Kopien: Mit einem 70B-Modell in NVFP4 sind das 68 volle 8K-Gespräche mit FP16-Cache oder 136 mit FP8-Cache. 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 eigentlichen Kaufgrund machen.

Was wir liefern

Wir liefern alle drei unter einem EU-Vertrag und auf einer Rechnung: den DGX Spark, die RTX PRO 6000 Blackwell in allen drei Editionen samt Workstation oder Server und die H200 NVL mit ihren NVLink-Bridges. Die Karten kommen in auf Bestellung gebaute KI-Server oder, nach einer Kompatibilitätsprüfung von Plattform, Stromversorgung und Kühlung, in einen Server, den Sie bereits besitzen. Mengen und Lieferzeit bestätigen wir schriftlich mit dem Angebot.

FAQ