MTPとは？Qwen3.6とllama.cppで推論を高速化する仕組み・設定・注意点

ひとことで言うと

MTP（Multi-Token Prediction）は、次のtokenを1つずつ出すだけでなく、複数step先のtoken予測を学習・推論へ利用する考え方です。llama.cppでは、draft tokenを作ってtarget側で検証するspeculative decodingの一方式としてdraft-mtpを指定します。

通常の自己回帰生成

通常の自己回帰生成では、直前までのtoken列を使って次のtokenを決め、出力へ追加してからまた次を計算します。生成中のdecodeは、入力全体をまとめて処理するprompt processingより、逐次処理の影響を受けやすい段階です。

prompt processing / prefill

入力promptをまとめて処理する段階。入力長、batch、context、TTFTへ影響します。

generation / decode

回答tokenを生成する段階。tokens/sとMTPの主な比較対象です。

TTFT

入力を送って最初のtokenが出るまで。MTPで常に改善するとは限りません。

speculative decodingの基本

llama.cpp公式ドキュメントは、draftを先に作り、target modelがまとめて検証することで、draft予測が頻繁に正しい場合に生成を加速できると説明しています。速さは候補を出すコストと、受理してまとめて進む効果の差で決まります。

通常： target → token 1 → target → token 2
MTP：   draft → token 1, 2, ... → targetで検証 → acceptedをまとめて採用

したがってMTPのフラグを付けたら必ず2倍ではありません。prompt、sampling、モデル、quant、GPU、受理率が異なる測定値を、そのまま別環境へ移しません。

Multi-Token PredictionとQwen3.6

Qwen公式モデルカードはQwen3.6-27BのMTPをmulti-stepsで訓練したと示しています。UnslothはQwen3.6-27B-MTP-GGUFとしてGGUFを配布し、llama.cppでdraft-mtpとspec-draft-n-max 2を使う例を掲載しています。

ここでの「公式」はQwenのモデル仕様、「配布者の案内」はUnslothのGGUFと実行例、「独自実測」は読者のColabで取得したlogです。3つの根拠を1つに混ぜず、モデルrevisionとllama.cpp commitを一緒に記録します。

• Qwen公式モデルカード - 27BとMTP訓練を確認する
• MTP GGUF配布ページ - quantとllama.cpp commandを確認する

llama.cppのdraft-mtp設定

現行のllama.cpp CLIではspec-typeにdraft-mtpがあり、spec-draft-n-maxでdraft token数を指定できます。Qwen3.6 MTP GGUFでは、配布者の例に合わせてn-max=2から始め、n-max=1やbaselineと比較します。

llama.cpp/build/bin/llama-cli --hf-repo "unsloth/Qwen3.6-27B-MTP-GGUF:Q3_K_S" --no-mmproj --ngl 99 --ctx-size 4096 --n-predict 128 --spec-type draft-mtp --spec-draft-n-max 2 --single-turn --seed 42 --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0.0 --prompt "$PROMPT"

CLIのhelpやREADMEでoption名を再確認し、実行時に出たcommitとversionを記録します。最新mainの挙動を将来も同じだと断定しません。

別draft model方式との違い

draftがあるからMTPとは限りません。llama.cppのdraft、draft-eagle3、draft-mtp、ngram系は同じ目的に見えても構成と制限が違います。

なぜ速くなることがあり、遅くなることもあるのか

論文や配布者ページの速度向上率は、その環境の観測または主張です。Qwen3.6-27BをColab T4で測っていない数字を、自分の結果として書かないでください。

受理率・n-max・p-minの読み方

accepted tokens

draftで提案したtokenのうち、targetの検証を通って採用された数。MTPの効き方を見るログ上の手がかりです。

n-max

1回にdraftするtoken数の上限。大きくすると候補数と負荷も増えるため、1→2の順で比較します。

p-min

speculative decodingを使う最低確率の設定。先にsamplingとn-maxを固定し、理由なく同時に変えません。

1. baselineを同じpromptで実行する。
2. MTP n-max=1を実行し、速度・VRAM・acceptedを記録する。
3. MTP n-max=2を実行し、baselineと同じ表へ追加する。
4. 受理率が低い場合はp-minをいじる前に、prompt、sampling、model revision、commitを確認する。

VRAM・context・MTPの追加負荷

MTPをonにすると、baselineと同じmodel weightsでも、draft関連のbufferやKV cacheの余白が足りなくなる場合があります。contextを長くするとKV cacheが増えるため、T4 16GBではQ3系・短いcontext・MTP offから段階的に上げます。

• VRAMの内訳 - weightsだけでなくbufferとKV cacheを見る
• context長の考え方 - 公式最大値とT4の実用値を分ける

出力品質・sampling・再現性

同じseedを使っても、runtime、chat template、llama.cpp commit、samplingの実装が違えば出力が同じとは限りません。速度の比較ではpromptと出力上限を固定し、内容の比較では出力を保存して人間が確認します。

• モデルrevisionとGGUFのquantを記録する
• temperature、top-p、top-k、min-p、seedを記録する
• thinking/reasoningの設定を記録する
• prompt processingとgenerationを分ける
• 精度損失ゼロや完全一致を未検証のまま書かない

MTP比較テンプレート

1回しか測れない場合は単回と明記し、GPU実測未完なら空欄を想像で埋めません。3回以上なら中央値、cold/warm、失敗条件も残します。

向いている用途・向いていない用途

llama-serverを使う場合も、外部公開トンネルや常設サービス化の手順へ広げません。まずllama-cliでモデル単体の推論を確認します。

FAQとColab実践への導線

• Google ColabでQwen3.6-27Bを動かす - Q3_K_S、CUDA build、baseline、MTP、OOMを順番に試す
• T4 16GBのOOM対策 - MTPだけOOMになる場合の切り分け
• 速度測定の一般ガイド - TTFT、RAM/VRAM、tokens/sを分けて記録する