DSparkによる推測的デコーディングでLLM推論を高速化

すでに導入済みのモデルや GPU インフラからより高いパフォーマンスを引き出す方法は数多く存在します。量子化（quantization）や最適化されたカーネル、高性能な推論エンジンも有効ですが、speculative decoding は特に有用です。なぜなら、これは追加で GPU を増やすことなく、生成速度を向上させることができるからです。

現在、speculative decoding にはいくつかのアプローチがあります。従来の手法では小さなドラフトモデルを使用しますが、Multi-Token Prediction (MTP) では複数の未来トークンを一度に予測します。Medusa や EAGLE は、これらのドラフトの生成方法を改善するものであり、DFlash は候補となるトークンのブロックを並列に生成します。

DSpark はこれらとは異なるアプローチを採用し、並列的なドラフト生成と軽量な逐次処理コンポーネントを組み合わせています。これにより、後のドラフトトークンが先行する予測の情報を利用できるようになりつつ、並列生成の速度メリットをほぼ維持することが可能になります。

本ガイドでは、Qwen3-8B と llama.cpp を用いて DSpark の性能を検証します。まずモデルを通常通りベンチマークし、次に同等のドラフトモデルを備えた DSpark を有効化して生成速度を比較し、同じ GPU 環境でどれほどのパフォーマンス向上が得られるかを確認します。

How DSpark Works

DeepSeek の DSpark は、speculative decoding のドラフト生成部分を改善した技術です。

並列ドラフトモデルは、一度にトークンのブロック全体を予測できるため高速ですが、ブロック内で後続の予測は先行するトークンへの依存が不十分になるため精度が低下する可能性があります。DSpark は並列バックボーンと軽量な逐次コンポーネントを組み合わせることで、後のドラフト位置でも先行して予測されたトークンの情報を取り込みつつ、並列生成の高い速度を維持します。

簡単に言えば以下の通りです。

DSpark は、ドラフトトークンが検証を通過する確率も推定できます。これにより、信頼度の低いブロック部分を切り捨てて、検証計算のリソースを無駄にしないことが可能になります。llama.cpp では、この機能を DSpark 実装とオプションの信頼度閾値を通じて提供しています。

DeepSeek の報告によると、DeepSeek-V4 と組み合わせてデプロイした際、DSpark は従来の MTP-1 本番ベースラインと比較してユーザーあたりの生成速度を60〜85% 向上させました。これらの数値は、私たちのような小規模なローカルモデルでの期待値として扱うべきではありません。そのため、今回は実際に測定して違いを確認していきます。

1. llama.cpp のビルドとモデルのダウンロード

CUDA アクセラレーションに対応した最新の DSpark 実装を利用するために、ソースコードから最新の llama.cpp をビルドします。

必要なツールをインストールしてください：

apt-get update
apt-get install -y git cmake build-essential

公式の llama.cpp リポジトリをクローンします：

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

CUDA サポートを有効にして構築します：

cmake llama.cpp -B llama.cpp/build \
  -DBUILD_SHARED_LIBS=OFF \
  -DGGML_CUDA=ON

cmake --build llama.cpp/build \
  --config Release \
  -j \
  --clean-first \
  --target llama-cli llama-mtmd-cli llama-server llama-gguf-split

これにより、必要なバイナリが作成されつつ、モデルを GPU で実行できるようになります。

次に、モデルファイル用のディレクトリを作成します：

mkdir -p /workspace/models

ベンチマークの結果にダウンロード時間が影響しないよう、GGUF ファイルは手動で Hugging Face CLI を使用してダウンロードします。

CLI のインストール:

pip install -U huggingface_hub

Hugging Face のトークンが HF_TOKEN に保存されている場合は、以下のように認証を実行してください。

hf auth login --token "$HF_TOKEN"

Qwen3-8B Q4_K_M ターゲットモデルをダウンロードしてください：

hf download \
  Qwen/Qwen3-8B-GGUF \
  Qwen3-8B-Q4_K_M.gguf \
  --local-dir /workspace/models

次に、対応する DSpark Q8_0 ドラフトモデルをダウンロードしてください。

hf download \
  ggml-org/Qwen3-8B-GGUF \
  dspark-Qwen3-8B-Q8_0.gguf \
  --local-dir /workspace/models

最初のファイルは、最終的な出力を生成するメインモデルです。より小型の DSpark モデルは、ターゲットモデルが検証するための推測ドラフトトークンを生成します。

両方のファイルが利用可能であることを確認してください：

ls -lh /workspace/models

以下のような結果が表示されます。

4.7G  Qwen3-8B-Q4_K_M.gguf
1.2G  dspark-Qwen3-8B-Q8_0.gguf

llama.cppをビルドし、両方のモデルをダウンロードした状態で、まずはスペキュレーティブ・ディコーディング（speculative decoding）を有効にする前のQwen3-8Bの生成速度を測定します。

2. ベースライン速度の計測

DSparkを有効化する前にベースラインが必要です。ここではQwen3-8Bを通常通り実行し、その生成速度を記録して、後でスペキュレーティブ・ディコーディング版との比較に用います。

llama.cppのディレクトリへ移動します：

cd /workspace/llama.cpp

推論を加速する DSpark によるスペキュレーティブ・デコーディング

Speculative Decoding（スペキュレーティブ・デコーディング）を用いない場合の Qwen3-8B の実行結果：

./build/bin/llama-cli \
  -m /workspace/models/Qwen3-8B-Q4_K_M.gguf \
  -ngl all \
  -fa on \
  --temp 0 \
  --top-k 1 \
  -n 512 \
  -st \
  -p "Write a complete Python implementation of merge sort. Explain how it works and include its time and space complexity. /no_think"

ここでは、-ngl all オプションでモデルの全レイヤーを GPU にオフロードし、-fa on で Flash Attention を有効化します。

また、決定論的なデコーディング（deterministic decoding）も使用しています：

--temp 0 --top-k 1

これは重要です。DSpark のテストでは、同じプロンプト、トークン制限、およびデコーディング設定を使用するため、公平な比較が可能になります。

生成が完了したら、llama.cpp が出力するベンチマークのサマリーを確認してください：

[ Prompt: 294.6 t/s | Generation: 95.0 t/s ]

本ガイドで重要なのは Generation: 95.0 tokens/s という数値です。DSpark の速度向上を測定する際の基準値としてこの値を使用します。

3. DSpark を使用して同じテストを実行

DSpark を有効にしてベンチマークを再実行します。目標は、ターゲットモデル、プロンプト、トークン制限、デコーディング設定をすべて同一に保ちつつ、推測型デコーディングの効果のみを直接測定することです。

同じ Qwen3-8B モデルを使用し、今回は DSpark のドラフトモデルを併用します。

./build/bin/llama-cli \
  -m /workspace/models/Qwen3-8B-Q4_K_M.gguf \
  -md /workspace/models/dspark-Qwen3-8B-Q8_0.gguf \
  --spec-type draft-dspark \
  --spec-draft-n-max 3 \
  -ngl all \
  -ngld all \
  -fa on \
  --temp 0 \
  --top-k 1 \
  -n 512 \
  -st \
  -p "Write a complete Python implementation of merge sort. Explain how it works and include its time and space complexity. /no_think"

ここで、-md オプションで DSpark ドラフトモデルを読み込み、--spec-type draft-dspark で DSpark 推測デコーディングを有効化します。

--spec-draft-n-max 3 オプションにより、DSpark は一度に最大 3 トークンをドラフト生成できます。また、-ngld all を指定することで、ドラフトモデルを GPU にオフロードします。

実行が完了したら、生成速度を記録します。

[ Prompt: 88.0 t/s | Generation: 124.9 t/s ]

次に、これをベースラインと比較しましょう。

DSpark は、同じターゲットモデルと GPU を使用しながら、生成スループットを 95.0 から 124.9 tokens/s に引き上げました。これは約 1.31 倍の高速化、つまり生成速度が約 31.5% 向上したことを意味します。

DSpark 実行時のプロンプト処理速度は若干低下しますが、今回測定しているのは主に自己回帰的な生成速度です。より長い応答を生成するワークロードでは、この高いトークン生成スループットが推論全体の所要時間に大きな影響を与えます。

まとめ

ローカル環境での LLM 高速化については、依然として MTP がより実用的な選択肢だと考えています。特に、MTP はシンプルでありながら、対応するモデルの範囲が広い点が強みです。一方で、ドラフトの品質向上により承認される推測トークンが増えるケースでは、DSpark が基本的多トークン予測を上回る可能性もあります。

DSpark の良い点は、llama.cpp でのセットアップが非常に簡単だということです。ただし、大きな制限として モデル対応状況 が挙げられます。現在、互換性のある DSpark ドラフトモデルを用意しているのはごく少数のモデルに限られています。

llama.cpp でのサポートも比較的新しいため、使用するモデルやビルドによってはバグや不安定さを経験する可能性があります。現時点では、DSpark は実験的な高速化技術として興味深いものですが、ローカル推論においては MTP がより汎用的に役立つ選択肢であることに変わりはありません。