Fachartikel · KI & Automatisierung
Neuer Motor,
aber wir haben den falschen Rundkurs getestet
Qwen3.6-35B verspricht +3,4pp SWE-bench. Im Praxistest mit 32 Agent-Tasks: gleicher Score wie Qwen3.5 — und eine wichtige Lektion darüber, was wir mit kurzem Single-Turn-Benchmark nicht messen können.
Test-Tasks
Code-Agents, Reasoning, Multi-File, Instruction — 8 Kategorien auf M4 Pro 48 GB
Langsamere Think-Laufzeit
Qwen3.6-think ohne Budget-Limit: 2238s vs. 646s (nothink) — bei identischem Score
Reasoning-Budget (Token)
Das entscheidende Setting: Think-Laufzeit 5× kürzer, F2-Timeout auf 79s gedrückt
Am 15. April 2026 veröffentlichte Alibaba Cloud Qwen3.6. Der Hersteller meldet 73,4% auf SWE-bench Verified — ein Plus von 3,4 Prozentpunkten gegenüber dem Vorgänger. Für viele ein klares Upgrade-Signal.
Ich habe das Modell mit denselben 32 Tasks getestet, die auch in meinem fortlaufenden LLM-Benchmark laufen: Code-Agents, Reasoning, Multi-File-Edits, Instruction-Following. Das Ergebnis ist nüchterner als die Pressemitteilung — und lehrreicher.
Der Artikel dokumentiert zwei Testrunden: V1 mit Default-Settings, V2 mit korrekten Hersteller-Empfehlungen. Der wichtigste Befund steckt nicht im Score-Vergleich, sondern in einem einzigen Parameter.
Modell-Fakten
Release: 15.04.2026 · llama.cpp b8680 · bartowski + Unsloth GGUFs verfügbar
Abschnitt 1
Was ist wirklich neu?
Qwen kommuniziert ein neues Modell. Die technischen Details erzählen eine andere Geschichte.
Qwen3.6 bringt zwei kommunizierte Neuerungen: verbesserte SWE-bench-Scores und das preserve_thinking Feature für Multi-Turn-Agents — damit können Reasoning-Tokens über mehrere Gesprächsrunden hinweg erhalten bleiben.
Was die technische Dokumentation nicht hervorhebt: das GGUF-Feld architecture zeigt qwen35moe — exakt der gleiche Wert wie bei Qwen3.5. Keine neue Architektur, kein struktureller Umbau der MoE-Schichten, kein verändertes Aktivierungsdesign.
Das ist keine Kritik — Training-Refreshes auf bewährten Architekturen sind legitim und können echte Qualitätssteigerungen liefern. Es ist aber eine wichtige Information für die Einordnung der Benchmark-Zahlen.
Architektur-Vergleich: 3.5 vs. 3.6
Strukturell identisch. Die Verbesserung liegt im Training — nicht in der Architektur.
Architektur-Hintergrund
Die Hybrid-Architektur verständlich erklärt
40 Attention-Layer im 3:1-Muster — warum das für Agentic-Workloads relevant ist.
Qwen3.6 hat 40 Attention-Layer, aufgeteilt in einem 3:1-Muster:
30 Effizienz-Layer (linear_attention)
Lineare Attention mit rekurrentem State. Vorteil: Speicherbedarf wächst nicht mit der Kontextlänge (O(1) statt O(n²)). Trade-off: Etwas weniger präzise bei fernen Referenzen im Kontext.
10 Präzisions-Layer (full_attention)
Klassische Full-Attention, teuer aber exakt. Über diese Layer baut sich der KV-Cache auf.
Die Community nennt die Effizienz-Layer "Gated DeltaNet" — ein lernbares Forget-Gate entscheidet, welche Informationen aus dem State verworfen werden. Das ist kein Fenster-basierter Ansatz wie bei anderen Hybrid-Modellen, sondern ein rekurrentes State Space Model mit selektivem Vergessen.
Warum das für Agent-Workloads interessant ist
Bei langen Multi-Turn-Sessions (smolagents, OpenHands, Aider) kann das Modell selbst entscheiden, welche älteren Instruktionen im State bleiben und welche vergessen werden. Das reduziert Context-Drift und stabilisiert lange Arbeitsketten.
Wichtig: Was sich gegenüber 3.5 geändert hat
Qwen3.5-35B-A3B hatte bereits dieselbe Hybrid-Struktur. Die config.json ist identisch. Der Unterschied liegt ausschließlich im Training — Qwen hat die Gewichte mit neuen Daten neu optimiert, mit Fokus auf agentic-coding und repository-navigation.
Abschnitt 2
V1: Der erste Test — nüchternes Ergebnis
Gleiche Settings wie im regulären Benchmark-Durchlauf. Vier Modelle im Direktvergleich.
V1 Ergebnisse — bartowski Q5_K_M · 32 Tasks
M4 Pro 48 GB · llama.cpp b8680| Modell | Quant | Score | Laufzeit | Hinweis |
|---|---|---|---|---|
| Qwen3.5-35B-A3B nothink | bartowski Q5_K_M | 29/32 (90%) | 651s | Baseline |
| Qwen3.6-35B-A3B nothink | bartowski Q5_K_M | 28/32 (87%) | 646s | |
| Qwen3.6-35B-A3B think | bartowski Q5_K_M | 28/32 (87%) | 2238s ⚠ | INT_MAX Budget |
| Qwen3-Coder-30B (Produktiv-Assistent) | Q4_K_M | 28/32 (87%) | 683s | Referenz |
Das Ergebnis ist eindeutig: Qwen3.5, Qwen3.6 nothink und der aktuell produktiv laufende Qwen3-Coder-30B liegen alle bei 87–90%. Kein messbarer Vorteil durch das neuere Modell.
Aber das ist belastbar: SWE-bench-Scores sind real — sie messen etwas. Nur nicht dasselbe wie unser Benchmark. Beide Messmethoden können korrekt sein.
Das Think-Problem
Qwen3.6-think: 2238s für 32 Tasks — 3,5× so lange wie nothink, bei identischem Score.
Ursache: Default-Wert für reasoning_budget ist 2147483647 (INT_MAX).
Das Modell reasonet ohne Limit. Test F2_config_integration timeoutete nach 600 Sekunden — FAIL durch Zeitüberschreitung, nicht durch falsche Logik.
Abschnitt 3
Settings-Debugging: Was die Community herausgefunden hat
Fünf Parameter, die bei Qwen3.6 mit Think-Modus den Unterschied machen.
V1 → V2: Welche Settings wurden geändert und warum
| Setting | V1 (Default) | V2 (Korrigiert) | Warum |
|---|---|---|---|
| reasoning_budget | INT_MAX (2147483647) | 8192 | Verhindert Over-Thinking-Loop — Hauptursache für Timeouts |
| Quant-Quelle | bartowski Q5_K_M | Unsloth UD-Q5_K_XL | Gepatchte Jinja-Templates gegen Tool-Calling-Bug (llama.cpp #20260) |
| Context-Window | Standard (32k) | 65k | Notwendig für Long-Context-Tests (A5, F-Serie) |
| temperature | 0.6 (default) | 1.0 | Qwen "Think General" Preset — besser kalibriert für Think-Modus |
| top_p | 0.9 | 0.95 | Qwen "Think General" Preset |
Produktive Qwen3.6 Konfiguration (llama.cpp / llama-server)
# llama-server Startparameter (Qwen3.6-35B-A3B, Think-Modus)
llama-server \
--model qwen3.6-35b-a3b-ud-q5_k_xl.gguf \
--ctx-size 65536 \
--n-gpu-layers 99 \
--port 11434
# Request-Parameter (OpenAI-kompatibel)
{
"model": "qwen3.6-35b",
"temperature": 1.0,
"top_p": 0.95,
"top_k": 20,
"min_p": 0.0,
"chat_template_kwargs": {
"thinking": true,
"reasoning_budget": 8192
}
} Das reasoning_budget ist der entscheidende Parameter. Ohne ihn läuft Think-Modus effektiv unbegrenzt — mit INT_MAX als Soft-Cap. 8192 Token sind für die meisten Coding-Tasks ausreichend und verhindern Over-Thinking-Loops.
Abschnitt 4
V2: Re-Test mit korrekten Settings
8 kritische Tests mit Unsloth-Quant, Budget 8192 und erweitertem Kontext.
F2 Config Integration — das dramatische Ergebnis
Derselbe Test, dasselbe Modell, ein geänderter Parameter. 600s Timeout → 79s PASS. Die Logik war nie falsch — das Modell hatte einfach kein Budget-Limit.
V2 Gesamtbilanz (8 kritische Tests)
Gesamtscore unverändert: Qwen3.6 ist nicht besser als Qwen3.5 — aber jetzt praktisch nutzbar.
A5 Long-Context — der echte Vorteil
A5 testet großflächiges Refactoring mit mehr als 30k Token Kontext. Hier zeigt Qwen3.6 einen messbaren Vorteil — der einzige Test mit klarer Differenz.
Ehrlich über den Benchmark-Scope
Unsere 32 Tests sind Single-Turn und relativ kurz (max ~34k Kontext, alle Tests isoliert). Qwen3.6 wurde laut Qwen vor allem für Multi-Turn-Agent-Sessions und Repository-Level-Navigation optimiert — genau die Szenarien, in denen die Hybrid-Architektur ihre Stärken ausspielen sollte: selektives Vergessen, langer rekurrenter State, stabilere Arbeitsketten.
Das erklärt, warum wir kaum Unterschiede zu Qwen3.5 sehen: Wir testen nicht, was 3.6 besser macht. Das heißt aber auch: Wer lange Agent-Sessions mit Repository-Navigation und vielen Tool-Calls fährt, könnte bei 3.6 echten Mehrwert sehen — nur belegen können wir das mit unserem aktuellen Benchmark-Scope nicht.
Eigene Long-Context-Multi-Turn-Testsuite steht auf der Roadmap. Bis dahin gilt: 3.6 ist in kurzen Tasks gleichauf mit 3.5 — über echten Agentic-Einsatz sagen unsere Zahlen nichts.
Einordnung
Qwen3.6 im Wettbewerb — nicht mehr allein an der Spitze
Nachfolge-Tests mit einer erweiterten Modell-Matrix (V6, Phase 3) zeigen: Gleichstand auf dem Spitzenscore, aber deutliche Laufzeit-Unterschiede.
V6 Phase 3 — Multi-Modell-Rangliste (4 kritische Tests)
M4 Pro 48 GB · llama.cpp| Modell | Architektur | Größe | Score | Zeit | Hinweis |
|---|---|---|---|---|---|
| Gemma-4-26B-A4B | MoE SWA | 26B/4B aktiv | 4/4 | 62s | Schnellster 4/4 |
| Qwen3.6-35B-A3B | MoE DeltaNet | 35B/3B aktiv | 4/4 | 80s | |
| GPT-OSS-20B | Dense | 20B | 4/4 | 106s | |
| Nemotron-3-Nano-30B-A3B | MoE Mamba | 30B/3B aktiv | 4/4 | 148s | |
| Gemma-4-31B | Dense SWA | 31B | 4/4 | 580s | Langsamster 4/4 |
Alle fünf Modelle erreichen 4/4 — kein klarer Score-Sieger. Aber die Laufzeit-Unterschiede sind erheblich: Gemma-4-26B-A4B löst dieselben Tests in 62 Sekunden, Gemma-4-31B (Dense) braucht 580 Sekunden.
Qwen3.6-35B-A3B liegt mit 80 Sekunden im vorderen Feld — schneller als alle Dense-Modelle gleicher Größe, aber langsamer als Gemma-4-26B. Wer auf Apple Silicon nur Inferenz-Geschwindigkeit optimiert, hat mit dem neueren Gemma-4-MoE heute eine gleichwertige, schnellere Option.
Was das für Qwen3.6 bedeutet
Ergebnis: Qwen3.6 ist nicht überholt — aber der Abstand zur Konkurrenz ist seit dem Release geschrumpft. Die Modellwahl hängt heute stärker am spezifischen Use-Case als am Benchmark-Score.
Erkenntnisse — April 2026
Was dieser Test wirklich zeigt
Sechs Befunde aus zwei Testrunden — mit konkreten Zahlen.
Gleicher Bauplan, neues Training — unser Benchmark trifft die Verbesserung nicht
87% vs. 90% — kein Durchbruch in unseren Tests
Das Config-Schema ist identisch zu Qwen3.5: gleicher model_type (qwen3_5_moe), gleiches Hybrid-Layer-Muster. Die Neuerung liegt im Training — optimiert für Multi-Turn-Agent-Sessions und Repository-Navigation. Genau diese Szenarien decken unsere 32 kurzen Single-Turn-Tasks nicht ab. Deshalb sehen wir kaum Unterschied: Wir testen nicht, was 3.6 besser macht.
Reasoning-Budget ist kein optionales Setting
INT_MAX → Timeout. Budget 8192 → 79s PASS
Ohne Reasoning-Budget reasonet Qwen3.6-think ins Leere: F2_config_integration timeoutete nach 600s. Mit --reasoning-budget 8192 löst dasselbe Modell denselben Test in 79 Sekunden. 5× kürzere Gesamtlaufzeit. Die meisten öffentlichen Benchmarks dokumentieren diesen Parameter nicht.
Quantisierungsquelle matters bei Agent-Workloads
Unsloth > bartowski für Tool-Calling-Stabilität
Unsloth Dynamic GGUFs enthalten gepatchte Jinja-Templates gegen bekannte Tool-Calling-Bugs (llama.cpp Issue #20260). Score-mässig selten sichtbar — aber bei Agent-Workloads mit vielen Tool-Calls ist die Fehlerrate messbar niedriger.
Hersteller-Benchmarks ≠ Alltags-Nutzen
+3,4pp SWE-bench, 0pp in eigenen Tests
Beide Messungen können korrekt sein und trotzdem verschiedene Dinge zeigen. SWE-bench Verified testet sehr spezifische Code-Repair-Szenarien. Unsere Agent-Harness testet allgemeine Coding-Tasks, Reasoning und Instruction-Following. Kontext entscheidet.
Die echte Stärke: Long-Context-Edits
A5: Qwen3.6 PASS 96s / Qwen3-Coder-30B FAIL
A5 (großes Refactoring mit >30k Kontext) ist der einzige Test wo Qwen3.6 einen klaren Vorsprung zeigt. Wer regelmäßig lange Dateien bearbeitet oder viele Kontext-Files im Workspace hat, bekommt einen echten Mehrwert.
MoE-Architektur macht paralleles Vorhalten akzeptabel
3B aktiv / Token — gleicher RAM-Footprint
Da Qwen3.6 und Qwen3-Coder-30B beide MoE-Modelle mit ~3B aktiven Parametern sind, ist der RAM-Footprint trotz nominell 35B bzw. 30B Parameter vergleichbar. Beide Modelle gleichzeitig zu laden ist auf Systemen mit 48 GB RAM machbar.
Deployment
Welches Backend, welche Quantisierung?
Nicht jedes Inferenz-Framework handhabt die Hybrid-Architektur gleich. Ein Faktor-40-Unterschied ist real.
Backend-Kompatibilität — Qwen3.6-35B-A3B
| Backend | Status | Anmerkung |
|---|---|---|
| llama.cpp (Metal / Apple Silicon) | ✅ Empfohlen | Unsloth UD-Q5_K_XL, gepatchtes Jinja-Template |
| llama.cpp (CUDA 12.x) | ✅ OK | Standard-Setup |
| llama.cpp (CUDA 13.2) | ❌ Gibberish-Output | NVIDIA-Bug, Fix ausstehend — CUDA 12.x nutzen |
| MLX (Apple Silicon) | ⚠️ Nur Single-Turn | Hybrid-KV-Cache-Problem bei Multi-Turn (siehe unten) |
| Ollama | ❌ Inkompatibel | mmproj-Handling fehlt |
MLX-Vorsicht bei Agent-Workloads
MLX-Community bietet mehrere Qwen3.6-Quants (4bit, 8bit, bf16, DWQ, MXFP4). Für einzelne Prompts funktioniert das. Aber:
Das MLX-lm Framework kann Prefix-Caches für Hybrid-Attention-Modelle aktuell nicht über Turns wiederverwenden (Issue #980). Effekt: Ein 40k-Kontext muss bei jedem neuen Turn komplett neu gefüllt werden — ~200 Sekunden statt ~5 Sekunden mit llama.cpp (Faktor 40 langsamer).
Für klassische Chat-Single-Shots ist MLX konkurrenzfähig. Für Agent-Frameworks mit Multi-Turn-Kontext (smolagents, OpenHands, Aider, Claude Code) führt MLX aktuell zu unbrauchbar langen Wartezeiten zwischen den Turns.
Empfehlung: Für Qwen3.6 im Agent-Einsatz auf Apple Silicon — llama.cpp mit Metal-Backend. Das verwaltet den Hybrid-KV-Cache korrekt.
Praxis-Empfehlung
Welches Modell für welchen Zweck?
Drei klare Empfehlungen — basierend auf den Benchmark-Ergebnissen.
Schneller Code-Assistent
Produktiv-AssistentQwen3-Coder-30B-A3B
~20 GB · ~73 t/s · 28/32
Für alltägliche Coding-Aufgaben, Bugfixes und mittlere Kontextfenster — bewährt im Produktivbetrieb. Kein Upgrade-Bedarf.
M4 Pro 48 GB
Long-Context-Editor
Long-ContextQwen3.6-35B-A3B
~20 GB · ~42 t/s · 28/32
Stärker bei Refactoring-Tasks mit mehr als 30k Kontext. A5-Test: PASS in 96s, wo Qwen3-Coder-30B scheitert. Pflicht-Setting: --reasoning-budget 8192.
M4 Pro 48 GB
Balanced Agent-Workloads
Sweet SpotQwen3.5-9B think
~6 GB · ~60 t/s · 6/7
Sweet Spot: Kleiner RAM-Footprint, schnelle Inferenz, solides Reasoning. Für klassische Agent-Tasks die keine 35B-Modelle brauchen. Qwen3.6 hebt sich erst bei sehr langen Multi-Turn-Sessions mit Repository-Navigation ab.
Mac mit 16 GB RAM
Upgrade-Empfehlung
Kein laufendes Setup ersetzen
Wer Qwen3.5 oder Qwen3-Coder-30B produktiv nutzt: kein Upgrade-Bedarf. Score-Unterschied ist marginal.
Neues Setup: Qwen3.6 wählen
Wer heute neu anfängt: Qwen3.6 mit korrekten Settings. Frischer Trainingsstand, preserve_thinking für Multi-Turn.
Long-Context-Workloads: klares Ja
A5-Ergebnis ist eindeutig. Wer regelmäßig große Kontextfenster braucht, bekommt einen messbaren Vorteil.
Benchmark reproduzierbar auf GitHub
Alle Fixture-Daten, Harness-Konfigurationen und Raw-JSONs sind öffentlich: formin/llm-benchmark — Kuratierte Summaries unter results/qwen36-v1.json und results/qwen36-v2.json, Raw-Runs unter results/qwen3.6-35b-a3b/. Hardware: MacBook Pro M4 Pro 48 GB, llama.cpp b8680. Qwen3.6-35B-A3B, Unsloth UD-Q5_K_XL.
Fazit
Qwen3.6 ist nicht schlechter als Qwen3.5 — und in unseren Tests auch nicht besser. Aber das liegt an uns: Wir haben den falschen Rundkurs gefahren. Die Hybrid-Architektur ist kein Marketing, sondern echte Technik für Multi-Turn-Agentic-Sessions. Unser Single-Turn-Benchmark trifft genau das nicht. Und: Reasoning-Budget ist kein Detail, sondern Pflicht-Parameter für jeden Think-Modus.
Hersteller-Benchmarks zeigen echte Stärken — aber immer im Kontext ihrer spezifischen Test-Fixtures. Wer Qwen3.6 für lange Agent-Sessions mit Repository-Navigation einsetzt, bekommt vermutlich einen echten Vorteil. Wer kurze isolierte Tasks fährt: Qwen3.5 oder Qwen3-Coder-30B reichen. Und für Apple Silicon gilt: llama.cpp mit Metal, nicht MLX — solange der Hybrid-KV-Cache-Bug offen ist.
Interesse an lokaler KI für Ihr Unternehmen?
KI, die in Ihrer Infrastruktur bleibt
Ich analysiere Ihren Automatisierungsbedarf und zeige, welche lokalen Modelle für Ihren Use-Case geeignet sind — DSGVO-konform, ohne Cloud-Abhängigkeit, ohne Vendor-Lock-in.