Qwen 3.6 27B och 35B MTP jämfört med Standard på 16 GB GPU

Jag testade prestandan för spekulativ dekodning (Multi-Token Prediction, MTP) i Qwen 3.6 27B och 35B på en RTX 4080 med 16 GB VRAM.

För en bredare överblick över toknhastigheter och VRAM-kompromisser över flera modeller på samma hårdvara, se 16 GB VRAM LLM-benchmarks med llama.cpp.

Vad MTP (Multi-Token Prediction) är

Multi-Token Prediction är en form av spekulativ dekodning som är inbyggd direkt i vissa modellcheckpoints. Istället för att förutsäga en token per framåtriktning (forward pass), bär modellen extra “MTP-huvuden” som föreslår flera framtida token på ett enda steg — och verifierar dem sedan parallellt. Om gissningarna accepteras ökar den effektiva genomströmningen utan att ändra utmatningskvaliteten.

Qwen 3.6-familjen levereras med både standard GGUF-filer och MTP-aktiverade varianter. I llama.cpp aktiveras MTP genom:

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

--spec-draft-n-max är den viktigaste inställningsparametern. Den bestämmer hur många spekulativa token MTP-huvudet föreslår vid varje steg. Högre värden ger en potentiell hastighetsökning men kostar extra VRAM för draft-buffrarna — en verklig begränsning på kort med 16 GB.

Vad och hur jag testade

Jag testade hur de två Qwen 3.6-modellerna beter sig med MTP aktiverat jämfört med standard dekodning på en GPU med 16 GB VRAM (RTX 4080).

För att få plats med modellvikt och KV-cache i VRAM använde jag kraftigt kvantiserade varianter:

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

Två kontextbudgetar spåras per körning:

• Avg Ctx — kontextstorleken vid vilken llama.cpp upptar ~14,8 GB VRAM, vilket lämnar andra appar (Xorg, GNOME Shell, Cursor) en bekväm buffert på ~500 MB.
• Max Ctx — den största kontext som llama.cpp kunde allokera givet att samma skrivbordsappar redan håller ~500 MB VRAM.

En viktig anledning till att hålla den genomsnittliga kontexten vid ett praktiskt mål är att Hermes Agent — som jag använder som primär AI-assistent som ansluter till llama.cpp på denna maskin — kräver minst 64 K kontext som standard och kommer att avvisa modeller med ett mindre fönster vid start. Modeller under denna tröskel kan inte upprätthålla tillräckligt med arbetsminne för flerstegs verktygsanrop (tool-calling). För llama.cpp innebär detta att skicka --ctx-size 65536 eller större. All MTP-konfiguration som komprimerar den genomsnittligt användbara kontexten betydligt under 64 K är därför olämplig för dagliga Hermes-arbetsbelastningar, vilket är varför Avg Ctx-nummren i tabellerna nedan är de mest beslutsrelevanta.

Båda KV-cache-kvantiseringsnivåerna testades: q8 (högre kvalitet, mer VRAM) och q5 (lägre VRAM, längre kontext). Var medveten om att övergången från q8 till q5 KV-cache kan orsaka en märkbar kvalitetsförsämring — i mina tester var försämringen tillräckligt stor för att göra q5 olämplig för mina arbetsbelastningar. Hastighets- och kontextnummren för q5 inkluderas för fullständighetens skull, men du bör testa svarskvaliteten på dina egna uppgifter innan du binder dig till det.

Qwen 3.6 27B MTP vs Standard

KV Cache q8

Med q8 KV-cache levererar MTP vid --spec-draft-n-max 2 ~67 % snabbare generering (75 vs 45 t/s) till priset av att halvera det genomsnittliga kontextfönstret från 80 K till 40 K. Promptingst hastigheten minskar från 200 till ~150 t/s eftersom MTP kräver överföringar från enhet till värd (device-to-host) under prefill-fasen.

KV Cache q5

Att byta till q5 KV-cache återställer meningsfull kontext: --spec-draft-n-max 1 ger 70 K genomsnittlig kontext vid 57 t/s — en 39 % ökning av genereringshastigheten jämfört med standard dekodning, samtidigt som man behåller kontextfönstret på en användbar storlek. Vid --spec-draft-n-max 3 minskar kontexten till 60 K men genereringen når 67 t/s (+63 %).

Sammanfattning Qwen 3.6 27B

MTP är genuint användbart för den täta 27B-modellen. Det optimala alternativet på 16 GB VRAM är:

• q8 KV + --spec-draft-n-max 2 — bäst råhastighet (75 t/s), kontext ner till 40–60 K
• q5 KV + --spec-draft-n-max 1 — bäst balans mellan hastighet och kontext (57 t/s, 70 K genomsnittlig kontext)

Qwen 3.6 35B MTP vs Standard

35B-modellen är en Mixture-of-Experts (MoE)-arkitektur (35B-A3B betyder 35B totala parametrar, ~3B aktiva per token). MoE-modeller gynnas oftast mer av MTP eftersom den sparsa routningen håller MTP-huvudet beräkningsmässigt billigt i förhållande till en fullständig framåtriktning.

KV Cache q8

MoE-arkitekturen levererar imponerande rå genereringshastighet med MTP (+27 % vid max 1, +29 % vid max 2 jämfört med standard 146 t/s). Men det praktiska problemet är den genomsnittliga kontexten. Med q8 KV-cache ger även --spec-draft-n-max 1 endast 15 K genomsnittlig kontext — knappt tillräckligt för måttliga uppgifter. Högre draft-djup har ingen användbar genomsnittlig kontext alls på ett 16 GB-kort.

Detta är den centrala VRAM-kostfrågan för MTP på konsumenthårdvara: de extra draft-buffrarna äter direkt på den återstående VRAM-budgeten, och 35B-A3B-modellen med q8 KV-cache lämnar mycket lite utrymme.

KV Cache q5

q5 KV-cache förbättrar bara marginellt historien om genomsnittlig kontext. --spec-draft-n-max 1 ger 10 K genomsnittlig kontext vid 151 t/s. Standard dekodning vid q5 ger 122 t/s med 120 K genomsnittlig kontext.

Sammanfattning Qwen 3.6 35B

På en 16 GB GPU möter 35B MoE-modellen med MTP en hård vägg: den genomsnittligt användbara kontexten kollapsar till 10–15 K token, vilket gör den opraktisk för verkliga arbetsbelastningar. Standard dekodning vid 122–146 t/s med 80–120 K kontext är betydligt mer användbar.

Om du har 24 GB+ VRAM blir kombinationen 35B + MTP mycket mer attraktiv — problemet med kontextfönstret försvinner och du behåller hastighetsfördelen.

Att välja rätt --spec-draft-n-max-värde

Frågan om hur många spekulativa token som ska föreslås per steg (--spec-draft-n-max) har inte ett enda rätt svar — det beror på både modellarkitektur och tillgänglig VRAM:

• För 27B dense på 16 GB: --spec-draft-n-max 2 med q8 KV är snabbast, --spec-draft-n-max 1 med q5 KV är mest kontextvänligt.
• För 35B MoE på 16 GB: --spec-draft-n-max 1 är det enda alternativet som behåller någon användbar kontext, och även då endast marginellt.
• Högre värden (3, 4) ökar VRAM-belastningen utan proportionella hastighetsvinster — vid max 4 spenderar du ungefär samma extra VRAM som vid max 2, men genereringshastigheten hinner inte ikapp.

Hur man aktiverar MTP i llama.cpp

Se till att du använder en MTP-aktiverad GGUF (filnamnet innehåller MTP). Om du är ny till llama.cpp-flaggor, täcker llama.cpp Quickstart med CLI och Server alla grunderna. Starta sedan llama-server eller llama-cli med:

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, ersätt q8_0 med q5_1 eller q5_0 och justera --ctx-size uppåt:

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 aktiveras automatiskt när llama.cpp ser MTP-huvudena i GGUF-filen och --spec-type draft-mtp är inställt. Så standard Qwen3.6-27B-UD-IQ3_XXS.gguf fungerar inte i MTP-läge, du behöver Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf. Men Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf kan fungera i både Spekulativ dekodning-läge och autoregressivt läge.

Slutsats

På en 16 GB GPU (RTX 4080), med dessa kvantiseringsnivåer, är llama.cpp:s MTP en tydlig vinst för Qwen 3.6 27B och en nettoförlust för Qwen 3.6 35B i praktisk användning:

Qwen 3.6 27B (IQ3_XXS) — MTP är värt det:

• q8 KV + MTP max 2 → ~67 % snabbare generering, kontext 40–60 K (jämfört med 80–100 K utan MTP)
• q5 KV + MTP max 1 → ~39 % snabbare generering, kontext 70–100 K (jämfört med 130–160 K utan MTP)
• Bra balans mellan hastighet och VRAM-effektivitet vid --spec-draft-n-max 2

Qwen 3.6 35B (IQ3_S) — MTP är inte praktiskt på 16 GB:

• Genereringshastigheten är 27–29 % högre men den genomsnittliga kontexten kollapsar till 10–15 K vid q8, 10 K vid q5
• Standard dekodning vid 122–146 t/s med 80–120 K kontext är mer användbar för verkliga uppgifter
• Situationen förbättras avsevärt på 24 GB+ VRAM

På papperet är q5 KV-cache det uppenbara svaret för att maximera kontextfönstret samtidigt som man behåller MTP:s hastighetsvinster — men i praktiken kan kvalitetsförsämringen från q8 till q5 vara betydande. Testa q5 på dina egna uppgifter innan du antar det; för mina arbetsbelastningar var försämringen oacceptabel, och q8 med en tightare kontextbudget förblir det bättre alternativet.

För den bredare bilden av LLM-serveringsalternativ och infrastrukturmässig avvägning, se LLM Hosting in 2026-pelaren och LLM Performance in 2026. Om du justerar Qwen 3.6:s sampler-inställningar parallellt med MTP, är Agentic LLM Inference Parameters Reference for Qwen 3.6 and Gemma 4 en användbar följeslagare.