投機的デコーディング実践：DeepSeek DSpark / DFlash / Eagle3 でローカル推論を高速化
投機的デコーディング実践
ローカル推論で最も体感しやすいボトルネックは「生成が遅い」ことです。量子化はモデルを VRAM に収めるための手段であり、投機的デコーディング（speculative decoding）はモデルを変えずに生成待ちを減らす手段です。DeepSeek は HuggingFace で DSpark・DFlash・Eagle3 の 3 シリーズを公開し、自社 V4 モデルに加えて Qwen3 や Gemma4 といった他社ベースもカバーしています。本記事では原理、既製の草稿モデル、設定の考え方、有効な場面を整理します。
30 秒でわかる要点
投機的デコーディング ＝ 小モデルが複数トークンを草稿 → 大モデルが 1 回の並列検証で確認 → 採用された接頭辞をそのまま利用。採用される各トークンは大モデル自身が確認しているため、出力分布は変わりません。DeepSeek の DSpark / DFlash / Eagle3 は公式公開の草稿モデルなので、自分で草稿モデルを訓練する前にまずこれを試すのが得策です。
原理：なぜ速く、なぜ結果が変わらないのか
自己回帰生成は逐次的です。N 番目のトークンを出すには N-1 番目の完了を待つ必要があり、GPU は一度に 1 トークンしか計算できず計算資源の多くが遊んでいます。投機的デコーディングの考え方：
- はるかに小さい「草稿モデル」が後続トークンを複数、安価に連続予測
- その候補を大模型にまとめて渡し並列検証（1 回の順伝播で複数位置を確認、計算利用率が上がる）
- 大模型が同意した接頭辞を採用、最初に不一致が出た位置から草稿をやり直し
要点は検証工程です。採用されるトークンはすべて大模型が確認したものなので、最終出力は非加速時と同一。これは「モデルを雑にする」ことではなく、「同じ計算をより少ない待ち時間で行う」ことです。出力分布が不変であることが、「より小さいモデルに切り替える」のとの根本的な違いです。
量子化との違い
量子化が削るのはモデルサイズと VRAM（Q4 は FP16 の約 3 分の 1）、投機的デコーディングが削るのは生成待ち時間。作用する次元が異なるため併用できます。量子化済みモデルにそのまま投機的デコーディングを重ねられます。
DeepSeek が公開した配套
HuggingFace の deepseek-ai 組織が 2026-06-27/28 に公開した情報に基づきます（ダウンロード数は採取時の参考値、最新は各モデルカードを参照してください）。
| シリーズ | 代表リポジトリ | 対象ベース | DL 参考 |
|---|---|---|---|
| DSpark (V4) | DeepSeek-V4-Flash-DSpark | DeepSeek V4-Flash | 約 12.8 万 |
| DSpark (V4) | DeepSeek-V4-Pro-DSpark | DeepSeek V4-Pro | 約 2.1 千 |
| DSpark (汎用) | dspark_qwen3_8b_block7 | Qwen3-8B | 約 2.2 万 |
| DSpark (汎用) | dspark_qwen3_14b/4b_block7、dspark_gemma4_12b_block7 | Qwen3-14B/4B、Gemma4-12B | 数千 |
| DFlash | dflash_qwen3_4b/8b/14b_block7、dflash_gemma4_12b_block7 | Qwen3、Gemma4 | 数百〜数千 |
| Eagle3 | eagle3_qwen3_4b/8b/14b_ttt7、eagle3_gemma4_12b_ttt7 | Qwen3、Gemma4 | 数百 |
命名則が実用的です。dspark_qwen3_8b_block7 は「Qwen3-8B 用の DSpark 草稿モデル」を意味します。block7 や ttt7 は構造・学習設定の識別子で、正確な意味は各モデルカードに従ってください。選ぶときはまずベース名と規模を合わせること — 14B 用の草稿を 4B の目標モデルに合わせないでください。
ベース一致が第一原則
効果は草稿モデルと目標モデルの一致度に強く依存します。ベースや規模が合わない配套は検証採用率が下がり、草稿側の計算が無駄になります。モデルカードに対象ベースが明記された配套を優先してください。
設定の考え方
フレームワークによって項目名は違いますが、手順は共通して 3 ステップです。
1. 目標モデルと草稿モデルを指定してロード。 llama.cpp 系は草稿モデルパスのフラグ（-md や --model-draft など、実際は利用バージョンの --help を確認してください）。vLLM は speculative config で草稿モデルと方式を指定します。
# llama.cpp の形の例：項目名はバージョンの --help に従う
./build/bin/llama-server \
-m ./models/Qwen3.8-27B-Q4_K_M.gguf \
-md ./models/draft-model.gguf \
-ngl 40 -c 8192 \
--host 127.0.0.1 --port 8080
2. まず動かしてから調整。 草稿長（一度に何トークン予測するか）と並列検証のバッチサイズが効果に影響します。デフォルトで動かし、同一プロンプトで加速オン／オフの token/s を比較します。
3. 固定プロンプトセットで実測。 非加速時の token/s と VRAM、加速後の値を記録します。効果はモデル・ハードウェア・タスク分布で変わるため、本記事では汎用の倍率を書きません — ご自身の実測が唯一の根拠です。
草稿モデルにも VRAM が必要
草稿モデルも VRAM を占有します。目標モデルよりはるかに小さいですが、元々 VRAM が厳しいマシンでは領域を確保する必要があります。有効化前に「目標重み ＋ KV cache ＋ 草稿 ＋ オーバーヘッド」で見積もってください。
どの場面で有効か
| 場面 | 有効か | 理由 |
|---|---|---|
| バッチ文書処理（長い出力） | 有効 | 採用率の高い繰り返しパターンが多い |
| 長いエージェントループ、コード生成 | 有効 | 生成量が大きく累積効果が明確 |
| 単発の短い Q&A | 限定的 | 逐次ステップが少なく伸びしろが小さい |
| VRAM が既に厳しい | 注意 | 草稿モデルが追加 VRAM を要する |
| 出力が不確実（創作） | 注意 | 草稿採用率が下がる可能性 |
| 構造化出力（JSON/表） | 有効 | 定型トークンが多く命中率が高い |
経験則：出力が長く予測しやすいほど、投機的デコーディングは割に合います。短い Q&A は逐次ステップが数えるほどしかなく、そもそも高速化の天井が低いのです。
他の高速化手段との関係
| 手段 | 作用層 | 併用 |
|---|---|---|
| 量子化（Q4/Q5/Q8） | 重みサイズ／VRAM | 可 |
| GPU レイヤー数（-ngl） | 計算配置 | 可 |
| 投機的デコーディング | 生成の逐次性 | 本テーマ |
| より小さいモデルへ変更 | モデル能力 | 別のトレードオフ（品質低下） |
| バッチ推論 | スループット | 可 |
「小さいモデルへ変更」は品質を速度と交換しますが、投機的デコーディングは交換しません。品質に敏感なタスクでは、投機的デコーディングの方がクリーンな選択です。
FAQ
回答品質は下がりますか？
DeepSeek の配套を Qwen に使えますか？
有効化で VRAM はどれだけ増えますか？
何倍速くなりますか？
量子化と競合しますか？
EXAIV クラウドで使えますか？
関連記事
- VRAM 計算実践 — VRAM 予算の立て方
- ローカルデプロイ完全プレイブック — 7 ステップ
- Qwen モデル選びガイド — 家族の使い分け
- ローカル計算コストモデル — コスト判断
- ローカル LLM のための GPU 選びガイド — ハードウェア選定