ローカルLLMを高速化する方法といえば、まず思いつくのは量子化です。
モデルを軽くする。
GPUへ多くオフロードする。
コンテキストを削る。
そして最後は、
もっと速いGPUを買う。
身も蓋もありません。
ところが最近、別の高速化手法が目立つようになってきました。
Speculative Decoding（投機的デコード／投機実行）です。
2026年8月28日に公開されたLM Studio 0.4.22では、DFlash、DSpark、MTPのassistant drafterがサポートされました。
LM Studio 0.4.22 Release Notes
私は以前、Qwen3.8-27BでMTPを試し、
約2.7 tok/s → 約7 tok/s
という劇的な高速化を確認しています。
ならば、新しく使えるようになったDSparkも試してみよう。
RTX 3060はまだ戦える。
そんな淡い期待を抱いて実験してみました。
結果から言います。
半分になりました。
未来を予測したら、未来を予測しない場合の半分の速度になったのです。
今回は、そんな悲喜交交の投機実行実験です。
LLMも「未来を先読み」する
LLMの生成は基本的に逐次処理です。
あるtokenを生成し、そのtokenを使って次を生成する。
今日は
↓
今日は天気
↓
今日は天気が
↓
今日は天気がいいこの繰り返しです。
巨大なLLMでは、この「次の1 token」を出すためだけに大量のパラメータを毎回読み出します。
だったら、
「どうせ次はこうなるだろう」と先に何tokenか予測しておけばいいのでは？
というのが投機的デコードの基本的な発想です。
llama.cppの説明でも、draft側が将来のtokenを提案し、本体モデルがそれらをまとめて評価することで、予測が十分当たれば逐次生成より高速化できるとされています。
概念的にはこうです。
普通
本体 → 1 → 2 → 3 → 4 → 5
投機実行
予測器 → [1, 2, 3, 4, 5]
↓
本体 → まとめて検証CPUに詳しい人なら、「投機実行」という言葉自体に既視感があるでしょう。
もちろんCPUのspeculative executionとLLMのspeculative decodingは同じ仕組みではありません。
ただし、
未来を予測して先回りすることで、逐次処理の待ち時間を減らす
という思想には、妙に似たところがあります。
Qwen3.8のMTPでは、本当に速くなった
私はすでにQwen3.8-27Bで投機実行の効果を体験しています。
使ったのはMTP（Multi-Token Prediction）です。
LM Studioでは対応モデルをロードすると、
- Off
- MTP
- Draft model
から投機方式を選択できます。
MTPはモデル自身が持つMulti-Token Prediction用の仕組みを利用して、将来の複数tokenを予測します。
私のRTX 3060 12GB環境では、Qwen3.8-27Bで、
| 設定 | 生成速度 |
|---|---|
| MTP OFF | 約2.7 tok/s |
| MTP ON | 約7 tok/s |
となりました。
約2.6倍です。
GPUを交換したわけではありません。
モデルを小さくしたわけでもありません。
生成方法を変えただけ。
RTX 3060で巨大モデルを動かしている身としては、これはかなり衝撃的でした。
「投機実行、すげえじゃん」
当然そう思います。
そしてLM Studio 0.4.22を見たら、今度はDFlashとDSparkにも対応したという。
試さない理由がありません。
DSparkは「本体専属の予言者」を横に置く
MTPとDSparkは、同じ投機実行でも仕組みが違います。
MTPでは、ざっくり言えば、
本体自身が未来を予測します。
一方、DSparkでは本体とは別に、未来のtokenを予測するための専用drafterを用意します。
私はLiquidAI公式の、
LFM2.5-2.6B
を本体として選びました。
そして同じくLiquidAI公式の、
LFM2.5-2.6B-DSpark-GGUF
をdrafterとして使用します。
LiquidAI LFM2.5-2.6B-DSpark-GGUF
このDSparkは、もう一つ完全な2.6Bモデルをロードするわけではありません。
LiquidAIの説明によれば、5つのattention layer、rank-256 Markov head、confidence headなどを持つstandalone draft sidecarです。token embeddingやLM headはロード時にtarget modelから共有されます。
今回使用したQ8_0版は約356MB。
つまり、
LFM2.5-2.6B
+
約356MBのDSpark
↓
未来のtokenを先読み
↓
本体が検証となります。
これならRTX 3060でもメモリ的には余裕です。
よし。
未来を予測してもらいましょう。
117.93 tok/s → 59.61 tok/s
まずDSparkなし。
結果は、
117.93 tok/s
でした。
ログにもきれいに出ています。
eval time = 7088.67 ms / 837 tokens
8.48 ms per token
117.93 tokens per secondLFM2.5-2.6Bは小さいモデルなので、RTX 3060でも十分高速です。
そしてDSparkを有効化。
同じ本体にDSparkをassistant drafterとして指定します。
結果。
59.61 tok/s。
……。
半分になりました。
ログはこちら。
eval time = 15500.26 ms / 925 tokens
16.78 ms per token
59.61 tokens per second見事なまでに遅くなっています。
追試もしました。
| モデル | 投機方式 | OFF | ON |
|---|---|---|---|
| Qwen3.8-27B | MTP | 約2.7 tok/s | 約7 tok/s |
| LFM2.5-2.6B | DSpark | 117.93 tok/s | 59.61 tok/s |
| LFM2.5-2.6B（追試） | DSpark | 約114 tok/s | 約66 tok/s |
Qwen3.8では約2.6倍。
LFM2.5では約0.5～0.6倍。
同じ「投機実行」という言葉からは想像しにくいほど、真逆の結果になりました。
何が起きているのでしょう。
436回予言して、当たったのは3回だった
答えはログに書いてありました。
draft acceptance = 0.00688
(3 accepted / 436 generated)
mean len = 1.01……3？
436 token提案して、採用されたのは3 tokenです。
Acceptance rateは、
0.688%。
ほぼ全滅です。
DSpark君は一生懸命、
「次はこれでしょう！」
と未来を予測している。
本体は、
違う。
次。
これでしょう！
違う。
今度こそ！
違う。
436回やって、3回当たりました。
これでは速くなるはずがありません。
未来を外すと「予測する仕事」だけが増える
ここまで来ると、投機実行の高速化原理が非常によく分かります。
DSparkを使うと、
DSparkで未来を予測
↓
本体モデルで検証
↓
当たったtokenを採用という処理が追加されます。
たくさん当たれば、本体モデルが1 tokenずつ生成する必要がなくなります。
予測コスト以上の計算を節約できる。
だから速くなる。
ところが今回のようにほとんど当たらないと、
DSparkで未来を予測
↓
本体モデルで検証
↓
外れ
↓
結局、本体が生成となります。
DSparkの仕事が、そのまま余計な計算として乗っかるわけです。
実際、今回のログでは、
8.48 ms/token → 16.78 ms/token
と、ほぼ2倍の処理時間になっています。
結果として、
117.93 tok/s → 59.61 tok/s
になった。
あまりにも理屈通りです。
だから「DSparkは遅い」とは言えない
ここは重要です。
今回の結果だけを見て、
「DSparkは使い物にならない」
と結論することはできません。
LiquidAIはDSparkについて、対応環境で大幅な高速化結果を公開しています。
また、投機的デコードの性能は単純なモデル性能だけでは決まりません。
モデルとdrafterの組み合わせ、量子化、バックエンド、GPU、実装、生成内容など、多くの要因が絡みます。
今回試したのは、
RTX 3060 12GB + Windows + LM Studio 0.4.22 + CUDA llama.cpp 2.31.2 + LiquidAI公式LFM2.5-2.6B + 公式DSpark Q8_0
という一つの環境に過ぎません。
さらにLM StudioのDFlash / DSpark assistant drafter対応自体、0.4.22で入ったばかりです。
今後のllama.cppやLM Studioの更新で結果が変わる可能性も十分あります。
ただし今回の環境では、
実際に遅くなった。
そしてログを見る限り、その直接的な原因は極端に低いdraft acceptanceでした。
この事実はそのまま残しておきます。
小さなモデルほど投機実行が有利とも限らない
もう一つ考えておきたいのが、今回の本体がLFM2.5-2.6Bだったことです。
DSparkなしでも、
約118 tok/s
出ています。
つまり、そもそも本体が猛烈に速い。
本体が1 token生成するコストが小さいなら、その処理を省略するために別のニューラルネットワークを走らせるメリットも相対的に小さくなります。
言ってしまえば、
予言者に聞いている暇があったら、自分で答えた方が早い。
一方、私のQwen3.8-27BはMTPなしで約2.7 tok/sでした。
1 tokenが非常に重い。
そこで複数tokenをうまく先読みできれば、その恩恵は大きくなります。
実際、MTPを有効化すると約7 tok/sまで高速化しました。
もちろんMTPとDSparkは方式が異なるため、この二つの実測だけからモデルサイズとの因果関係を断定することはできません。
それでも、
投機実行はONにすれば無条件に速くなるTurboボタンではない
ということだけは、今回かなりよく分かりました。
MTPとDSpark、同じ「投機実行」でも別物だった
今回触ってみて面白かったのは、投機実行にも複数のアプローチが存在することです。
現在のllama.cppには通常のdraft modelだけでなく、MTP、DFlash、DSpark、EAGLE-3、n-gramなど、複数のspeculative decoding方式があります。
llama.cpp Speculative Decoding documentation
大雑把に表現するなら、
MTP
本体自身に未来を予測させる。
通常のDraft Model
小さなLLMに下書きを作らせる。
DSpark
本体専用に訓練された小さな予測器に未来を読ませる。
目的は似ています。
しかし、未来の予測方法が違います。
そしてLM Studio 0.4.22では、こうした「未来予測器」をGUIから扱える範囲がさらに広がりました。
これはローカルLLMの高速化という観点では、かなり面白い進化だと思います。
投機実行の本質は「未来を当てること」
今回の実験は、期待したような結果にはなりませんでした。
Qwen3.8-27BのMTPでは、
2.7 → 7 tok/s。
大勝利です。
DSparkでは、
117.93 → 59.61 tok/s。
大敗です。
436回予測して3回しか採用されなければ、当然でしょう。
しかし、この失敗のおかげで投機実行という技術がずいぶん分かりやすくなりました。
重要なのは、
何token先まで予測できるかではない。
その予測を、
本体がどれだけ採用してくれるか。
投機実行は魔法ではありません。
未来を予測するにも計算資源が必要です。
そのコストを、的中した未来によって取り返せたときだけ高速化する。
だから、
未来を予測すれば速くなる。
そして、
未来を外せば、予測しない方が速い。
当たり前でした。
RTX 3060は今日も、身をもってコンピューター科学を教えてくれています。
追記：英語なら未来を当てられるのか？
公開後、日本語生成がDSparkの低いAcceptance Rateに影響している可能性を指摘されたため、英語でも追試した。
日本語では0.69%だったDraft Acceptanceが、英語では16.42%まで上昇した。生成速度も59.6 tok/sから70.4 tok/sへ改善した。
ただしDSparkなしの約114～118 tok/sには依然として届かず、Mean Draft Lengthも1.20に留まった。
この1回だけで言語差が原因とは断定できないが、DSparkの効果が生成内容によって大きく変化することを示す興味深い結果になった。
