DeepSeek-V4-Pro Hardware-Anforderungen: acht H200 NVL oder eine DGX B300

Welchen Server DeepSeek-V4-Pro braucht

DeepSeek-V4-Pro braucht entweder einen Server mit acht H200 NVL oder eine DGX B300. Das offizielle Release -0813 wiegt 892,7 GB, 831,4 GiB; acht H200 NVL halten es nach unserer Regel für Nutzer je Karte mit 155,5 GiB Reserve für den Cache, genug für rund 65 gleichzeitige Gespräche zu je 32K Token mit Tensor-Parallelismus über alle acht Karten. Ein Server mit acht RTX PRO 6000 Server Edition verfehlt die Gewichte um 167,1 GiB, und eine DGX B300 hält sie mit Platz für mehrere hundert Gespräche und rechnet die FP4-Experten nativ.

Zur Wahl stehen damit zwei sehr verschiedene Systeme. Den Server mit acht H200 NVL bauen wir auf Bestellung; er hat zwei NVLink-Domänen zu je vier Karten, die über PCIe verbunden sind, und Hopper rechnet die FP4-Gewichte nicht nativ. Die DGX B300 bieten wir projektbezogen an; sie verbindet alle acht GPUs über NVLink, rechnet FP4 nativ und hat mehr als den doppelten Speicher. Unser Leitfaden zu den DeepSeek-Hardware-Anforderungen behandelt V4-Flash, V4.1-Flash und V3.2; dieser Artikel behandelt das Flaggschiff mit 1,6T.

Unsere Schätzungen nach der Regel für Nutzer je Karte für den Checkpoint mit 831,4 GiB, 16-Bit-Cache vollständig auf jeder Karte gezählt. DGX B300 mit rund 270 GB je GPU (MLPerf®-Beschleunigername B300-SXM-270GB), vorsichtig als 10⁹ Byte gelesen. Leistung der PCIe-Server ist unsere Schätzung an der Steckdose; DGX B300 laut NVIDIAs User Guide und Datenblatt, wie in unseren Artikeln zur DGX B300 zitiert.

DeepSeek-V4-Pro-0813 auf Hugging Face

DeepSeeks Model Card nennt den Checkpoint -0813 „the official release of DeepSeek-V4-Pro, superseding the preview version“. Das vLLM-Rezept, aktualisiert am 13. Oktober 2026, beschreibt ihn als „a 1.6T-total / 49B-active Mixture-of-Experts model“ und nutzt -0813 als Standard. Die safetensors-Dateien in der Dateiliste des Repositorys haben wir am 24. Oktober 2026 summiert.

Model Card, Dateiliste und config.json von DeepSeek-V4-Pro-0813 auf Hugging Face, gelesen am 24. Oktober 2026; Parameter aus dem vLLM-Rezept zu DeepSeek-V4-Pro (aktualisiert am 13. Oktober 2026), das Metadatenfeld der Model Card zeigt 1,7T. Die Checkpoint-Größe ist unsere Summe der gelisteten Dateien.

Das Rezept nennt „~893 GB on disk versus ~865 GB for the preview“; der Unterschied ist das DSpark-Modul für spekulatives Dekodieren, das das Release im selben Checkpoint mitbringt. Die Model Card empfiehlt für ihre Reasoning-Stufen high und max „a maximum output length of 384K tokens“; die Kontextlänge, mit der Sie planen, entscheidet also mehr, als die Zahlen für 32K vermuten lassen. DeepSeeks eigenes Beispiel betreibt das Modell „on a single 4×GB300 node“, einem Rack-System außerhalb dessen, was wir liefern.

KV-Cache: komprimierte Attention, auf jeder Karte kopiert

V4 speichert je Token weit weniger Cache als DeepSeek-V3.2. Die config.json führt die Kompressionsverhältnisse in 62 Einträgen (das Modell hat 61 Schichten und eine Schicht für Multi-Token-Prediction): 29 Einträge komprimieren um 4, 30 um 128, und drei stehen auf 0, halten nach unserer Lesart also nur das Sliding Window von 128 Token. Wir zählen den komprimierten Eintrag mit 512 Werten und den Indexer-Key mit 128 Werten in 16 Bit auf den Schichten mit Faktor 4 und nur den Eintrag auf denen mit Faktor 128, dieselbe Zählung, die in unserem DeepSeek-Leitfaden 6,4 KiB je Token für V4-Flash ergibt. Für V4-Pro sind das rund 9,3 KiB je Token.

Unsere Schätzung aus den Feldern compress_ratios, head_dim und index_head_dim der config.json, gelesen am 24. Oktober 2026; das Sliding Window kommt mit rund 7,8 MiB je Gespräch hinzu. Ein FP8-Cache, den die vLLM-Rezepte mit --kv-cache-dtype fp8 setzen, ist kleiner.

Die Größenordnung passt zum Rezept, das V4-Pro „10% of V3.2's KV cache at 1M context“ zuschreibt; unsere Rechnung für V3.2 bei 32K ergibt 2,39 GiB. Der Haken ist, wo der Cache liegt. vLLMs Blogbeitrag vom 7. August 2026 schreibt für Latent-Caches: „Under normal TP there is nothing to split by head, meaning the latent KV cache is replicated in full across every TP rank.“ V4 hat einen KV-Head; bei Tensor-Parallelismus hält also jede Karte den ganzen Cache jedes Gesprächs, und der freie Speicher einer Karte, nicht des Servers, bestimmt die Zahl der Gespräche.

Acht H200 NVL: die Gewichte passen mit FP4-Experten in 4 Bit

Acht H200 NVL geben nach unserer Regel 986,9 GiB. Nach 831,4 GiB Gewichten bleiben 155,5 GiB, 19,4 GiB je Karte. Hopper hat FP8, aber keine FP4-Arithmetik, wie unser Leitfaden zu FP4-Modellen auf H200 NVL und Ada-GPUs erklärt. Das Rezept führt trotzdem „H200 (8× GPU): DP + EP with --data-parallel-size 8“ und begrenzt den Kontext auf 800K Token, „to leave KV headroom with dense params replicated across ranks“. Eine Kopie von 1,6T Parametern in FP8 bräuchte rund 1,6 TB, mehr als die 1.128 GB von acht Karten; nach unserer Rechnung funktioniert die H200-Aufteilung also nur, weil die Experten im Speicher in 4 Bit bleiben und mit höherer Genauigkeit gerechnet werden. Wie Hopper sie verarbeitet, sagt das Rezept nicht; messen Sie die Geschwindigkeit auf dieser Karte daher selbst.

Unsere Schätzungen nach der Regel für Nutzer je Karte, acht H200 NVL, 16-Bit-Cache, 19,4 GiB freier Speicher je Karte; bei TP=4 × PP=2, eine Stufe je NVLink-Domäne, hält jede Karte den Cache ihrer 31 oder 30 der 61 Schichten, gerechnet für die größere Stufe. Obergrenzen: Auf acht H200 maß das vLLM-Rezept zu Kimi-K2-Thinking rund 7,4 GiB je Karte weniger Cache als unsere Regel, wie unser Kimi-K2-Leitfaden beschreibt.

Die datenparallele Aufteilung des Rezepts gibt jeder Karte ihren eigenen Cache, wiederholt aber die dichten Gewichte auf jeder Karte, und die Grenze bei 800K zeigt, wie wenig Platz das lässt. Wir haben sie nicht gerechnet, weil die Größe des dichten Teils nicht veröffentlicht ist. Zwei weitere Punkte betreffen die H200 NVL. Das Rezept nennt den Formfaktor seiner H200 nicht; in einem Server mit acht H200 NVL bilden zwei 4-Wege-Brücken zwei NVLink-Domänen zu je vier, verbunden über PCIe, sodass Tensor-Parallelismus über alle acht und der Expertenverkehr von DP + EP über PCIe laufen, wie unser Leitfaden zum Server mit 8× H200 NVL zeigt. TP=4 × PP=2 hält die All-Reduces jeder Stufe auf NVLink und halbiert den Cache je Karte ungefähr. Wir bauen diesen Server mit seinen NVLink-Brücken und legen die Aufteilung je Modell aus; senden Sie uns Kontextlänge und Spitzenzahl der Gespräche, und unser Team antwortet mit den Zahlen je Aufteilung.

Warum acht RTX PRO 6000 Server Edition nicht reichen

Die RTX PRO 6000 Server Edition rechnet FP4 nativ, was zu den V4-Experten passt, doch acht Karten haben 768 GB, weniger als die 892,7 GB des Checkpoints vor jedem Cache. Nach unserer Regel halten sie 664,3 GiB, 167,1 GiB zu wenig für die Gewichte. Auch NVIDIAs Variante nvidia/DeepSeek-V4-Pro-NVFP4, die das vLLM-Rezept für Blackwell führt, hilft nicht: Sie quantisiert die Experten neu in Standard-NVFP4, lässt Attention, geteilte Experten und das Prediction-Modul in FP8, und ihre 64 Dateien summieren sich auf 913,1 GB (850,4 GiB). Die kleineren Modelle der Familie passen auf diesen Server: DeepSeek-V4-Flash mit 167 GB und DeepSeek-V4.1-Flash mit rund 511 GB, die unser DeepSeek-Leitfaden rechnet. Was an Modellen mit 600 bis 700 GB auf Blackwell-PCIe-Karten passt, zeigt unser Leitfaden zu acht RTX PRO 6000 Server Edition für LLMs.

DGX B300: natives FP4 und NVLink über acht GPUs

Eine DGX B300 hat acht Blackwell-Ultra-GPUs mit je 288 GB HBM3e, davon rund 270 GB nutzbar, der Wert im Beschleunigernamen B300-SXM-270GB der MLPerf®-Einträge. Vorsichtig als 10⁹ Byte gelesen, sind das 251,5 GiB je GPU und nach unserer Regel 223,3 GiB, 1.786,5 GiB für das System. Nach den Gewichten bleiben rund 955 GiB, 119,4 GiB je GPU. Mit dem Cache auf jeder GPU bei TP=8 ist das Platz für rund 400 Gespräche zu je 32K oder 34 bei 384K; die B300-Aufteilung des Rezepts ist „single-node DP + EP with --data-parallel-size 8“, die wir aus dem oben genannten Grund nicht gerechnet haben.

Die B300 rechnet die FP4-Experten in FP4, ein Weight-only-Pfad entfällt, und NVLink verbindet alle acht GPUs, kein Verkehr läuft über PCIe. Unser Vergleich DGX B300 oder ein Server mit acht RTX PRO 6000 behandelt die Bandbreite und die MLPerf®-Ergebnisse. Auch im Rechenzentrum stellt das System andere Anforderungen: 10U und 168 kg in der AC-Version, zwölf Netzteile mit 3,2 kW und 14,5 bis 15,1 kW laut NVIDIAs User Guide und Datenblatt. 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.

Server, Strom und Raum für jede Variante

Der Server mit acht H200 NVL folgt unserem Trainingsknoten: zwei AMD-EPYC-Prozessoren, 2,3 TB DDR5 ECC, acht NVMe-Laufwerke und 400G-Netzwerk. Der Arbeitsspeicher folgt NVIDIAs Konfigurations­leitfaden für zertifizierte Systeme, der mindestens das Doppelte des GPU-Speichers verlangt; unser Leitfaden zum Arbeitsspeicher eines GPU-Servers erklärt die Regel. Der Checkpoint braucht 893 GB auf lokalem NVMe, und Platz für eine zweite Kopie erlaubt ein Update, ohne den Dienst anzuhalten.

Mit acht Karten zu 600 W und zwei Prozessoren mit 64 Kernen schätzen wir rund 6,3 kW an der Steckdose, ein Wert, den eine Messung am gelieferten System bestätigt oder korrigiert. Das braucht einen Drehstromplatz mit 400 V auf Strang A und B, wie unser Leitfaden zu GPU-Servern an 16 A, 32 A und Drehstrom zeigt. Eine DGX B300 zieht mehr als das Doppelte: NVIDIAs Rechenzentrums­leitfaden für das System plant zwei AC-Systeme je Rack mit 39,4 kW Spitze und empfiehlt aktive Rücktür-Wärmetauscher für Racks mit hoher Dichte. Prüfen Sie, was Ihr Raum oder Ihr Colocation-Vertrag je Rack liefert, bevor Sie wählen. Wir prüfen Rack, Anschluss und Luftführung, bevor wir anbieten; nennen Sie uns Strom und Kühlung am Rackplatz, und wir sagen, welche Variante passt.

Wann zwei H200-NVL-Server der bessere Schritt sind

Ein Server mit acht H200 NVL stößt an seine Grenze, wenn viele Nutzer gleichzeitig mit langem Kontext arbeiten: Bei 384K, der Reasoning-Länge, die die Model Card empfiehlt, hält er selbst in der zweistufigen Aufteilung rund 10 Gespräche. Zwei Server mit je acht H200 NVL haben nach unserer Regel 1.973,8 GiB. Als eine Kopie mit Pipeline-Stufen über beide betrieben, lassen sie 71,4 GiB je Karte für den Cache, fast viermal so viel wie ein Server. Als zwei Kopien betrieben, bleibt der Dienst verfügbar, wenn ein Server ausfällt. Unser Vergleich 1T-Modelle für 100 Nutzer auf einer DGX B300 oder zwei H200-NVL-Servern rechnet beide Aufteilungen für V4-Pro und andere große Modelle durch.

MIT-Lizenz und Umgang mit Daten

Die Model Card schreibt: „This repository and the model weights are licensed under the MIT License.“ Die Lizenz erlaubt Nutzung, Änderung und Weitergabe unter der Bedingung, dass der Copyright- und Erlaubnishinweis in Kopien enthalten ist, und schließt jede Gewährleistung aus. Ein Modell, das aus heruntergeladenen Gewichten auf Ihren eigenen Servern läuft, sendet keine Prompts oder Ausgaben an DeepSeek. Ob für Ihre Nutzung weitere Bedingungen gelten, beurteilt Ihre Rechtsabteilung.

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. Für DeepSeek-V4-Pro bauen wir 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, 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 Bereitstellung des Modells mit vLLM und die Anbindung an Ihre Anwendungen gehören zu unserem Service Private AI/ML.

FAQ