Qwen3.6-27B als lokale Reasoning-Schicht: Ergebnisse eines 2-wöchigen Multi-Agenten-Tests

Ein Entwickler ersetzte Claude durch Qwen3.6-27B in einem Multi-Agenten-Orchestrator für zwei Wochen, der vollständig auf einer einzelnen RTX 3090 lief. Das Ziel war klar: testen, ob ein lokales Modell als Reasoning-Schicht – Lead/Manager/Sub-Agent-Schleife – in realen Codierungs-Workflows dienen kann. Die Ergebnisse liefern harte Zahlen für alle, die Cloud-Kosten senken möchten.

Aufbau und Basislinie

• Hardware: RTX 3090, 24 GB VRAM
• Modell: Qwen3.6-27B mit Q6_K-Quantisierung (~22 GB on-GPU), effektiver Kontext 32k
• Inferenz-Engine: Ollama
• Orchestrator: Multi-Agenten-System mit strukturierten JSON-Plänen, Planbestätigungsmodal und automatischem Überprüfungsdurchlauf nach Sub-Agent-Abschluss
• Workload: 47 mehrstufige Codierungs-Workflows über zwei reale Repositories

Was funktionierte (Die Reasoning-Schicht)

Planerstellung. Qwen3.6 erstellte mehrstufige Pläne ungefähr so gut wie Claude bei diesen Aufgaben. Etwas konservativer – weniger unerwünschte Refactoring-Vorschläge – aber kohärent und schemakonform ~95% der Zeit nach Prompt-Anpassungen. Die restlichen 5% waren mit einem einzigen erneuten Prompt behebbar.

Extraktion von Fakten. Mem0-artige Faktenextraktion alle 6 Durchläufe funktionierte einwandfrei. Qwen extrahierte dieselben Fakten wie Claude (z.B. "Benutzer bevorzugt keine Kommentare, es sei denn, sie erklären ein 'Warum'") und speicherte sie sauber in Qdrant.

Automatische Überprüfung der Sub-Agent-Ausgabe. Eine zweite Qwen-Instanz, die den Code der ersten überprüfte, erkannte ~60% der Fehler, die Claudes Überprüfung bei derselben Menge erkannte. Weniger aggressiv, dennoch nützlich und kostenlos.

Wo es scheiterte

Zuverlässigkeit von Tool-Aufrufen. Qwen3.6s JSON-Tool-Call-Ausgabe hatte eine ~12% Formatfehlerrate bei 47 Aufgaben. Claude lag bei ~0,5% bei derselben Arbeitslast. Fehler waren kein fehlerhaftes JSON – es waren falsche Feldnamen, falsche Typen, halluzinierte Tool-Signaturen. Die Verwendung von Outlines oder Strict-Output-Modus reduzierte Fehler, eliminierte sie jedoch nicht.

Drift im langen Kontext. Nach ~14k Token akkumulierten Sitzungskontexts begann Qwen, Entscheidungen falsch zu erinnern (z.B. "Sie sagten, verwenden Sie Postgres", wenn das Gegenteil gesagt wurde). Effektive praktische Grenze liegt bei ~12k Token, dann aggressiv zusammenfassen und zurücksetzen.

Behandlung von Kaskadenfehlern. Wenn ein Sub-Agent scheiterte, bemerkte Claudes Planer dies normalerweise und plante neu. Qwen generierte manchmal nachgelagerte Schritte unter der Annahme, dass der Sub-Agent erfolgreich war. Drei kaskadierende Halluzinationen in 47 Läufen – nicht katastrophal mit Plan-Gating, aber ohne wäre es das.

Praktische Auswirkungen

Die Einschätzung des Entwicklers: "Qwen3.6-27B ist eine brauchbare Reasoning-Schicht für lokale Multi-Agenten-Systeme heute. Es ist KEINE brauchbare Ausführungsschicht." Wenn Sie reine Lokalagenten bauen, benötigen Sie:

1. Strukturierte Ausgabeerzwingung an der Tool-Call-Grenze (Outlines, lm-format-enforcer oder Grammar-Modus Ihrer Inferenz-Engine)
2. Planbestätigungs-Gating, sodass die 12% Formatfehler nie tatsächliche Dateischreibvorgänge erreichen
3. Neuplanung bei Fehlschlag-Logik – das Modell selbst kann nicht mit Kaskadenfehlern umgehen

Die 12% Tool-Call-Fehlerlücke ist die Kennzahl, die es zu beobachten gilt. Sobald Qwen3.6 oder das nächste lokale Modell ~2% bei dieser Kennzahl erreicht, schwächt sich das Argument für Cloud-Reasoning in Agentenschleifen erheblich ab.