Gemma 4 assistant-MTPとは：Multi-Token Predictionのドラフトモデルが推論を高速化する仕組み

Gemma 4 関連のモデルで assistant-MTP、assistant、MTP drafter といった名前を見かけても、それを独立したチャットモデルとして扱わないほうがよいです。

より正確には、Gemma 4 の主モデルと組み合わせて使う Multi-Token Prediction のドラフトモデルであり、Speculative Decoding、つまり投機的デコードのためのものです。

一言でいうと、最終判断は主モデルが行い、assistant-MTP は先に下書きを作ります。その下書きが当たっていれば、主モデルは複数の token を一度に確認でき、生成速度が上がります。

これは何なのか

MTP は Multi-Token Prediction、つまり複数 token の予測を意味します。

Gemma 4 の assistant-MTP は軽量な補助モデルと考えるとわかりやすく、drafter、draft model、ドラフトモデルとも呼ばれます。通常は対応する Gemma 4 主モデルとペアで使います。たとえば：

Gemma 4 12B と対応する 12B assistant-MTP
Gemma 4 26B と対応する 26B assistant-MTP
Gemma 4 31B と対応する 31B assistant-MTP

役割はユーザーの質問に直接答えることではなく、主モデルのために次に出そうな token をいくつか予測することです。

最終出力はあくまで主モデルが検証して決めます。そのため assistant-MTP は「先読み役」や「ドラフトヘッド」に近く、新しいチャットモデルではありません。

通常の生成が遅くなる理由

従来の自己回帰型言語モデルは、通常このようにテキストを生成します。

既存の文脈から次の token を予測する。
その token を文脈に戻す。
次の token を予測する。
生成が終わるまで繰り返す。

この手順は安定していますが、本質的に直列処理です。固定フォーマット、コードテンプレート、よくある短い表現のように、後続の token が予測しやすい場合でも、モデルは一つずつ計算します。

ローカル推論やコンシューマー向け GPU では、この token ごとの生成がメモリ帯域のボトルネックを強めます。1 token を生成するたびに大量のモデル重みを繰り返し読み出すため、計算ユニットを十分に使い切れないことがあります。

MTP の考え方は、この隙間を使うことです。より軽いドラフトモデルが先に複数 token を予測し、それを主モデルに渡して並列に検証します。

投機的デコードの流れ

流れは四つのステップに分けられます。

assistant-MTP がまず未来の token をいくつか予測する。

たとえば一度に 4 個の候補 token を予測します。
主モデルがそれらの候補 token を読む。

主モデルは下書きをそのまま信じるのではなく、それらの token が自分の分布に合うかを並列に確認します。
正しく予測された token が採用される。

最初の 3 個が検証を通れば、主モデルが一度に 3 token を生成したのと同じになります。
間違った位置で戻る。

4 個目が採用されなければ、そこから主モデルの通常ロジックで生成を続けます。

つまり、これは「品質を犠牲にして速度を得る」仕組みではありません。最終検証は主モデルが行い、正しそうな後続 token を先に検査しているだけです。

出力が一貫し得る理由

投機的デコードで最も誤解されやすい点は、小さなモデルを使うと結果が悪くなるのではないか、という点です。

標準的な speculative decoding では、答えは通常ノーです。ドラフトモデルは候補を出すだけで、主モデルが採否を決めます。採用される token は主モデルのサンプリングロジックに従う必要があり、合わない token は拒否されます。

つまり理論上、最終出力分布はドラフトモデルを使わない場合と一致させられます。Google も Gemma 4 MTP drafter を、出力品質や推論ロジックを落とさず速度を上げるものとして位置づけています。

実際のエンジニアリングでは、最終的な挙動は推論フレームワークの実装、サンプリングパラメータ、MTP サポートの完成度、主モデルと assistant モデルの正しい組み合わせに依存します。

なぜ高速化できるのか

高速化は二つの要因から来ます。

ドラフトモデルが軽く、候補 token の予測コストが低い。
主モデルが複数の候補 token を一度に検証でき、token ごとの待ち時間を減らせる。

assistant-MTP の予測が正確なら、主モデルの 1 回の forward で複数 token を採用でき、スループットは大きく上がります。Google は発表時、Gemma 4 と MTP drafter の組み合わせで、一部のハードウェアやフレームワークでは最大約 3 倍の速度向上が得られると述べています。

ただし、この数字がどの場面でも安定して再現できるわけではありません。高速化の効果は次の要素に左右されます。

主モデルのサイズ。
assistant モデルと主モデルの一致度。
一度に予測する speculative tokens の数。
prompt の種類。
サンプリング temperature。
推論フレームワークの実装。
GPU / CPU / メモリ帯域。

一般に、整形済みテキスト、コード、固定構造、よくある短い表現はドラフトモデルが当てやすいです。一方で、非常に自由度が高く、ランダム性が強く、temperature が高い生成では、加速効果が弱くなることがあります。

使い方

assistant-MTP には推論フレームワーク側の対応が必要です。assistant モデルをダウンロードしただけで、そのままチャットできるわけではありません。

よくある使い方は二つあります。

方法1：主モデル側の MTP 対応を使う

一部のフレームワークは Gemma 4 の MTP 関連構造を直接読み取り、パラメータで有効化できます。たとえば vLLM コミュニティでよく見られる方向は speculative config を使う方法です。

1
2


vllm serve google/gemma-4-31B-it \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

この方法では、モデル形式やフレームワーク実装によっては assistant モデルを別途指定しなくてもよい場合があります。

方法2：assistant / drafter モデルを別途ロードする

GGUF / llama.cpp のようなローカル推論では、主モデルと draft モデルを分けてロードする形がよく使われます。考え方は次のようなものです。

1
2
3
4
5
6


llama-server \
  -m gemma-4-12B-it-Q4_K_M.gguf \
  --model-draft gemma-4-12B-it-assistant-MTP-Q8_0.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 4 \
  --ctx-size 8192

ここで重要なのは次の点です。

-m は主モデルを指します。
--model-draft は assistant-MTP ドラフトモデルを指します。
--spec-type draft-mtp は MTP ドラフトモードを有効にします。
--spec-draft-n-max 4 は最大 4 token までドラフトするという意味です。

llama.cpp のバージョンによってパラメータ名は変わる可能性があります。実際に使う前に、現在の --help とモデルカードを確認してください。

パラメータ調整

`--spec-draft-n-max`

このパラメータは、assistant-MTP が一度に最大何 token までドラフトするかを制御します。

小さな値から始めます。

1

--spec-draft-n-max 2

次に試します。

1

--spec-draft-n-max 4

値が大きいほど速いとは限りません。ドラフトの命中率が下がると、主モデルが候補を頻繁に拒否し、かえって計算を浪費します。

temperature

temperature が高いほど出力はランダムになり、assistant-MTP が主モデルの後続 token を当てにくくなります。

速度と安定性を優先するなら、まずは次の値から始めます。

1

--temp 0.7

またはさらに低くします。

1

--temp 0.4

コード補完、フォーマット修正、構造化出力では、低めの temperature のほうが適していることが多いです。

コンテキスト長

MTP は VRAM の魔法ではありません。主モデルとドラフトモデルはどちらもリソースを使い、長いコンテキストは引き続き KV cache を消費します。

8GB や 12GB VRAM の環境で、いきなり 64K / 128K を開くのは避けます。まずは次から試します。

1

--ctx-size 8192

安定を確認してから少しずつ上げます。

向いているタスク

assistant-MTP は次のような場面に向いています。

コード補完。
JSON / Markdown / XML などの構造化出力。
固定フォーマットのレポート。
数学の手順や表形式の出力。
低 temperature で決定性が高い Q&A。
ローカルモデルのチャットで遅延を下げたい場合。

これらの共通点は、後続 token に強い規則性があり、ドラフトモデルが当てやすいことです。

向いていないタスク

これは「モデルを賢くする」道具ではありません。

assistant-MTP は主モデルを賢くするわけでも、事実の正確性を改善するわけでもありません。解決するのは生成速度の問題であり、推論品質の問題ではありません。

次の場面では効果が小さい可能性があります。

temperature が非常に高い創作。
ランダム性の強いサンプリング。
ドラフトモデルと主モデルが合っていない。
推論フレームワークの MTP 対応が不完全。
VRAM がすでに厳しく、さらに draft モデルをロードする必要がある。

特に小容量 VRAM の環境では、assistant-MTP も VRAM や RAM を消費する点に注意が必要です。追加リソースの消費で速度上の利益が相殺されることもあります。

よくある誤解

誤解1：assistant-MTP はチャットモデルである

違います。これは主モデルの speculative decoding を補助するモデルです。直接チャットさせても実用的な意味はなく、結果も悪くなる可能性があります。

誤解2：MTP を使うと出力は必ず同じになる

理論上の目標は、最終検証を主モデルが行うため、主モデルの出力分布を保つことです。ただし、実装、サンプリングパラメータ、フレームワークのバージョンは実際の挙動に影響します。本番利用前には比較テストが必要です。

誤解3：`--spec-draft-n-max` は大きいほどよい

必ずしもそうではありません。多くドラフトするほど、外れる確率も上がる可能性があります。パラメータ値だけでなく、採用率と tokens/s を見るべきです。

誤解4：VRAM 不足を解決できる

できません。MTP は推論高速化であり、VRAM 圧縮ではありません。小容量 VRAM では、まず量子化、コンテキスト長、GPU オフロード層数を調整し、その後で MTP を検討するべきです。

本当に速くなったか判断する方法

体感だけで判断しないほうがよいです。同じ prompt 群で A/B テストを行います。

MTP をオフにして tokens/s を記録する。
MTP をオンにして tokens/s を記録する。
同じモデル、コンテキスト、temperature、prompt を使う。
出力品質と遅延を比較する。

次の三種類の prompt で試せます。

1

Markdown の表を CSV に変換する Python 関数を書いてください。

1
2


次の JSON を修正し、有効な JSON だけを出力してください：
{"name":"demo","items":[{"id":1,"tags":["a","b",],},]}

1

Linux のトラブルシューティング手順を固定フォーマットで 5 件出力してください。各項目には、問題、コマンド、判断基準を含めてください。

こうした構造化タスクが明らかに速くなり、出力品質が落ちていなければ、その環境では assistant-MTP を残す価値があります。

まとめ

Gemma 4 の assistant-MTP は、主モデルと組み合わせて使う Multi-Token Prediction のドラフトモデルです。speculative decoding により複数 token を先に予測し、それを主モデルが並列に検証することで、token ごとの生成遅延を減らします。

価値は高速化であり、モデル能力の向上ではありません。正しい使い方は、主モデルが最終出力を担当し、assistant-MTP が先にドラフトし、推論フレームワークが候補 token を検証して採用する、という形です。

すでに Gemma 4 を安定して動かせているなら、その次に MTP を検討します。まずは少ない speculative token 数から始め、tokens/s、VRAM 使用量、出力品質を見て、日常の実行スクリプトに入れるか判断します。

参考資料：