Qwen 3.6 27B i 35B MTP w porównaniu do standardowych modeli na GPU z 16 GB

Przetestowałem wydajność spekulacyjnego dekodowania (Wieloznakowego Przewidywania, MTP) w modelach Qwen 3.6 27B i 35B na karcie RTX 4080 z 16 GB pamięci VRAM.

Aby uzyskać szerszy przegląd szybkości przetwarzania tokenów i kompromisów związanych z wykorzystaniem pamięci VRAM w przypadku większej liczby modeli na tym samym sprzęcie, zobacz 16 GB VRAM LLM benchmarks with llama.cpp.

Czym jest MTP (Wieloznakowe Przewidywanie)

Wieloznakowe Przewidywanie to forma spekulacyjnego dekodowania wbudowana bezpośrednio w określone punkty kontrolne modeli. Zamiast przewidywać jeden token w jednym przelocie forward, model posiada dodatkowe „głowy MTP”, które proponują kilka przyszłych tokenów w jednym kroku, a następnie weryfikują je równolegle. Jeśli zgadywane tokeny zostaną zaakceptowane, efektywna przepustowość rośnie bez zmiany jakości wyjścia.

Rodzina Qwen 3.6 dystrybuowana jest zarówno jako pliki GGUF w standardowej wersji, jak i w wariantach obsługujących MTP. W llama.cpp funkcja MTP jest aktywowana za pomocą:

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

Parametr --spec-draft-n-max jest kluczowym elementem dostrajania. Określa on, ile spekulacyjnych tokenów głowa MTP proponuje w każdym kroku. Wyższe wartości dają potencjalny wzrost szybkości, ale wymagają dodatkowej pamięci VRAM dla buforów szkiców — co stanowi realne ograniczenie w przypadku kart z 16 GB pamięci.

Co i jak testowałem

Przetestowałem, jak dwa modele Qwen 3.6 zachowują się z włączonym MTP w porównaniu do standardowego dekodowania na GPU z 16 GB pamięci VRAM (RTX 4080).

Aby zmieścić wagi modelu i pamięć podręczną KV w pamięci VRAM, użyłem mocno skwantyzowanych wariantów:

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

W każdej sesji testowano dwa budżety kontekstu:

• Średni Ctx — rozmiar kontekstu, przy którym llama.cpp zajmuje ok. 14,8 GB pamięci VRAM, pozostawiając innym aplikacjom (Xorg, GNOME Shell, Cursor) komfortowy margines ok. 500 MB.
• Maksymalny Ctx — największy kontekst, który llama.cpp mógł przydzielić, biorąc pod uwagę, że te same aplikacje pulpitu zajmują już ok. 500 MB pamięci VRAM.

Kluczowym powodem utrzymywania średniego kontekstu na praktycznym poziomie jest fakt, że Hermes Agent — którego używam jako głównego asystenta AI połączonego z llama.cpp na tym komputerze — wymaga domyślnie co najmniej 64 K kontekstu i odrzuci modele o mniejszym oknie przy starcie. Modele poniżej tego progu nie mogą utrzymać wystarczającej pamięci roboczej dla wieloetapowych przepływów pracy z wywoływaniem narzędzi. Dla llama.cpp oznacza to przekazanie parametru --ctx-size 65536 lub większego. Każda konfiguracja MTP, która zmniejsza średni użyteczny kontekst znacząco poniżej 64 K, jest zatem nieodpowiednia do codziennych zadań Hermes, dlatego liczby Średniego Ctx w tabelach poniżej są najbardziej istotne dla podejmowania decyzji.

Przetestowano oba poziomy kwantyzacji pamięci podręcznej KV: q8 (wyższa jakość, więcej VRAM) oraz q5 (mniejsza pamięci VRAM, dłuższy kontekst). Należy pamiętać, że przejście z pamięci KV q8 do q5 może powodować zauważalny spadek jakości — w moich testach degradacja była na tyle znacząca, że q5 nadawały się do moich obciążeń. Dane dotyczące szybkości i kontekstu dla q5 zostały dołączone dla kompletności, ale powinieneś przetestować jakość odpowiedzi w swoich własnych zadaniach przed ich pełnym wdrożeniem.

Qwen 3.6 27B MTP vs Standard

Pamięć podręczna KV q8

Z pamięcią podręczną KV q8, MTP przy --spec-draft-n-max 2 zapewnia ~67 % szybsze generowanie (75 vs 45 t/s) kosztem połowicznego zmniejszenia średniego okna kontekstu z 80 K do 40 K. Szybkość przetwarzania promptu spada z 200 do ~150 t/s, ponieważ MTP wymaga transferów urządzenie-host podczas fazy prefill.

Pamięć podręczna KV q5

Przejście do pamięci podręcznej KV q5 odzyskuje znaczący kontekst: --spec-draft-n-max 1 daje 70 K średniego kontekstu przy 57 t/s — co stanowi 39 % wzrost szybkości generowania w porównaniu do standardowego dekodowania, jednocześnie utrzymując okno kontekstu na użytecznym poziomie. Przy --spec-draft-n-max 3 kontekst spada do 60 K, ale generowanie osiąga 67 t/s (+63 %).

Podsumowanie dla Qwen 3.6 27B

MTP jest naprawdę przydatny dla gęstego modelu 27B. Optymalne punkty na 16 GB VRAM to:

• KV q8 + --spec-draft-n-max 2 — najlepsza surowa szybkość (75 t/s), kontekst spada do 40–60 K
• KV q5 + --spec-draft-n-max 1 — najlepszy balans szybkości i kontekstu (57 t/s, 70 K średniego kontekstu)

Qwen 3.6 35B MTP vs Standard

Model 35B to architektura Mixture-of-Experts (MoE) (35B-A3B oznacza 35B całkowitych parametrów, ~3B aktywnych na token). Modele MoE zazwyczaj korzystają bardziej z MTP, ponieważ rozproszone routowanie utrzymuje głowę MTP w niskich kosztach obliczeniowych względem pełnego przelotu forward.

Pamięć podręczna KV q8

Architektura MoE dostarcza imponującą surową szybkość generowania z MTP (+27 % przy max 1, +29 % przy max 2 w porównaniu do standardowych 146 t/s). Jednak praktycznym problemem jest średni kontekst. Z pamięcią podręczną KV q8, nawet --spec-draft-n-max 1 daje tylko 15 K średniego kontekstu — ledwo wystarczającego do umiarkowanych zadań. Wyższe głębokości szkiców nie mają w ogóle użytecznego średniego kontekstu na karcie 16 GB.

To jest główne pytanie dotyczące kosztu VRAM dla MTP na sprzęcie konsumenckim: dodatkowe bufory szkiców bezpośrednio zjadają pozostały budżet VRAM, a model 35B-A3B z pamięcią KV q8 pozostawia bardzo mało miejsca manewru.

Pamięć podręczna KV q5

Pamięć podręczna KV q5 poprawia historię średniego kontekstu jedynie marginalnie. --spec-draft-n-max 1 daje 10 K średniego kontekstu przy 151 t/s. Standardowe dekodowanie przy q5 daje 122 t/s przy 120 K średniego kontekstu.

Podsumowanie dla Qwen 3.6 35B

Na GPU 16 GB model MoE 35B z MTP napotyka twardą barierę: średni użyteczny kontekst zawala się do 10–15 K tokenów, co czyni go niepraktycznym do realnych obciążeń. Standardowe dekodowanie przy 122–146 t/s z kontekstem 80–120 K jest znacznie bardziej użyteczne.

Jeśli dysponujesz 24 GB+ pamięci VRAM, kombinacja 35B + MTP staje się znacznie bardziej atrakcyjna — problem okna kontekstu znika, a zyskujesz korzyści ze szybkości.

Wybór odpowiedniej wartości --spec-draft-n-max

Pytanie, ile spekulacyjnych tokenów proponować w każdym kroku (--spec-draft-n-max), nie ma jednej prawidłowej odpowiedzi — zależy ono zarówno od architektury modelu, jak i dostępnej pamięci VRAM:

• Dla 27B dense na 16 GB: --spec-draft-n-max 2 z KV q8 jest najszybszy, --spec-draft-n-max 1 z KV q5 jest najbardziej przyjazny dla kontekstu.
• Dla 35B MoE na 16 GB: --spec-draft-n-max 1 to jedyna opcja, która utrzymuje jakikolwiek użyteczny kontekst, i to tylko marginalnie.
• Wyższe wartości (3, 4) zwiększają presję na VRAM bez proporcjonalnych zysków szybkości — przy max 4 wydajesz mniej więcej tyle samo dodatkowej pamięci VRAM co przy max 2, ale szybkość generowania nie nadąża.

Jak włączyć MTP w llama.cpp

Upewnij się, że używasz pliku GGUF z włączonym MTP (nazwa pliku zawiera MTP). Jeśli jesteś nowy w flagach llama.cpp, llama.cpp Quickstart with CLI and Server obejmuje wszystkie podstawy. Następnie uruchom llama-server lub llama-cli z:

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

Dla pamięci podręcznej KV q5, zamień q8_0 na q5_1 lub q5_0 i zwiększ wartość --ctx-size:

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 jest aktywowany automatycznie, gdy llama.cpp wykryje głowy MTP w pliku GGUF i ustawiony jest parametr --spec-type draft-mtp. Zwykły plik Qwen3.6-27B-UD-IQ3_XXS.gguf nie będzie działał w trybie MTP, konieczny będzie plik Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf. Jednak plik Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf może działać zarówno w trybie spekulacyjnego dekodowania, jak i autoregresywnym.

Podsumowanie

Na GPU 16 GB (RTX 4080), z tymi kwantyzacjami, MTP w llama.cpp jest wyraźnym sukcesem dla Qwen 3.6 27B i netto negatywnym dla Qwen 3.6 35B w praktycznym użyciu:

Qwen 3.6 27B (IQ3_XXS) — MTP opłaca się:

• KV q8 + MTP max 2 → ~67 % szybsze generowanie, kontekst 40–60 K (vs 80–100 K bez MTP)
• KV q5 + MTP max 1 → ~39 % szybsze generowanie, kontekst 70–100 K (vs 130–160 K bez MTP)
• Dobry balans szybkości i wydajności VRAM przy --spec-draft-n-max 2

Qwen 3.6 35B (IQ3_S) — MTP nie jest praktyczny przy 16 GB:

• Szybkość generowania jest o 27–29 % wyższa, ale średni kontekst zawala się do 10–15 K przy q8, 10 K przy q5
• Standardowe dekodowanie przy 122–146 t/s z kontekstem 80–120 K jest bardziej użyteczne do realnych zadań
• Sytuacja poprawia się znacząco przy 24 GB+ pamięci VRAM

Na papierze pamięć podręczna KV q5 jest oczywistą odpowiedzią na maksymalizację okna kontekstu przy jednoczesnym zachowaniu zysków szybkości MTP — ale w praktyce spadek jakości przy przejściu z q8 do q5 może być znaczący. Przetestuj q5 na własnych zadaniach przed jego wdrożeniem; w moich obciążeniach degradacja była nieakceptowalna, a q8 z mniejszym budżetem kontekstu pozostaje lepszym kompromisem.

Aby uzyskać szerszy obraz opcji hostingu LLM i kompromisów infrastrukturalnych, zobacz filar LLM Hosting in 2026 oraz LLM Performance in 2026. Jeśli dostrajasz ustawienia samplera Qwen 3.6 wraz z MTP, Agentic LLM Inference Parameters Reference for Qwen 3.6 and Gemma 4 jest przydatnym uzupełnieniem.