LLM-Denksteuerung: Was 13 Modelle beachten oder ignorieren

Derselbe Parameter zur Steuerung des Denkprozesses bedeutet drei verschiedene Dinge, je nachdem, an welches Modell man ihn sendet: thinking_budget: 16 verbraucht bei Qwen 3.8 Max, GLM 5.2 und beiden DeepSeek V4-Builds exakt 16 Reasoning-Tokens, wird bei Kimi K3 und MiniMax M3 stillschweigend ignoriert und von GPT-5.6 mit einem 400 abgelehnt. Wir haben 13 Modelle von neun Anbietern mit jeder Steuerungsschreibweise getestet, die die OpenAI-kompatible Schnittstelle akzeptiert, und dann gemessen, was jede Reglerposition an Reasoning-Tokens kostet und was sie an Genauigkeit einbüßt – bei denselben vier gesalzenen Aufgaben, drei Durchläufe pro Zelle.

TL;DR

• thinking: {"type": "disabled"} setzt das Reasoning bei 11 von 13 Modellen auf null; die beiden Ausnahmen (Gemini pro, GPT-5.6) lehnen es ab.
• Qwen, GLM und DeepSeek verbrauchen thinking_budget: 16 als genau 16; Kimi und MiniMax akzeptieren das Feld und ändern nichts: Kimi verbrauchte 8-97 gegen dieses Limit, nie 16.
• Bei ausgeschaltetem Thinking fiel die 5-schrittige Arithmetik bei acht Modellen von 3/3 auf 0-1/3; DeepSeek V4 Pro und Claude behielten 3/3, indem sie die Schritte in die sichtbare Antwort schrieben.
• Die JSON-Extraktion erreichte 3/3 mit ausgeschaltetem Thinking bei allen 12 Modellen, die das Ausschalten unterstützen.

Welche Denksteuerungen akzeptiert die jeweilige API?

Auf OpenAI-kompatiblen APIs sind drei Arten der Steuerung verbreitet, doch kein Modell berücksichtigt sie alle. reasoning_effort erwartet ein Enum (none bis max), thinking_budget eine Token-Anzahl. thinking: {"type": "disabled"} und die verwandte Variante enable_thinking: false sollen Thinking vollständig abschalten. Die folgende Übersicht zeigt die gemessene Akzeptanz. Pro Zelle haben wir eine einfache gesalzte Frage gesendet:

Zwei Zeilen verdienen eine Kennzeichnung. Google teilt seine eigene Linie: Die Flash-Stufe lässt sich sauber abschalten, während die Pro-Stufe jede Off-Schreibweise mit einem 400 ablehnt, was Googles Position entspricht, dass Denken der Pro-Klasse nicht deaktiviert werden kann. Und die beiden mit „accepted” markierten claude-fable-5-Zellen weichen von Anthropics veröffentlichtem Vertrag für dieses Modell ab, der festlegt, dass Denken nicht deaktiviert werden kann; betrachte diese Zellen als im Wandel begriffen.

Bedeutet „akzeptiert“ auch „durchgesetzt“?

Nein, und für den Unterschied zahlen Sie. Eine HTTP-200-Antwort bestätigt nur, dass der Parameter geparst wurde. Sie sagt nicht, ob er das Modell erreicht hat. Ein einfacher Test schafft Klarheit: Budget 16 senden und anschließend den Zähler prüfen.

Qwen, GLM und beide DeepSeek-Builds verbrauchten exakt 16. Kimi verbrauchte 8, 19, 79 und 97 gegen dieselbe Obergrenze über vier Durchläufe, nie 16, und MiniMax verhielt sich bei 18-44 genauso, wurde wie üblich abgerechnet, ohne dass in der Antwort irgendetwas darauf hindeutete, dass die Obergrenze fallengelassen worden war. Gemini übersetzt Budgets mit grober Granularität in seine native Steuerung: Bei flash verhielten sich Obergrenzen von 0 bis 64 wie ein vollständiges Aus, während 1.024 das Nachdenken erlaubte (Median 141 bei unserer 5-Schritt-Aufgabe); die pro-Stufe reduzierte ihren Verbrauch unter einer Obergrenze, blieb aber bei etwa 200 gegen eine angeforderte 64 hängen und kann nicht null erreichen. GPT-5.6 und Claude liegen am ehrlichen Ende des Spektrums: Numerische Budgets werden mit einem 400 abgelehnt, und man weiß sofort, woran man ist.

Die praktische Regel lautet: Prüfen Sie nach jeder Änderung an der Denksteuerung in der nächsten Antwort completion_tokens_details.reasoning_tokens und kontrollieren Sie, ob sich der Wert tatsächlich geändert hat. Eine laut fehlschlagende Steuerung kostet einen Retry. Eine stillschweigend wirkungslose Steuerung verursacht bei jedem Aufruf genau die Reasoning-Kosten, die Sie eigentlich begrenzen wollten.

Gibt es einen universellen Ausschalter?

thinking: {"type": "disabled"} kommt dem am nächsten: Es setzte das Reasoning bei 11 der 13 Modelle auf null, darunter Kimi, Qwen, beide DeepSeeks, GLM, Gemini flash, MiniMax, die Seed-Reihe von ByteDance und alle drei Claude-Modelle. Sein Doppelgänger enable_thinking: false stimmt fast überall damit überein, mit einer stillen Ausnahme: MiniMax akzeptiert es und behält das Reasoning bei (31 Reasoning-Tokens bei unserem Test).

Die beiden Ausnahmen scheitern laut statt still: Gemini pro gibt für jede Falschschreibung einen 400 zurück (die Stufe kann das Nachdenken nicht deaktivieren), und GPT-5.6 weist das Feld ebenfalls zurück. GPT-5.6 braucht im gleichen Sinne keinen Ausschalter: gpt-5.6-luna verbrennt bei einfachen Abfragen und Extraktionen standardmäßig null Reasoning-Tokens (das Zwei-Hebel-Muster dieser Familie), und reasoning_effort: "none" fixiert dieses Verhalten auch für mathematisch geformte Eingaben.

Wie stark leidet die Genauigkeit ohne Thinking?

Bei einer fünfstufigen Rechenkette massiv: Acht Modelle fielen unmittelbar nach dem Abschalten von Thinking von 3/3 auf 0/3 oder 1/3. Bei einer Textaufgabe mit zwei Schritten waren die Auswirkungen deutlich geringer. Die meisten Modelle hielten ohne Thinking 3/3. Nur Kimi und MiniMax fielen dort auf 0/3. Es ist derselbe instabile Aus-Zustand, den die K3-Analyse bereits beim ursprünglichen Build gezeigt hat. Der Einbruch beginnt dort, wo das Modell nicht mehr alle Schritte in einem einzigen sichtbaren Durchlauf verarbeiten kann.

Die drei Modelle ohne Genauigkeitsverlust nutzen denselben Trick: Bei deaktiviertem Thinking schreiben sie die Zwischenschritte in die sichtbare Antwort. Die mediane Antwortlänge von DeepSeek V4 Pro stieg von 115 auf 142 Token, die von Sonnet 5 von 70 auf 139. Statt für verborgenes Reasoning zahlen Sie nun für sichtbares Reasoning. Bei den meisten Preismodellen gilt dafür derselbe Output-Tarif. Der Ausschalter verschiebt die Kosten also eher, als sie zu beseitigen. Modelle, die im Aus-Zustand pflichtgemäß nur 1-4 Token ausgeben, brechen dagegen ein.

Wo dieser Einbruch auftritt, reicht ein kleines Budget aus, um die Genauigkeit wiederherzustellen: thinking_budget: 256 brachte Qwen und beide DeepSeek-Builds bei einem Median von 77-128 Reasoning-Token wieder auf 3/3. Dieses Muster, bei dem ein kleines Mindestbudget die Leistung rettet, haben wir auch beim neu trainierten DeepSeek-Modell und bei den versteckten Limits von Qwen 3.8 gemessen.

Eine Zelle unserer Matrix lieferte überhaupt keine Zahlen: claude-fable-5 antwortete bei unserer exakten Formulierung der Rechenaufgabe in 12 von 12 Durchläufen und bei jeder Effort-Einstellung mit stop_reason: "refusal" (Kategorie cyber). Eine semantisch identische Umformulierung wurde in 12 von 12 Fällen akzeptiert. Anthropic dokumentiert Ablehnungen als eigenen Stop-Grund und bietet einen optionalen Fallback-Mechanismus. Wenn Fable-Modelle Teil Ihrer Rotation sind, sollten Sie diesen Stop-Grund behandeln, bevor er in Produktion auftritt.

Was bringen die einzelnen Effort-Stufen tatsächlich?

Die Kurve unterscheidet sich je nach Anbieter, und nur bei Google steigt sie gleichmäßig an. Wir haben für jedes Modell das vollständige akzeptierte Enum mit derselben fünfstufigen Aufgabe getestet, jede Einstellung dreimal ausgeführt und die Medianwerte gemeinsam dargestellt:

Die Linien lassen sich in vier Gruppen einteilen. Echte Drosselung: Beide Gemini-Modelle steigen monoton an, bei Flash von 137 auf 390 Reasoning-Token und bei Pro von 180 auf 387, wobei die Kurve bei high in die Sättigung geht. low hielt bei einem Drittel bis zur Hälfte des Verbrauchs der höchsten Einstellungen eine Genauigkeit von 3/3. Für Gemini-Pipelines ist das daher die Einstellung, die sich standardmäßig fest konfigurieren lässt. Flache Linien: DeepSeek (78 bei low, 54 bei max, mit sinkender Tendenz), Kimi (94 bei minimal, 67 bei max) und MiniMax (61-93 ohne erkennbare Reihenfolge) bieten mehrere Reglerpositionen, die praktisch nichts verändern. Die Modellbeschreibung von DeepSeek nennt Benchmarks mit „max reasoning effort“, obwohl sich diese Einstellung bereits in früheren Messungen nicht vom Standard unterschied. Limits, die nicht greifen: Die Stufen von Qwen sind Budgetobergrenzen. Bei einer Aufgabe dieser Größe bleiben sie unsichtbar (85-156 ohne Trend) und wirken erst bei komplexen Aufgaben, wie separate Messungen zeigen. Nicht monoton: high verbrauchte bei GLM 116 Token, gegenüber 184 bei low und 345 bei max. Solange diese Zuordnung nicht stabil ist, sollten die mittleren Einstellungen als ungeordnet betrachtet werden. Die beiden adaptiven Modelle brauchen den Regler kaum: gpt-5.6-luna liegt über das gesamte Enum hinweg zwischen 32 und 41 Token. Bei Opus 5 bewegte output_config.effort die sichtbare Ausgabe nur im Bereich des Messrauschens (54-63 Token, bei Sonnet 5 ähnlich mit 71-92). Die eigentliche Entscheidung trifft das adaptive Thinking.

Daraus folgt eine klare Betriebsregel: Bei Gemini muss die Stufe bewusst gewählt werden, weil jeder Schritt reale Kosten verursacht. Bei Qwen, GLM und DeepSeek sollten Sie mit dem exakten thinking_budget und dem Ausschalter steuern, nicht mit dem Enum. Bei allen anderen Modellen ist das Enum zwischen Aus und Standard meist nur Dekoration. Gewissheit liefert nur der beschriebene Stufentest: dieselbe Aufgabe mit jeder Einstellung ausführen und anschließend den Zähler prüfen.

Die Erkenntnis zur Aufgabenstruktur lässt sich verallgemeinern: Bei unserer einstufigen JSON-Extraktion entstanden mit aktiviertem Thinking die höchsten Werte der gesamten Matrix, nämlich 377 Reasoning-Token bei GLM und 332 bei Gemini Flash. Einen Nutzen gab es nicht. Alle 12 Modelle, die Thinking abschalten können, erreichten ohne Thinking 3/3. Bei strukturierten Extraktionen fällt die größte sinnlose Reasoning-Abgabe an. Gleichzeitig ist genau dort der Ausschalter sicher.

Können Sie sehen, wofür Sie bezahlt haben?

Der Abrechnungszähler ist überall verfügbar, die Denkprozesse selbst sind es nicht. Sechs Modelle aus den Open-Weight-Familien geben Reasoning-Text in reasoning_content zurück: GLM 5.2 und DeepSeek V4 Pro lieferten offenbar die vollständige Gedankenkette zurück, mit 508 beziehungsweise 312 Zeichen für 167 beziehungsweise 100 Reasoning-Token. Kimi, Qwen, DeepSeek Flash, MiniMax und Seed gaben kürzere Traces zurück, die ungefähr ihrem geringen Verbrauch entsprachen. GPT-5.6 und beide Gemini-Modelle geben nichts zurück: Die Reasoning-Token werden berechnet, bleiben aber unsichtbar. Claude liefert thinking-Blöcke, deren Inhalt auf der von uns gemessenen API standardmäßig fehlt. Sie erkennen also, dass Thinking stattgefunden hat, sehen aber nicht dessen Inhalt.

Diese unterschiedliche Sichtbarkeit ist beim Debugging des Budgetverhaltens relevant. Wenn ein Modell keinen Inhalt zurückgibt, bleiben die reasoning_tokens in den Nutzungsdetails das einzige Messinstrument. Es gilt erneut: Vertrauen Sie dem Zähler, nicht dem HTTP-200-Status.

FAQ

Wie schalte ich Thinking bei einer OpenAI-kompatiblen API ab?

Sende thinking: {"type": "disabled"}; in unserer Matrix aus 13 Modellen setzte dies das Reasoning bei 11 auf null (Kimi, Qwen, DeepSeek x2, GLM, Gemini flash, MiniMax, Seed und die Claude-Familie). Gemini pro lässt sich nicht abschalten und gibt einen 400 zurück; GPT-5.6 lehnt das Feld ab, denkt aber bei einfachen Aufgaben standardmäßig kaum nach. Überprüfe dies, indem du reasoning_tokens in der nächsten Antwort ausliest.

Deaktiviert thinking_budget: 0 das Thinking?

Das hängt vom Modell ab. Bei Gemini flash und ByteDance Seed verhält sich 0 wie ein sauberes Aus; Qwen und DeepSeek lehnen 0 mit einem 400 ab; Kimi und MiniMax akzeptieren jedes Budget und ignorieren es. Wo Budgets tokengenau durchgesetzt werden (Qwen, GLM, DeepSeek), ist der kleinste nützliche Wert eine kleine positive Zahl: 256 hielt 3/3 bei Qwen und beiden DeepSeek-Builds bei unserer 5-stufigen Aufgabe, während GLM bei derselben Einstellung auf 2/3 schwankte.

Kann Thinking bei der JSON-Extraktion sicher deaktiviert werden?

In unseren Tests ja: Die einstufige Extraktion erreichte bei jedem Modell, das Thinking abschalten kann, ohne Thinking 3/3. Mit aktiviertem Thinking wurden für dieselbe Ausgabe bis zu 377 Reasoning-Token verbraucht. Entscheidend ist die Anzahl der Verarbeitungsschritte, nicht das Ausgabeformat. Mehrstufige Aufgaben brachen ohne Thinking bei 8 von 11 Modellen ein. Eine Einschränkung zeigte unsere DeepSeek-Analyse: Beim neu trainierten 0731-Modell verfälschte aktiviertes Thinking Werte in strikt vorgegebenem JSON. Dort verbessert der Ausschalter auch die Korrektheit.

Welche Modelle setzen Thinking-Budgets exakt durch?

Qwen 3.8 Max, GLM 5.2 und beide DeepSeek-V4-Builds: Anfrage 16, der Zähler zeigt 16 an. Kimi K3 und MiniMax akzeptieren dasselbe Feld und ignorieren es; Gemini übersetzt es grob (kleine Werte wirken auf Flash wie „aus”, Pro deckelt hohe Werte); GPT-5.6 und die Claude-5-Generationsmodelle lehnen numerische Budgets rundweg ab (Claudes budget_tokens gibt einen 400 zurück, der auf adaptives Denken verweist).

Gemessen am 11./12.08.2026 über das Synthorai-Gateway: Akzeptanz-Proben für reasoning_effort (7 Werte), thinking_budget (0/16/1024), enable_thinking und thinking:{"type":"disabled"} über 13 Modelle hinweg, Stunden vor der Veröffentlichung erneut verifiziert; danach eine Steuer-Matrix mit 552 Aufrufen (vier gesalzene Aufgabenformen x 3 Durchläufe pro Arm, Arme beschränkt auf die verifiziert funktionierenden Steuerungen jedes Modells), eine Voll-Enum-Leiter mit 183 Aufrufen auf der 5-Schritt-Aufgabe (die Daten des Diagramms), Aufstock-Zellen und eine modellweise Probe zur Sichtbarkeit des Reasonings. Genauigkeit anhand der Rohantworten bewertet; Token-Mediane von n=3; Reasoning-Tokens aus completion_tokens_details.reasoning_tokens gelesen (Claude-Modelle melden nur Output-Tokens). Prompts pro Aufruf gesalzen. Dial-Semantik und Enums sind die Oberfläche, die wir an diesem Datum gemessen haben, und können sich ändern; erneut proben, bevor man sich auf eine einzelne Zelle verlässt.

← Zurück zum Blog