DeepSeek V4 Flash: Thinking beschädigt striktes JSON

DeepSeek V4 Flash kostet $0.14 pro Million Input-Token und $0.28 pro Million Output-Token, Cache-Treffer kosten $0.0028. Der neu trainierte 0731-Build, der inzwischen unter diesem Namen ausgeliefert wird, hat jedoch einen Defekt, den das Routing berücksichtigen muss: Bei aktiviertem Thinking, der Standardeinstellung, und einem strikten json_schema kamen Integer-Felder in 8 von 13 Läufen über zwei unabhängige Request-Pfade verfälscht zurück. Ohne Thinking waren alle Läufe korrekt, und die Extraktion benötigte nur ein Siebtel der Token. Wir haben deepseek-v4-flash-0731 am ersten Tag vermessen: die Verfälschung, den durch das Retraining verschärften Leistungseinbruch bei deaktiviertem Thinking, das rettende Mindestbudget, die 1.024-Token-Cache-Seiten und die verbleibenden Unterschiede zum Preview-Build und zu V4 Pro.

TL;DR

• Mit standardmäßig aktiviertem Thinking und striktem json_schema verfälschte deepseek-v4-flash-0731 Integer-Felder in 8 von 13 Läufen über zwei Request-Pfade. V4 Pro verfälschte 2 von 4; nur die Preview blieb fehlerfrei.
• Das 0731-Retraining hat den Leistungseinbruch bei deaktiviertem Thinking verschärft: Zweistufige Mathematik fiel von 6/6 auf 0/6.
• Der Cache liefert 1.024-Token-Seiten ab einer Untergrenze von ungefähr 1,1K Token, trifft 0,3 Sekunden nach dem Priming und hält Einträge länger als 45 Minuten.
• enable_thinking: false korrigierte alle strukturierten Läufe bei einem Siebtel der Token. Für zweistufige Mathematik liegt das sichere Thinking-Budget bei 256.

Wie unterscheiden sich die drei V4-Builds laut Datenblatt und Messung?

Gleicher Tokenizer, gleicher Cache, dieselbe Thinking-Mechanik, aber unterschiedliche Preise und Fehlerbilder. Alle folgenden Werte stammen aus identischen Tests mit allen drei Builds. Ein Gedankenstrich bedeutet, dass wir diese Zelle nicht geprüft haben. Die Analysen vom ersten Tag konzentrieren sich auf Benchmarks; hier geht es um die betrieblichen Unterschiede:

Beschädigt der Thinking-Modus strukturierte Ausgaben bei V4 Flash?

Beim 0731-Build ja, und der Fehler ist unauffällig genug, um bis in die Produktion zu gelangen. Bei der Extraktion einer Rechnung mit vier Feldern unter einem strikten json_schema (Anbieter, Datum, Gesamtbetrag, Anzahl der Positionen) lieferte das Modell mit standardmäßig aktiviertem Thinking schema-konformes JSON, aber falsche Zahlen. Für line_items kamen -1, 1, -1 und -19 zurück, obwohl das Dokument eindeutig drei Positionen enthält. Über unser Gateway war keiner von 5 Läufen korrekt. Eine Budgetbegrenzung umgeht den Fehler nicht: Ein Lauf mit einem Budget von 64 Token zeigte dieselbe Verfälschung, und selbst bei einem Budget von 256 Token lieferte 1 von 3 Läufen 670 Positionen. Entscheidend ist, ob Thinking vorhanden ist, nicht wie umfangreich es ausfällt. Über einen zweiten, unabhängigen Request-Pfad war derselbe Test in 3 von 8 Läufen aus zwei Batches fehlerhaft. Einmal kam ein Gesamtbetrag von 519.95 statt der im Dokument angegebenen $520.00 zurück, einmal eine Positionszahl von 22. Auf diesem Pfad blieb Reasoning aktiviert, obwohl es deaktiviert werden sollte. Die unten beschriebene saubere Lösung ist deshalb auf dem primären Pfad verifiziert. Das JSON ließ sich immer parsen und bestand stets die Schema-Validierung. Nur die Werte waren falsch. Für eine Pipeline, die der Validierung vertraut, ist das der ungünstigste mögliche Fehlermodus.

Die Lösung besteht aus einer Zeile: Mit enable_thinking: false war das JSON in jedem Lauf korrekt und gültig. Die Completion benötigte ungefähr 44 Token statt 328 mit der Standardeinstellung. Die Unterschiede innerhalb der Modellfamilie sind aufschlussreich: Der identisch getestete Preview-Build blieb mit aktiviertem Thinking in 4/4 Läufen fehlerfrei, während V4 Pro 2 von 4 Läufen verfälschte. Der Fehler betrifft damit die gesamte V4-Thinking-Reihe, trifft den neu trainierten Flash-Build aber am stärksten. Es handelt sich auch nicht um den bereits dokumentierten Fehler bei Thinking in Kombination mit einem Schema: vLLM behob im vergangenen April ein Problem in der Verarbeitungskette, bei dem DeepSeek-JSON im Reasoning-Feld landete und das Content-Feld leer blieb. Hier funktioniert die Verarbeitungskette, aber die Werte sind falsch. Das ist deutlich gravierender. Bis DeepSeek den Fehler behebt, sollten Thinking und strikt strukturierte Ausgaben bei diesen Modellen nicht zusammen verwendet werden. Das verursacht keine Mehrkosten: Einstufige Extraktion ist genau die Art von Workload, bei der deaktiviertes Thinking sicher und siebenmal günstiger ist.

Welche Thinking-Steuerungen akzeptiert die API?

Die API bietet zwei Möglichkeiten zum Abschalten, ein exaktes Budget und eine Effort-Einstellung ohne Aus-Option. Die von uns getestete Schnittstelle akzeptiert für reasoning_effort die Werte low, medium, high, xhigh und max. Anders als bei Qwen 3.8 Max werden none und minimal abgelehnt. Über diese Einstellung allein lässt sich das Modell daher nicht zum Schweigen bringen. Thinking wird entweder mit enable_thinking: false oder mit thinking: {"type": "disabled"} deaktiviert. Beide Varianten verhalten sich identisch und lieferten bei einer trivialen Frage Antworten mit 9 Token. thinking_budget wird token-genau eingehalten, genau wie bei unserer Messung von Qwen 3.8: Werden 16 angefordert, zeigt der Zähler 16. Die vollständige Gedankenkette wird in reasoning_content zurückgegeben. Der feste Prompt-Overhead liegt bei schlanken 5 Token pro Aufruf.

Bei der Effort-Einstellung konnten wir dagegen keinen Effekt messen. Bei einer anspruchsvollen Aufgabe zum Zählen von Primzahlen verbrauchten low und high 31.374 beziehungsweise 31.370 Reasoning-Token, gegenüber 26.897 mit der Standardeinstellung. Alle drei Antworten waren korrekt. Das entspricht normaler Streuung; eine Begrenzung war nicht erkennbar. Während die Stufen von Qwen 3.8 versteckte Budgetgrenzen sind, die bei anspruchsvollen Aufgaben greifen, änderten die Stufen von V4 Flash in keinem unserer Tests etwas. Bei diesem Modell zählen nur zwei Steuerungen: der Ausschalter und thinking_budget. Die Effort-Einstellung kann ignoriert werden. Bemerkenswert ist, dass DeepSeeks eigene Model Card die Agent-Benchmarks mit „max reasoning effort“ ausführt. Auf der von uns getesteten Schnittstelle war diese Einstellung nicht von der Standardeinstellung zu unterscheiden.

Wie viel Thinking braucht zweistufige Mathematik tatsächlich?

Mehr als vor dem Retraining. Damit kehrt sich unsere bisherige Empfehlung zum günstigen Modus anderer Modelle um. In unserem reproduzierbaren Batch für zweistufige Arithmetik (1.850 Kisten mit je 24 Teilen, 75 % werden versendet, 3.120 kommen an) verhalten sich die drei V4-Builds wie drei unterschiedliche Modelle:

Daraus folgen zwei Punkte. Erstens hat das Agent-Retraining die Arithmetik in den Thinking-Kanal verschoben: Der Preview-Build kommt ohne Thinking noch eingeschränkt zurecht, 0731 fällt vollständig aus, und Pro zeigt keinen Unterschied. Zweitens ist das Mindestbudget modellspezifisch. 16 Thinking-Token reichen bei Qwen 3.8 Max für denselben Batch vollständig aus, 0731 braucht dagegen 256. Bei diesem Wert arbeitet das Modell fehlerfrei und günstiger als mit der Standardeinstellung: Die Completions umfassen insgesamt 53 bis 188 Token statt 100 bis 200. Wer eine Thinking-Budget-Konfiguration auf ein anderes Modell überträgt, muss die Genauigkeit erneut prüfen. Der Mechanismus ist universell, der Schwellenwert nicht.

Was leistet der implizite Cache?

Der Cache arbeitet mit 1.024-Token-Seiten, einer niedrigen Mindestgröße, kurzen Zugriffszeiten und langer Haltedauer. Bei Paaren mit gesalzenen Präfixen ergaben sich mit wachsendem Prompt Treffer von exakt 1.024, 2.048, 4.096 und 7.168 Token. Die Quantisierung erfolgt also in 1.024-Token-Seiten. Die Untergrenze liegt knapp über einer Seite: Ein Prompt mit 704 Token traf nie den Cache, ein Prompt mit 1.166 Token ergab einen Treffer von 1.024 Token. Bereits 0,3 Sekunden nach dem Priming wurde ein Treffer geliefert. Es gibt somit keine Verzögerung beim Aufbau, die architektonisch berücksichtigt werden müsste. Der Eintrag wurde auch nach mehr als 45 Minuten noch ausgeliefert. Das ist der langlebigste implizite Cache, den wir in dieser Preisklasse bisher getestet haben. Der Eintrag von Qwen 3.8 Max lief zwischen 15 und 45 Minuten ab, seine Untergrenze liegt bei ungefähr 4,3K Token. DeepSeek berechnet für Cache-Treffer beim Input $0.0028 pro Million, also 2 % des Preises bei einem Miss, ohne Aufschlag für Schreibvorgänge. Es gilt die übliche Reihenfolge beim Aufbau des Prompts: zuerst das stabile Präfix, danach die veränderlichen Inhalte.

Sind das Kontextfenster von 1M und das Output-Limit von 384K real?

Das Kontextfenster hielt in allen Tests stand. Eingepflanzte Override-Codes wurden bei 137.638, 465.238 und 838.198 Prompt-Token innerhalb von 7 bis 20 Sekunden wortgetreu zurückgegeben. Das ist der schnellste Long-Context Recall, den wir in dieser Preisklasse gemessen haben. Beim Output ist die API großzügiger als dokumentiert: DeepSeek nennt ein maximales Output-Limit von 384K Token, akzeptierte aber sowohl mit als auch ohne Thinking Anfragen mit max_tokens von 393.217 und sogar 524.288. Das Limit wird bei der Anfrage also nicht erzwungen, und ein zu großes Budget löst keinen deutlichen Fehler aus. Wer auf eine Obergrenze angewiesen ist, sollte sie selbst setzen.

Preview, 0731 und Pro: Welcher Build beantwortet die Requests?

Auf der Preisseite von DeepSeek steht inzwischen nur noch eine SKU: deepseek-v4-flash, Modellversion DeepSeek-V4-Flash-0731, zu unveränderten Preisen. In der Praxis wird der Preview-Build auf einigen Routen weiterhin unter seinem eigenen Namen ausgeliefert. Beide lassen sich von außen leicht unterscheiden, obwohl sie denselben Tokenizer verwenden. Die Token-Anzahlen für englische, chinesische und Code-Korpora sind identisch, sodass Budgets übertragbar sind. Der zuverlässigste Fingerabdruck ist der Test mit deaktiviertem Thinking: Bei zweistufiger Mathematik erreicht die Preview in unseren Batches ungefähr 2/6, 0731 dagegen 0/6. Die Preview ist zudem der einzige Build, der den Test für strukturierte Ausgaben fehlerfrei bestand: 4/4, gegenüber 5/5 verfälschten Läufen bei 0731 und 2/4 bei Pro. Wenn der Traffic von einem dieser Verhaltensmerkmale abhängt, sollte der tatsächlich verwendete Endpoint getestet werden. Der Modellname allein reicht nicht. V4 Pro ($0.435/$0.87) zeigte keinen Einbruch bei Mathematik, aber denselben Fehler bei strukturierten Ausgaben.

Für die Planung ist außerdem relevant: Der gemeinsame Tokenizer der drei Modelle erzeugt bei identischen Korpora ungefähr 6 bis 9 % mehr Token als Qwen 3.8. Für Budgetvergleiche zwischen Anbietern braucht es deshalb die Dichtewerte pro Sprache, nicht nur die Preisliste.

FAQ

Sind strukturierte Ausgaben bei DeepSeek V4 Flash sicher?

Mit deaktiviertem Thinking ja: Das strikte json_schema wurde eingehalten, und jede Extraktion in unserem Batch war korrekt. Beim 0731-Build mit standardmäßig aktiviertem Thinking kamen Integer-Felder in 8 von 13 Läufen über zwei Request-Pfade verfälscht zurück, obwohl die Schema-Validierung erfolgreich war. V4 Pro verfälschte im selben Test 2 von 4 Läufen; nur der Preview-Build blieb fehlerfrei. Setzen Sie für Routen mit strukturierten Ausgaben enable_thinking: false, bis der Defekt behoben ist.

Lässt sich Thinking bei DeepSeek V4 Flash deaktivieren?

Ja, in zwei Schreibweisen: enable_thinking: false oder thinking: {"type": "disabled"}. Durch das 0731-Retraining ist der deaktivierte Zustand bei mehrstufigen Aufgaben jedoch unzuverlässig geworden: Bei zweistufiger Mathematik erreichte das Modell 0/6. Verwenden Sie für alles, was über einstufige Abfragen hinausgeht, ein thinking_budget von mindestens 256. In unseren Messungen war diese Einstellung sowohl fehlerfrei als auch günstiger als der Standard.

Wie groß muss ein Prompt mindestens sein, damit der V4-Flash-Cache greift?

Knapp über 1.024 Token: Ein Prompt mit 704 Token wurde nie gecacht, einer mit 1.166 Token ergab einen Treffer von exakt 1.024 Token. Treffer werden in 1.024-Token-Seiten quantisiert, stehen 0,3 Sekunden nach dem Priming bereit und bleiben länger als 45 Minuten erhalten. Cache-Treffer beim Input kosten laut Liste $0.0028 pro Million, also 2 % des Preises bei einem Miss.

Haben sich die Preise mit dem 0731-Release geändert?

Nein. DeepSeek behielt $0.14 pro Million Input-Token bei einem Cache-Miss, $0.0028 bei einem Cache-Treffer und $0.28 für Output bei. 0731 wurde als aktuelle Modellversion in den bestehenden Namen deepseek-v4-flash übernommen. Geändert hat sich das Verhalten, nicht der Preis: Das Modell hängt stärker von Thinking ab und weist den beschriebenen Defekt bei strukturierten Ausgaben auf.

Gemessen am 2026-08-04 über das Synthorai-Gateway mit deepseek-v4-flash-0731 sowie Vergleichsläufen auf der deepseek-v4-flash-Preview und deepseek-v4-pro: Batches zur Extraktion mit striktem Schema und Protokollierung der Payload jedes einzelnen Laufs, verifiziert über einen zweiten unabhängigen Request-Pfad; Tests der akzeptierten Effort-Einstellungen und ungültiger Werte; der gesalzene Batch zur zweistufigen Genauigkeit (n=4-6 pro Variante) mit schrittweise erhöhtem Thinking-Budget; gesalzene Cache-Paare im Abstand von 2,5 s mit Tests zu Untergrenze, Seitengröße, Aufbauverzögerung und Zeitabstand; Grenzwerttests für max_tokens in beiden Modi; sowie identische Tokenizer-Zählungen für drei Korpora über alle drei Modelle und Qwen 3.8 Max. Die Dollarbeträge entsprechen den von DeepSeek zum Veröffentlichungszeitpunkt angegebenen Listenpreisen. Prüfen Sie die Werte anhand des Zählers Ihres eigenen Providers. Das Verhalten kann sich ändern, während DeepSeek den 0731-Build weiterentwickelt.

← Zurück zum Blog