DeepSeek V4 Pro selbst hosten: die echte Rechnung

DeepSeek-V4-Pro kam mit den zwei verführerischsten Zahlen der Open-Weights-Geschichte: 1,6 Billionen Parameter und 1 Million Token Kontext, unter MIT-Lizenz. Das Take des Internets — „ein Frontier-Modell fürs Wohnzimmer" — liegt um rund drei Größenordnungen daneben. Dieser Guide ist die Arithmetik, die die beiden Aussagen trennt: Die Gesamtparameter bestimmen Ihre Speicherrechnung, die aktiven Parameter Ihre Geschwindigkeit, und der 1M-Kontext Ihre KV-Cache-Rechnung. Keines davon ist ein GPU-Kauf; die kleinste sinnvolle Einheit ist ein 8-GPU-Node, die ehrliche Einheit ein Rack.

Jede Zahl hier stammt entweder direkt aus DeepSeeks eigenen Primärquellen (Release-Note, Model Card, Tech Report, config.json) oder wird offen berechnet, mit gekennzeichneten Annahmen. Die Hardware-Referenzwerte (H200 = 141 GB bei 4,8 TB/s, H100 = 80 GB bei 3,35 TB/s, B200 = 180 GB bei 7,7 TB/s, MI355X = 288 GB bei 8,0 TB/s) sind die auf dieser Seite bereits geprüften Konstanten aus dem VRAM-Deep-Dive.

Die offizielle Konfiguration, festgenagelt

Aus Model Card und Release-Note — nicht aus irgendwem Benchmark ^{1 2}:

Das Instruct-Checkpoint, das man tatsächlich herunterlädt, ist das FP4+FP8-gemischte: Die 64 Safetensors-Shards umfassen laut Hugging Face 865 GB ⁴ — bevor ein einziges Byte KV-Cache, Aktivierungspuffer oder CUDA-Graphs dazukommt.

Die MoE-Asymmetrie: Gewichte sind total, Compute ist aktiv

Mixture-of-Experts bedeutet: Jedes Token wird durch eine kleine Teilmenge des Netzes geroutet. DeepSeeks Konfiguration: 384 routed Experts, 6 pro Token ausgewählt, 1 Shared Expert. Pro Token werden also nur etwa 49B der 1,6T Parameter angerührt. Daraus entsteht die Asymmetrie, die V4-Pro täuschend billig wirken lässt:

Gewichts-VRAM skaliert mit den Gesamtparametern (1,6T) — jeder Expert muss im Speicher liegen, selbst wenn die meisten idle sind, denn das Routing ist datenabhängig und nicht vorhersehbar. Serving-FLOPs und die pro Token gelesenen Bytes skalieren mit den aktiven Parametern (49B) — auf Byte-Ebene ein Mittelklasse-Dense-Modell. Das ist der ganze „1,6T klingt wie 49B"-Pitch: Die Marketing-Zahl (49B aktiv, ~30 GB bewegte Bytes pro Token) und die Speicherzahl (1,6T, ~0,9–3,2 TB resident) sind beide wahr — gleichzeitig — und nur eine davon passt in Ihr Budget. Es ist dieselbe Quantisierungs-und-Bits-pro-Gewicht-Mathematik wie bei Dense-Modellen; der Twist ist, welcher Parameterbestand welcher Ressource folgt.

Die Asymmetrie ist echt, kein Trick: Sie ist der Grund, warum DeepSeek das zu API-Preisen anbieten kann, die wir unten festnageln. Aber sie verlagert die Compute-Kosten zu Ihnen und behält die Speicherkosten in voller Höhe. Ihr 8-GPU-Node idlet bei 77–88 % Speicherauslastung, nur um die Token-Geschwindigkeit eines kleinen Modells zurückzugewinnen.

Weight-Bänder: was passt worauf

Gewichtsbytes je Precision (mit $P_{\text{total}}$, obiger Formel) plus ca. 15 % Serving-Overhead (Aktivierungspuffer, Kommunikations-Scratch, CUDA-Graph-Allokationen — derselbe Overhead-Band, den unser Inference-Rechner ansetzt), bevor irgendein KV-Cache dazukommt:

Lesen Sie die rechte Spalte genau: Keine aktuell lieferbare GPU hält selbst die FP4-Gewichte — die 288 GB der MI355X fassen weniger als ein Drittel des released Checkpoints. Die Node-Rechnung geht nur auf, weil 8-GPU-Plattformen den Speicher per Tensor-/Expert-Parallelität poolen, und jeder dieser GPU-Übergänge kostet Bandbreite — auf H200 NVLink (~900 GB/s bidirektional pro GPU) überschreiten Experts ständig GPUs, weshalb MoE-Serving weit parallelitätsempfindlicher ist als Dense-Modelle.

Und für ein 1M-Kontext-Modell war fp16 nie im Rennen: Das Modell ist nativ FP4+FP8; ein Hochquantisieren auf fp16 kauft eine Qualitätsmarge, die niemand gemessen hat, und verdreifacht eine Rechnung, die Sie ohnehin nicht bezahlen können. Realistisch sind die letzten zwei Zeilen: das veröffentlichte Checkpoint auf einem 8×H200-Klasse-Node (~994 GB gesamt, KV-Budget ~50–130 GB) oder fp8 auf 8×MI355X / größeren Clustern.

Die KV-Kette: wo 1M Kontext explodiert

Gewichte sind der Fixkostenblock; der KV-Cache ist der Kostenblock pro Nutzer — linear im Kontext. Die Grundformel ist dieselbe wie in unserem KV-Cache-Guide:

V4-Pro veröffentlicht keine nackten pro-Token-KV-Bytes wie ein GQA-Modell — die CSA/HCA-Hybridarchitektur komprimiert den Cache entlang der Sequenzdimension mit per-Layer-Ratios (128×, 4×, teils 0, alles in der config.json ⁵). Was DeepSeek selbst veröffentlicht, als Efficiency-Headline: Bei 1M Kontext braucht V4-Pro nur 10 % des KV-Cache von DeepSeek-V3.2 und nur 27 % der Single-Token-FLOPs ³. V3.2 nutzt V3s MLA-Schema mit 68,6 KiB/Token in bf16 (die Zahl, die unser KV-Guide aus V3s Konfiguration abgeleitet hat ⁶). Also die ehrliche, gekennzeichnete Schätzung:

— eine Schätzung, abgeleitet aus ihrem veröffentlichten Verhältnis, angewandt auf eine bekannte V3-Konfiguration; keine direkt gedruckte Zahl. Nun die Tabelle für einen Nutzer:

Zwei Lesarten, und Sie brauchen beide:

• Die Kompression ist wirklich bemerkenswert. 1M Token Konversation für 7,4 GB wären auf V3.2 ~74 GB gewesen und auf einem unkomprimierten GQA-Modell dieser Größe in Terabyte gemessen. Die Architektur leistet echte Arbeit.
• 1M Kontext ist trotzdem ein ganzer H200 an Speicher pro paar Nutzer. Auf dem einzig realistischen Node (8×H200, ~130 GB frei nach FP4-Checkpoint + Overhead) kostet ein voll ausgenutzter 1M-Kontext-Nutzer 7,4 GB — aber 32 gleichzeitige 128k-Nutzer kosten $32 \times 0{,}92 = 29{,}4$ GB, und der Think-Max-Modus, den DeepSeek selbst bei ≥384K Kontext empfiehlt ², verdreifacht das pro Nutzer. Ihre Concurrency-Grenze auf der Flaggschiff-Konfiguration liegt im Dutzend-Bereich, nicht im Hunderten — es sei denn, Sie kaufen weitere Nodes.

Auch der Prefill-Block zählt: 1M Input-Token zu verarbeiten heißt ~$10^{17}$ FLOPs — eine FLOP-Schätzung, keine Zeitprognose. Für die Prefill-Latenz zählen auch Attention, Routing und erreichte Auslastung; lange Prompts belegen zudem KV-Speicher und konkurrieren mit anderen Anfragen.

Durchsatzgrenze: Bandbreite ÷ bewegte Bytes

Decode ist memory-bound (das Arithmetik-Modell aus dem KV-Guide): Jedes generierte Token erfordert das Lesen der aktiven Gewichte aus dem HBM. Mit $P_{\text{active}} = 49$B:

Aggregate ceiling includes KV-read overhead: at full 1M context (7.37 GB KV re-read per token, effective) it drops to ~681 tok/s on 8×H200 fp8.

Vorbehalte, klar benannt: Das sind Obergrenzen, keine Benchmarks — Attention-FLOPs, Routing-/Kommunikations-Overhead (groß bei 384 Experts auf 8 GPUs), Kernel-Launch und Dequantisierung fehlen. Der tatsächliche Durchsatz muss für Modell, Batchgröße, Laufzeit und Verbindung gemessen werden; aus dieser Roofline folgt kein fester Effizienzprozentsatz. Und die Latenz pro Nutzer ist das, was Nutzer spüren: N gebatchte Nutzer amortisieren eine Gewichts-Lesung, teilen aber die Pro-Nutzer-Geschwindigkeit durch N. Die 26,5 GB der FP4-Spalte sind unsere Schätzung (49/1600 des 865-GB-Checkpoints). Über alle Vorbehalte hinweg hält sich die Kernfaktenlage: Der Node verhält sich pro Token wie ein 30–50-GB-Modell, das über 900 GB Speicher braucht.

Die API, gegen die Sie antreten

DeepSeeks veröffentlichte Peak-Preise für deepseek-v4-pro, geprüft am 29. September 2026, betragen 1,32 $ pro Million Cache-Miss-Input-Token, 3,96 $ pro Million Output-Token und 0,044 $ pro Million Cache-Hit-Input-Token. Off-Peak-Preise sind halb so hoch; Preise können sich ändern.⁷ Bei einer beispielhaften Mischung von 3:1 Cache-Miss-Input zu Output kostet eine Million gesamte abgerechnete Token:

Beide Seiten müssen dieselbe Einheit verwenden. Angenommen, ein gemieteter 8×H200-Node kostet 22 $/Stunde und erzeugt nachhaltig 300 Output-Token/Sekunde, mit genau drei Input-Token je Output-Token. Das sind 1.200 gesamte Token/Sekunde oder 4,32 Millionen gesamte Token/Stunde. Ohne den zusätzlichen Rechen- und Schedulingaufwand für Prefill ergeben sich optimistische Kosten von 22 $ / 4,32 ≈ 5,09 $ pro Million gesamte Token. Gegenüber dem API-Beispiel mit 1,98 $ sind das ungefähr 2,6×, nicht 10×. Der frühere Vergleich teilte durch den Durchsatz an Output-Token und verglich das Ergebnis mit einem gemischten API-Preis für Input und Output. Die Einheiten passten nicht zusammen.

An der theoretischen H200-Bandbreitengrenze von 784 Output-Token/Sekunde oben ergäbe dieselbe Mischung 3.136 gesamte Token/Sekunde und optimistische 1,95 $ pro Million gesamte Token. Der exakte Punkt gleicher Kosten liegt unter diesen Annahmen bei rund 772 Output-Token/Sekunde (22 × 10^6 / (1,98 × 3600 × 4)). Das liegt sehr nahe an der Roofline, die Kommunikation, Attention, Prefill, Strom und Auslastungsverluste ausklammert. Ein gemessener Einsatz bräuchte im Allgemeinen einen günstigeren Stundensatz, mehr Cache-Treffer, einen Off-Peak-Vergleich oder einen anderen Workload-Mix, um das Ergebnis zu ändern. Aus diesen Zahlen folgt kein universeller Break-even fürs Selbsthosting.

Die Rechnungen sind Beispiele. Für eine Entscheidung braucht man ein Hardwareangebot, gemessenen Durchsatz einschließlich Prefill, die tatsächliche Mischung aus Input, Output und Cache-Treffern, Auslastung, Support- und Betriebskosten sowie einen aktuellen API-Preis. Anforderungen an Datenstandort oder Kontrolle können unabhängig vom Tokenpreis zählen.

Was „Open Weights" Ihnen kauft — und was nicht

Die kritische Sicht, in der Primärquellen-Edition:

• Die Gewichte sind offen; das Rezept ist nicht vollständig reproduzierbar. MIT-lizenzierte Gewichte, ja. Aber das 32T+-Token-Pretraining-Korpus ist unveröffentlicht, die komplette Post-Training-Pipeline (Domain-Experten, GRPO-Reward-Modelle, On-Policy-Distillation-Teachers) wird im Tech Report ³ nur auf dem Niveau beschrieben, das Sie oben lesen können. „Offen" heißt hier nutzbar und veränderbar, nicht reproduzierbar — Sie können weder nachtrainieren noch vollständig auditieren, was Sie deployen.
• DeepSeek hat nie „schlägt jedes Frontier-Modell" behauptet. Die eigenen Vergleichstabellen der Model Card ² zeigen V4-Pro-Max bei den meisten Knowledge- und Agentic-Benchmarks hinter Opus-4.6 Max und Gemini-3.1-Pro (z. B. MMLU-Pro 87,5 vs. Gemini 91,0; Terminal Bench 67,9 vs. GPT-5.4 75,1), mit Siegen bei einigen Coding- und Mathe-Benchmarks. „Beats Frontier"-Posts stammen aus Community-Leaderboards und Vibes — die Release-Note selbst sagt „performance rivaling the world's top closed-source models" und ausdrücklich: „please rely only on our official accounts for DeepSeek news" ¹. DeepSeeks eigene Ehrlichkeit ist hier ungewöhnlich gut; leihen Sie sie sich.
• Die tatsächlich verwendete Version pinnen. Die ursprüngliche V4-Ankündigung und Model Card beschreiben ein Preview; DeepSeek kündigte im August 2026 jedoch die allgemeine Verfügbarkeit von V4-Pro an, und die Preisseite nennt DeepSeek-V4-Pro-0813 als API-Version.⁸⁷ Ein Open-Weight-Checkpoint und ein fortentwickelter API-Endpunkt sollten nicht als byte-identisch angenommen werden.
• Die Efficiency-Zahlen sind DeepSeeks — byte-level noch nicht unabhängig verifiziert. Die 10 %-KV- und 27 %-FLOPs-Werte stammen aus Figure 1 des eigenen Tech Reports. Unsere KV-Tabelle erbt diese Unsicherheit und sagt das auch.

Das Fazit ist nicht, dass V4-Pro überhyped ist — nach den Primärquellen ist es ein extraordinary Stück Engineering. Das Fazit ist, dass Open Weights Ihnen eine Speicherrechnung und ein Ops-Problem überträgt, kein Frontier-Modell für den Schreibtisch. Die 49B zahlen Sie pro Token; die 1,6T kaufen Sie vorab; und der 1M-Kontext ist der Posten, der Ihre Flottengröße bestimmt. Rechnen Sie im Inference-Rechner nach, bevor Sie irgendwem Cluster-Preise zitieren.