DeepSeek V4 Pro GA vs. Preview: 18–62 % weniger Thinking

Die allgemein verfügbare Version von DeepSeek V4 Pro verbraucht bei identischen Aufgaben 18 % bis 62 % weniger Reasoning-Token als die abgelöste Preview. Außerdem behebt sie einen Fehler, der das gesamte Ausgabefenster mit 8.192 Token aufbrauchen konnte. Es ist auch die erste Pro-Version, bei der sich striktes JSON zuverlässig extrahieren lässt, wenn Thinking deaktiviert ist. Dafür kann sie nicht mehr wie die Preview eingestehen, dass sie etwas nicht weiß. Wir haben deepseek-v4-pro-0813 vier Tage nach der allgemeinen Verfügbarkeit in einem gemeinsamen Batch mit der Preview-Version verglichen. Dabei haben wir nur Token gezählt: DeepSeek hatte am Vortag die Preise für V4 geändert und eine zeitabhängige Abrechnung für Haupt- und Nebenzeiten eingeführt. Ein Kostenvergleich zwischen zwei Preislisten in Bewegung wäre weniger aussagekräftig als die Tokenzahlen. DeepSeek veröffentlichte die GA-Version ohne Blogpost, Changelog oder Pressemitteilung. Was sich geändert hat, lässt sich daher nur durch Messungen feststellen.

TL;DR

• GA verbraucht pro Aufgabe 18–62 % weniger Reasoning-Token, bei einer einfachen Abfrage 18 statt 48.
• Thinking verfälscht bei beiden Versionen die Werte in striktem JSON (2/8 korrekt). Nur GA mit deaktiviertem Thinking lieferte durchgehend korrekte Ergebnisse (8/8).
• GA behebt einen Fehler der Preview: Mit thinking_budget: 16 füllte die Preview in 5 von 9 Läufen das Ausgabefenster mit 8.192 Token; GA in 0 von 9.
• GA verweigert erfundene Sachverhalte nicht mehr sauber: Die Preview lehnt in 100 bis 150 Token ab, GA gibt entweder nichts zurück oder erfindet eine Antwort.

Wie viel weniger denkt die GA-Version?

Je nach Aufgabe 18 % bis 62 %, wobei der Unterschied bei einfachen Aufgaben am größten ist. Für unsere vier Standardaufgaben haben wir jeweils drei Läufe mit Salt durchgeführt. Die Tabelle zeigt den Median für Reasoning- und gesamte Completion-Token:

Beide Versionen erreichten bei jeder Aufgabe 3/3 korrekte Antworten. Die höhere Effizienz geht also nicht zulasten der Qualität. Entscheidend für die Planung ist der Verlauf: Je anspruchsvoller die Aufgabe, desto geringer die Einsparung. Sie sinkt von 62 % bei einer direkten Abfrage auf 18 % bei einer Kette aus fünf Schritten. Unabhängig von den Preisen der beiden Versionen bleibt dieses Verhältnis bestehen. Am stärksten profitiert die strukturierte Extraktion: Unter einem strikten json_schema sinkt die Zahl der Reasoning-Token von 159 auf 40, also auf ein Viertel.

Das Caching verhält sich bei beiden Versionen gleich: Beide cacheten 4.096 Token eines Präfixes mit 5.000 Token und lieferten 4 Sekunden nach dem initialen Request einen Cache-Hit. Derzeit ändern sich die Preise, nicht der Mechanismus. DeepSeek erhöhte die Preise der V4-Familie und führte eine zeitabhängige Abrechnung ein, bei der Requests außerhalb der Hauptzeit die Hälfte kosten. Die Änderung gilt seit dem 2026-08-16 um 16:00 UTC. Prüft deshalb die aktuelle Preisliste für die jeweilige Version und die Ausführungszeit, bevor ihr diese Tokenzahlen in Kosten umrechnet.

Hat GA messbare Fehler behoben?

Ja, darunter den teuersten Fehlermodus dieser Modellfamilie. Bei thinking_budget: 16 verliert die Preview den Faden. Statt kurz nachzudenken und zu antworten, gerät sie in eine Wiederholungsschleife („I’ll output: 168. I’ll output: 168…“), bis max_tokens ausgeschöpft ist. Bei neun Läufen derselben Aufgabe mit fünf Schritten füllte die Preview fünfmal das gesamte Fenster mit 8.192 Token. GA tat das kein einziges Mal und antwortete in jedem Lauf korrekt mit 79 bis 130 Token.

Genau darin liegt das Kostenproblem: Ein Request, der durch ein begrenztes Reasoning-Budget eigentlich Geld sparen soll, wird mit 8.193 Completion-Token abgerechnet. Eine normale Antwort benötigt ungefähr 130 Token. Der Versuch, das Modell weniger denken zu lassen, erzeugt damit eine 63-mal höhere Rechnung für die Ausgabe. Auch ein Budget von 64 Token war bei der Preview nicht sicher: In 2 von 3 Läufen waren die Antworten falsch (183, 174). Wer noch an die Preview gebunden ist und die Kosten über kleine Thinking-Budgets steuert, sollte diese Kombination zuerst ablösen.

Thinking lässt sich hier gefahrlos abschalten. Das gilt nicht für alle Modelle dieser Familie: Flash 0731 fiel bei Arithmetik mit 2 Schritten von 6/6 auf 0/6, sobald Thinking deaktiviert wurde. Beide Pro-Versionen blieben bei unserer Kette mit fünf Schritten dagegen bei 3/3, unabhängig davon, ob thinking: {"type": "disabled"} oder enable_thinking: false gesetzt war. Bei Pro beeinträchtigt das Abschalten die Genauigkeit von Reasoning-Aufgaben nicht und behebt zugleich die Probleme bei der strukturierten Extraktion, wie unten beschrieben.

reasoning_effort bleibt bei beiden Versionen ohne erkennbare Steuerwirkung. Akzeptiert werden low, medium, high, xhigh und max. none und minimal führen zu einem 400-Fehler, der die gültigen Werte nennt. Bei unserer Aufgabe mit fünf Schritten lagen die Werte je nach Stufe bei GA zwischen 76 und 122 Reasoning-Token und bei der Preview zwischen 116 und 167, ohne monotone Entwicklung. Wie bereits unsere modellübergreifende Matrix der Thinking-Regler zeigte, wird DeepSeek über den Ausschalter und das Budget gesteuert, nicht über das Enum.

Verfälscht Thinking weiterhin striktes JSON?

Ja, bei beiden Versionen. Die GA-Version ist allerdings die erste Pro-Version mit einem zuverlässigen Ausweg. Diesen Fehler fanden wir bereits bei DeepSeek V4 Flash 0731: Das JSON erfüllt das Schema, enthält aber falsche Zahlen. Der Fehler besteht bei Pro weiter. Beide Versionen sollten aus einer Rechnung mit drei Zeilen vier Felder unter einem strikten json_schema extrahieren. Wir führten acht Läufe pro Konfiguration durch und prüften nicht nur das Schema, sondern auch die Werte:

Alle fehlerhaften Antworten lassen sich parsen, erfüllen das Schema und enthalten falsche Angaben. Obwohl das Dokument eindeutig drei Positionen auflistet, gab das Modell in verschiedenen Läufen 45, 22, 2026, -4, -35 und -3864 als Anzahl zurück. Eine Preview-Antwort meldete eine Gesamtsumme von -139,308,173,307,904. Eine GA-Antwort erfand sogar ein anderes Unternehmen („MITRE“, Gesamtsumme 1000). Für einen Validator ist jede dieser Antworten gültiges JSON.

Die Konsequenz für den Betrieb ist klar: Deaktiviert bei der GA-Version Thinking für strukturierte Extraktion. In allen unseren Läufen verschwand der Fehler damit. Diese einzelne Einstellung ist das stärkste Argument für den Wechsel von der Preview, die selbst bei deaktiviertem Thinking in 6 von 8 Fällen fehlerhaft blieb. Das entspricht dem Muster, das wir bei Flash gemessen haben, wo deaktiviertes Thinking ebenfalls alle Läufe bereinigte. Es bestätigt auch die Zone für sichere Einzelschritt-Aufgaben aus unserer Matrix der Thinking-Regler: Extraktion braucht kein Reasoning, und bei dieser Modellfamilie verschlechtert Reasoning das Ergebnis sogar.

Was hat GA verloren?

Die Fähigkeit, „Ich weiß es nicht“ zu sagen. Wir fragten nach fünf erfundenen Sachverhalten: dem Aktienkurs eines Unternehmens, der Mitarbeiterzahl eines Instituts, der Satzung einer Stadt, dem Schmelzpunkt einer Legierung und einem Preisträger. Die Preview lehnt solche Fragen in 100 bis 150 Ausgabe-Token sauber ab: „I don’t have any information about a 1987 Pan-Continental Robotics Prize.“ Die GA-Version reagiert stattdessen auf eine von zwei Arten. Keine davon ist brauchbar:

Vor der Veröffentlichung prüften wir dieses Verhalten über einen zweiten, unabhängigen Request-Pfad. Dort lehnte die Preview alle drei Stichproben in 101 bis 148 Token ab. GA verbrauchte bei einer Frage 8.191 Token und lieferte eine leere Antwort, wich einer weiteren Frage aus und nannte für eine nicht existente Legierung einen konkreten Schmelzpunkt („2,314 degrees Celsius“). Anderer Client, gleiche Asymmetrie: Das Verhalten liegt am Modell.

Für Retrieval-Pipelines entstehen daraus doppelte Kosten: Eine Frage, die der Index nicht beantworten kann, verbraucht ein ganzes Fenster für verborgenes Reasoning. Als Ergebnis kommt entweder nichts oder eine erfundene Antwort zurück, die der Validator problemlos akzeptiert. Wenn nicht beantwortbare Anfragen an dieses Modell gehen, sollte max_tokens so niedrig gesetzt werden, dass der Fehler sichtbar und günstig bleibt. Eine leere Completion sollte als Miss gelten, nicht als Fehler.

Ändert sich beim Wechsel sonst noch etwas?

Wenig. Der Wechsel ist damit eher eine Verhaltens- als eine Integrationsentscheidung. Beide Versionen akzeptierten 279.000 Eingabe-Token in einem Request und beantworteten eine Needle-Frage aus der Mitte des Kontexts. Beide verwenden denselben Tokenizer der Modellfamilie: Ein identischer Korpus aus Englisch, Chinesisch und Code erzeugt bei GA, Preview und deepseek-v4-flash-0731 dieselbe Tokenzahl. Token-Budgets lassen sich daher unverändert innerhalb der Familie übernehmen. Beide akzeptieren temperature, top_p und top_k ohne Rückmeldung sowie einen vorbefüllten Assistant-Turn, also DeepSeeks dokumentierte Funktion zur Präfix-Vervollständigung.

Auch beim Caching stimmen die Versionen bis zur Seitengröße überein: Ein Präfix mit 512 Token wurde von keiner Version gecacht. Darüber cacheten beide in exakt 1.024 Token großen Seiten (1.024, 2.048, 4.096) und lieferten 4 Sekunden nach dem initialen Request einen Treffer. Das ist dieselbe Seitengröße, die Flash verwendet. Eine weitere Kostenfrage lässt sich ebenfalls klären: Beide Versionen geben die vollständige Chain of Thought in reasoning_content zurück. Wird sie im nächsten Turn erneut mitgesendet, entstehen dafür keine Kosten. Ein Folge-Turn wurde bei GA mit denselben 134 Eingabe-Token abgerechnet, bei der Preview mit denselben 56, unabhängig davon, ob das Reasoning des vorherigen Turns enthalten oder entfernt war. Anders als Modelle, die beibehaltenes Reasoning Token für Token erneut berechnen, verwirft diese Familie es einfach.

Bei Tool-Loops gibt es weder einen klaren Vorteil noch einen Nachteil. In einem Agent-Loop mit zwei Funktionen, der zuerst einen Incident nachschlägt und danach den darin genannten Service neu startet, benötigte GA beim ersten Schritt mehr Reasoning (48 statt 34 Token) und beim zweiten weniger (18 statt 35). Beide Versionen wählten in 3/3 Fällen das richtige Tool. Da DeepSeek diese Version für Agent-Workloads positioniert, sind die Unterschiede beim Reasoning pro Schritt weniger eindeutig, als es die allgemeinen Effizienzzahlen nahelegen. Für einen Agenten, der in Sackgassen gerät, ist das oben beschriebene Ablehnungsverhalten relevanter.

FAQ

Wie viel günstiger ist der Betrieb der GA-Version?

Gemessen in Token benötigt sie pro Aufgabe 18–62 % weniger Reasoning und unter einem strikten json_schema nur ein Viertel. Für die Kosten muss die aktuelle Preisliste geprüft werden: DeepSeek änderte am 2026-08-16 die Preise der V4-Familie und führte eine zeitabhängige Abrechnung ein, bei der Nebenzeiten die Hälfte kosten. Dieselbe Tokenzahl kann daher je nach Version und Uhrzeit unterschiedlich viel kosten.

Spart die GA-Version bei einfachen oder komplexen Aufgaben mehr?

Bei einfachen. Die Einsparung beim Reasoning liegt bei einer direkten Abfrage bei 62 %, bei einer Textaufgabe mit 2 Schritten und bei der JSON-Extraktion bei ungefähr 48 % und bei einer arithmetischen Kette mit fünf Schritten nur bei 18 %. Bei komplexen Aufgaben mit vielen Schritten nähern sich die beiden Versionen an. Am stärksten lohnt sich der Wechsel bei einfachen Anfragen mit hohem Volumen.

Sollte ich bei DeepSeek V4 Pro weiterhin kleine Thinking-Budgets verwenden?

Nicht mit der Preview. thinking_budget: 16 löste eine Wiederholungsschleife aus, die in 5 von 9 Läufen das gesamte Ausgabefenster mit 8.192 Token verbrauchte. Ein Request, der günstig sein sollte, erzeugte dadurch eine ungefähr 63-mal höhere Rechnung für die Ausgabe. Mit 64 Token lieferte das Modell falsche Antworten. GA verarbeitete dasselbe Budget in 9 von 9 Läufen korrekt. Kleine Budgets sind daher nur bei der datierten Version sicher.

Kann ich der strikten JSON-Ausgabe von DeepSeek V4 Pro vertrauen?

Nur bei deaktiviertem Thinking und nur mit der GA-Version. In acht Läufen pro Konfiguration enthielten schema-konforme Antworten bei aktiviertem Thinking in 6 von 8 Fällen falsche Zahlen, darunter Positionszahlen von 45, 2026 und -3864 für eine Rechnung mit drei Positionen. Das galt für beide Versionen. GA mit thinking: {"type": "disabled"} lieferte in 8 von 8 Fällen korrekte Werte. Die Preview blieb selbst bei deaktiviertem Thinking in 6 von 8 Fällen fehlerhaft. Prüft die Werte, nicht nur das Schema.

Lehnt DeepSeek V4 Pro Fragen ab, die es nicht beantworten kann?

Die Preview tut das in 100–150 Token. Die GA-Version meist nicht: Bei erfundenen Sachverhalten verbraucht sie entweder das gesamte Ausgabefenster für Reasoning und gibt eine leere Nachricht zurück, oder sie nennt bei einem größeren Fenster selbstbewusst eine erfundene Antwort. Gleicht Antworten mit eigenen Quellen ab, statt einer fehlenden Ablehnung zu vertrauen. Leere Completions sollten als Misses gelten.

Gemessen am 2026-08-17 über das Synthorai-Gateway, vier Tage nach Erscheinen der GA-Version. Für jeden Vergleich wurde die Preview im selben Batch erneut ausgeführt: Matrix aus Reglern und Ausschaltern (7 Effort-Werte, 5 Budgets, 2 Off-Parameter, n=3), Reasoning-Vergleich mit vier Aufgaben, strukturierte Ausgabe mit strengem JSON, Function-Calling-Loop mit zwei Turns, Test mit fünf erfundenen Sachverhalten bei zwei Fenstergrößen, Prüfung der Werteintegrität für vier Felder unter strengem JSON (n=8 pro Konfiguration), Abrechnungspaar für erneut übermitteltes Reasoning, implizite Cache-Paare mit zwei Wartezeiten und Eingrenzung der Cache-Untergrenze, Annahme eines Kontexts mit 279K Token samt Needle, Tokenizer-Vergleich mit einem festen Korpus innerhalb der V4-Familie sowie Tests zur Annahme von Sampling, Prefill und n>1. Die Runaway-Rate basiert auf neun Läufen pro Version mit max_tokens: 8192. Wir geben Tokenzahlen statt Kosten an, weil DeepSeek am 2026-08-16, einen Tag vor diesem Batch, die Preise der V4-Familie änderte und eine zeitabhängige Abrechnung für Haupt- und Nebenzeiten einführte. Das Ablehnungsverhalten und der Runaway wurden über einen zweiten, unabhängigen Request-Pfad gegengeprüft. Preise und Verhalten können sich ändern. Messt erneut, bevor ihr euch auf einen einzelnen Wert verlasst.

← Zurück zum Blog