DeepSeek-V4 ist auf lange agentische Workloads ausgelegt, bei denen offene Frontier-Modelle heute typischerweise an der Kontextlaenge, am KV-Cache oder an Tool-Call-Round-Trips scheitern. Ein Kontextfenster von 1 Million Token ist dabei laut Beitrag nur Kapazitaet, nicht automatisch nutzbare Leistung: Bei langen Tool-Use-Trajektorien wird jedes Tool-Ergebnis an den Kontext angehaengt, und jeder folgende Token traegt die vollstaendigen Attention-Kosten gegen den bisherigen Verlauf.
Entscheidend sind dabei die single-token inference FLOPs und die Groesse des KV-Caches, die beide mit der Sequenzlaenge wachsen. Bei 1 Million Token benoetigt DeepSeek-V4-Pro nach den Angaben 27 Prozent der single-token inference FLOPs von DeepSeek-V3.2 und 10 Prozent des KV-Cache-Speichers. V4-Flash senkt diese Werte weiter auf 10 Prozent der FLOPs und 7 Prozent des KV-Caches. Verglichen mit einer etablierten Architektur wie grouped query attention mit 8 Heads in bfloat16 benoetigt DeepSeek v4 dem Beitrag zufolge etwa 2 Prozent der Cache-Groesse.
Die Effizienz entsteht durch zwei Attention-Mechanismen, die ueber die Layer hinweg alternieren. Compressed Sparse Attention, kurz CSA, komprimiert KV-Eintraege entlang der Sequenzdimension um den Faktor 4 mittels softmax-gated pooling mit learned positional bias. Ein lightning indexer mit FP4 und ReLU-scored multi-head dot product waehlt pro Query die top-k komprimierten Bloecke aus. Die sparse selection aus DeepSeek Sparse Attention in V3.2 bleibt damit erhalten, arbeitet aber auf bereits um den Faktor 4 verkuerzter Sequenz.
Heavily Compressed Attention, kurz HCA, komprimiert KV-Eintraege um den Faktor 128 und verzichtet auf sparse selection. Jede Query attendiert dicht auf alle komprimierten Bloecke. Weil die komprimierte Sequenz kurz genug ist, bleibt dense attention guenstig. In V4-Pro mit 61 Layern sind die Layer 0 und 1 HCA, die Layer 2 bis 60 alternieren zwischen CSA und HCA, und der MTP-Block am Ende nutzt nur sliding-window. Beide Pfade speichern die meisten KV-Eintraege in FP8 und nur die RoPE-Dimensionen in BF16; der lightning indexer in CSA arbeitet in FP4.
Als weitere Architekturmerkmale nennt der Beitrag DeepSeekMoE in den Feed-forward-Layern sowie manifold-constrained hyper-connections, die Residualverbindungen ersetzen. Die genannten Speicherformate wirken zusammen mit den Kompressionsraten auf die ausgewiesene KV-Cache-Groesse.
Fuer agentische Nutzung beschreibt der Beitrag zudem drei Post-Training- und Infrastrukturentscheidungen. In V3.2 blieben reasoning traces ueber Tool-Result-Runden erhalten, wurden aber verworfen, sobald eine neue User-Nachricht eintraf. V4 behaelt reasoning content ueber User-Nachrichten hinweg bei, wenn die Konversation Tool-Calls enthaelt. Damit bleibt die vollstaendige Reasoning-Historie ueber alle Runden und User-Turns erhalten. Fuer Konversationen ohne Tools bleibt das bisherige Verhalten bestehen, bei dem Reasoning in jedem Turn verworfen wird, um den Kontext knapp zu halten.
Fuer Tool-Aufrufe fuehrt V4 ein spezielles Token namens |DSML| sowie ein XML-basiertes Tool-Call-Format ein. Dieses XML-Format soll Escaping-Fehler gegenueber JSON-in-string-Tool-Calls reduzieren, insbesondere bei verschachtelten Anfuehrungszeichen. Das Schema trennt String-Parameter, die unveraendert mit string="true" uebergeben werden, von strukturierten Parametern, die als JSON mit string="false" uebergeben werden. Laut Beitrag entfernt das eine Klasse von Parsing-Fehlern bei Zahlen und Booleans.
Das Agent-Verhalten wurde mit RL gegen reale Tool-Umgebungen trainiert. Dafuer beschreibt der Beitrag DeepSeek Elastic Compute, kurz DSec, eine in Rust geschriebene Plattform mit vier Ausfuehrungssubstraten hinter einer Python-SDK: function calls, container, microVMs auf Firecracker-Basis und vollstaendige VMs mit QEMU. Ein Cluster unterstuetzt demnach Hunderttausende gleichzeitige Sandboxes. Fuer das Agent-Training hebt der Beitrag schnelles Image-Laden ueber geschichteten 3FS-Speicher, preemption-safe trajectory replay und eine einheitliche API ueber alle Substrate hinweg hervor.
Bei Knowledge- und Reasoning-Werten seien die Ergebnisse konkurrenzfaehig, aber nicht fuehrend; staerker trennten sich die Agent-Zahlen von V4-Pro-Max vom Feld. In Table 6 erreicht V4-Pro-Max auf Terminal Bench 2.0 einen Wert von 67,9, vor GLM-5.1 mit 63,5 und K2.6 mit 66,7, aber hinter GPT-5.4-xHigh mit 75,1 und Gemini-3.1-Pro mit 68,5. Auf SWE Verified werden 80,6 geloeste Faelle genannt, innerhalb eines Punkts von Opus-4.6-Max mit 80,8 und gleichauf mit Gemini-3.1-Pro mit 80,6. Auf MCPAtlas Public liegt der Wert bei 73,6 und damit knapp hinter Opus-4.6-Max mit 73,8. Bei Toolathlon erreicht V4-Pro-Max 51,8, vor K2.6 mit 50,0, GLM-5.1 mit 40,7 und Gemini-3.1-Pro mit 48,8.
Im internen R&D-Coding-Benchmark mit 30 kuratierten Aufgaben aus PyTorch, CUDA, Rust und C++ erzielt V4-Pro-Max eine Pass-Rate von 67 Prozent, gegenueber 47 Prozent fuer Sonnet 4.5 und 70 Prozent fuer Opus 4.5. In einer Umfrage unter 85 DeepSeek-Entwicklern, die V4-Pro als taegliches Modell nutzten, sagten 52 Prozent, es sei bereit, ihr bisheriges primaeres Coding-Modell zu ersetzen, und 39 Prozent tendierten zu Ja.
Bei Long-Context-Retrieval bleibt die MRCR-8-needle-Accuracy laut Figure 9 ueber 0,82 bis 256K Token und liegt bei 1 Million Token noch bei 0,59.
Auf dem Hub stehen vier Checkpoints bereit: deepseek-ai/DeepSeek-V4-Pro mit 1.6T Parametern und 49B aktivierten Parametern als instruct-Modell, deepseek-ai/DeepSeek-V4-Flash mit 284B und 13B aktiviert als instruct-Modell, sowie die Base-Varianten deepseek-ai/DeepSeek-V4-Pro-Base und deepseek-ai/DeepSeek-V4-Flash-Base. Die instruct-Modelle nutzen FP4 fuer MoE-Expert-Weights und FP8 fuer alles andere; die Base-Modelle sind durchgaengig FP8.
Beide instruct-Modelle unterstuetzen drei Reasoning-Modi: Non-think ohne chain of thought, Think High mit explizitem Reasoning in <think>-Bloecken und Think Max mit maximalem Reasoning-Aufwand ueber einen eigenen System-Prompt. Fuer Think Max ist ein Kontextfenster von mindestens 384K Token erforderlich. Als empfohlene Sampling-Parameter nennt der Beitrag fuer alle Modi temperature=1.0 und top_p=1.0.
Als offene Frage benennt der Beitrag, wie sich Tool-Harnesses der Community an das |DSML|-Schema anpassen und ob die Gewinne durch interleaved thinking auf agentische Frameworks ausserhalb der trainierten Domaenen uebertragbar sind.
