Multi-Token Prediction Tutorial: How To Speed Up LLMs

Run Qwen3.6 27B on an RTX 3090 and learn how Multi-Token Prediction (MTP) with llama.cpp can boost local LLM inference by almost 2x without upgrading your GPU.

更新 2026年5月14日 · 9 分読む

GPU をアップグレードしたり、マシンを変えたり、小さいモデルに切り替えたりせずに、大規模言語モデルをもっと速く動かせるとしたらどうでしょうか？

本ガイドでは、マルチトークン予測（MTP）を使ってそれを検証します。私のベンチマークでは、同じ RunPod の RTX 3090 環境で同じ Qwen3.6 27B モデルが、MTP を有効化しただけで1 秒あたり 38 トークンから 65 トークンへと向上しました。つまり1.71 倍の高速化（約 71% のスループット向上）で、出力品質の目に見える低下はありませんでした。

本ガイドでは次の内容を行います。

RunPod の RTX 3090 マシンをセットアップする
MTP ブランチをクローンして切り替える
CUDA 対応で llama.cpp をビルドする
Qwen3.6 27B MTP GGUF モデルをダウンロードする
MTP なしでモデルを実行し、ベースライン速度を取得する
MTP を有効化して再度モデルをテストする
MTP あり・なしでのトークン生成速度を比較する
さらなる最適化の次の一手として TurboQuant を検討する

マルチトークン予測（MTP）とは？

多くの LLM はテキストを 1 トークンずつ生成します。モデルは次のトークンを予測し、文脈に追加し、同じ処理を繰り返します。これは堅実ですが、新しいトークンごとに通常は別のデコード工程が必要になるため、遅くなることがあります。

マルチトークン予測は、1 つだけでなく複数の将来トークンを先読みして提案できるようにすることで、これを変えます。提案されたトークンはメインのデコード処理で検証され、正しければ一度に複数のトークンを受け入れられます。途中で不一致があれば、その時点から通常の経路にフォールバックします。

実際には、MTP はビルトインの下書きメカニズムのように機能します。モデルはいくつかの尤もらしい次トークンを下書きし、検証して、有効なものを採用します。受け入れられる下書きトークンが多いほど、必要なフルデコード工程が少なくなり、最終的な出力品質を変えずに 1 秒あたりのトークン数を増やせます。

簡単に言うと、

MTP なし: トークン1を生成 → トークン2を生成 → トークン3を生成
MTP あり: 複数トークンを下書き → 検証 → 有効なトークンをまとめて採用

このため、MTP はローカル LLM の推論を体感的に大幅に速くします。モデルを一歩ずつしか進められないようにするのではなく、下書き予測が正しければ安全に先へジャンプできるようにするからです。

例えば llama.cpp や vLLM 風の実装では、これは投機的デコーディングに密接に関連しており、下書きトークンは検証器の出力と一致したときにのみ受け入れられます。

1. RunPod の RTX 3090 マシンをセットアップする

本ガイドでは、RTX 3090 を搭載した RunPod の GPU インスタンスを使用しました。別の CUDA 対応 GPU でも構いませんが、本チュートリアルのベンチマーク結果は RTX 3090 構成に基づいています。

まず、新しい RunPod の Pod を作成し、RTX 3090 GPU を選択します。

Pod をデプロイする前に、テンプレート設定を編集します。

ボリュームディスクサイズを 100 GB に増やす
HTTP ポートを追加する：8910
HF_TOKEN という環境変数を追加し、Hugging Face のアクセストークンを値として設定する

追加の HTTP ポートにより、ブラウザから llama.cpp のサーバーと Web UI にアクセスできるようになります。Hugging Face のトークンはダウンロード要求の認証に役立ち、特に大きな GGUF ファイルのモデルではダウンロード速度の向上につながります。

テンプレートを更新したら Pod をデプロイします。起動後、RunPod から JupyterLab インスタンスへのアクセスが提供されるまで待ちます。JupyterLab を開き、新しいターミナルを起動してください。

ターミナル内で、必要なシステムパッケージをインストールします。

apt update
apt install -y git cmake build-essential curl wget python3-pip

2. MTP ブランチをクローンして切り替える

次に、llama.cpp をインストール・ビルドする作業用ディレクトリに移動します。

cd /workspace

llama.cpp リポジトリをクローンします。

git clone --depth 1 https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

MTP の変更は専用の llama.cpp プルリクエストでまだテスト中のため、標準の main に取り込まれる前に最新の MTP 実装を使えるよう、そのブランチを取得して切り替えます。

MTP ブランチをローカルに取得します。

git fetch origin pull/22673/head:mtp-pr
git checkout mtp-pr

これでローカルの llama.cpp ビルドが MTP 対応版に切り替わり、以降の手順で使用します。

3. CUDA 対応で llama.cpp をビルドする

MTP 対応ブランチにいるので、CUDA 対応で llama.cpp をビルドします。これにより、推論を CPU ではなく RTX 3090 の GPU で実行できます。

CMake のビルド設定を実行します。

cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release

次に、このガイドで必要な 2 つのターゲットをコンパイルします。

cmake --build build --target llama-cli llama-server -j

これにより以下がビルドされます。

llama-cli：コマンドラインでの簡易テスト用
llama-server：ブラウザアクセス可能な OpenAI 互換サーバーの起動用

ビルドが完了したら、llama-server バイナリを llama.cpp のルートディレクトリにコピーします。

cp ./build/bin/llama-server ./llama-server

これで、次の手順でプロジェクトルートからサーバーを起動しやすくなります。

4. Qwen3.6-27B-MTP モデルをダウンロードする

次に、テストに使用する Qwen3.6 27B MTP GGUF モデルをダウンロードします。まずは MTP なしで実行し、その後 MTP を有効にして速度差を比較します。

まず、Hugging Face のダウンロードツールをインストールします。

pip install -U "huggingface_hub[hf_xet]" hf-xet hf_transfer

次に、Hugging Face の高速ダウンロードを有効化します。

export HF_HUB_ENABLE_HF_TRANSFER=1

これは特に GGUF ファイルなど大きなモデルのダウンロードを高速化するのに役立ちます。

モデル用の専用ディレクトリを作成します。

mkdir -p /workspace/models/qwen3.6-mtp

Qwen3.6 27B MTP GGUF モデルをダウンロードします。

hf download froggeric/Qwen3.6-27B-MTP-GGUF \
 Qwen3.6-27B-Q4_K_M-mtp.gguf \
 --local-dir /workspace/models/qwen3.6-mtp

LLM の微調整に興味があれば、医療系 Q&A データセットで Qwen3.6 を微調整するチュートリアルもご覧ください。

5. MTP を無効のまま Qwen3.6-27B を実行する

ここからが本題です。MTP の有効化前後でモデルの速度を比較します。

まずは MTP なしでモデルを実行します。これにより、後で速度差を比較するためのクリーンなベースラインが得られます。同じモデル、同じ GPU、同じコンテキストサイズ、同じサーバー設定を使用し、次の手順での主な変更点は MTP の有効化だけです。

llama.cpp ディレクトリに戻ります。

cd /workspace/llama.cpp

MTP なしでサーバーを起動します。

./llama-server \
-m "/workspace/models/qwen3.6-mtp/Qwen3.6-27B-Q4_K_M-mtp.gguf" \
--alias qwen3.6-27b-no-mtp \
--host 0.0.0.0 \
--port 8910 \
-ngl 99 \
-c 100000 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-b 2048 \
-ub 512 \
-t 8 \
-fa on \
--temp 0.7 \
--top-k 20 \
--top-p 0.95 \
--repeat-penalty 1.1 \
--metrics

これでポート 8910 上で OpenAI 互換の llama.cpp サーバーが起動します。

サーバーはモデルの重みを GPU メモリに読み込む必要があるため、ロードに少し時間がかかる場合があります。準備が整うと、ターミナルにポート 8910 でサーバーが利用可能になった旨が表示されます。

RunPod のテンプレート設定時にこのポートを公開しているため、追加の設定は不要です。RunPod のダッシュボードに戻り、ポート 8910 に対応するリンクをクリックしてください。これにより、ブラウザでllama.cpp の Web UI が開き、ローカルモデルが読み込まれた状態になります。

ここから、チャットインターフェースのようにブラウザ上で直接プロンプトのテストを開始できます。

ベースラインテストでは、MTP なしで応答生成速度は約 38.86 トークン/秒でした。より複雑なプロンプトでも、速度は同程度の範囲に収まりました。

RTX 3090 上で 27B モデルを動かすには、これはすでに実用的な結果です。特に、この GPU は新しいデータセンター向けカードに比べて遅く、メモリも限られていることを考えると妥当です。

6. MTP を有効化して Qwen3.6-27B を実行する

次に、同じモデルを MTP を有効にして再度実行します。

サーバーを実行中のターミナルに戻り、以下で停止します。

CTRL + C

重要なのは、モデル、GPU、量子化、その他の実行時設定の大半は変更しないことです。追加するのは MTP 関連の 2 つのフラグだけです。

--spec-type mtp
--spec-draft-n-max 3

最初のフラグは、llama.cpp に MTP 方式の投機的デコーディングを使うよう指示します。2 つ目は下書きトークンの最大数を 3 に設定します。つまり、検証前に最大 3 個の将来トークンを下書きできるという意味です。

では、MTP を有効にしてサーバーを再起動します。

./llama-server \
-m "/workspace/models/qwen3.6-mtp/Qwen3.6-27B-Q4_K_M-mtp.gguf" \
--alias qwen3.6-27b-mtp \
--host 0.0.0.0 \
--port 8910 \
-ngl 99 \
-c 100000 \
--spec-type mtp \
--spec-draft-n-max 3 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-b 2048 \
-ub 512 \
-t 8 \
-fa on \
--temp 0.7 \
--top-k 20 \
--top-p 0.95 \
--repeat-penalty 1.1 \
--metrics

サーバーの準備ができたらブラウザをリロードしてください。自動再接続しない場合は、RunPod のダッシュボードから再度ポート 8910 のリンクを開き直します。

同じタイプのプロンプトで再度モデルをテストします。

MTP を有効にすると、速度は明らかに向上しました。単純な挨拶プロンプトでは、約 65～67 トークン/秒に達しました。ベースラインの約 38.86 トークン/秒と比べると、コマンドラインフラグを 2 つ追加しただけで大幅な改善です。

Python で簡単なゲームを作るように頼むなど、より複雑なプロンプトではやや遅くなりましたが、それでも非 MTP のベースラインよりかなり高速でした。このテストでは約 56～61 トークン/秒を記録し、RTX 3090 上の 27B モデルとしては十分に強力な結果です。

総合すると、RunPod の RTX 3090 環境で Qwen3.6 27B は、MTP の有効化により約 38 トークン/秒から 65 トークン/秒に改善しました。これは 1.71 倍の高速化（約 71% のスループット向上）で、ハードウェアを変えたり小さいモデルに切り替えたりする必要はありませんでした。

7. 推奨：TurboQuant でさらなる高速化

本ガイドのベンチマークは、TurboQuant やカスタムパッチ、その他の実行時最適化を加えず、llama.cpp の素の MTP 設定のみを使用しています。これにより、テストはシンプルで再現性が高く、MTP の有効化そのものによる速度向上に焦点を当てられます。

さらなる性能向上を目指すなら、次に検討すべきは MTP と TurboQuant の併用です。MTP は複数の予測トークンを受け入れることでスループットを改善し、TurboQuant は推論中の KV キャッシュのメモリ負荷を軽減します。

これは、より大きなモデルや長いコンテキストのプロンプト、そしてメモリ帯域や VRAM がボトルネックになりやすい RTX 3090 のような GPU で特に有効です。

このため、r/LocalLLaMA コミュニティの一部の結果では本ガイドより高いトークン/秒が報告されています。そうした環境では、MTP に加えて TurboQuant、パッチ適用ビルド、異なる KV キャッシュ設定、あるいはより高速な GPU を組み合わせていることが多いからです。本チュートリアルは MTP のみのクリーンなベンチマークに焦点を当てているため、TurboQuant は現行セットアップの一部ではなく、推奨される次の実験と捉えてください。

まとめ

最近、LocalLLaMA の Reddit コミュニティを追っているのですが、ローカル LLM 推論がここまで進化したのは本当に驚きです。人々は Qwen3.6 27B のようなモデルを、VRAM が限られた古い GPU でもローカルのコーディングエージェントとして動かしています。Mac で似た構成を動かしている人もおり、その結果は実に印象的です。

自分で MTP を試してみて、盛り上がりの理由が分かりました。同じモデル・同じ RTX 3090 構成で、マルチトークン予測を有効にするだけで生成速度は約 38 トークン/秒から 65 トークン/秒に向上しました。GPU をアップグレードしたり小さいモデルに変えたりせずに、ほぼ 2 倍の高速化です。

本ガイドは llama.cpp を用いたシンプルで再現性の高い MTP 構成に絞りましたが、これは始まりに過ぎません。次は、より良い GGUF 量子化や MTP、TurboQuant、さらに調整された実行時設定を組み合わせ、ローカル推論速度をどこまで伸ばせるか検証してみてください。

とりわけワクワクするのは、これがローカルのコーディングエージェントにもたらす意味です。自分のハードウェアで強力なモデルを動かし、問い合わせあたりのコストを下げ、コードをプライベートに保ち、インターネット経由の API に全面的に依存せずに AI コーディングアシスタントを使えるのです。ローカル LLM は、以前に比べて格段に速く、実用的で、役に立つ存在になりつつあります。