DeepSeek V4 Preview vs. V3.2: Was sich beim Upgrade wirklich ändert

1. Der 1-Million-Token-Kontext ist der sichtbarste Sprung

Der auffälligste neue Punkt in DeepSeek V4 Preview ist das Kontextfenster von 1 Million Token. Praktisch ist das vor allem dann relevant, wenn ein einzelner Modellaufruf sehr viel Material enthalten soll: mehrere Dateien aus einem Repository, lange technische Dokumentationen, Systemlogs, umfangreiche Gesprächsverläufe oder Agentenketten mit vielen Zwischenschritten.

Ganz neu ist die Long-Context-Richtung aber nicht. Schon DeepSeek-V3.2-Exp führte DeepSeek Sparse Attention ein, laut DeepSeek für effizienteres Training und effizientere Inferenz bei langen Kontexten. Sauberer formuliert: V4 macht Long Context zum sichtbaren Kern der neuen Modellgeneration, während V3.2-Exp bereits ein wichtiger experimenteller Schritt in diese Richtung war.

2. V4-Pro und V4-Flash trennen Qualität und Effizienz klarer

Bei V3.2 führt DeepSeek im Changelog DeepSeek-V3.2 und DeepSeek-V3.2-Speciale auf. Bei V4 wechselt die Einteilung zu DeepSeek-V4-Pro und DeepSeek-V4-Flash.

Laut V4-Preview-Seite hat V4-Pro 1,6T Gesamtparameter mit 49B aktiven Parametern; V4-Flash kommt auf 284B Gesamtparameter mit 13B aktiven Parametern. Für Teams ist das praktisch: V4-Pro bietet sich für besonders schwierige Aufgaben innerhalb der V4-Linie an, V4-Flash eher für Tests, bei denen Latenz, Kosten, Durchsatz und Qualität zusammen betrachtet werden müssen.

Die sichere Vorgehensweise bleibt: nicht nach Namen entscheiden. Wer V3.2, V4-Flash und V4-Pro vergleichen will, sollte dieselben Prompts, dieselben Daten, dieselben Token-Limits und dieselben Bewertungskriterien verwenden.

3. Agentic Coding rückt stärker in den Mittelpunkt

DeepSeek V3.2 war bereits für Agenten-Workflows relevant, weil der Release Thinking mit Tool-Use betont. Gemeint sind also nicht nur Einmalantworten, sondern Abläufe, in denen ein Modell schlussfolgert, Werkzeuge aufruft, Ergebnisse liest und danach weiterarbeitet.

V4 Preview führt diese Linie fort, setzt aber stärker auf Agentic Coding: Workflows, in denen ein Modell Codekontext lesen, planen, ändern und mehrere Schritte koordinieren muss, statt nur ein kurzes Codefragment zu erzeugen.

Der Unterschied ist daher nicht: V3.2 kann keine Agenten, V4 kann Agenten. Treffender ist: V3.2 legt den Schwerpunkt auf Reasoning und Tool-Use; V4 versucht, diese Richtung für Coding-Agents und Long-Context-Workflows auszubauen.

4. Benchmarks sind ein Signal – keine Leistungsgarantie

DeepSeek veröffentlicht Benchmark- und Leistungsangaben sowohl im V3.2-Release als auch in der V4-Preview. Zusätzlich beschreibt eine externe technische Analyse der DeepSeek-Modelle von V3 bis V3.2 V3.2 als bemerkenswert, unter anderem wegen der Leistung und der Verfügbarkeit als Open-Weight-Modell.

Trotzdem sollten diese Angaben nicht mit einer Garantie für die eigene Anwendung verwechselt werden. Die hier relevanten Quellen sind vor allem Release Notes, API-Dokumentation und technische Einordnungen auf Basis veröffentlichter Informationen. Sie helfen bei der Richtung der Evaluierung, ersetzen aber keine internen Tests auf den eigenen Workloads.

Für den Produktivbetrieb zählt am Ende: Welches Modell ist besser auf den eigenen Prompts, den eigenen Daten, dem eigenen Token-Budget, den eigenen Latenzvorgaben und den eigenen Qualitätsmetriken? Solange diese Punkte nicht neu gemessen wurden, ist V4 Preview ein starker Kandidat für Tests – aber nicht automatisch der neue Standard.

5. Die API-Änderung ist der Teil, den man nicht nebenbei erledigen sollte

Mit V4 ändert sich auch, wie Modellaufrufe geplant werden sollten. DeepSeek schreibt in der V4 Preview, dass deepseek-chat und deepseek-reasoner derzeit auf deepseek-v4-flash routen – einmal im Non-Thinking-, einmal im Thinking-Modus – und nach dem 24. Juli 2026 um 15:59 UTC vollständig abgeschaltet werden.

Das ist deshalb wichtig, weil die frühere API-Dokumentation deepseek-chat und deepseek-reasoner DeepSeek-V3.2 zuordnete. Wer im Produktivsystem Aliasse statt konkreter Modell-IDs nutzt, riskiert also, dass sich das Modellverhalten ändert, ohne dass dies im eigenen Code ausdrücklich sichtbar ist.

Für die Integration verweist DeepSeek darauf, dass die API ein OpenAI-kompatibles Format nutzt; OpenAI-SDKs oder OpenAI-kompatible Software können demnach durch geänderte Endpoint-Konfigurationen verwendet werden. Außerdem gibt es eine Dokumentation zur Anthropic-API-Kompatibilität, die den Unterstützungsstatus von Feldern wie max_tokens, stream, system, temperature und thinking aufführt.

Eine sinnvolle Migrations-Checkliste sieht so aus:

1. Codebase, Konfigurationen und Secrets darauf prüfen, ob deepseek-chat, deepseek-reasoner oder konkrete Modell-IDs verwendet werden.
2. Prompts erneut im Thinking- und Non-Thinking-Modus testen, falls der Workflow Reasoning nutzt.
3. Latenz, Kosten, Fehlerraten, Timeouts und Antwortqualität auf realen Daten neu messen.
4. Vor dem 24. Juli 2026 um 15:59 UTC von den alten Aliassen wegmigrieren.
5. API-Felder erneut prüfen, wenn eine OpenAI- oder Anthropic-Kompatibilitätsschicht verwendet wird.

Sollte man von DeepSeek V3.2 auf V4 wechseln?

V4 sollte auf die Testliste, wenn sehr lange Kontexte, Coding-Agents, V4-Pro für schwierige Aufgaben oder V4-Flash für Workloads mit vielen Requests relevant sind.

V3.2 bleibt vorerst ein sinnvoller Baseline-Kandidat, wenn die bestehende Pipeline stabil läuft, kein 1-Million-Token-Kontext gebraucht wird oder der Produktivbetrieb erst interne Benchmarks verlangt.

Kurz gesagt: V3.2 war der Schritt in Richtung Reasoning und Tool-Use; V4 Preview ist der nächste Schritt bei Long Context, Pro-/Flash-Aufteilung und Agentic Coding. Für technische Teams ist aber nicht nur die Modellqualität entscheidend. Genauso wichtig ist ein sauberer Plan, um rechtzeitig von den alten API-Aliassen wegzukommen.