MTP（マルチトークン予測）でローカルLLMは本当に速くなるか｜RTX 5080実測、非MoEで1.69倍・MoEは1.0〜1.4倍と構成次第

MTP（マルチトークン予測）は、LLMが次の1トークンだけでなく数トークン先までまとめて下書きし、本体が一括で検証して通す高速化技術。

llama.cpp に MTP が入り、Gemma 4 や Qwen3.6 をローカルで動かすと「2〜3倍速くなる」という話が広がっている。手法そのものは2024年に Meta のGloeckleらが提案したもので、推論を最大3倍まで速くできると報告していた。ただしこの3倍は、最初から複数トークン予測込みで訓練された専用モデルでの値。配布版GGUFに同梱された予測ヘッド／ドラフターを使う場合でも、手元のGPU構成で同じ倍率が出るとは限らない。RTX 5080 を中心に、非MoE型とMoE型のモデルを、量子化やGPU構成を変えながらMTPの有無で実測した。出てきたのは公称より控えめで、しかも構成で大きく動く倍率だった。

MTPの仕組み｜ドラフトモデル不要で複数トークンを一括検証する

通常のデコードは、1回の順伝播（forward pass）で1トークンを出す。このときバッチ1の生成では、各ステップで必要な重みをVRAMから読み出すため、モデルによってはメモリ帯域がボトルネックになりやすい。MTPはモデルに予測ヘッド（ドラフター）を持たせ、本体が次のトークンを確定するのと同時に、その先の数トークンを下書きさせる。下書きが本体の出力と一致していれば、1回の検証で複数トークンをまとめて確定できる。順伝播の回数を減らせるぶん、生成が速くなる。

鍵になるのが採択率（acceptance）。下書きしたn個のトークンのうち、本体が検証して「これで合っている」と通した分だけが得になる。下書きが外れれば、その先は捨てて引き直すので、採択率が低いと順伝播の節約が効かない。下書きをn本提案して平均a本通れば、1回の順伝播で平均1+a本ほどを確定でき、これが倍率の天井を決める。たとえば下書き3本のうち平均1.5本通れば、1回の順伝播で2.5トークンぶん進む計算になる。実際にはドラフターを動かすコストや、外れた分の引き直しが乗るので、倍率は単純な2.5倍より小さくなる。採択率が頭打ちなのに本数だけ増やしても伸びないのもこのためだ。

もう一つ押さえたいのは、MTPが書き換えるのは「確定に至る過程」だけだという点。下書きしたトークンは本体（target）が検証して通すので、検証なしに近似で済ませる方式ではない。greedy（温度0）のように条件を固定すれば、MTPを切ったときの出力と一致しやすい。サンプリング設定や実装の違いで完全一致の扱いは変わるが、いずれにせよ品質を削って速度を買う種類の高速化ではない。ここが、精度を落として軽くする量子化とは性格が違う。

古典的な投機的デコード（speculative decoding）は、本体とは別に小型のモデルを下書き役として走らせる。これに対しMTPは下書き役をモデルに同梱しているため、別の小型ドラフトモデルを手で用意する必要がなく、構成は軽い。ただし予測ヘッド／ドラフター分の小さな追加ロードはあり、VRAM増分は実装と量子化で変わる。llama.cpp では --spec-type draft-mtp で有効化する。手法はもともと、複数トークン先を当てる訓練を課すと本体の性能そのものが上がる、という学習側の工夫としてGloeckleらが提案したもので、訓練で育った予測ヘッドを推論時の下書きに転用できる。最近のGemmaやQwenのローカル版が下書きヘッドを同梱しているのはこの流れで、対応していないモデルではこの方式のMTPは使えない。

検証環境とベンチの取り方｜何を固定し何を測ったか

数値が環境で動く技術なので、条件を先に開示する。

• GPU：RTX 5080 16GB（単GPU）／ RTX 5080 + RTX 5060 Ti 16GB（Oculink接続の2枚で分割＝dual）
• 実行系：llama.cpp 公式プリビルド ビルドb9745（CUDA 13.3）、flash-attention有効、全層GPU、KVキャッシュf16
• モデル：unsloth配布のGGUF。非MoE型 gemma-4-12b-it（Gemma 4 では Unified と呼ばれる。MoE ではなく毎トークン全パラメータを使う）、MoE型 gemma-4-26B-A4B-it（活性4B）、Qwen3.6-35B-A3B-MTP（活性3B）
• 計測：greedy（温度0）で256トークン生成を16〜20回流し、暖機の2回を除いたうえで外れ値をIQRで弾いた中央値

GPU使用率と帯域は生成中にサンプリングして取った。環境のせいで遅くなる・ぶれる要因（CUDAグラフの再生成、KVキャッシュの量子化、電力・温度制限、CPUオフロード）は事前に切り分けてある。最初は3回の中央値で見ていたが、偶然高い1回を拾うことがあり、各条件16〜20回のIQR中央値に揃えた。

とくに引っかかったのが、MoE型を1枚のGPUに載せるときの罠だ。VRAMが96%まで埋まるとドラフターが正しく載らず、MTP有りが無しの0.6倍まで落ちることがあった。これは効きの話ではなく載せ方の問題なので、量子化を下げてVRAMに2〜3割の余裕を作り、ドラフターがGPUに載った状態の数値だけを採用している。数値はこのビルド・このモデルの2026年6月時点のもので、別ビルドや別量子化では動く前提で読んでほしい。

RTX 5080実測｜公称2〜3倍に対し1.05〜1.69倍

MTPの有無で生成速度（tok/s）と採択率を測った。倍率はMTP有を無で割った値。

まず公称の2〜3倍は、この環境のどの構成でも出なかった。いちばん効いたのは非MoE型のgemma-4-12bを1枚のGPUで動かしたときで、1.69倍。これは投機的デコードの実装報告でよく見る1.5〜2倍の上側にあたる。一方MoE型は1.0〜1.4倍と控えめで、しかも同じモデルでも量子化やGPUの構成で大きく動いた。同じgemma-4-26B-A4Bが、2枚分割のQ4で1.05倍、量子化を下げると1.19倍（後述）、さらに下げたIQ3で1.30倍、1枚に載せると約1.4倍。ここで測ったのは数機種・数構成であって、非MoE型・MoE型すべてに当てはまる値ではない。

VRAM列も見ておきたい。同じ26B-A4Bでも、Q4（約20GB）やQwen（約22GB）は16GBを超えて1枚に収まらず、2枚に分割している。この分割が、後で見る倍率の振れに効いてくる。逆に量子化を下げたIQ3なら約14GBで1枚に収まり、12bに至っては約10GBと余裕がある。16GBに収まらないさらに大きいモデルがどこまで手元で動くかは、巨大オープンモデルを手元で動かせるか比較した記事でも扱っている。

同じMoEを構成違いで何度も測ったのには理由がある。最初に2枚分割のQ4（1.05倍）だけを見て「MoEはMTPが効かない」と結論しかけたが、2枚に分けたぶんの通信が倍率を食っている疑いがあった。実際、1枚に載せ直すと約1.4倍まで上がり、量子化を変えると同じ2枚分割でも倍率が動く。一つの構成の数字を技術全体の評価に広げると、こうして読み違える。次の節で、その中身を分解する。

なぜ倍率が動くのか｜MTPは「1順伝播あたりのボトルネック」を薄める

バラついて見える倍率は、一つの見方でつながる。MTPは1回の順伝播で複数トークンを確定する技術なので、その順伝播でいちばん時間を食っている処理（ボトルネック）を、確定できたトークン数で薄められるほど効く。ボトルネックが何かは構成で変わる。

1枚のGPUで動かすときは、重みの読み出し（メモリ帯域）がボトルネック。バッチ1の生成は毎トークン、必要な重みをVRAMから読み出すからだ。非MoE型は全層の重みを使うので、その読み出しが重くなる。非MoE型のgemma-4-12b（約7GB）をMTP無で回すと、演算（SM）使用率が約90%・帯域（MEM）使用率が約70%、重み読みだけで毎秒およそ590GB——理論ピーク約960GB/sの6割を超える。完全に帯域で頭打ちの状態だ。MTPを入れると帯域使用率が70%→50%へ下がる。1回の重み読みで複数トークンを確定するので、トークンあたりの帯域消費が減り、頭打ちが緩む。読む量が多い非MoE型ほど薄める旨味が大きく、1.69倍が出た。

MoE型は1トークンで使う重み（活性パラメータ）が3〜4B分しかなく、読む量が元から少ない（26B全体はVRAMに載るが、毎トークン読むのは活性4B分だけ）。帯域での頭打ちが弱いぶん、MTPで薄める旨味も小さい。1枚に載せたときの約1.4倍が、非MoE型の1.69倍に届かないのはこのため。裏を返せば、MoEがそもそも速いのも同じ理由だ。読む量が少ないから帯域に余裕があり、MTP無しでも速く回る（実測でも単GPUのMoEは158.6 tok/sと、非MoE型の83.6 tok/sを上回る）。電力あたりの生成速度でMoEがdense型を上回るのも、A3B型のMoEが最速級で回るのも、この読む量の少なさが効いている。MTPは「帯域で詰まっているほど効く」技術なので、すでに速いMoEには伸びしろが少ない、と捉えると分かりやすい。

16GBに収まらず2枚のGPUに分けると、今度はGPU間の受け渡し待ちがボトルネックになる。llama.cppの層分割は、順伝播ごとに層の境界でGPU間にデータを渡して相手の計算を待つ方式だ（16GB VRAMで38%あふれるMoEを2枚目で解消した検証と同じ構成）。受け渡す量そのものは小さいが、Oculink越しの転送の待ち時間と、2枚が互いを待って直列化するぶんが乗る。生成中のSM25%・MEM13%という演算も帯域も低いままの数字が、その待ちで時間を使っているサインだ。ここでMTPはその待ちを薄める。おもしろいのは、同じMoEでも量子化を下げるほど倍率が上がったこと。

量子化を下げると1トークンあたりの計算は軽くなるが、GPU間の受け渡しにかかる待ち時間はあまり変わらない。すると順伝播の時間に占める待ちの割合が増える＝ボトルネックが受け渡し待ちに寄る。MTPはその待ちを薄めるので、待ちに寄っているほど旨味が増す。だからQ4（1.05倍）よりQ3（1.19倍）、IQ3（1.30倍）と倍率が上がっていく。「小さい量子化＝帯域に余裕＝MTP効かない」という単純な予想とは逆で、ボトルネックが帯域から受け渡し待ちへ移っていることを示している。

採択率も効く。確定できるトークンが多い順伝播ほど薄める効果が大きいからだ。ただし採択率はモデルとドラフターの相性で決まり、量子化やGPU構成でも動く。実際、同じIQ3_Sの26B-A4Bでも、1枚では採択率0.60、2枚分割では0.82と差が出た（温度0で固定しても、複数GPUでは分割方法・計算順序・量子化誤差・実装差の影響で、ドラフターの当たり方が変わった可能性がある）。倍率を一つの数字で言い切りにくいのは、ボトルネックの種類と採択率がこうして構成ごとに動くからだ。

設定の詰め方｜下書き本数・量子化・温度

効きを最大化する設定を、いちばん素直な非MoE型gemma-4-12bで測った。

下書き本数（--spec-draft-n-max）は3本前後

2本で1.57倍、3本で1.69倍、4本で1.66倍。本検証では3本前後が最も安定し、4本にすると僅差で下回った。公開モデルカードの例ではQwen3.6が2本、Gemma 4 QATが4本を挙げており、最適値はモデル・量子化・ビルドで変わる。下書きを増やすほど、当たれば一度に確定できるトークンは増えるが、外れたときに捨てる計算も増える。この綱引きで最適な本数が決まるので、2〜4本を実際に振って一番速い本数を選ぶのが確実だ。

量子化は速度だけでなくMTPの効きにも絡む

量子化はファイルを軽くしてVRAMに収めるためのものだが、上で見たようにMTPの倍率や採択率にも絡む。さらに、非MoE型のgemma-4-12bで高品質をうたう動的量子化（UD-Q4_K_XL）に替えると、採択率が0.57から0.39へ落ちた。重みの当たり方が変わるとドラフターの予測が本体とずれやすくなる、という挙動で、これは1モデルでの観測だが、MTP前提なら凝った量子化より、素直なQ4_K_Mを起点にする方が読みやすい。量子化を選ぶときは、収まるかどうかだけでなく、MTPの効きまで一度実測しておくと外さない。

温度を上げると採択率が下がる

温度（temperature）は生成のランダム性を決める設定で、低いほど毎回似た答えに寄り、高いほど答えが散らばる。これがMTPの採択率にも響く。最も決定的な温度0（greedy）で採択率0.57、温度0.7で0.51、温度1.0で0.48。サンプリングを効かせるほど本体の出力がぶれて下書きとの一致が減り、採択率が下がる。事実確認や要約のように温度を下げて使う場面ではMTPの旨味が出やすく、創作のように温度を上げる用途では目減りする。KVキャッシュは今回f16で固定した。KVを量子化すると検証側の出力が変わり採択率に響くため、MTPの素性を見るならf16が無難だ。なお、ここまでの詰め方はどれも非MoE型で帯域に詰まっている前提の話で、MoEや複数GPUでは効きの大きさ自体が変わる。まずは自分の構成でMTPの有無を比べるのが先になる。

非MoE型を単機・n-max3で動かす最小構成のコマンドは次のとおり。

llama-server -hf unsloth/gemma-4-12b-it-GGUF:Q4_K_M \
  --spec-type draft-mtp --spec-draft-n-max 3 \
  --flash-attn on -ngl 99 -c 4096

フラグ名はビルドで変わることがある（このコマンドはビルドb9745時点）。手元の llama-server --help で --spec-type の選択肢に draft-mtp があるかを確認してほしい。倍率が伸びないときは、設定を触る前にMTPが実際に使われているか（サーバーが出す採択率が0でないか）を見て、次に生成中のGPU使用率で帯域・通信のどちらで詰まっているかを切り分けると早い。ベンチの「毎秒○トークン」が自分の環境で出るとは限らないのは、MTPでも同じだ。

まとめ｜MTPは効くが、倍率は構成で決まる

ドラフターがGPUに正しく載った有効条件では、MTPはこの環境のどの構成でも生成を速くした（1.05〜1.69倍）。切る理由は基本ないが、公称の2〜3倍を期待すると外れる。いちばん効くのは、非MoE型のモデルを1枚のGPUに載せ、メモリ帯域で頭打ちになっている使い方。RTX 5080級の単機ローカル実行はまさにこれにあたり、gemma-4-12bで実測1.69倍が出た。設定はn-max3前後・素直なQ4_K_M・温度低めが噛み合う。

MoE型は活性パラメータが少なく帯域での頭打ちが弱いぶん、効きは小さめ（1.0〜1.4倍）で、量子化やGPU構成で振れる。とくに16GBに収まらず複数GPUに分けると、ボトルネックがGPU間通信に移り、倍率は量子化次第で動く。MoEで倍率を一つの数字に期待するより、まず1枚に収まるGPU・量子化を選んで実測するのが近道になる。

使うかどうかの判断はシンプルだ。対応モデルがあるなら、基本は有効にしておけばよい。出力は変わらず、まともに載っていれば速度が落ちることもない（落ちるならVRAMの載せ方を疑う）。あとは期待値だけ構成に合わせて調整する——非MoE型を1枚で動かすなら大きく、MoEや複数GPUなら控えめに見ておく、という具合だ。

なお、ここで測ったのは速度と採択率まで。出力の質や、コーディング・事実確認・エージェントといった用途別の向き不向きはこの計測の範囲外だ。MTPは本体の出力自体を変えずに順伝播を減らす技術なので質は基本そのまま保たれるが、量子化や温度を一緒に動かす場合は別途、自分のタスクで確認したい。

参考資料

• Gloeckle et al. “Better & Faster Large Language Models via Multi-token Prediction” arXiv:2404.19737 (2024) — MTPの提案元、最大3倍の報告
• llama.cpp（ggml-org/llama.cpp） — MTPを含む投機的デコードの実装
• unsloth — 検証に使ったGGUFモデルの配布元