llama.cpp の DFlash・DSpark・MTP を日本語で比べた — 投機的デコーディングで日本語の文章が速くなったのは MTP だけだった（Qwen3.8-27B・Gemma 4 26B・RTX 5060 Ti 16GB）
CONTENTS目次（10）
この記事の結論
- 日本語の文章で速くなったのは MTP だけだった。Qwen3.8-27B の生成（1 秒あたりのトークン数）が、手数 2 の MTP で 1.2〜1.3 倍になった。DFlash と DSpark は下書きの当たりが 6〜15% しかなく、先読みなしより遅くなった（0.64〜0.99 倍）。
- コードでは、どの方式も速くなった（1.3〜2.2 倍）。下書きの当たりは、コードのほうが日本語の文章より約 2〜5 倍高かった。DFlash はコードでは MTP と並ぶか上回った。
- MoE の Gemma 4 26B に MTP を足すと、日本語では 0.72〜0.75 倍に遅くなった。コードでも 1.05〜1.08 倍にとどまった。もともと速い MoE では、当たりが 2 割台だと下書きと確かめの手間のほうが大きくなるとみられる。
投機的デコーディング（speculative decoding）は、次の数トークンを安く「下書き」して、本体のモデルがまとめて確かめる仕組みです。下書きが当たった分だけ 1 回の計算で進むトークンが増え、確かめる工程があるので出力の傾向は変わりません（仕組みは ngram-mod の記事でも説明しています）。
llama.cpp では、下書きの作り方として MTP・DFlash・DSpark が使えます。公開元の数字では、DFlash や DSpark は 2.0〜3.4 倍の速さを出しています。ただしそれは、データセンター向けの GPU で、英語の数学・コード・会話の問題を、考える（思考あり）使い方で解かせたときの数字です。日本語の文章を、16GB の GPU で、考えずに書かせたときにどうなるかを測りました。数字は 2026年9月29日時点のものです。
3 つの方式
どれも「下書きを作って本体が確かめる」点は同じで、下書きの作り方が違います。1 回に下書きさせるトークンの数を、この記事では「手数」と呼びます（llama.cpp の --spec-draft-n-max）。
| 方式 | 下書きの作り方 | 今回使った下書き | 手数 |
|---|---|---|---|
| MTP | モデル自身に付いた小さな「先読みの頭」（Multi-Token Prediction）が、次の数トークンを下書きする | Qwen3.8-27B は GGUF の中に入っている頭をそのまま使う。Gemma 4 26B は unsloth が配る別ファイル（Q8_0・0.46GB） | 2・3（Gemma 4 は 4） |
| DFlash | 小さな下書きモデルが、本体の途中の計算結果（隠れ状態）を読みながら、数トークンのかたまり（ブロック）を 1 回の計算でまとめて作る | ggml-org が変換した Qwen3.8-27B 用（Q4_0・1.09GB。元は incoai の DFlash 2） | 7 |
| DSpark | DFlash のやり方に、直前のトークンに応じて各位置の予測を補正する「マルコフの頭」を足したもの | magnitudedev が変換した Qwen3.8-27B 用（Q8_0・1.46GB。元は RadixArk の DSpark） | 7 |
仕組みの説明は llama.cpp の投機的デコーディングの説明と、各下書きモデルの公開ページによる。DFlash と DSpark の手数は、下書きモデルのブロックの大きさに合わせた。
Qwen3.8 の MTP の正しい付け方（MTP の層が入った GGUF に、別ファイルの MTP を重ねない）と、Ollama での設定は Qwen3.8 の MTP の記事にまとめています。この記事の測定は、どれも llama.cpp の llama-server を直接使いました。
測った環境
| 項目 | 内容 |
|---|---|
| GPU | GeForce RTX 5060 Ti 16GB（電力の上限 180W） |
| CPU・メモリ | Core i5-12400F・DDR4-3200 32GB |
| OS・ドライバ | Windows 11・NVIDIA ドライバ 610.47 |
| llama.cpp | b11193（公式の Windows 向け CUDA 13.4 版）の llama-server |
| 本体（密なモデル） | Qwen3.8-27B。unsloth の UD-Q3_K_XL（13.15GB）と、一回り小さい UD-IQ3_XXS（10.93GB）。どちらも MTP の頭が入っている。-ngl 99 --fit off（全部 GPU）・-fa on -ctk q8_0 -ctv q8_0 -b 512 -ub 512・文脈 8K と 16K |
| 本体（MoE） | Gemma 4 26B-A4B（Ollama の gemma4:26b-a4b-it-qat の GGUF・14.4GB）。1 トークンの計算に使うのは約 4B。置き場所は llama.cpp の自動・-fa on -ctk q8_0 -ctv q8_0 -b 512 -ub 512・文脈 8K |
| サンプリング | 各モデルの推奨値。Qwen3.8 は考えない使い方の値（温度 0.7・top_p 0.8・top_k 20・presence_penalty 1.5）、Gemma 4 は温度 1.0・top_p 0.95・top_k 64。どちらも思考なし |
| 問い | 日本語: 日本語の記事の本文を渡し、「続きを同じ調子で書いて」と頼む。コード: 日本語の参考資料のあとに、「CSV の銀行明細を集計する Python のモジュールを、型ヒント・docstring・pytest のテストつきで書いて」と頼む。入力は約 1,500〜2,200 トークン。出力はどちらも 512 トークンで打ち切り、別の文章で 2 回ずつ |
結果 1: Qwen3.8-27B（UD-Q3_K_XL）
| 方式 | 日本語 文脈 8K | 日本語 文脈 16K | コード 文脈 16K | VRAM 8K／16K |
|---|---|---|---|---|
| 先読みなし | 27.5 | 27.5 | 27.5 | 12,865 13,131 |
| MTP 手数 2 | 35.4〜35.6 ×1.29 | 35.2〜36.7 ×1.28〜1.33 | 48.3〜49.0 ×1.75〜1.78 | 13,659 13,941 |
| MTP 手数 3 | 35.3〜35.7 ×1.28〜1.30 | 32.3〜38.1 ×1.17〜1.38 | 52.2〜52.6 ×1.90〜1.91 | 13,809 14,091 |
| DFlash 手数 7 | 25.8〜27.0 ×0.94〜0.98 | 25.0〜27.1 ×0.91〜0.99 | 52.8〜55.1 ×1.92〜2.00 | 15,543 15,809 |
| DSpark 手数 7 | 起動せず | 起動せず | 起動せず | — |
生成の tok/s（2 回の範囲）。2 行目の × は、同じ問いの先読みなしとの比。VRAM は起動直後の GPU 全体の使用量（MiB・画面表示の分を含む。上が文脈 8K、下が 16K）。2026年9月29日に測定。
- 日本語で速くなったのは MTP だけでした。手数 2 と 3 はほぼ同じ速さで、手数 3 は回によるぶれが大きくなりました（1.17〜1.38 倍）
- DFlash は、日本語では先読みなしより少し遅く（0.91〜0.99 倍）、コードでは MTP と並びました（1.92〜2.00 倍）
- DSpark は、下書き側の作業領域を確保できず、文脈 8K でも起動しませんでした（下の注意を参照）
結果 2: 一回り小さい UD-IQ3_XXS では 5 つとも動いた
本体を UD-IQ3_XXS（10.93GB）に替えて VRAM を空け、DSpark も同じ条件で比べました。
| 方式 | 日本語 文脈 8K | 日本語 文脈 16K | コード 文脈 16K | VRAM 8K／16K |
|---|---|---|---|---|
| 先読みなし | 30.6〜30.7 | 30.6〜30.7 | 30.6〜30.7 | 10,744 11,046 |
| MTP 手数 2 | 37.6〜38.8 ×1.22〜1.27 | 38.8〜40.3 ×1.27〜1.31 | 51.4〜54.2 ×1.68〜1.77 | 11,538 11,856 |
| MTP 手数 3 | 35.6〜37.7 ×1.16〜1.23 | 34.4〜37.0 ×1.12〜1.21 | 54.3〜54.6 ×1.77〜1.79 | 11,688 12,006 |
| DFlash 手数 7 | 24.7〜25.3 ×0.80〜0.83 | 26.4〜28.6 ×0.86〜0.93 | 52.5〜66.0 ×1.71〜2.16 | 13,422 13,724 |
| DSpark 手数 7 | 19.7〜20.6 ×0.64〜0.67 | 19.6〜20.3 ×0.64〜0.66 | 40.0〜50.2 ×1.30〜1.64 | 14,318 14,780 |
見方は結果 1 と同じ。2026年9月29日に測定。
- 本体が小さい分、先読みなしでも 30.6〜30.7 tok/s と 1 割ほど速くなりました
- 並びは結果 1 と同じです。日本語では MTP だけが速く、DFlash は 0.80〜0.93 倍、DSpark は 0.64〜0.67 倍に遅くなりました
- コードでは、DFlash が 2.16 倍と最も速い回がありました。DSpark は 1.30〜1.64 倍で、MTP と DFlash には届きませんでした
下書きの当たり（採用率）
速さの差は、下書きの当たり（下書きしたトークンのうち、本体が採用した割合）でほぼ説明できます。
| 方式 | 日本語の文章 | コード |
|---|---|---|
| MTP 手数 2 | 42〜49% | 79〜87% |
| MTP 手数 3 | 29〜41% | 71〜73% |
| DFlash 手数 7 | 11〜15% | 41〜57% |
| DSpark 手数 7 | 6〜7% | 29〜40% |
llama-server が返す下書きの数と採用された数から計算。結果 1・2 の両方の本体・文脈の範囲（DSpark のコードは UD-IQ3_XXS だけ）。2026年9月29日に測定。
- 日本語の文章では、DFlash と DSpark の下書きは 7 つのうち 1 つ当たるかどうかでした。毎回 7 トークン分を作って確かめる手間を、当たりで取り返せていません
- MTP は手数が少ない（2〜3）ので外れたときの損が小さく、日本語でも 3〜5 割の当たりで元が取れています
- コードでは、どの方式も当たりが日本語の約 2〜5 倍になりました。書き方の決まった部分（構文や、同じ名前の繰り返し）が多く、次のトークンを予測しやすいためとみられます
結果 3: MoE の Gemma 4 26B に MTP を足すと遅くなった
| 問い | 先読みなし | MTP 手数 4 | 比 | 当たり |
|---|---|---|---|---|
| 日本語の文章 | 99.0〜99.2 | 71.1〜74.2 | ×0.72〜0.75 | 20〜21% |
| コード | 99.2〜99.3 | 104.3〜106.9 | ×1.05〜1.08 | 44〜45% |
生成の tok/s（2 回の範囲）。文脈 8K・置き場所は自動。VRAM は起動直後で 14,731 → 15,245MiB。2026年9月29日に測定。
日本語では 0.72〜0.75 倍に遅くなり、コードでも 1.05〜1.08 倍にとどまりました。下書きを配る unsloth は、B200 と UD-Q4_K_M の本体で 159 → 257 tok/s（当たり 0.72）と公表していますが、今回の当たりは日本語で 2 割、コードで 4 割台でした。
Gemma 4 26B は、1 トークンの計算に使う重みが約 4B と少なく、先読みなしでも 99 tok/s 出ます。1 トークンが安いぶん、下書きを作って確かめる手間の割合が大きくなり、当たりが低いと元が取れないとみられます。MoE では確かめるトークンごとに別の専門家（重みの一部）を読むので、まとめて確かめる手間が密なモデルより大きいことも、遅くなった一因かもしれません（確かめていません）。
なぜ日本語の文章で当たらないのか（見立て）
- 測った問いは「続きを自由に書く」もので、次の言葉の選び方の幅が広く、コードのような決まった形が少ない
- DFlash と DSpark の公開元の評価は、英語の数学・コード・会話の問題で、思考ありの使い方でした。学習に使ったデータの言語は公開ページからは確かめられませんでしたが、日本語の文章が得意な範囲から外れている可能性があります（未確認）
- 今回の本体は 3 ビット台に量子化した版で、下書きモデルが合わせた元の重み（BF16・FP8 など）とは少し違う計算をします。これも当たりを下げる方向に働きうる（未確認）
- 英語の文章は測っていないので、「日本語だから」当たらないのか、「自由に書く文章だから」当たらないのかは、この測定では分けられません
使い分けの目安（16GB の GPU・日本語の場合）
- 密なモデル（Qwen3.8-27B）で日本語の文章を書かせるなら、本体に入っている MTP の手数 2。追加のファイルは要らず、VRAM も約 800MiB 増えるだけ
- コードが中心なら、MTP の手数 3 か DFlash。DFlash は VRAM を約 2,700MiB 余分に使う
- DSpark は、今回の組み合わせでは日本語・コードとも MTP を上回らなかった（VRAM は約 3,600MiB 増える）
- MoE（Gemma 4 26B）では、日本語の文章に MTP を付けない
DSpark が起動しないとき
UD-Q3_K_XL（13.15GB）と DSpark の下書き（1.46GB）を組み合わせると、既定の -ub 512 では、下書き側の作業領域（991MiB）を確保できずに起動しませんでした（cudaMalloc failed: out of memory）。-b 256 -ub 256 にすると文脈 8K で起動し（VRAM 15,754MiB）、日本語の文章は 20.3〜20.6 tok/s でした。同じ設定の先読みなし（27.5 tok/s）の 0.74〜0.75 倍で、当たりは 7% です。入力 2K トークンの読み込みの速さは、-ub 256 でもほぼ同じでした（792〜857 tok/s。-ub 512 は 794〜865 tok/s）。
MoE に DFlash を足そうとして、同じように作業領域が入らなかった例は Ollama と llama.cpp の速度の記事に書いています。
測っていないこと
- 英語の文章と、日本語の要約・翻訳・書き直しのように入力を写す部分がある使い方
- 思考ありの使い方（公開元の評価は思考あり）と、出力が 512 トークンより長い場合
- 量子化していない本体（BF16・FP8）と、公開元が使った SGLang・vLLM などの実行環境
- DFlash・DSpark の手数を 7 から変えた場合と、確信度の低い下書きを打ち切る設定（DSpark の
--spec-draft-conf-min） - 各条件は 2 回ずつなので、1 割前後の差は偶然の範囲かもしれない
まとめ
- 日本語の文章で速くなったのは MTP だけ（Qwen3.8-27B で 1.2〜1.3 倍・RTX 5060 Ti・2026年9月29日時点）
- DFlash と DSpark は、日本語の文章では下書きの当たりが 6〜15% で、先読みなしより遅くなった（0.64〜0.99 倍）
- コードでは、どの方式も速くなった（1.3〜2.2 倍）。公開元の 2.0〜3.4 倍は、英語の数学・コード・会話を思考ありで解かせたときの数字
- MoE の Gemma 4 26B では、MTP が日本語で逆効果だった（0.72〜0.75 倍）
出典
- llama.cpp の投機的デコーディングの説明（DFlash・DSpark・MTP の仕組み）: https://github.com/ggml-org/llama.cpp/blob/master/docs/speculative.md
- Qwen3.8-27B（Hugging Face・推奨のサンプリング）: https://huggingface.co/Qwen/Qwen3.8-27B
- Qwen3.8-27B の GGUF（unsloth・UD-Q3_K_XL と UD-IQ3_XXS）: https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
- DFlash の下書き（ggml-org の GGUF）: https://huggingface.co/ggml-org/Qwen3.8-27B-GGUF
- DFlash 2 の元のモデルと公開元の評価: https://huggingface.co/incoai/Qwen3.8-27B-DFlash2
- DSpark の下書き（magnitudedev の GGUF）: https://huggingface.co/magnitudedev/Qwen3.8-27B-DSpark-GGUF
- DSpark の元のモデルと公開元の評価: https://huggingface.co/RadixArk/Qwen3.8-27B-DSpark
- Gemma 4 26B-A4B の MTP の下書き（unsloth）: https://huggingface.co/unsloth/gemma-4-26B-A4B-it-GGUF
- Gemma 4 26B-A4B（推奨のサンプリング）: https://huggingface.co/google/gemma-4-26B-A4B-it
この記事は、手元の機材で行った測定をもとにした一般的な技術情報の提供を目的としており、特定の製品・ソフトウェアの購入や利用を推奨・勧誘するものではありません。数値は 2026年9月29日時点の測定で、モデル・ソフトの版・設定・機材によって変わることがあります。