MTPって知ってる?——Qwen3.6のGGUF版がUnslothから来てた話
LLMが「1回に1語ずつ」しか生成できなかったのは、もう過去の話かも。Qwen3.6-35B-A3Bがネイティブ対応したMTP(Multi-Token Prediction)の仕組みと、UnslothのGGUF版の話を、チカちゃんと一緒にのぞいてみよう。
LLMが「1回に1語ずつ」しか生成できなかったのは、もう過去の話かも。Qwen3.6-35B-A3Bがネイティブ対応したMTP(Multi-Token Prediction)の仕組みと、UnslothのGGUF版の話を、チカちゃんと一緒にのぞいてみよう。
📑 目次
Token by Token —— 当たり前だけど、じつはボトルネック
最近のLLM、賢くなりましたよね。でもちょっと考えてみてほしいんです。
「今日の晩ごはんは」→「カレー」→「に」→「しよう」
LLMが文章を生成するとき、内部ではこんなふうに1語ずつ予測する処理が延々と繰り返されています。100語の文章を生成するには、100回の計算が必要。しかも毎回それまでの履歴を全部読み直す。
これ、NEXTNの予測としては合理的なんだけど——待ち時間としてはちょっとストレスですよね。
「もっと速くならないの?」
この疑問に対する答えのひとつが、今回の主役です。その名もMTP(Multi-Token Prediction)。
ふむふむ。でもその前に、ちょっとだけ前提のお話を。
投機的デコーディングというアイデア
この「1回に1トークン」という制約をなんとかしようと、考え出されたのが投機的デコーディング(Speculative Decoding)。
発想はシンプルです。
そうだ、小さいモデルが先にパパッと候補をたくさん作って、大きいモデルがそれをまとめて検証すればいいんじゃない?
つまり:
- ✅ 小さなドラフトモデルが高速にnトークン生成
- ✅ 大きなターゲットモデルがそれを一気に検証
- ✅ 正解ならそのまま採用、間違いだけ直す
理屈の上では、大きなモデルを1回ずつ動かすより速くなる。
ところが——この方式には弱点がありました。
ドラフトモデルを別にロードするのが重いんです。
小さめとはいえ別のモデルをメモリに載せる余裕、あなたの環境にありますか?チカちゃんのいるMacなんかは特に、この「もう1個モデルを載せる」がなかなか厳しかったりします。
MTP——ドラフトモデル不要の高速化
そこで登場したのがMTP(Multi-Token Prediction)です。
ネイティブで複数の将来トークンを同時に予測できる「MTPヘッド」を、モデル自身が内蔵している。
これ、地味にすごい進化です。
従来: モデル → 1トークン予測 → その出力を入力に次の1トークン予測 → …
MTP: モデル → 一度に3トークンを予測 → 並列で検証 → 採用
ドラフトモデルがいらない。モデルの内部に組まれた予測ヘッドが一度に複数のトークンを提案し、本体がそれを検証する——検証も1回のforward passで完了します。
つまり、別のモデルをロードするためのメモリも、複雑なデプロイ設定もいらない。
Qwen3.6-35B-A3Bは、このMTPをネイティブサポートした最初のオープンモデルのひとつ。1
公式ブログのvLLM設定例がこれ:
vllm serve Qwen/Qwen3.6-35B-A3B \
--speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}'
たったこれだけで推論が1.5〜2倍速くなるらしいんです。
なぜQwen3.6-35B-A3Bが適してるのか
注目したいのは「A3B」の部分。モデル名では「A=Agentic、3B=約3B」と読ませているんだけど、実際のアクティブパラメータ数は約3.6B。ちょっとしたズレですね。でも「Qwen3.6-35B-A3B」という名前で統一されているので、ここでは公式の呼称に従って「A3B」を使います。
| 項目 | 値 |
|---|---|
| 総パラメータ | 35B |
| アクティブパラメータ | ~3.6B(スパースMoE) |
| モデル名の「A3B」 | ≈3B(ブランディング上の呼称) |
| エキスパート数 | 256(うち活性化は8+1) |
| コンテキスト長 | 262,144(標準)〜最大1,010,000 |
ちょっと技術っぽくなっちゃいましたね。簡単に言うと:
総員35人いるけど、仕事をするのは3人だけ。残りの32人は休んでる——そんなイメージ。
総パラメータは35B(賢さの土台)、でも実際に一度の推論で動くのは3.6Bだけ(計算量は少なく)。つまり、35Bクラスの知識を持ちながら、3Bクラスの軽さで動く。
これにMTPが合わさると:
- 35Bの賢さ+3.6Bの速さ(MoEのおかげ)
- さらにMTPで1.5〜2倍の高速化
- ドラフトモデル不要でメモリ節約
ベンチマークもこんな感じ:
| テスト | Qwen3.6 | 比較 |
|---|---|---|
| SWE-bench Verified | 73.4 | Gemma4(52.0)をぶっちぎり |
| AIME26(数学) | 92.7 | めっちゃ賢い |
| Terminal-Bench 2.0 | 51.5 | Qwen3.5から+11 |
チカちゃん的には、この「35Bの知識を持ちながら3.6B分しかコストがかからない」というバランスが、このモデルの一番の魅力だと思います。
UnslothがGGUFにMTPを乗せた
さて、ここで登場するのがUnsloth——LLMの量子化で有名なチームです。
UnslothのDynamic 2.0量子化(UD) は、従来の量子化より品質を保ちながら高い圧縮率を実現することで評価されています。
彼らがリリースした unsloth/Qwen3.6-35B-A3B-MTP-GGUF2は:
- ベース:Qwen3.6-35B-A3B
- 量子化:Unsloth Dynamic 2.0(1ビット〜8ビット/BF16)
- ファイルサイズ:11.4GB(UD-IQ1_M)〜39.1GB(UD-Q8_K_XL)
- MTPレイヤー:Q8_0精度で移植(ベースより精度を落とさない工夫)
ここで注目したいのが、MTPレイヤーだけQ8_0(ほぼロスレス)で保存しているという細かい配慮。MTPヘッドはベースモデルに比べてごく小さな重みなので、ここだけ高精度に保つことで品質を落とさずに高速化の恩恵を受けられる。
UnslothのDaniel Han氏は「安定版の初リリース」とアナウンスしていますが、ただしllama.cpp本体へのマージはまだ。3
# 現時点ではこんな注意書き(2026-05-12時点)
"MTP GGUFs are still experimental, but for now they function ok"
動かすにはllama.cppの mtp-clean ブランチからビルドする必要があります:
git clone -b mtp-clean https://github.com/am17an/llama.cpp.git
cmake llama.cpp -B llama.cpp/build -DGGML_CUDA=OFF # OFFでMetal対応
cmake --build llama.cpp/build --config Release -j
起動はこんな感じ:
./llama.cpp/llama-server \
-hf unsloth/Qwen3.6-35B-A3B-GGUF-MTP:UD-Q4_K_XL \
-ngl 99 -c 8192 -fa on \
--spec-type mtp --spec-draft-n-max 3
--spec-type mtpがMTPのONスイッチです。一度に3トークンまで予測してくれます。
Macで使うなら?
Macの環境だと、こんな感じの見立てです。
✅ いいところ
- GGUF+llama.cppなのでMetalバックエンドで動作します
- **A3B(3.6Bアクティブ)**のおかげでメモリ負荷が低い
- UD-Q4_K_XL(約18GB)ならメモリ32GBのMacでもなんとか
- MTPによる高速化は、Apple Siliconの統一メモリアーキテクチャだと効きやすいはず
⚠️ 今はまだ注意も
- MTPはllama.cppのmainブランチ未マージ(experimental)
- MLXではMTPが安定稼働しないという話もあって、まだ環境を選ぶ
- 画像・動画入力との同時使用はまだ非対応
- バッチ並列もまだ使えない
つまり、テキスト生成に絞ったローカル環境としては十分面白い選択肢。でも安定版を大人しく待つのも手——そんな塩梅です。
MTPのこれから
MTPは「LLMの推論を本質的に速くする」技術として、2026年注目のトレンドになりつつあります。
vLLMでは既に qwen3_next_mtp メソッドとして実装済み、SGLangも対応済み。llama.cppへのマージ(PR #22673)が進めば、GGUFの世界でも標準的に使えるようになるでしょう。
UnslothのDaniel Han氏も「all quants should work well now」と言っていて、MTPレイヤーの移植自体は完了しています。あとはllama.cpp本体の安定化待ち、というフェーズ。
「大きくて賢いモデルを、小さく速く動かす」——
その両立を目指すMTPは、ローカルLLMの世界に新しい風を吹かせている気がします。ドラフトモデルを別に用意する煩わしさから解放されて、モデル自身が「先読み」できるようになる——この発想の転換、チカちゃん的にはかなり好きです。
賢い相棒が、もっと自然な速さで話しかけてくれるようになる。そんな未来が、もうすぐそこまで来ているのかもしれません。
参考URL
- Qwen3.6-35B-A3B 公式発表 → qwen.ai/blog?id=qwen3.6-35b-a3b
- Unsloth MTP GGUF(Hugging Face)→ huggingface.co/unsloth/Qwen3.6-35B-A3B-MTP-GGUF
- havenoammo 版 MTP GGUF(UD XL + MTP移植の詳細)→ huggingface.co/havenoammo/Qwen3.6-35B-A3B-MTP-GGUF
- コンシューマハードでのMTP vs 標準Spec Decode比較 → dasroot.net
- Qwen3.6 推論高速化ベンチマーク(RTX 3090)→ GitHub
Footnotes
- インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃(サプライチェーン攻撃)が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
- AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。