1T-Modelle für 100 Nutzer: eine DGX B300 oder zwei Server mit acht H200 NVL

Was 100 Nutzer eines 1T-Modells brauchen

Hundert Menschen, die im selben Moment mit einem Modell von 750B bis 1,6T Parametern arbeiten, brauchen mehr als die Gewichte. Für Gespräche zu je 32K Token erreicht ein Server mit acht H200 NVL diese Zahl nach unserer Regel für Nutzer je Karte vom Speicher her bei Kimi K2.6 und DeepSeek-V4-Pro, und bei Muse Spark Open in NVFP4, wenn die Engine es weight-only ausführt. GLM-5.3 braucht zwei solche Server als eine Kopie oder eine DGX B300 mit zwei Pipeline-Stufen, Muse Spark Open in BF16 zwei Server oder eine DGX B300.

Unsere Modell-Leitfäden enden an dieser Stelle: In ihren Zellen für 100 Nutzer steht bei einigen dieser Modelle „über 8“, weil sie einen Server rechnen. Dieser Artikel geht den nächsten Schritt und vergleicht zwei Server mit je acht H200 NVL, 16 Karten in vier NVLink-Domänen zu je vier, mit einer NVIDIA DGX B300, acht B300-GPUs in einer NVLink-Domäne. Die H200-NVL-Server bauen wir auf Bestellung, die DGX B300 liefern wir projektbezogen. Die Modellzahlen stammen aus den Dateilisten auf Hugging Face, die wir am 24. Oktober 2026 summiert haben, und aus unseren Leitfäden zu Kimi K2, GLM, DeepSeek-V4-Pro und Muse Spark Open.

Gespräche zu je 32.768 Token in voller Länge nach unserer Regel für Nutzer je Karte, 16-Bit-Cache, sofern nicht anders angegeben. Ein Server: TP=4 × PP=2, außer bei Kimi K2.6, wo der Wert der Cache ist, den das vLLM-Rezept zu Kimi-K2-Thinking auf acht H200 mit Decode Context Parallelism (DCP) gemessen hat. Zwei Server: eine Kopie als TP=4 × PP=4. DGX B300: TP=8, sofern nicht anders angegeben, rund 270 GB je GPU, vorsichtig als 10⁹ Byte gelesen. Gewichte: Summen der safetensors-Dateien auf Hugging Face, gelesen am 24. Oktober 2026.

Warum die Art des Caches die Antwort verschiebt

Die Gewichte dieser Modelle unterscheiden sich um den Faktor drei, der Cache je Gespräch um mehr. Kimi K2.6 und GLM-5.3 speichern je Schicht einen komprimierten Latent-Vektor, nach den Rechnungen unserer Leitfäden 2,14 GiB und 3,06 GiB je Gespräch mit 32K in 16 Bit. DeepSeek-V4-Pro komprimiert weiter, auf rund 0,30 GiB. Muse Spark Open speichert Keys und Values für 16 KV-Heads, nach unserer Rechnung rund 2,36 GiB, weil 46 seiner 62 Schichten nur ein Fenster von 2.048 Token halten.

Wo der Cache liegt, zählt ebenso wie seine Größe. vLLMs Blogbeitrag vom 7. August 2026 schreibt: „Under normal TP there is nothing to split by head, meaning the latent KV cache is replicated in full across every TP rank.“ Bei Kimi, GLM und DeepSeek hält deshalb bei Tensor-Parallelismus jede Karte den ganzen Cache jedes Gesprächs, und der freie Speicher einer Karte bestimmt die Zahl. Pipeline-Stufen teilen ihn, weil jede Karte nur den Cache ihrer eigenen Schichten hält, und DCP teilt jedes Gespräch nach Token. Muse Spark Open hat 16 KV-Heads; Tensor-Parallelismus verteilt seinen Cache auf die Karten, und ihr Speicher addiert sich. Unser Leitfaden zu Hardware für LLMs mit langem Kontext erklärt diese Cache-Arten genauer.

Deshalb hält eine DGX B300 mit fast dem doppelten Speicher eines H200-NVL-Servers nicht automatisch doppelt so viele Nutzer. Bei TP=8 lässt GLM-5.3 auf jeder B300-GPU rund 135 GiB frei, Platz für 72 Gespräche mit FP8-Cache, während zwei H200-NVL-Server in vier Pipeline-Stufen 79,4 GiB je Karte freilassen, jede Karte aber nur ein Viertel der Schichten hält. Die Aufteilung ist auf beiden Plattformen eine Frage der Konfiguration; planen Sie sie daher zusammen mit der Hardware.

Zwei Server mit acht H200 NVL: eine Kopie oder zwei

Zwei Server können das Modell auf zwei Arten betreiben. Als zwei Kopien hält jeder Server das ganze Modell, und die Nutzer verteilen sich auf beide: doppelt so viele, wie ein Server hält. Als eine Kopie wird das Modell in Pipeline-Stufen über beide Server geschnitten, und das macht auf jeder Karte Speicher frei: Die Gewichte von GLM-5.3 sinken von 88 GiB auf 44 GiB je Karte, der freie Speicher steigt von 35,4 auf 79,4 GiB.

Unsere Schätzungen nach der Regel für Nutzer je Karte für GLM-5.3 in FP8 (703,7 GiB), 3,06 GiB je Gespräch mit 32K in 16 Bit und 1,88 GiB in FP8 wie in unserem GLM-Leitfaden; jede Stufe hält höchstens 20 der 78 Schichten. Reservierte die Engine je Karte 7,4 GiB mehr als unsere Regel, wie es das vLLM-Rezept zu Kimi-K2-Thinking auf acht H200 gemessen hat, hielte die Aufteilung als eine Kopie rund 92 und 149.

vLLMs Dokumentation zum Betrieb über mehrere Knoten schreibt: „Set tensor_parallel_size to the number of GPUs per node and pipeline_parallel_size to the number of nodes.“ Bei der H200 NVL hält jeder Server zwei NVLink-Domänen zu je vier Karten, verbunden über PCIe; wir halten den Tensor-Parallelismus daher innerhalb einer Domäne und geben jeder Domäne eine eigene Pipeline-Stufe, vier Stufen über zwei Server, so wie unser Leitfaden zum Server mit 8× H200 NVL es für einen Server tut. Zwischen den beiden Servern laufen nur die Aktivierungen an der Stufengrenze, einmal je Schritt. Dieselbe Dokumentation warnt: Meldet NCCL [send] via NET/Socket, hat es „used a raw TCP socket, which *is not* efficient for cross-node tensor parallelism“, und sie nennt [send] via NET/IB/GDRDMA als Zeichen für GPUDirect RDMA. Jeder Server unseres Trainingsknotens hat für diese Verbindung 400G-Netzwerk.

Der Haken ist die Verfügbarkeit. Unser Vergleich ein 8-GPU-Server oder zwei 4-GPU-Server zeigt, dass ein Modell, das über zwei Hosts geteilt ist, stillsteht, wenn einer der Hosts ausfällt, und das gilt auch hier. Zwei Kopien behalten bei einem Ausfall, einem Neustart oder einem Treiber-Update die halbe Kapazität. Für Kimi K2.6 ist das die naheliegende Wahl: Ein Server hält in vLLMs Messung bereits 174 Gespräche mit DCP, zwei Kopien geben also 348 mit voller Redundanz. Für GLM-5.3 ist die Aufteilung als eine Kopie der einzige Weg zu 100 Nutzern auf zwei Servern. Wir bauen beide Aufteilungen und legen sie je Modell aus; senden Sie uns Modell, Kontextlänge und Spitzenzahl der Gespräche, und unser Team antwortet mit den Zahlen für beide.

DeepSeek-V4-Pro und Muse Spark Open

DeepSeek-V4-Pro lässt auf einem Server nur 19,4 GiB je Karte frei, sein Cache ist aber klein. Mit zwei Pipeline-Stufen, eine je NVLink-Domäne, ergibt unsere Regel rund 126 Gespräche zu je 32K, oder rund 78, wenn die Engine so viel reserviert, wie das Kimi-Rezept gemessen hat. Ein Server erreicht 100 Nutzer auf dem Papier; zwei Server oder eine DGX B300 erreichen sie mit Reserve. Bei der Ausgabelänge von 384K, die DeepSeeks Model Card für ihre höheren Reasoning-Stufen empfiehlt, hält ein Server rund 10 Gespräche, und dort zahlt sich ein zweiter Server aus.

Bei Muse Spark Open zählt die Kartengeneration am meisten. Sein NVFP4-Checkpoint läuft nativ auf Blackwell; acht RTX PRO 6000 Server Edition halten ihn nach unserer Regel mit rund 71 Gesprächen zu je 32K mit 16-Bit-Cache oder rund 142 mit FP8-Cache, wie unser Leitfaden zu Muse Spark Open zeigt. Auf der H200 NVL läuft er nur weight-only, ein Weg, den weder Meta noch vLLM für dieses Modell dokumentieren. Der BF16-Checkpoint mit 1.531,4 GiB läuft nativ auf Hopper, braucht aber zwei H200-NVL-Server.

Eine DGX B300: Speicher, FP4 und NVLink in einem System

Eine DGX B300 hat acht Blackwell-Ultra-GPUs mit je 288 GB HBM3e, davon rund 270 GB nutzbar, wie der Beschleunigername B300-SXM-270GB in MLPerf®-Einträgen zeigt. Vorsichtig als 10⁹ Byte gelesen, ergibt unsere Regel 223,3 GiB je GPU und 1.786,5 GiB je System. Sie rechnet NVFP4 und die FP4-Experten von DeepSeek-V4-Pro nativ, und NVLink verbindet alle acht GPUs, Tensor-Parallelismus über acht läuft also weder über PCIe noch über ein Netzwerk.

Die veröffentlichten Durchsatzwerte zeigen den Unterschied, den der Speicher allein nicht zeigt. Auf Llama 2 70B im Offline-Szenario erreichte die DGX B300 109.277 Token pro Sekunde, ein Server mit acht H200 NVL in der Runde davor 32.004,0 (MLPerf® Inference: Datacenter, Closed Division; v6.1 Eintrag 6.1-0071, NVIDIA DGX B300, abgerufen von mlcommons.org am 24. Oktober 2026; v6.0 Eintrag 6.0-0021, Dell PowerEdge XE7740 mit acht H200 NVL, Benchmark llama2-70b-99, abgerufen von mlcommons.org am 24. September 2026; Ergebnisse verifiziert durch die MLCommons Association). Nach unserer Division, die keine MLPerf-Metrik ist, lieferte eine DGX B300 das 3,4-Fache eines H200-NVL-Servers und das 1,7-Fache von zweien. 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.

Die DGX B300 liefern wir projektbezogen. Bevor wir ein Angebot erstellen können, fragt die Distribution nach Unternehmen, Projekt und Einsatzzweck, wie unser Leitfaden zum Kauf einer DGX B300 in der EU beschreibt.

Strom, Rack und Lizenzen je Variante

H200-NVL-Server: unser Trainingsknoten und unsere Schätzung von rund 6,3 kW je Server an der Steckdose (acht Karten mit 600 W, zwei AMD EPYC 9555, plus 15 Prozent), zu bestätigen durch eine Messung am gelieferten System. DGX B300: NVIDIAs User Guide, Datenblatt und Rechenzentrums­leitfaden, wie in unseren Artikeln zur DGX B300 zitiert; Bedingungen von NVIDIA AI Enterprise aus NVIDIAs Lizenzleitfaden, wie dort und in unserem H200-NVL-Leitfaden zitiert.

Zwei H200-NVL-Server können in zwei Racks an getrennten Anschlüssen stehen, und jeder braucht einen Drehstromplatz mit 400 V, wie unser Leitfaden zu GPU-Servern an 16 A, 32 A und Drehstrom zeigt. Eine DGX B300 bündelt die Last: NVIDIAs Rechenzentrums­leitfaden schätzt eine Spitze von 19,7 kW je AC-System und plant zwei Systeme je Rack mit 39,4 kW Spitze, mit aktiven Rücktür-Wärmetauschern als Empfehlung für hohe Dichte. Liegt die Grenze Ihres Raums bei 20 kW je Rack, passen die zwei Server dort, wo die DGX bauliche Arbeiten bräuchte. Wir prüfen Rack, Anschluss und Luftführung, bevor wir anbieten; beschreiben Sie Ihre Rackplätze und deren Leistungsgrenzen, und wir sagen, welche Variante Ihr Raum aufnimmt.

Welche Variante für welchen Fall

• Kimi K2.6 für 100 Nutzer: Ein Server mit acht H200 NVL und DCP hält sie; ein zweiter Server als zweite Kopie bringt Redundanz.
• GLM-5.3 für 100 Nutzer: zwei H200-NVL-Server als eine Kopie mit FP8-Cache oder eine DGX B300 mit zwei Pipeline-Stufen; zwei getrennte Kopien reichen nicht.
• DeepSeek-V4-Pro mit langen Reasoning-Längen: zwei Server oder eine DGX B300; ein Server hält 100 Nutzer bei 32K nur auf dem Papier.
• Muse Spark Open in NVFP4: acht RTX PRO 6000 Server Edition, der native Weg auf PCIe, oder eine DGX B300; in BF16 zwei H200-NVL-Server oder eine DGX B300.
• Mehrere dieser Modelle oder vor allem Durchsatz: eine DGX B300, die je System mehr Token pro Sekunde liefert und jedes Modell dieser Tabelle in einer NVLink-Domäne hält.

Auch die Lizenzen unterscheiden sich. DeepSeek veröffentlicht V4-Pro unter der MIT-Lizenz; Kimi K2.6 hat eine Modified MIT License mit einer Anzeigeklausel für sehr große Dienste; GLM-5.3 hat eine eigene Lizenz mit einer Klausel zur Sicherheitsprüfung für große Anbieter von Model-as-a-Service; die Lizenz von Muse Spark Open verlangt für Anbieter von Model-as-a-Service mit mehr als 20 Millionen US-Dollar Umsatz einen gesonderten Vertrag mit Meta. Unsere Modell-Leitfäden zitieren jede Klausel, und Ihre Rechtsabteilung entscheidet, ob sie greift.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration nach Ihrer Last und Ihrem Budget aus und antwortet innerhalb eines Werktages. Wir bauen Server mit acht H200 NVL und zwei 4-Wege-NVLink-Brücken, zwei AMD-EPYC-Prozessoren, 2,3 TB DDR5 ECC, acht NVMe-Laufwerken und 400G-Netzwerk, als einzelnen Server oder als Paar für ein Modell, vor der Lieferung montiert und getestet, mit EU-Vertrag und EU-Rechnung sowie Herstellergarantie auf jede Komponente; den Bestellablauf beschreibt unsere Seite Server mit 8× H200 NVL kaufen. Die DGX B300 bieten wir projektbezogen an. Die Aufteilung eines Modells über Server, die Serving-Plattform und die Kapazitätsplanung gehören zu unserem Service Private AI/ML, und unser Leitfaden zur GPU-Kapazitätsplanung für eine LLM-Plattform zeigt, wie Sie die Spitze messen, bevor Sie bestellen.

FAQ