MTP・投機的デコードとは？ ローカルLLMで速くなる仕組みと条件

MTP（Multi-Token Prediction）や投機的デコードは、LLMの生成を効率化するために使われる仕組みだ。ただし、「MTP対応モデルなら必ず高速」「有効にすれば2倍」といった固定した効果があるわけではない。

基本となる考え方は、次に来そうなトークンを先に提案し、対象モデルが検証して採用することだ。候補がうまく当たれば複数トークンを効率よく進められる一方、候補を作る処理と検証にもコストがかかる。

投機的デコードは提案と検証に分かれる

通常の自己回帰生成では、対象モデルが次のトークンを順番に決めていく。投機的デコードでは、その前に別の方法で複数の候補を作る。

処理は大きく次の三段階で考えられる。

1. proposal — 次に続きそうなトークン列を作る
2. verification — 対象モデルがその候補を確認する
3. acceptance — 条件を満たした候補を採用する

候補が外れれば採用できるトークン数は減る。そのため、候補を大量に作れば必ず速くなるという仕組みではない。

最終的な生成を対象モデルが検証する点も重要だ。小さなdraft modelを使う場合でも、そのdraft modelの出力へ単純に置き換わるわけではない。

MTPは投機的デコードの一つの経路

llama.cppの投機的デコード文書では、draft modelを使う方式のほか、EAGLE、DFlash、MTP、ngramなど複数の方式が区別されている。

MTPは、モデル側が複数トークン先の予測に関する仕組みを持ち、それをランタイムが候補生成へ利用する経路になる。別のdraft modelを用意する方式とは必要なファイルや設定が同じとは限らない。

ngramのように入力中のパターンを利用して候補を作る方式もある。候補生成方法が異なるため、MTP、draft model、ngramを同じ設定名の別表記として扱うことはできない。

モデルカードの「MTP対応」だけでは使えない

Qwen3.8-27B、Qwen3.6-35B-A3B、Nemotron 3.5 Lightningなどでは、提供元がMTPに関する機能を案内している。

しかし、モデル側にMTP機能があることと、手元のローカル環境で利用できることは別だ。

少なくとも次の条件を確認する必要がある。

• 対象モデルの正確なリビジョン
• 使う量子化や配布形式
• ランタイムのバージョン
• そのモデル向けMTP経路の対応状況
• 必要な補助ファイルやhead
• GPUとRAMの余裕

コミュニティ配布でMTP用ファイルが別に用意される場合も、ファイルが存在するだけで自動的に有効になるわけではない。

draft model方式では組み合わせも重要

小さなdraft modelを使う方式では、対象モデルと候補生成側の組み合わせが必要になる。

tokenizerやモデル系列、リビジョンなどの条件が合わなければ、期待した候補生成ができない場合がある。別のモデル名が似ているから組み合わせられる、と推測するべきではない。

ランタイムの公式資料で対象方式と必要条件を確認し、対応する組み合わせを使う必要がある。

高速化率は固定できない

投機的デコードの効果は、候補がどの程度受理されるかだけでは決まらない。

• proposalを作るための計算時間
• 対象モデルの検証コスト
• 候補の受理率
• プロンプトの内容
• 出力長
• バッチや同時処理
• GPUやCPU
• メモリ配置

こうした条件が関係する。

候補がよく当たる用途では効果が出る可能性がある一方、proposal側の負荷が大きければ全体の時間が短くならないこともある。そのため、MTPや投機的デコードに共通する「○倍高速」という値は置けない。

まず通常生成と同じ条件で比べる

使う価値があるか判断するなら、同じモデル・プロンプト・コンテキスト・出力条件で通常生成と比較するのが分かりやすい。

最初は一つの方式だけを有効にし、生成速度だけでなく初回応答までの時間、メモリ使用量、候補の受理状況などを見る。複数の変更を同時に加えると、どの設定が効いたのか分かりにくくなる。

モデルの読み込みやテンプレート、GPU配置がまだ安定していない段階では、投機的デコードを先に追加する必要はない。通常生成が安定してから追加機能として比較する方が原因を追いやすい。

実行環境そのものをまだ選んでいない場合は、LM Studio・Ollama・llama.cppの比較から確認できる。

MTPや投機的デコードは、対応モデルを選ぶだけで得られる無料の速度倍率ではない。モデル・候補生成方式・ランタイムをそろえ、通常生成より実際に有利かを同じ条件で確かめる機能として考えるのが適切だ。