DeepSeek V4-Flash-0731: Thinking lässt sich nicht deaktivieren

Gewinner ist die Prüfung des finalen ausgehenden JSON-Requests. Sie sollten nicht aus einer Konfigurationsdatei oder einem Schalter im Anwendungscode schließen, dass Thinking deaktiviert ist. Bei DeepSeek V4-Flash-0731 muss die Einstellung im tatsächlich gesendeten Request als thinking.type = disabled ankommen. Fehlt dieses Feld, gilt Thinking nicht als nachgewiesen deaktiviert. Beim OpenAI SDK gehört die Einstellung in extra_body; wenn ein direkter Replay bereits funktioniert, die Produktionskette aber weiterhin reasoning_content liefert, liegen die Ursachen meist in der SDK-Serialisierung, im Gateway oder in separaten Agent-Unteranfragen.

Diese Anleitung richtet sich an Entwickler, die nach der Umstellung auf DeepSeek V4-Flash-0731 weiterhin reasoning_content erhalten. Sie hilft außerdem Plattformingenieuren bei der Suche nach Gateway- oder Umgebungsvariablen-Überschreibungen. Teams mit mehrstufigen AI Agent-Prozessen finden hier eine Methode, um Hauptanfrage, Planung, Tool-Aufruf und Wiederholung getrennt zu prüfen.

Letzte Aktualisierung: 02.08.2026. Die Versions-, Modell- und Parameterangaben wurden anhand der offiziellen DeepSeek-Dokumentation am 02.08.2026 erneut geprüft.

Der erste Befund: Konfiguration ist nicht gleich Request

Die häufigste Fehlannahme sieht in der Praxis so aus:

1. In der Anwendungskonfiguration steht „Thinking deaktiviert“.
2. Die SDK-Funktion wird ohne sichtbaren Fehler aufgerufen.
3. Die Antwort enthält trotzdem reasoning_content.
4. Die Latenz oder der Tokenverbrauch steigt.
5. Das Team ändert den Modellnamen oder startet mehrere Rollbacks.

Der Fehler liegt oft nicht beim Modellnamen. Er liegt darin, dass die gewünschte Einstellung nie im finalen HTTP-Request angekommen ist.

Die offizielle DeepSeek-Dokumentation beschreibt Thinking als standardmäßig aktiviert. Für das OpenAI-Format wird die Umschaltung über ein Objekt mit thinking und type vorgenommen. Der Wert disabled aktiviert den Non-Thinking-Modus. Beim OpenAI SDK muss dieses Objekt innerhalb von extra_body übergeben werden. (api-docs.deepseek.com)

Für die Diagnose sollte ein Entwickler zunächst vier Werte derselben Anfrage zusammenführen:

• die eindeutige Request-ID,
• das tatsächlich gesendete Modell,
• den Zeitstempel der Antwort,
• die Antwortfelder und usage-Daten.

Ein altes Logfile mit reasoning_content beweist nicht, dass die aktuelle Anfrage weiterhin Thinking nutzt. Ebenso beweist ein leerer Wert im Frontend nicht, dass der Dienst keine Reasoning-Tokens erzeugt hat. Streaming-Parser, Datenbankfelder und UI-Filter können die Darstellung verändern.

Die aktuelle Modellbezeichnung ist zusätzlich eine Fehlerquelle: Die offizielle Dokumentation führt die Version als „DeepSeek-V4-Flash-0731“, nennt für API-Aufrufe aber weiterhin den Modellwert deepseek-v4-flash. Die alte Kennung deepseek-chat wurde laut offizieller Ankündigung nach dem 24.07.2026 um 15:59 UTC nicht mehr als dauerhaft verfügbare Modellroute vorgesehen. (api-docs.deepseek.com)

Achtung: Ein Feld in einer internen Konfigurationsdatei ist nur eine Absichtserklärung. Erst das anonymisierte JSON direkt vor dem Netzwerkversand ist ein belastbarer Nachweis.

OpenAI SDK und extra_body: der entscheidende Übergabepunkt

Bei einem direkten OpenAI-SDK-Aufruf sollte die minimale Struktur ungefähr so aussehen:

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Kurzer Test"}],
    extra_body={
        "thinking": {
            "type": "disabled"
        }
    }
)

Der Code ist kein vollständiges Integrationsbeispiel. Er zeigt nur den Prüfpunkt: thinking darf nicht ausschließlich in einer eigenen Anwendungseinstellung oder in einem nicht unterstützten Top-Level-Argument liegen.

Für die Fehleranalyse sind drei Versionen desselben Aufrufs zu protokollieren:

1. Aufrufparameter der Anwendung

Hier wird dokumentiert, was die Anwendung an das SDK übergeben wollte. Beispiel:

{
  "model": "deepseek-v4-flash",
  "extra_body": {
    "thinking": {
      "type": "disabled"
    }
  }
}

2. Ausgabe des SDK-Adapters

Viele Anwendungen verwenden eine eigene Client-Klasse, ein Framework oder einen Modellrouter. Dieser Layer kann Parameter normalisieren. Dabei werden nicht standardisierte Felder manchmal nur dann weitergereicht, wenn sie auf einer Whitelist stehen.

Wenn extra_body an dieser Stelle bereits fehlt, ist der DeepSeek-Endpunkt nicht die erste Fehlerquelle. Die Ursache liegt im Adapter, in einer Typdefinition oder in der Serialisierungslogik.

3. Finaler Netzwerk-Request

Entscheidend ist der Request, der den Prozess tatsächlich verlässt:

{
  "model": "deepseek-v4-flash",
  "messages": [
    {
      "role": "user",
      "content": "Kurzer Test"
    }
  ],
  "thinking": {
    "type": "disabled"
  }
}

Die genaue Darstellung kann je nach Client variieren. Maßgeblich ist, dass der Server das Feld auf der erwarteten Ebene erhält. Ein interner Logeintrag wie thinking_enabled=false reicht nicht aus, wenn der Netzwerk-Trace kein entsprechendes Feld zeigt.

Die Protokollierung sollte API-Schlüssel, Benutzerdaten, vollständige Prompts und vertrauliche Tool-Argumente entfernen. Für eine DSGVO-konforme Prüfung genügen in vielen Fällen Modell, Thinking-Wert, Request-ID, Feldnamen, Tokenzähler und Zeitmessung. Hinweise zur sicheren Verwaltung von Zugangsdaten und Zugriffsrechten sollten zusätzlich in der ProxyMac-Hilfe dokumentiert werden.

SDK-Adapter gegen Netzwerkspur: wo verschwindet das Feld?

Ein „Schalter ohne Wirkung“ hat typischerweise drei Ursachen:

Ursache A: Falsche Parameterebene

Das Team setzt beispielsweise thinking="disabled" als eigenes Argument. Der verwendete Client akzeptiert dieses Argument zwar intern, überträgt es aber nicht in das von DeepSeek erwartete Request-Objekt.

Ursache B: Whitelist im Wrapper

Eine gemeinsame SDK-Schicht übernimmt nur bekannte Felder wie model, messages, temperature und max_tokens. extra_body wird entweder vollständig verworfen oder ohne das innere thinking-Objekt weitergereicht.

Ursache C: Mehrfaches Serialisieren

Der Request wird zuerst in ein internes Modellobjekt, danach in ein OpenAI-kompatibles Objekt und zuletzt in JSON umgewandelt. Ein Feld kann zwischen diesen Schritten verloren gehen, besonders wenn die Zwischendefinition keine Erweiterungsfelder erlaubt.

Der belastbare Vergleich lautet daher:

• Anwendung: Sollte thinking.type vorhanden sein?
• Adapter: Ist extra_body noch vorhanden?
• HTTP-Schicht: Enthält das finale JSON den deaktivierten Wert?
• Antwort: Fehlt reasoning_content im aktuellen Response-Objekt?
• Usage: Sind die Tokenfelder derselben Request-ID zugeordnet?

Ein Framework-Schalter in einer Weboberfläche ist dagegen nur ein Hinweis. Er kann einen Standardwert setzen, der später von einem Modellrouter überschrieben wird. Ohne Debug-Log, Request-Interceptor oder direkten Replay bleibt die Schlussfolgerung spekulativ.

Der offizielle API-Referenz beschreibt thinking als Request-Feld mit den zulässigen Werten enabled und disabled. Außerdem weist die Response-Struktur reasoning_content ausdrücklich dem Thinking-Modus zu. Für die Diagnose müssen deshalb Request- und Response-Seite gemeinsam ausgewertet werden. (api-docs.deepseek.com)

Gemeinsames Gateway gegen lokale Direktverbindung

Ein lokaler Test kann erfolgreich sein, während die Produktionsumgebung weiterhin Reasoning-Inhalte erzeugt. Das ist kein Widerspruch. Zwischen Anwendung und DeepSeek können mehrere Konfigurationsquellen liegen:

• Modellalias im Gateway,
• Mandanten- oder Projektprofil,
• Umgebungsvariable,
• Aufgaben- oder Routing-Tag,
• Policy für komplexe Anfragen,
• automatischer Fallback bei Fehlern,
• Wiederholungslogik mit einem neuen Request-Objekt.

Besonders gefährlich ist ein Gateway, das den Modellwert korrekt weiterleitet, aber Thinking anhand eines Profils neu setzt. Dann sieht der Entwickler im Produktionslog zwar deepseek-v4-flash, nicht aber den tatsächlich wirksamen Thinking-Wert.

Der Vergleich sollte immer mit demselben anonymisierten Input erfolgen:

1. offizieller Endpunkt ohne Gateway,
2. bestehender SDK-Aufruf,
3. Test-Gateway,
4. Produktions-Gateway.

Für jede Station werden mindestens folgende Felder aufgezeichnet:

• model,
• thinking.type,
• Request-ID,
• Antwort-ID,
• reasoning_content vorhanden oder nicht vorhanden,
• usage.total_tokens,
• usage.completion_tokens,
• usage.completion_tokens_details.reasoning_tokens, sofern zurückgegeben,
• Startzeit und Ende der Anfrage.

Die offizielle API-Dokumentation weist für die Usage-Daten unter anderem prompt_tokens, completion_tokens, total_tokens und die Reasoning-Token-Unterteilung aus. Bei Streaming-Anfragen kann include_usage einen zusätzlichen Abschlussblock mit den Nutzungsdaten liefern. (api-docs.deepseek.com)

Es sollte nicht versucht werden, durch zufälliges Umbenennen des Modells eine andere Betriebsart zu erzwingen. Das verdeckt die Ursache und erschwert später die Kostenprüfung. Zuerst muss feststehen, welches Modell die Anfrage tatsächlich verarbeitet und welcher Thinking-Wert auf der letzten Netzwerkschicht vorhanden ist.

Hauptanfrage gegen versteckte Agent-Aufrufe

Bei einem einfachen Chat-Aufruf ist der Fehler oft schnell sichtbar. Bei einem AI Agent verteilt sich die Nutzung dagegen über mehrere Anfragen:

• Benutzeranfrage,
• Planungs- oder Analyseaufruf,
• Tool-Auswahl,
• Tool-Ergebnisverarbeitung,
• Zusammenfassung,
• Fehlerwiederholung,
• abschließende Antwort.

Das Abschalten in der sichtbaren Einstiegsmethode garantiert nicht, dass jede dieser Anfragen dieselbe Konfiguration übernimmt. Ein Agent-Framework kann für Planung und Tool-Aufrufe eigene Client-Instanzen erzeugen. Eine Retry-Funktion kann ein neues Payload zusammensetzen und extra_body dabei verlieren.

Die Prüfung sollte deshalb nicht nur den ersten Request betrachten. Jede Unteranfrage benötigt ein eigenes Trace- oder Span-Label, zum Beispiel:

trace_id=abc123
stage=planning
model=deepseek-v4-flash
thinking=disabled
reasoning_content=false

Für Tool-Aufrufe ist außerdem die Nachrichtenkette wichtig. DeepSeek dokumentiert, dass reasoning_content bei Thinking-basierten Tool-Aufrufen in nachfolgenden Anfragen vollständig zurückgegeben werden muss. Das erklärt, warum ein gespeichertes Feld in einer späteren Nachricht auftauchen kann. Es beweist allein noch nicht, dass der aktuelle Hauptaufruf Thinking aktiviert hat. (api-docs.deepseek.com)

Die Kostenfrage muss daher auf der Ebene des Aufrufbaums beantwortet werden:

• Erzeugt nur die Planungsanfrage Reasoning-Tokens?
• Aktiviert ein Retry Thinking erneut?
• Werden Tool-Ergebnisse mit einem neuen, nicht konfigurierten Client verarbeitet?
• Stammt das sichtbare reasoning_content aus der aktuellen Antwort oder aus einer gespeicherten Assistant-Nachricht?
• Stimmen die usage-Daten aller Unteranfragen mit der Rechnung überein?

Die offizielle Preisdokumentation legt die Abrechnung als Anzahl der Eingabe- und Ausgabetokens multipliziert mit dem jeweiligen Preis fest. Für eine Kostenregression reicht deshalb keine einzelne Antwort. Die Teamstatistik muss alle relevanten Unteranfragen und deren Tokenfelder erfassen. Die angekündigte Peak-/Off-Peak-Regel ist in der offiziellen Dokumentation zum Stand 02.08.2026 noch nicht als bereits wirksam eingeführt; sie darf daher nicht als nachträgliche Erklärung für eine aktuelle Abweichung verwendet werden. (api-docs.deepseek.com)

Isolierter Replay: der schnellste Nachweis

Eine saubere Rückprüfung benötigt keinen vollständigen Produktivverkehr. Ein fester, anonymisierter Testinput ist meist besser. Er verhindert, dass unterschiedliche Prompts oder wechselnde Tool-Ergebnisse die Diagnose verfälschen.

Schritt 1: Testfall einfrieren

Verwenden Sie einen kurzen Prompt ohne personenbezogene Daten, zufällige Werte oder externe Tools. Speichern Sie die erwartete Modellkennung und die gewünschte Betriebsart neben dem Testfall.

Schritt 2: Direkten Endpunkt prüfen

Senden Sie den Test ohne eigenen Adapter direkt an den offiziellen API-Endpunkt. Prüfen Sie, ob thinking.type als disabled im JSON steht und ob die Antwort bei derselben Request-ID kein aktuelles reasoning_content enthält.

Schritt 3: SDK-Schicht wieder zuschalten

Führen Sie exakt denselben Input über das OpenAI SDK aus. Speichern Sie nicht nur den Python- oder Anwendungscode, sondern den Request unmittelbar vor der Übertragung.

Schritt 4: Framework und Adapter aktivieren

Fügen Sie die zweite Client-Schicht hinzu. Vergleichen Sie den JSON-Baum mit dem direkten Test. Der erste Unterschied markiert die wahrscheinlichste Verluststelle.

Schritt 5: Gateway einzeln vergleichen

Testen Sie zuerst die lokale Gateway-Konfiguration und danach die Produktionsroute. Achten Sie auf Modellalias, Mandant, Umgebungsvariablen und automatische Fallbacks.

Schritt 6: Agent-Unteranfragen sichtbar machen

Deaktivieren Sie nicht die gesamte Agent-Logik, sondern versehen Sie jede Anfrage mit einem Stage-Label. Prüfen Sie Planung, Tool-Aufruf und Retry getrennt.

Schritt 7: Kostenbasis festhalten

Vergleichen Sie prompt_tokens, completion_tokens, total_tokens und Reasoning-Tokens pro Aufrufstufe. Eine Veränderung darf nur mit offizieller Abrechnungslogik oder mit klar gekennzeichneten eigenen Replay-Daten bewertet werden. Eine pauschale Einsparungsquote lässt sich aus dem deaktivierten Schalter nicht seriös ableiten.

Abnahme als ausführbare Prüfliste

• [ ] Der Test verwendet den aktuell dokumentierten Modellwert deepseek-v4-flash.
• [ ] Der Request enthält thinking.type ausdrücklich mit dem Wert disabled.
• [ ] Das Feld ist im finalen Netzwerk-JSON vorhanden, nicht nur in der Anwendungskonfiguration.
• [ ] SDK-Adapter und Framework-Wrapper verändern die Struktur nicht.
• [ ] Lokale Direktverbindung, Test-Gateway und Produktions-Gateway wurden mit demselben Input verglichen.
• [ ] Modellalias und tatsächliches Modellfeld stimmen überein.
• [ ] Umgebungsvariablen und Mandantenprofile wurden auf Überschreibungen geprüft.
• [ ] Hauptanfrage, Planung, Tool-Aufruf und Retry besitzen eigene Trace-Labels.
• [ ] Die aktuelle Antwort wurde von historischen reasoning_content-Feldern getrennt.
• [ ] Streaming-Parser speichern Reasoning-Fragmente nicht fälschlich als neue aktuelle Antwort.
• [ ] usage-Daten sind der korrekten Request-ID zugeordnet.
• [ ] Der Agent verwendet auch in versteckten Unteranfragen den gewünschten Thinking-Wert.
• [ ] API-Schlüssel, Prompts und personenbezogene Inhalte wurden vor der Logweitergabe entfernt.
• [ ] Eine produktive Änderung wurde erst nach erfolgreichem isoliertem Replay aktiviert.

Ein Team, das diese Punkte nicht belegen kann, sollte den Fall nicht als „Thinking ist deaktiviert“ markieren. Die korrekte Statusbezeichnung lautet dann: „Deaktivierung im finalen Request noch nicht nachgewiesen“.

Wenn die lokale Umgebung selbst der Störfaktor ist

Für einen kurzen API-Replay reicht häufig ein lokaler Rechner. Bei mehreren SDK-Versionen, parallelen Gateway-Konfigurationen und getrennten Agent-Branches entstehen jedoch weitere Fehlerquellen: globale Umgebungsvariablen, nicht reproduzierbare Paketstände, gemeinsam genutzte Logs und fehlende Netzwerkmitschnitte. Ein geteilter Entwicklungsrechner kann zusätzlich Datenschutz- und Berechtigungsprobleme verursachen.

Die aktuelle Umgebung ist deshalb für schnelle Einzeltests geeignet, aber weniger zuverlässig für reproduzierbare Kettenvergleiche. Typische Nachteile sind:

• SDK-, Adapter- und Gateway-Versionen lassen sich nicht sauber isolieren.
• Andere Prozesse verändern Umgebungsvariablen oder Ports.
• Produktionsähnliche Agent-Unteranfragen werden nicht vollständig nachgebildet.
• Ein lokaler Replay ist schwerer für mehrere Teammitglieder nachvollziehbar.

Eine gemietete Mac-Umgebung von ProxyMac ist für diesen begrenzten Zweck die sinnvollere Alternative, wenn ein unabhängiger Testplatz, getrennte Projektstände und ein klarer Übergabeprozess benötigt werden. Sie ersetzt keine dauerhafte Hochlast-Infrastruktur und ist nicht ideal, wenn physische Schnittstellen oder dauerhaft laufende, schwere Workloads erforderlich sind. Für zeitlich begrenzte SDK-, Gateway- und Agent-Regressionstests kann die Trennung jedoch sauberer sein als ein gemeinsam genutzter Arbeitsplatz. Vor dem Zugriff sollten Rollen, Protokollierung und Datenschutzanforderungen bei ProxyMac geprüft werden.

Für den ersten Test genügt eine kleine, klar abgegrenzte Umgebung. Die Kostenentscheidung sollte erst fallen, wenn feststeht, dass mehrere Ketten wiederholt verglichen werden müssen. Einen passenden Zugang und die verfügbaren Verwaltungsoptionen finden Sie in der ProxyMac-Konsole.

Die entscheidende Diagnose bleibt unabhängig vom Ausführungsort dieselbe: Nicht der Schalter in der Konfiguration entscheidet, sondern der letzte ausgehende Request und die dazugehörige Antwort. Wenn dort thinking.type tatsächlich auf disabled steht, die Antwort aber weiterhin aktuelle Reasoning-Felder und hohe Usage-Werte zeigt, muss die Untersuchung bei Gateway-Routing, Agent-Unteranfragen oder der Response-Verarbeitung fortgesetzt werden.

Weiterlesen

• LLM über API oder lokal betreiben: Kosten, Kontrolle und Architektur im Vergleich
• JSONL-Protokolle und Diagnostik: API-Aufrufe und Agentenfehler systematisch untersuchen