Qwen 3.6: 35B vs 27B Vergleich - Benchmark-Ergebnisse
Endlich habe ich alle Qwen 3.6 Modell-Testergebnisse zusammengefasst, die ich in den letzten Tagen gesammelt habe. Ich habe zwei Modelle im Detail verglichen: das Qwen3.6-35B-A3B (MoE, hybrid attention/delta) und das Qwen3.6-27B (dense, hybrid attention/delta). Beide habe ich mit turbo3 KV Cache-Kompression auf einer RTX 4090 als llama.cpp Server betrieben.
Wenn ich kurz zusammenfassen müsste: das 35B-A3B ist 3-4x schneller in allem, aber das 27B liefert bessere Qualität. Dies ist der klassische MoE vs. Dense Tradeoff, nur mit Zahlen untermauert.
Architektur - was ist der Unterschied?#
Beide Modelle stammen aus derselben Qwen3.6-Familie, beide verwenden eine hybrid Mamba/Attention-Architektur, aber ihre Ansätze sind völlig unterschiedlich:
35B-A3B:
- 35B Gesamtparameter, aber nur 3B aktiv pro Token
- 40 Schichten: 10 × (3× Gated DeltaNet → MoE) + 1 × (Gated Attention → MoE) pro Block
- Nur 10 Full-Attention-Schichten (GQA, 16Q/2KV, 256-dimensional)
- 30 Gated DeltaNet-Schichten (rekurrent, kein KV Cache)
- MoE Routing: 8+1 Shared Expert aus 256 Experts
- Native Kontextlänge: 262.144 Token
27B Dense:
- 27B Gesamtparameter, 27B aktiv pro Token (jeder Parameter wird aktiviert)
- 64 Schichten: 16 × (3× Gated DeltaNet → FFN) + 1 × (Gated Attention → FFN) pro Block
- Nur 16 Full-Attention-Schichten (GQA, 24Q/4KV, 256-dimensional)
- 48 Gated DeltaNet-Schichten (rekurrent, kein KV Cache)
- Dichter FFN - kein MoE, alles wird pro Token berechnet
- Native Kontextlänge: 262.144 Token
Der Punkt: das 35B-A3B ruft nur 9 von 256 Experts pro Token auf, während das 27B alle seine Parameter verarbeiten muss. Das bedeutet 9x weniger Berechnung pro Token.
Needle-In-Haystack (NIAH) - Langkontext-Abfrage#
Dieser Test misst, ob das Modell eine wichtige Information in einem riesigen Text finden kann. Die Nadel ist ein Satz, den ich irgendwo im Heuhaufen versteckt habe, und das Modell muss ihn wiederherstellen.
35B-A3B (IQ4_XS Quant, turbo3 KV Cache):
| Kontext | 0% | 5% | 25% | 50% | 75% | 100% |
|---|---|---|---|---|---|---|
| 4k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 8k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 16k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 32k | 1.0 | - | 1.0 | 1.0 | - | 1.0 |
| 64k | 1.0 | - | 1.0 | 1.0 | - | 1.0 |
| 128k | 1.0 | - | 1.0 | 1.0 | 1.0 | 1.0 |
| 200k | 1.0 | - | - | 1.0 | - | 1.0 |
Gesamt: 100% (74/74 Tests) - perfekt bei jeder Kontextlänge und jeder Tiefenposition.
27B (UD-Q5_K_XL Quant, turbo3 KV Cache):
| Kontext | 0% | 5% | 25% | 50% | 75% | 100% |
|---|---|---|---|---|---|---|
| 4k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 8k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 16k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 32k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 64k | 1.0 | - | 1.0 | 1.0 | 1.0 | 1.0 |
| 100k | 1.0 | - | 1.0 | 1.0 | 1.0 | 1.0 |
| 130k | 1.0 | - | 1.0 | 1.0 | 1.0 | 1.0 |
Gesamt: 100% (78/78 Tests) - ebenfalls überall perfekt.
Fazit: Beide Modelle liefern perfekte NIAH-Ergebnisse, ohne jegliche Degradation unter turbo3 KV Cache Quantisierung. Ich habe das 35B-A3B bis zu höheren Kontextlängen getestet (200k vs 130k), aber das 27B lieferte ebenfalls stabil 100% bei allen getesteten Punkten.
Token-Generierungsgeschwindigkeit - der große Unterschied#
Hier wird der MoE vs. Dense Unterschied wirklich beeindruckend. Auf einer RTX 4090 mit turbo3 KV Cache:
Decode (Token-Generierung):
| Kontext | 35B-A3B (tok/s) | 27B (tok/s) | Verhältnis |
|---|---|---|---|
| Kurzer Kontext (Spitze) | 161.8 | 40.3 | 4.0× |
| 4k | 152.6 | 38.7 | 3.9× |
| 8k | 142.7 | 36.5 | 3.9× |
| 16k | 122.2 | 32.4 | 3.8× |
| 32k | 96.0 | 28.1 | 3.4× |
| 64k | 65.4 | 18.6 | 3.5× |
| 100k+ | ~55 (geschätzt) | 16.6 | ~3.3× |
Prefill (Prompt-Verarbeitung):
| Kontext | 35B-A3B (tok/s) | 27B (tok/s) | Verhältnis |
|---|---|---|---|
| Spitze | 5912 (bei 4k) | 2620 (bei 4k) | 2.3× |
| 4k | 5912 | 2620 | 2.3× |
| 16k | 5441 | 2610 | 2.1× |
| 32k | 5271 | 2331 | 2.3× |
| 64k | 4688 | 1959 | 2.4× |
| 100k | ~4200 (geschätzt) | 1733 | 2.4× |
Was bedeutet das in der Praxis?
Das 35B-A3B ist 3,5-4x schneller bei der Token-Generierung. Das bedeutet, wenn das 27B 10 Sekunden braucht, um einen Absatz zu schreiben, macht das 35B-A3B dasselbe in 2,5 Sekunden. Das Bild ist ähnlich beim Prefill: 2-2,4x schnellere Prompt-Verarbeitung.
Das Interessante ist, dass das 35B-A3B insgesamt mehr Parameter hat (35B vs 27B), aber trotzdem viel schneller ist, weil es pro Token nur 3B laden und verarbeiten muss aufgrund des MoE-Routings. Das 27B muss alle seine Parameter pro Token verarbeiten.
VRAM und Kontextkapazität#
Hier glänzt das 35B-A3B wirklich:
| 35B-A3B (IQ4_XS) | 35B-A3B (Q4_K_S) | 27B (UD-Q5_K_XL) | |
|---|---|---|---|
| Modellgröße | 17,7 GB | 20,9 GB | 18,65 GB |
| VRAM idle | ~20400 MB | ~22700 MB | ~22900 MB |
| Max Kontext | 262k | 188k | 156k |
| VRAM frei bei Max | ~3600 MB | ~1300 MB | ~1134 MB |
Wichtiger Hinweis: der 262k Kontext des 35B-A3B ist mit IQ4_XS Quantisierung erreichbar. Mit derselben Q4_K_S Quantisierung (die näher an der UD-Q5_K_XL des 27B liegt) ist das Maximum 188k. Das ist immer noch mehr als die 156k des 27B, aber nicht so dramatisch wie 262k.
Der Punkt: die MoE-Architektur des 35B-A3B verbraucht weniger VRAM pro Token, weil sie nur 3B Parameter während des Forward Pass laden muss. Das lässt mehr Platz für den KV Cache.
Die Tests werden nicht nur von der turbo3 KV Cache-Kompression getragen, sondern auch von der Sparse V (attention-gated value dequantization) Technik. Dies ist eine Optimierung, die im Flash-Attention-Kernel Positionen filtert, wo das Attention-Gewicht vernachlässigbar ist (unter 10⁻⁶), und dort keine V (Value) Dequantisierung durchführt. Der Punkt: anstatt jede Position Dequantisierung zu beschleunigen (was an Hardware-Grenzen stößt), überspringen wir einfach die unnötigen Operationen. Bei langem Kontext kann dies bis zu 22,8% Decode-Geschwindigkeitsverbesserung bedeuten, ohne Qualitätsverlust. Und das Beste: diese Technik ist nicht turboquant-spezifisch, sondern funktioniert auf jedem quantisierten KV Cache-Format (q8_0, q4_0, turbo3), weil sie auf der Attention-Verteilung basiert, nicht auf dem Dequant-Mechanismus.
Qualität - wo das 27B gewinnt#
Basierend auf den offiziellen Qwen-Benchmark-Ergebnissen übertrifft das 27B das 35B-A3B auf jedem einzelnen Benchmark:
| Benchmark | 35B-A3B | 27B | Gewinner |
|---|---|---|---|
| SWE-bench Verified | 73.4 | 77.2 | 27B |
| SWE-bench Pro | 49.5 | 53.5 | 27B |
| Terminal-Bench 2.0 | 51.5 | 59.3 | 27B |
| SkillsBench | 28.7 | 48.2 | 27B (+19.5!) |
| MMLU-Pro | 85.2 | 86.2 | 27B |
| GPQA Diamond | 86.0 | 87.8 | 27B |
| AIME 2026 | 92.7 | 94.1 | 27B |
| LiveCodeBench v6 | 80.4 | 83.9 | 27B |
| HLE | 21.4 | 24.0 | 27B |
| QwenWebBench | 1397 | 1487 | 27B |
Der besondere Highlight ist SkillsBench: +19.5 Punkte zugunsten des 27B. Dies ist ein Benchmark, der auf Coding-Agent-Aufgaben spezialisiert ist, und dort ist das 27B unschlagbar. Der Unterschied ist ähnlich groß im Terminal-Bench (+7.8) und SWE-bench (+3-4).
Zusammenfassung - welches soll ich wählen?#
Für das 35B-A3B:
- 🚀 3-4x schneller bei der Generierung
- 📏 Mehr Kontext (188k-262k vs 156k)
- Großartig für RAG, lange Gespräche, hoher Durchsatz
- Qualität: sehr gut, fast auf demselben Niveau wie das 27B
Für das 27B Dense:
- 🏆 Bessere Qualität auf jedem Benchmark
- Besonders besser für Coding-Agent-Aufgaben (SkillsBench: +19.5)
- Langsamer, aber wenn Qualität das Ziel ist, ist die Wartezeit es wert
- Weniger Kontext (156k max)
Mein praktischer Rat:
Wenn du RAG betreibst, lange Kontext-Gespräche führst, oder einfach willst, dass Antworten schnell kommen - 35B-A3B. Wenn du einen Coding-Agenten betreibst, komplexe logische Aufgaben löst, oder Qualität das Wichtigste ist - dann 27B.
Beide Modelle funktionieren wunderbar mit turbo3 KV Cache-Kompression, und beide erreichten 100% bei NIAH. Turbo3 verschlechtert nichts - im Gegenteil, aufgrund der VRAM-Einsparung musste man bei der Kontextlänge überhaupt keinen Kompromiss eingehen.