llama.cppのMTP対応でQwen3.6の推論速度が2倍超に

ローカルLLMの推論速度がボトルネックになっていませんか。同じハードウェアのまま2倍以上速くなる可能性が、llama.cpp の新しいプルリクエストで現実になりつつあります。

2026年5月4日、llama.cppに「MTP（Multi-Token Prediction）サポート」を追加するプルリクエスト #22673 がオープンされました。Qwen3.6-27Bでの実測では、7 tok/s だった推論速度が最大21 tok/s 超へ——約2.5倍の高速化が確認されています。

この記事でわかること

MTPとは何か、従来の推論と何が違うのか
llama.cpp PR #22673 の実測データ
有効化の方法と必要な GGUF の入手先
現時点での制限と注意点

https://github.com/ggml-org/llama.cpp/pull/22673

従来の推論が遅い理由

通常のLLM推論は「次トークン予測（NTP: Next-Token Prediction）」という逐次処理で動きます。1つのトークンを生成し、それを入力に戻してまた1トークン生成する——この繰り返しが速度の上限を決めます。どれだけ高速なGPUを使っても、この直列構造は変わりません。

MTP（Multi-Token Prediction）はこの制約を回避する手法です。モデルが持つ「MTPヘッド」と呼ばれる追加の小さな予測器を使い、複数のトークン候補を先読みします。メインモデルが最終的に承認・棄却を判断するため、出力品質を維持したまま処理を並列化できます。スペキュラティブデコーディングの一種ですが、外部ドラフトモデルを別途用意する必要がないのが特徴です。

PR #22673 の概要と実測値

作者の am17an 氏は Qwen3.6-27B（Q8_0）を DGX Spark 上でベンチマークし、以下の結果を公開しています。

MTPなし（ベースライン）

9つの代表的なプロンプト（コード生成、概念説明、要約、翻訳など）を処理した合計時間は201秒。平均 7.0〜7.7 tok/s でした。

MTP有効（ドラフトトークン数3）

同じ条件で処理時間は83.8秒に短縮。tok/s は 13.9〜21.6 まで伸びました。ドラフトトークンの承認率は平均72%で、これは「3トークン先読みして2つ以上が正解」という高い精度を示しています。

コード生成タスクでは承認率が90%を超えており、21.6 tok/s という最高値を記録しています。翻訳など文の多様性が高いタスクでは承認率が54%程度まで下がりますが、それでもベースラインの2倍近い速度が出ています。

MTPヘッドの仕組みと特徴

このPRの設計で注目すべき点は、MTPヘッドをメインモデルと同じGGUFファイルから読み込む構造です。ドラフトモデルを別途ダウンロードする必要がなく、--spec-type mtp フラグ1つで有効化できます。

MTPヘッドが使う追加メモリは全体の10%未満です（単一の変換器レイヤーとKVキャッシュのみ）。Qwen3.5-0.8B のようなドラフトモデルを使う方法と比べると、軽量で運用しやすいのがメリットです。

使い方

am17an氏がHugging Faceで公開しているGGUFファイル（am17an/Qwen3.6-27B-MTP-GGUF）を使います。

./llama-server \
  -m qwen3.6-q8_0-mtp.gguf \
  --spec-type mtp \
  --spec-draft-n-max 3 \
  --chat-template-kwargs '{"preserve_thinking": true}'

--spec-draft-n-max はドラフトトークン数で、3が現時点の推奨値です。2に下げると承認率は約83%まで上がりますが、速度はやや落ちます（avg 15〜16 tok/s）。タスクの性質に応じて調整してください。

現時点での制限

このPRは執筆時点でドラフト状態であり、llama.cpp 本体への正式マージはまだ行われていません。使用にあたって以下の制限を把握しておく必要があります。

CUDAバックエンド以外は動作が不安定です。Vulkanバックエンドで試したユーザーから文字化けが報告されており、am17an氏も「現時点ではCUDAのみで検証済み」と明言しています。

ビジョン（画像入力）とMTPを同時に使うとllama-serverがクラッシュします。マルチモーダル用途には --spec-type mtp を外して起動する必要があります。

4bit量子化（Q4_K_M）を使う場合、HumanEvalなどのコーディングベンチマークでBF16比5ポイント程度の精度低下が報告されています（参考）。速度優先か精度優先かによってQ8_0とQ4_K_Mを使い分けるとよいでしょう。

llama.cppにとっての意義

従来、llama.cppでの高速化にはドラフトモデルを別途用意するEAGLEやngram補完が使われてきました。MTPはモデル側に予測ヘッドが組み込まれているため、別モデルのダウンロードや管理が不要です。Qwen3.6-27Bはこのアーキテクチャをネイティブに持つ数少ないオープンモデルの一つです。

llama.cppのコントリビューターである pwilkin 氏は「vLLMとのトークン生成速度の差を大幅に埋め、テンソル並列と組み合わせれば超える可能性もある」とコメントしており、ローカル推論の実用性をクラウドと競争できる水準に引き上げる技術として注目が集まっています。

マージのレビューはggerganov氏を含む2名の承認が必要で、現在審査中です。正式マージ後はllama.cpp標準の機能として利用できるようになります。ローカルLLMの速度制約を感じているなら、このPRとQwen3.6-27BのGGUFは今すぐ試す価値があります。