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 8,0 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 — auf einem einzelnen 8×H200-Node bei fp8-Dense-Auslastung rund eine Minute reine Rechenzeit, aber die Speicherspitzen (KV-Allokation für einen vollen 1M-Token-Batch) machen riesige Single-Prompt-Prefills auf geteilter Self-Hosting-Hardware unpraktisch.

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. Reale Deployments erreichen typischerweise 30–60 % der Grenze. 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 eigene Preise für deepseek-v4-pro, abgerufen am 24.09.2026 ⁷ (Peak; Off-Peak ist die Hälfte): 1,32 $ pro 1M Cache-Miss-Input-Tokens, 3,96 $ pro 1M Output-Tokens (0,044 $/M Cache-Hit). Für ein typisches 3:1 Input-Output-Mix ergibt das gemischt:

Nun der brutale Vergleich. Ein 8×H200-Node zur Miete für ~22 $/Stunde (gekennzeichnete Annahme; Cloud-Preise schwanken), mit einer großzügigen nachhaltigen Decode-Rate von 300 tok/s aggregiert:

Das sind ~10× den Peak-API-Preis — und 300 tok/s nachhaltig ist schon optimistisch. Selbst an der theoretischen Grenze von 784 tok/s produziert der Node bestenfalls 7,80 $/M pro Output-Token — während die 1,98 $/M der API Input und Output 3:1 blenden, der ehrliche Vergleich ist also per Anwendungsfall, nicht Zahl gegen Zahl. Die Break-even gegen 1,98 $/M:

— und das maximal mögliche Decode-Output des Nodes liegt an der Grenze bei 784 tok/s × 86.400 s ≈ 67M Tokens/Tag. Hier zählen die Einheiten: Die 267M Break-even zählt blended abgerechnete Tokens (Input + Output), die 67M zählen Output-Tokens. Unter derselben 3:1-Input:Output-Mischung, die der API-Preis blendet, werden 67M Output-Tokens als rund 4×67M ≈ 270M blended Tokens/Tag abgerechnet — im Wesentlichen AN der Break-even, nicht 4× darunter. An der theoretischen Grenze liegt der Node also bei wenigen Prozent um Kostengleichheit. (Dieselbe Methode wie im Wirtschaftsmodus unseres Inference-Rechners: Stundensatz ÷ nachhaltige Tokens pro Stunde; passen Sie dort 22 $/Stunde und Auslastung an Ihre eigenen Cloud-Angebote an.)

Das ehrliche Urteil, mechanisch: Solange Ihr marginaler Stundensatz deutlich unter 22 $/Node liegt und Ihre nachhaltige Nachfrage im Zehn-Millionen-Tokens-pro Tag-Bereich bei hoher Concurrency liegt, gewinnt die API auf reinen Kosten — um eine Größenordnung. V4-Pro selbst zu hosten ist ein Cluster-Kauf, gerechtfertigt durch Datensouveränität, Air-Gapped-Deployment oder unbegrenzte Kapazität, preislich ~20 $/M statt 2 $/M. Für Einzelpersonen und die meisten Unternehmen ist die rationale Version von „Ich will DeepSeek selbst betreiben" V4-Flash (284B total / 13B aktiv — FP4-Gewichte um die 160 GB, ein echtes 2–4-GPU-Projekt) oder ein quantisiertes V3.2.

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.
• „Preview" heißt: Drift kommt. Model Card und Release-Note nennen das eine Preview-Version; die API-Preisseite zeigt bereits ein neueres V4.1-Flash, das die Flash-Linie ersetzt hat. Pinnen Sie Versionen und planen Sie Ihren eigenen API-Deprecation-Takt.
• 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.