MTP有効で速度が落ちる！？dGPUなしの環境での実測レビューと品質向上の秘訣
ローカルLLMの最新機能として話題を集めている「MTP（Multi-Token Prediction）」。従来の推測デコードとは異なり、追加のモデルを用意せずにメインモデル単体で高速化が可能になるという触れ込みです。
しかし、実際に自分の環境であるAMD Ryzen 7 7735HS with Radeon 680M iGPU + 64GB RAMのPCでテストを進めたところ、速度面では「逆の結果」が出ました。一方で、文章の品質において新たな発見もあった今回の検証。LM Studio 0.4.14 ベータ版でのMTP設定や実測結果をベースに解説します。
MTPとは？ドラフトモデル不要の高速化技術
従来の推測デコードでは、メインモデルとは別に軽量な「ドラフトモデル」を別途読み込ませることで推論を先読みし、メインモデルが並列で検証することで速度を上げていました。しかし、これにはVRAMの消費増大や別モデルの準備が必要という課題がありました。
一方、MTPはモデルそのものに「トークンを先に予測するための機能（ドラフトヘッド）」を組み込んだものです。LM Studioの設定でMTPを有効にするだけで追加のモデルなしに高速化が可能になり、Qwen3.6ベースのモデルでは特に1.4倍から2倍程度の生成速度向上が期待されています。
実測結果：速度は「通常モデル」が勝利
今回のテストで使用したモデルはQwopus3.6 35B A3B v1 APEX I-Balanced（MTP版／通常版）、KV CacheはQ8_0、テスト内容はMTPに向いているとされるコード生成や論理的推論ではなく、敢えて不向きな資料読解と文章作成で試してみました。
速度比較（tok/s）
MTPなし（通常モデル）：12.54 tok/s（最速）
MTP Max Draft=3：10.29 tok/s（Acceptance Rate 60.3%）
MTP Max Draft=2：10.99 tok/s（Acceptance Rate 55.2%）
MTP Max Draft=1：11.41 tok/s（Acceptance Rate 42.4%）
結論として、MTPを有効にすると約10〜15%程度速度が遅くなりました。
理論的には並列検証で高速化が期待されますが、iGPU環境ではメインメモリをVRAMとして共有する構造上、予測トークンを生み出すコストとメインモデルによる検証コストの合計が、通常の1トークンずつ生成するよりも大きくなってしまう可能性があります。特にAcceptance Rate（トークン採用率）が70%を下回っている場合、MTPのオーバーヘッドが勝ってしまい、結果として低速化につながったと考えられます。
また、KV CacheをQ8_0からF16に変更しても速度面での改善は見られず、Acceptance Rateにも大きな変化はありませんでした。
意外なメリット：MTPは文章の品質が上がる！
速度面で残念な結果になった一方、文章の品質において発見がありました。
MTP版モデルの方が、文章が自然でまとまりが良いと感じる
Max Draft Tokensの変更（1→2→3）は文章品質にほぼ影響なし
つまり、「1トークンずつ生成するよりセットで予測した方が文脈の整合性が取れやすい」というMTP特有の性質が、iGPU環境では「速度向上」ではなく「出力の安定化・品質向上」として現れている可能性があります。
iGPU/CPU環境でMTPは本当に速くなるのか？
ここが一番のポイントですが、MTPがあなたの環境で実際にどの程度効果を発揮するかについては、意見が分かれています。
【速度向上する可能性がある見方】 MTPによるトークン採用率（予測がメインモデルに受け入れられる確率）が70％以上と高ければ、1.4倍から2倍の生成速度向上が見込めます。特に、iGPU環境ではVRAM確保のためにオフロード範囲を広げられ、CPU側の推論負荷を軽減できるため、MTPの恩恵が相対的に大きいという見方があります。また、プロンプト処理（最初の1文字目が出るまでの待ち時間）も高速化される傾向にあります。
【速度が下がってしまう可能性のある見方】 iGPUやCPU主体で推論を行う場合、MTPによって逆に生成速度が遅くなるリスクがあるとの報告もあります。その理由は、「予測トークンを生み出すコスト」と「メインモデルによる検証コスト」の合計が、通常の1トークンずつ生成するよりも大きくなってしまう可能性があるためです。特に、予測が外れて検証に失敗した際のリカバリ処理が重く、iGPU/CPU環境ではこのオーバーヘッドが顕著に出る可能性があります。
つまり、「MTP有効で速度が上がった」という報告と、「CPU/iGPUではむしろ遅くなった」という報告の両方が存在するため、実際に試してみない限りは断言できないのが正直なところです。
私の環境での実測結果は後者に寄り、MTP有効で10〜15%の低速化というデータが出ました。しかし、これはあくまでローカルLLMに最適化されていない環境での結果です。
iGPUの性能やdGPU、メモリ帯域幅の異なる環境では全く逆の結果が出る可能性が非常に高く、文章作成ではなくコード生成や論理的推論なら更に良好な結果が得られるかもしれませんし、微調整で改善する可能性もあります。
調整結果：MTPオンでも速度がほぼ互角に！
私の環境ではMTPで文章の品質が向上したため、このメリットを維持したまま速度を改善するために若干の調整を加えてみました。前述のテストではコンテキスト長を長めに設定していたためMTPのオーバーヘッドが顕著に出ましたが、コンテキスト長を65k→16384に絞り、GPUオフロード層数を16→30に設定してみました。
MTP OFF（通常モデル）：12.54 tok/s（これまでの最速記録）
MTP ON（Max Draft=2）：12.07 tok/s（Acceptance Rate 56.6%）
結果はこのとおり、MTP Max Draft=2の速度が10.99 tok/sから約10％向上し、通常モデルとの差が4%程度まで縮まりました。品質も安定しており、MTPでも実用上ほぼ互角のパフォーマンスが発揮できる状態になりました。
現在の設定のまとめと今後の微調整ポイント
現在の結果を踏まえると、私の環境では以下の設定であれば最小限の速度低下で出力文章の品質向上が得られそうです。
GPUオフロード層数：30
コンテキスト長：16384
MTP Max Draft Tokens：2
KV Cache量子化：F16（安定性優先）
Flash Attention：ON
以下の方向性を試すことで更に最適化が見込めるかもしれませんが、もともとの速度が遅いので、あまりこだわる必要もないかもしれません。
GPUオフロード層数を微増 / 微減させて推論負荷を調整する
コンテキスト長を12288まで下げて、処理速度のさらなる向上を試みる
同じプロンプトでMax Draft=1と2を比較し、速度と品質のバランスを探る
また、よりサイズの小さい量子化モデルを使えばベースの速度は向上するはずですが、出力品質との兼ね合いで現在のAPEX I-Balancedに落ち着いているので速度は諦めているという事情もあります。
今回は、環境や使い方に合わせた微調整次第で、あまり性能の高くないiGPUでも、ある程度はMTPの恩恵を受けられることがわかりました。最も期待されていた速度面の向上は得られませんでしたが、文脈の整合性や出力の安定性を考慮すると現在の設定バランスは悪くなさそうなので、しばらくこのまま使ってみたいと思います。