KI · Benchmark · Analyse
Der Think-Mythos: Warum Reasoning-Mode bei lokalen LLMs meist schadet
Reasoning-Mode ist der heißeste LLM-Hype 2026. Alle Hersteller werben mit `<think>`-Tags und besseren Benchmarks. Ich habe es empirisch getestet: Auf 9 lokalen Modellen in einem echten Agent-Framework brachte Thinking niemals einen Vorteil — und einmal sogar einen 19×-Malus.
24
Datenpunkte
9 Modelle × 4 Reasoning-Fixtures im Agent-Loop
0
Fälle mit Think-Vorteil
Kein Modell, keine Task — Think hat nie geholfen
19×
Schlimmster Think-Malus
Qwen3.5-4B bei Architektur-Task: 34s PASS ohne, 667s FAIL mit Think
1 · Der Hype
Was Reasoning-Mode verspricht
Seit Qwen3, DeepSeek-R1 und OpenAI-o1 ist "Thinking" das heiße Thema. Modelle geben ihre Gedanken in einem speziellen <think>...</think>-Block aus, bevor sie eine Antwort formulieren. Hersteller-Benchmarks zeigen zum Teil dramatische Verbesserungen: +10 bis +30 Prozentpunkte bei AIME-Mathematik, SWE-bench-Coding, LiveBench.
Die Community-Weisheit lautet: Bei starken Modellen ist Think optional, bei schwächeren hilft es. Viele Tutorials empfehlen Reasoning-Mode als Default für anspruchsvolle Aufgaben.
Meine Frage: Stimmt das in realen Agent-Workloads — wenn das Modell nicht alleine dasteht, sondern in einem Framework wie OpenCode mit echten Tools (Read, Edit, Write, Bash) arbeitet? Gibt Thinking da tatsächlich noch einen Vorteil, oder wird es durch das Tool-Feedback überflüssig?
2 · Erster Test — das große Modell
Qwen3.6-35B-A3B: Think bringt nichts, kostet viel Zeit
Qwen3.6-35B-A3B (MoE, 35B total, 3B active) gegen vier Fixtures: ein Single-File-Bugfix, ein Long-Edit mit mehreren Bugs, eine Architektur-Design-Aufgabe, und eine bewusst mehrdeutige Optimierungs-Task. Jeweils mit und ohne Thinking, identische OpenCode-Konfiguration.
| Task | NoThink | Think | Δ Zeit |
|---|---|---|---|
| A2 Bugfix | 5 Steps · 10,1s | 7 Steps · 21,2s | +110% |
| A5 Long-Edit | 11 Steps · 42,3s | 11 Steps · 61,3s | +45% |
| Architektur | 2 Steps · 57,5s | 2 Steps · 103,3s | +80% |
| Ambiguity-Probe | 3 Steps · 10,0s | 5 Steps · 24,3s | +143% |
Alle vier Tests bestehen in beiden Modi — mit identischem Outcome. Think verlängert die Laufzeit zwischen 45% und 143%. Die Fix-Qualität? Geprüft per Oracle-Script plus manuelle Code-Review: kein Unterschied. Das Think-Modell schreibt teilweise minimal längere Kommentare, oft ein ASCII-Diagramm, und trifft bei der Architektur-Aufgabe dieselbe Design-Entscheidung (AWS SQS FIFO) mit fast identischer Begründung.
Erste Hypothese nach diesem Test: Vielleicht ist Qwen3.6-35B schlicht zu stark — die Lösungen sind "in den Weights". Think würde vermutlich bei kleineren Modellen helfen, die weniger Intuition haben.
3 · Zweiter Test — die Hypothese fällt
Qwen3.5-4B: Think macht es drastisch schlechter
Qwen3.5-4B (Dense, 4B, Q4_K_M, ~2,5 GB RAM) — klein genug, dass die "Think hilft kleinen Modellen"-Hypothese hier greifen müsste. Gleiche vier Fixtures, gleicher Ablauf.
| Task | NoThink | Think | Delta | Wertung |
|---|---|---|---|---|
| Debug (unmarkiert) | PASS · 8,5s | PASS · 21,9s | +156% Zeit | gleich |
| Custom-Constraint | FAIL · 6s | FAIL · 23,4s | FAIL → FAIL | kein Effekt |
| Architektur | PASS · 34,5s | FAIL · 667,3s | PASS → FAIL | ⚠️ Think schadet |
| Ambiguity-Probe | PASS · 9,8s | PASS · 18,1s | +84% Zeit | gleich |
Die Hypothese fällt. Nicht "Think hilft kleinen Modellen" — Think kann kleinen Modellen aktiv schaden.
Der Architektur-Task zeigt es am deutlichsten: Ohne Think löst das 4B-Modell die Aufgabe in 34 Sekunden mit einer soliden Analyse. Mit Think laufen 667 Sekunden (mehr als 11 Minuten), der Reasoning-Context wächst auf mehrere tausend Tokens, und am Ende produziert das Modell ein Design-Dokument, das inkonsistent ist und den Oracle-Check nicht besteht. Das Modell verwirrt sich durch den eigenen inneren Monolog.
Bei der Custom-Constraint-Aufgabe (einem mathematischen Puzzle, das die Capacity des 4B-Modells grundsätzlich übersteigt) ändert Think nichts: FAIL bleibt FAIL, nur viermal länger.
4 · Warum das so ist
Tool-Calling ersetzt in-head Reasoning
Meine Erklärungs-Hypothese: Reasoning-Mode wurde für einen Kontext entworfen, in dem das Modell alleine denken muss — keine externen Tools, kein Feedback, nur die eigene Simulation. Bei Mathematik-Benchmarks wie AIME ist das die Realität: Das Modell bekommt eine Textaufgabe und muss ohne Hilfsmittel zur Lösung kommen. Da hilft Think.
In einem Agent-Framework wie OpenCode ist die Situation fundamental anders. Das Modell hat Read, Edit, Write, Bash, Grep, Glob. Jede Operation liefert konkretes Feedback aus der echten Welt: "So sieht der Code aus. So reagiert er auf die Änderung. So war der Test-Output." Dieses externe Signal ist informativer als jede selbst simulierte Spekulation.
Wenn das Modell dann zusätzlich denkt — also den Tool-Output nochmal in Prosa durchspielt, Hypothesen bildet, Optionen abwägt — ist das Doppelarbeit. Bei starken Modellen nur Zeit-Verschwendung. Bei schwächeren Modellen eine aktive Fehlerquelle: Der wachsende Reasoning-Context überfordert die begrenzte Aufmerksamkeit, das Modell verliert den Plan, produziert inkohärente Ausgaben.
Die nachfolgende Tabelle zeigt den Kontrast direkt: Ein starker Agent in einer Agent-Umgebung braucht kein Think. Ein schwacher Agent in einer Agent-Umgebung verträgt kein Think.
5 · Zwei offene Fragen
Wo Think vielleicht doch etwas bringt
Reasoning-Spezialisten mit Flag
Modelle wie Magistral-Small-24B oder DeepSeek-R1-Varianten wurden explizit für Thinking trainiert. Bei Magistral-Small-24B ohne Flag: 2 von 4 Tests PASS (schwächer als das kleinere GPT-OSS-20B mit 4/4). Ob Magistral mit aktiviertem Thinking aufholt und über die Generalist-Konkurrenz hinausgeht, steht in meiner Testpipeline noch aus. Bei Reasoning-Spezialisten ist Think möglicherweise kein Optional, sondern strukturelle Grundausstattung.
Isolierte Analyse-Tasks ohne Tools
Nicht jede Aufgabe lässt sich mit Tool-Calling lösen. Wenn ein Modell einen Log-Auszug nur aus dem Prompt lesen und eine Root-Cause-Hypothese aufstellen soll, ohne Zugriff auf das laufende System, fehlt der externe Feedback-Kanal. In solchen Fällen könnte Thinking eine Hilfe sein — analog zum Mathematik-Benchmark-Szenario. Auch hier steht der empirische Vergleich aus.
Für die große Mehrheit der Coding-Agent-Workloads bleibt die Botschaft aber klar: Thinking einschalten ohne belegten Grund ist eine schlechte Idee.
6 · Praxis-Empfehlung
Welcher Modus für welchen Fall
--reasoning off
Kein Think. Strukturiertes Tool-Calling liefert besseres Signal als interner Monolog. Default für alle Produktiv-Agents.
--reasoning on + reasoning_budget 4096-8192
Nur wenn keine externen Tools verfügbar sind. Root-Cause-Analyse ohne Logs, Trade-Off-Matrix-Bewertung, reine Mathematik. IMMER Budget setzen.
Provider-Default respektieren
Modelle wie Magistral-Small wurden für Think trainiert — ohne Flag unterperformen sie. Bei solchen Modellen den vom Hersteller empfohlenen Modus übernehmen.
Wichtige Regel
Wenn Thinking an ist, immer ein `reasoning_budget` von 4096 bis 8192 Tokens setzen. Ohne Budget läuft das Modell in Over-Thinking-Loops — Context-Overflow, Timeouts, korrumpierte Ausgaben. Das Default-Verhalten (unbegrenzt) ist in der Praxis fast immer ein Fehler.
Zusammenfassung
Sechs Befunde aus 24 Datenpunkten
Starke Modelle: Think ist pure Zeit-Verschwendung
+45% bis +143% Laufzeit, 0% Quality-Gewinn
Qwen3.6-35B-A3B auf vier Agent-Tasks: ohne Think immer schneller, immer gleich gut. Think-Modus verlängert jeden Task um 45-143%, ohne dass ein einziger Test-Outcome besser wird — der Oracle-Check ist in beiden Modi identisch.
Kleine Modelle: Think kann dramatisch schaden
19× Laufzeit + FAIL statt PASS
Qwen3.5-4B auf Architektur-Design-Task: ohne Think 34 Sekunden PASS. Mit Think 667 Sekunden FAIL — das Modell reasoning't sich in einen Fehler hinein. Der Reasoning-Context wird so groß, dass das 4B-Modell vom eigenen Output verwirrt wird.
Strukturiertes Tool-Calling ersetzt in-head Reasoning
Read → Insight → Edit ist informativer als Selbst-Simulation
Im OpenCode-Agent-Loop liefert jedes Tool-Aufruf-Ergebnis konkretes Feedback. Das Modell muss nicht raten was im Code steht — es liest, reagiert, editiert. Think-Modus produziert hingegen einen langen inneren Monolog, der bei Coding-Tasks redundant ist.
Knowledge-Tasks sind keine Reasoning-Tasks
N-Queens-Solver: 2 Steps in beiden Modi
Klassische Algorithmus-Puzzles (Fibonacci, N-Queens, Sudoku) wirken wie Reasoning — sind aber für starke Modelle reine Knowledge-Retrieval. Die Lösung steckt in den Gewichten. Think oder NoThink spielt keine Rolle, das Modell schreibt die klassische Backtracking-Implementation direkt aus dem Stand.
Reasoning-Spezialisten ohne Think-Flag sind schwach
Magistral-Small-24B: 2/4 PASS nothink
Mistrals "Reasoning-Modell" schneidet ohne aktiviertes Thinking deutlich schlechter ab als ein gleichgroßes Generalist-Modell (GPT-OSS-20B: 4/4). Der Think-Flag ist bei diesen Modellen offenbar kein Optional, sondern struktureller Bestandteil. Retest mit Flag noch offen.
Ohne Reasoning-Budget droht Context-Overflow
3,5× langsamer + Timeouts
Ein Think-Lauf ohne explizites `reasoning_budget` führt zu Over-Thinking-Loops: Das Modell generiert Thinking-Tokens bis zum Context-Limit, Tasks timeouten, Ergebnisse werden durch Compaction korrumpiert. Budget auf 4096-8192 Tokens setzen — oder Think abschalten.
Reproduzierbarkeit — Open-Source-Benchmark
Alle Fixtures, Oracle-Skripte und Ergebnis-JSONs liegen im Benchmark-Repository. Die OpenCode-Konfiguration ist dokumentiert, Server-Start-Skripte für jedes Modell sind reproduzierbar. Die V6-Reasoning-Phase ist Teil des größeren LLM-Benchmark-Projekts auf Apple Silicon.
Repository: forgejo.routetohome.renewulff.de/formin/llm-benchmark — V6-Reasoning-Daten unter results/v6-reasoning/, OpenCode-Harness unter harnesses/opencode/.
Fazit
Thinking-Mode ist nicht kaputt. Er ist nur am falschen Platz. In der Agent-Welt, in der ein Modell Tools ruft statt alleine zu denken, wird der innere Monolog zum Ballast — und bei kleinen Modellen zur Sollbruchstelle. Der Default sollte "Thinking aus" sein, nicht "Thinking an".
Der Benchmark läuft weiter. Die Reasoning-Spezialisten-Frage und der Test auf isolierten Analyse-Tasks sind offen. Stand dieses Artikels: V6-Phase-3, 21.04.2026.
Lokale KI für Ihr Unternehmen?
Agent-Setups die wirklich funktionieren
Ich analysiere Ihren Automatisierungsbedarf und zeige, welche lokalen Modelle und Agent-Frameworks für Ihren Use-Case geeignet sind — datenbasiert, ohne Hype, ohne Vendor-Lock-in.