Anwendung der Claude-Code-Architektur auf lokale 9B-Modelle: Wichtige Erkenntnisse und Optimierungen

Experimenteller Aufbau und Schlüsselerkenntnis

Der Entwickler verwendete eine RTX 5070 Ti (16 GB VRAM) mit qwen3.5:9b über Ollama (6,6 GB) und das OpenClaw-Local-Agent-Framework. Nach 18 Tests und 10 Optimierungen war die wichtigste Erkenntnis, dass qwen3.5:9b native strukturierte tool_calls hat, während qwen2.5-coder:14b und qwen2.5:14b JSON in das Inhaltsfeld einfügen anstatt korrekte tool_calls, was zusätzliches Parsing erfordert.

Leistungsvergleich

Modellleistungsvergleich:

• qwen3.5:9b: Native tool_calls-Struktur, Denkkette aktiviert, 39 Tok/s
• qwen2.5-coder:14b: Defekter Tool-Aufruf (im Inhaltsfeld), keine Denkkette, ~30 Tok/s
• qwen2.5:14b: Defekter Tool-Aufruf (im Inhaltsfeld), keine Denkkette, ~35 Tok/s

10 Optimierungen aus der Architektur von Claude Code

• Strukturierte Systemaufforderung → +600 % Ausgabequalität (A/B-getestet: 4 gefundene Probleme vs. 25+)
• MicroCompact (Tool-Ergebnis-Kompression) → 80–93 % Kompression, 11 KB auf 367 Zeichen reduziert
• Harter Cutoff (erzwungener Übergang von Erkunden zu Erzeugen) → Löste Erkundungsschleifen, in denen 9B-Modelle stecken bleiben, indem sie Dateien lesen, ohne Ausgabe zu erzeugen
• think=false → 8–10-fache Token-Effizienz, eliminiert Sprachkontamination
• ToolSearch verzögerte Ladung → –60 % Aufforderungsplatz (229 vs. 568 Tokens)
• Vier-Typen-Gedächtnissystem (Benutzer/Feedback/Projekt/Referenz) → Personalisierte Antworten
• KV-Cache-Forking → Minimaler Effekt auf einzelne GPU (1,1-fach), benötigt vLLM
• Strenge Schreibdisziplin → Vor dem Aktualisieren des Gedächtnisses überprüfen, verhindert Gedächtniskorruption
• Paralleles Bootstrap → 9 % schnellere Kaltstartzeit
• Cache-Break-Tracking → Ollama cacht identische Aufforderungen (182 ms → 75 ms)

Kernaussage: Selbstdisziplin als die wahre Grenze

Die größte Erkenntnis war, dass die wahre Grenze für 9B-Modelle nicht die Denkfähigkeit oder die Genauigkeit der Tool-Nutzung ist, sondern die Selbstdisziplin – zu wissen, wann man mit dem Erkunden aufhören und mit der Ausgabeerzeugung beginnen soll. Ohne harten Cutoff nutzte das Modell alle 12 Schritte zum Lesen von Dateien und erzeugte 0 Bytes Bericht. Mit hartem Cutoff: 5 Schritte Lesen + 1 Schritt Schreiben = 6080 Bytes strukturierter Bericht.

Was qwen3.5:9b tatsächlich kann

• 800-zeilige Bash-Skripte lesen und echte Fehler finden (Race Conditions, nicht-atomare Operationen) – 2 Min.
• Architektur eines Vertriebs-Feedback-Systems entwerfen – 8,7 KB Dokument in 2,5 Min.
• Vollständiges Projekt erstellen (Rechner + Tests + Tests ausführen) – 28 Sek.
• 10-stufige autonome Ausführung: Web-Scraper schreiben → pip install scheitert → Workaround finden → erneut versuchen → Tests bestehen – null menschliches Eingreifen
• Vollständige Mini-Fabrik-Pipeline: suchen → Artikel schreiben → überprüfen → als HTML veröffentlichen – 2,5 Min.

Vollständige Engine-Leistung

Alle 10 Optimierungen wurden in eine einzelne Python-Engine (~280 Zeilen) verpackt. Ergebnisse des ersten Laufs:

• Bootstrap: 527 ms (paralleles Gedächtnis + Modellvorwärmung)
• Erkunden: 5 Tool-Schritte mit MicroCompact (88 % Kompression)
• Erzeugen: 1947 Zeichen strukturierter Bericht
• Gesamt: 39,4 s / null API-Kosten

Was nicht funktionierte

• KV-Cache-Forking auf einzelner GPU (benötigt Multi-GPU oder vLLM)
• Schrittbudget in der Systemaufforderung (Modell ignoriert Meta-Anweisungen über sein eigenes Verhalten)
• qwen2.5-Serie für Tool-Aufrufe (Formatprobleme)

Der Entwickler führte dies auf WSL2 + Ubuntu 24.04 aus und ist bereit, weitere Details oder den Engine-Code zu teilen.