16GB GPUにおけるQwen 3.6 27Bおよび35B MTPと標準モデルの比較
RTX 4080におけるMTPと標準デコーディングの比較 — 実ベンチマーク
RTX 4080（16 GB VRAM）環境で、Qwen 3.6 27Bおよび35Bにおける推論デコーディング（マルチトークン予測、MTP）のパフォーマンスをテストしました。
同じハードウェア上のより多くのモデルにおけるトークン速度とVRAMのトレードオフをより広範に比較するには、16 GB VRAM LLMベンチマーク（llama.cpp）をご覧ください。
MTP（マルチトークン予測）とは
マルチトークン予測（Multi-Token Prediction）は、特定のモデルチェックポイントに直接組み込まれた推論デコーディングの一種です。モデルはフォワードパスごとに1つのトークンを予測するのではなく、複数の将来のトークンを1ステップで提案する追加の「MTPヘッド」を備えています。その後、それらを並行して検証します。推測が受け入れられれば、出力品質を変更せずに実効スループットが向上します。
Qwen 3.6 ファミリーは、標準GGUFファイルとMTP対応バリエーションの両方を提供しています。llama.cppでは、MTPは以下のコマンドで有効化されます。
--spec-type draft-mtp --spec-draft-n-max 3
--spec-draft-n-maxが重要なチューニングパラメータです。これは、各ステップでMTPヘッドが何個の推論トークンを提案するかを設定します。値を高くすると速度向上の可能性がありますが、ドラフトバッファのための追加のVRAMコストがかかります。16 GBクラスのGPUでは現実的な制約となります。
テスト対象と方法
16 GB VRAM（RTX 4080）のGPU上で、2つのQwen 3.6モデルがMTP有効時と標準デコーディング時どのように動作するかをテストしました。
モデル重みとKVキャッシュをVRAMに収めるために、高度に量子化されたバリエーションを使用しました。
Qwen3.6-27B-UD-IQ3_XXSとQwen3.6-27B-UD-IQ3_XXS-MTPQwen3.6-35B-A3B-UD-IQ3_SとQwen3.6-35B-A3B-UD-IQ3_S-MTP
各実行で追跡される2つのコンテキスト予算は以下の通りです。
- Avg Ctx（平均コンテキスト） — llama.cppが約14.8 GBのVRAMを占有し、他のアプリケーション（Xorg、GNOME Shell、Cursorなど）に快適な約500 MBのバッファを残すことのできるコンテキストサイズ。
- Max Ctx（最大コンテキスト） — 同じデスクトップアプリがすでに約500 MBのVRAMを占有していることを前提として、llama.cppが割り当てられる最大のコンテキスト。
平均コンテキストを実用的な目標値に抑える主な理由は、このマシン上のllama.cppに接続する主要なAIアシスタントとして使用しているHermes Agent がデフォルトで少なくとも64 Kのコンテキストを必要とし、起動時にそれより小さなウィンドウを持つモデルを拒否するためです。その閾値以下のモデルでは、マルチステップのツール呼び出しワークフローに必要な作業メモリを維持できません。llama.cppの場合、これは --ctx-size 65536 またはそれ以上を渡すことを意味します。したがって、平均使用可能コンテキストを64 K以下に大幅に圧縮するMTP設定は、日々のHermesワークロードには適さないため、以下の表におけるAvg Ctxの数値が最も意思決定に関連するものとなります。
KVキャッシュの量子化レベルはq8（高品質、VRAM使用量多め）とq5（VRAM使用量少め、コンテキスト長め）の両方をテストしました。q8からq5のKVキャッシュへ移行すると、品質に目立つ低下が生じる可能性があることに注意してください。私のテストでは、q5では品質の劣化が顕著であり、私のワークロードには不適合でした。q5の速度とコンテキストの数値は完全性を保つために記載していますが、採用する前に各自のタスクでレスポンス品質をテストしてください。
Qwen 3.6 27B MTP vs 標準
KV Cache q8
| MTP max 1 | MTP max 2 | MTP max 3 | MTP max 4 | 標準 (IQ3_XXS) | |
|---|---|---|---|---|---|
| プロンプト速度 | 148 t/s | 151 t/s | 148 t/s | 147 t/s | 200 t/s |
| 生成速度 | 65 t/s | 75 t/s | 73 t/s | 75 t/s | 45 t/s |
| Avg Ctx | 40 K | 40 K | 40 K | 30 K | 80 K |
| Max Ctx | 60 K | 60 K | 60 K | 50 K | 100 K |
q8 KVキャッシュでは、--spec-draft-n-max 2 のMTPは、平均コンテキストウィンドウを80 Kから40 Kに半減させるコストで、~67 %高速な生成（75対45 t/s）を実現します。プリフィルフェーズ中にデバイスからホストへの転送が必要になるため、プロンプトの取り込み速度は200 t/sから~150 t/sに低下します。
KV Cache q5
| MTP max 1 | MTP max 2 | MTP max 3 | MTP max 4 | 標準 (IQ3_XXS) | |
|---|---|---|---|---|---|
| プロンプト速度 | 145 t/s | 144 t/s | 141 t/s | 139 t/s | 191 t/s |
| 生成速度 | 57 t/s | 62 t/s | 67 t/s | 66 t/s | 41 t/s |
| Avg Ctx | 70 K | 60 K | 60 K | 50 K | 130 K |
| Max Ctx | 100 K | 100 K | 90 K | 80 K | 160 K |
q5 KVキャッシュに切り替えると、意味のあるコンテキストが回復します。--spec-draft-n-max 1 では、57 t/sで70 Kの平均コンテキストを得られ、標準デコーディングに対して39 %の生成速度向上を達成しつつ、まだ実用的なサイズのコンテキストウィンドウを維持します。--spec-draft-n-max 3 ではコンテキストが60 Kに低下しますが、生成速度は67 t/sに達します（+63 %）。
Qwen 3.6 27B まとめ
MTPは27Bデンスモデルにとって真に有用です。16 GB VRAMでのスイートスポットは以下の通りです。
- q8 KV +
--spec-draft-n-max 2— 最速の生速度（75 t/s）、コンテキストは40–60 Kに低下 - q5 KV +
--spec-draft-n-max 1— 速度とコンテキストのバランスが最適（57 t/s、70 Kの平均コンテキスト）
Qwen 3.6 35B MTP vs 標準
35Bモデルは混合専門家（Mixture-of-Experts, MoE）アーキテクチャ（35B-A3B は合計35Bパラメータ、1トークンあたり約3Bアクティブ）です。MoEモデルは通常、スパースルーティングがMTPヘッドをフルフォワードパスと比較して計算コストが低く保つため、MTPにより大きな利益を得ます。
KV Cache q8
| MTP max 1 | MTP max 2 | MTP max 3 | MTP max 4 | 標準 (IQ3_S) | |
|---|---|---|---|---|---|
| プロンプト速度 | 277 t/s | 277 t/s | 265 t/s | 275 t/s | 368 t/s |
| 生成速度 | 186 t/s | 189 t/s | 180 t/s | 171 t/s | 146 t/s |
| Avg Ctx | 15 K | 10 K | — | — | 80 K |
| Max Ctx | 80 K | 70 K | 60 K | 50 K | 150 K |
MoEアーキテクチャは、MTPにより印象的な生生成速度を実現します（max 1で+27 %、max 2で+29 %、標準の146 t/s比）。しかし、実用的な問題は平均コンテキストにあります。q8 KVキャッシュでは、--spec-draft-n-max 1 でも平均コンテキストはわずか15 Kで、 modest なタスクにはかろうじて十分です。より深いドラフト深度では、16 GBカード上では実用的な平均コンテキストは全くありません。
これがコンシューマハードウェアにおけるMTPのVRAMコストに関する核心的な問題です。追加のドラフトバッファは残りのVRAM予算を直接消費し、q8 KVキャッシュを持つ35B-A3Bモデルでは余裕が非常に少ないためです。
KV Cache q5
| MTP max 1 | MTP max 2 | MTP max 3 | MTP max 4 | 標準 (IQ3_S) | |
|---|---|---|---|---|---|
| プロンプト速度 | 264 t/s | 266 t/s | 270 t/s | 264 t/s | 343 t/s |
| 生成速度 | 151 t/s | 147 t/s | 137 t/s | 131 t/s | 122 t/s |
| Avg Ctx | 10 K | — | — | — | 120 K |
| Max Ctx | 120 K | 110 K | 110 K | 80 K | 200 K |
q5 KVキャッシュは平均コンテキストの状況をわずかに改善するだけです。--spec-draft-n-max 1 では、151 t/sで10 Kの平均コンテキストを得られます。q5での標準デコーディングは、122 t/sで120 Kの平均コンテキストを提供します。
Qwen 3.6 35B まとめ
16 GB GPU上では、35B MoEモデルのMTPは硬い壁にぶつかります。平均使用可能コンテキストが10–15 Kトークンに崩壊し、実際のワークロードには実用的ではありません。80–120 Kのコンテキストを持つ122–146 t/sの標準デコーディングの方が実用的です。
24 GB以上のVRAMをお持ちの場合、35B + MTPの組み合わせははるかに魅力的になります。コンテキストウィンドウの問題は解消され、速度のメリットを保つことができます。
適切な --spec-draft-n-max 値の選択
1ステップあたり何個の推論トークンを提案するか（--spec-draft-n-max）という問いには、唯一の正解はありません。モデルアーキテクチャと利用可能なVRAMの両者に依存します。
- 16 GB上の27Bデンスの場合:
--spec-draft-n-max 2と q8 KVが最速で、--spec-draft-n-max 1と q5 KVがコンテキストに最も優しい設定です。 - 16 GB上の35B MoEの場合:
--spec-draft-n-max 1が実用的なコンテキストを維持する唯一のオプションですが、それでも僅かなものです。 - より高い値（
3,4）は、VRAMへの圧力を比例した速度向上なしに増加させます。max 4では、max 2と同程度以上の追加VRAMを消費しますが、生成速度はそれに追いつきません。
llama.cppでMTPを有効化する方法
MTP対応のGGUF（ファイル名に MTP が含まれる）を使用していることを確認してください。llama.cppのフラグにご不明な点がある場合は、llama.cpp クイックスタート（CLIおよびサーバー） で基礎事項をカバーしています。次に、llama-serverまたはllama-cliを以下のように起動します。
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
q5 KVキャッシュの場合、q8_0 を q5_1 または q5_0 に置き換え、--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
llama.cppは、GGUFファイル内のMTPヘッドと --spec-type draft-mtp の設定を検知すると、MTPを自動的に有効化します。
したがって、標準の Qwen3.6-27B-UD-IQ3_XXS.gguf はMTPモードでは動作しません。Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf が必要です。
ただし、Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf は、推論デコーディングモードと自己回帰（オートレグレッシブ）モードの両方で動作可能です。
結論
16 GB GPU（RTX 4080）上で、これらの量子化レベルにおいて、llama.cppのMTPは Qwen 3.6 27B では明確な勝利ですが、実用的な使用では Qwen 3.6 35B では純粋な損失となります。
Qwen 3.6 27B (IQ3_XXS) — MTPは worthwhile（価値がある）:
- q8 KV + MTP max 2 → ~67 %高速な生成、コンテキスト 40–60 K（MTPなしでは80–100 K）
- q5 KV + MTP max 1 → ~39 %高速な生成、コンテキスト 70–100 K（MTPなしでは130–160 K）
--spec-draft-n-max 2で速度とVRAM効率の良いバランス
Qwen 3.6 35B (IQ3_S) — 16 GBではMTPは実用的ではない:
- 生成速度は27–29 %向上するが、q8では平均コンテキストが10–15 Kに、q5では10 Kに崩壊
- 80–120 Kのコンテキストを持つ122–146 t/sの標準デコーディングの方が、実際のタスクに有用
- 24 GB以上のVRAMでは状況が大幅に改善
紙面上では、q5 KVキャッシュはMTPの速度向上を維持しつつコンテキストウィンドウを最大化するための明らかな解答ですが、実際にはq8からq5への移行による品質低下は顕著な場合があります。採用する前に、自身のタスクでq5をテストしてください。私のワークロードでは劣化が許容できず、より狭いコンテキスト予算を持つq8の方が良いトレードオフでした。
LLMホスティングのオプションとインフラストラクチャのトレードオフのより広い図については、2026年のLLMホスティング の柱と 2026年のLLMパフォーマンス を参照してください。MTPと並行してQwen 3.6のサンプラー設定をチューニングしている場合は、Qwen 3.6およびGemma 4のためのエージェント型LLM推論パラメータリファレンス が有用な補足資料となります。
