Qwen 3.6 27B und 35B MTP gegenüber Standard auf 16-GB-GPU

Ich habe die Leistung von spekulativem Decoding (Multi-Token Prediction, MTP) bei Qwen 3.6 27B und 35B auf einer RTX 4080 mit 16 GB VRAM getestet.

Für einen umfassenderen Überblick über Token-Geschwindigkeiten und VRAM-Abwägungen bei weiteren Modellen auf derselben Hardware, siehe 16 GB VRAM LLM Benchmarks mit llama.cpp.

Was MTP (Multi-Token Prediction) ist

Multi-Token Prediction ist eine Form des spekulativen Decodings, die direkt in bestimmte Modell-Checkpoints integriert ist. Anstatt pro Forward-Pass nur ein Token zu vorhersagen, enthält das Modell zusätzliche „MTP-Heads“, die mehrere zukünftige Tokens in einem einzigen Schritt vorschlagen – diese werden anschließend parallel verifiziert. Wenn die Vorhersagen akzeptiert werden, steigt die effektive Durchsatzrate, ohne dass die Ausgabequalität beeinträchtigt wird.

Die Qwen 3.6-Familie wird sowohl als standard GGUF-Dateien als auch als MTP-fähige Varianten ausgeliefert. In llama.cpp wird MTP über folgende Parameter aktiviert:

--spec-type draft-mtp --spec-draft-n-max 3

--spec-draft-n-max ist der entscheidende Einstellungsparameter. Er legt fest, wie viele spekulative Tokens der MTP-Head bei jedem Schritt vorschlägt. Höhere Werte bieten ein potentielles Geschwindigkeitsplus, kosten jedoch zusätzliche VRAM für die Entwurfs-Puffer (draft buffers) – was bei Karten mit 16 GB VRAM eine echte Einschränkung darstellt.

Was und wie ich getestet habe

Ich habe getestet, wie sich die beiden Qwen 3.6-Modelle mit aktiviertem MTP im Vergleich zum Standard-Decoding auf einer GPU mit 16 GB VRAM (RTX 4080) verhalten.

Um die Modellgewichte und den KV-Cache in die VRAM zu passen, habe ich stark quantisierte Varianten verwendet:

• Qwen3.6-27B-UD-IQ3_XXS und Qwen3.6-27B-UD-IQ3_XXS-MTP
• Qwen3.6-35B-A3B-UD-IQ3_S und Qwen3.6-35B-A3B-UD-IQ3_S-MTP

Pro Durchlauf werden zwei Kontext-Budgets verfolgt:

• Avg Ctx — die Kontextgröße, bei der llama.cpp ca. 14,8 GB VRAM belegt, sodass anderen Apps (Xorg, GNOME Shell, Cursor) ein komfortabler Puffer von ca. 500 MB bleibt.
• Max Ctx — der größte Kontext, den llama.cpp zuweisen konnte, unter der Voraussetzung, dass dieselben Desktop-Apps bereits ca. 500 MB VRAM belegen.

Ein wichtiger Grund, den durchschnittlichen Kontext auf ein praktisches Ziel zu begrenzen, ist Hermes Agent, den ich als primären KI-Assistenten verwende, der auf diesem Computer mit llama.cpp verbunden ist. Hermes Agent verlangt standardmäßig mindestens 64 K Kontext und lehnt Modelle mit einem kleineren Fenster beim Start ab. Modelle unterhalb dieser Schwelle können nicht genug Arbeitspeicher für mehrstufige Tool-Calling-Workflows halten. Für llama.cpp bedeutet dies die Übergabe von --ctx-size 65536 oder mehr. Jede MTP-Konfiguration, die den durchschnittlich nutzbaren Kontext deutlich unter 64 K komprimiert, ist daher für tägliche Hermes-Workloads ungeeignet. Deshalb sind die Avg-Ctx-Werte in den nachfolgenden Tabellen die entscheidendsten für die Entscheidungsfindung.

Beide KV-Cache-Quantisierungsebenen wurden getestet: q8 (höhere Qualität, mehr VRAM) und q5 (weniger VRAM, längerer Kontext). Seien Sie sich bewusst, dass der Wechsel vom q8- zum q5-KV-Cache zu einem spürbaren Qualitätsverlust führen kann – in meinen Tests war die Degradation signifikant genug, um q5 für meine Workloads ungeeignet zu machen. Die Geschwindigkeits- und Kontextzahlen für q5 sind zur Vollständigkeit angegeben, Sie sollten jedoch die Antwortqualität bei Ihren eigenen Aufgaben testen, bevor Sie sich dafür entscheiden.

Qwen 3.6 27B MTP vs. Standard

KV Cache q8

Mit q8 KV Cache liefert MTP bei --spec-draft-n-max 2 ~67 % schnellere Generierung (75 vs. 45 t/s) auf Kosten der Halbierung des durchschnittlichen Kontextfensters von 80 K auf 40 K. Die Prompt-Ingestions-Geschwindigkeit sinkt von 200 auf ca. 150 t/s, da MTP während der Prefill-Phase Device-to-Host-Transfers erfordert.

KV Cache q5

Der Wechsel zum q5 KV Cache stellt einen sinnvollen Kontext wieder her: --spec-draft-n-max 1 ergibt 70 K durchschnittlichen Kontext bei 57 t/s – eine 39 %ige Beschleunigung der Generierung im Vergleich zum Standard-Decoding, während das Kontextfenster auf einer nützlichen Größe bleibt. Bei --spec-draft-n-max 3 sinkt der Kontext auf 60 K, aber die Generierung erreicht 67 t/s (+63 %).

Fazit zu Qwen 3.6 27B

MTP ist für das 27B dichte Modell tatsächlich nützlich. Der optimale Punkt bei 16 GB VRAM ist:

• q8 KV + --spec-draft-n-max 2 — beste Rohgeschwindigkeit (75 t/s), Kontext reduziert auf 40–60 K
• q5 KV + --spec-draft-n-max 1 — bestes Geschwindigkeits-Kontext-Verhältnis (57 t/s, 70 K durchschnittlicher Kontext)

Qwen 3.6 35B MTP vs. Standard

Das 35B-Modell ist eine Mixture-of-Experts (MoE)-Architektur (35B-A3B bedeutet 35B Gesamtparameter, ca. 3B aktiv pro Token). MoE-Modelle profitieren normalerweise stärker von MTP, da das sparsity-Routing den MTP-Head im Verhältnis zu einem vollständigen Forward-Pass rechnerisch günstig hält.

KV Cache q8

Die MoE-Architecture liefert beeindruckende Roh-Generationsgeschwindigkeit mit MTP (+27 % bei max 1, +29 % bei max 2 im Vergleich zum Standard von 146 t/s). Das praktische Problem ist jedoch der durchschnittliche Kontext. Mit q8 KV Cache ergibt selbst --spec-draft-n-max 1 nur 15 K durchschnittlichen Kontext – kaum genug für moderate Aufgaben. Höhere Entwurfs-Tiefen bieten auf einer 16-GB-Karte überhaupt keinen praktikablen durchschnittlichen Kontext.

Dies ist die zentrale VRAM-Kostenfrage für MTP auf Consumer-Hardware: Die zusätzlichen Entwurfs-Puffer fressen direkt in das verbleibende VRAM-Budget, und das 35B-A3B-Modell mit q8 KV Cache lässt sehr wenig Spielraum.

KV Cache q5

Der q5 KV Cache verbessert die Geschichte des durchschnittlichen Kontexts nur marginal. --spec-draft-n-max 1 ergibt 10 K durchschnittlichen Kontext bei 151 t/s. Standard-Decoding bei q5 ergibt 122 t/s mit 120 K durchschnittlichem Kontext.

Fazit zu Qwen 3.6 35B

Auf einer 16-GB-GPU stößt das 35B MoE-Modell mit MTP an eine harte Grenze: Der durchschnittlich nutzbare Kontext kollabiert auf 10–15 K Tokens, was es für echte Workloads unpraktikabel macht. Standard-Decoding bei 122–146 t/s mit 80–120 K Kontext ist deutlich nützlicher.

Wenn Sie 24 GB+ VRAM haben, wird die Kombination aus 35B + MTP viel attraktiver – das Problem des Kontextfensters verschwindet und Sie behalten den Geschwindigkeitsvorteil.

Die richtige --spec-draft-n-max-Wert wählen

Die Frage, wie viele spekulative Tokens pro Schritt vorgeschlagen werden sollen (--spec-draft-n-max), hat keine einzelne richtige Antwort – sie hängt sowohl von der Modellarchitektur als auch vom verfügbaren VRAM ab:

• Für 27B dense auf 16 GB: --spec-draft-n-max 2 mit q8 KV ist das schnellste, --spec-draft-n-max 1 mit q5 KV ist kontextfreundlichsten.
• Für 35B MoE auf 16 GB: --spec-draft-n-max 1 ist die einzige Option, die überhaupt einen nutzbaren Kontext beibehält, und selbst das nur marginal.
• Höhere Werte (3, 4) erhöhen den VRAM-Druck ohne proportionale Geschwindigkeitsgewinne – bei max 4 verbrauchen Sie grob denselben zusätzlichen VRAM wie bei max 2, aber die Generationsgeschwindigkeit hält nicht Schritt.

So aktivieren Sie MTP in llama.cpp

Stellen Sie sicher, dass Sie ein MTP-fähiges GGUF verwenden (der Dateiname enthält MTP). Wenn Sie neu bei llama.cpp-Flags sind, deckt der llama.cpp Schnellstart mit CLI und Server alle Grundlagen ab. Starten Sie dann llama-server oder llama-cli mit:

llama-server \
  --model Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf \
  --ctx-size 40000 \
  -ngl 99 --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

Für q5 KV Cache ersetzen Sie q8_0 durch q5_1 oder q5_0 und passen Sie --ctx-size nach oben an:

llama-server \
  --model Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf \
  --ctx-size 80000 \
  -ngl 99 --flash-attn on \
  --cache-type-k q5_1 --cache-type-v q5_1 \
  --spec-type draft-mtp \
  --spec-draft-n-max 1

MTP wird automatisch aktiviert, sobald llama.cpp die MTP-Heads in der GGUF-Datei erkennt und --spec-type draft-mtp gesetzt ist. Das standardmäßige Qwen3.6-27B-UD-IQ3_XXS.gguf funktioniert also nicht im MTP-Modus, Sie benötigen Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf. Aber das Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf kann sowohl im spekulativen Decoding-Modus als auch im autoregressiven Modus arbeiten.

Fazit

Auf einer 16-GB-GPU (RTX 4080) ist llama.cpps MTP mit diesen Quants ein klarer Gewinn für Qwen 3.6 27B und ein Netto-Nachteil für Qwen 3.6 35B in der praktischen Anwendung:

Qwen 3.6 27B (IQ3_XXS) — MTP ist lohnenswert:

• q8 KV + MTP max 2 → ~67 % schnellere Generierung, Kontext 40–60 K (vs. 80–100 K ohne MTP)
• q5 KV + MTP max 1 → ~39 % schnellere Generierung, Kontext 70–100 K (vs. 130–160 K ohne MTP)
• Gutes Gleichgewicht aus Geschwindigkeit und VRAM-Effizienz bei --spec-draft-n-max 2

Qwen 3.6 35B (IQ3_S) — MTP ist bei 16 GB nicht praktikabel:

• Die Generationsgeschwindigkeit ist 27–29 % höher, aber der durchschnittliche Kontext kollabiert auf 10–15 K bei q8, 10 K bei q5
• Standard-Decoding bei 122–146 t/s mit 80–120 K Kontext ist für echte Aufgaben nützlicher
• Die Situation verbessert sich bei 24 GB+ VRAM erheblich

Auf dem Papier ist der q5 KV Cache die offensichtliche Antwort, um das Kontextfenster zu maximieren und gleichzeitig die MTP-Geschwindigkeitsgewinne zu behalten – in der Praxis kann der Qualitätsverlust beim Wechsel von q8 zu q5 jedoch signifikant sein. Testen Sie q5 bei Ihren eigenen Aufgaben, bevor Sie es übernehmen; für meine Workloads war die Degradation inakzeptabel, und q8 mit einem engeren Kontext-Budget bleibt der bessere Kompromiss.

Für das größere Bild der LLM-Serving-Optionen und Infrastruktur-Abwägungen, siehe die LLM Hosting in 2026 Säule und LLM Performance in 2026. Wenn Sie Qwen 3.6 Sampler-Einstellungen neben MTP optimieren, ist das Referenzwerk für Agentic LLM Inference-Parameter für Qwen 3.6 und Gemma 4 ein nützlicher Begleiter.