0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@0h-n0

EAGLE-3とMedusaで実装するSpeculative Decoding実践ガイド

0
Last updated at Posted at 2026-07-25

EAGLE-3とMedusaで実装するSpeculative Decoding実践ガイド

LLMの推論レイテンシを2〜6倍短縮するSpeculative Decoding（投機的デコーディング）の実装方法を、2026年時点で主流の2手法（EAGLE-3・Medusa）を中心に解説します。本記事では、原理の理解から vLLM / SGLang での本番デプロイまでを一貫してカバーします。

この記事でわかること

  • Speculative Decodingの動作原理（ドラフト生成→並列検証→棄却サンプリング）
  • EAGLE-3のアーキテクチャ（multi-layer feature fusion、training-time test）とドラフトヘッドの学習方法
  • Medusaの複数デコーディングヘッド方式と、EAGLE-3との使い分け基準
  • vLLM / SGLang を使った本番環境でのデプロイ手順とベンチマーク結果
  • バッチサイズ・モデル規模ごとの性能特性と、効果が出ないケースの判断基準

対象読者

  • 想定読者: LLMの推論パイプラインを構築・運用するMLエンジニア
  • 必要な前提知識:
    • Transformerアーキテクチャの基本（Self-Attention、KV Cache）
    • PyTorch での推論コードの読み書き
    • vLLM または SGLang の基本的な使い方

結論・成果

EAGLE-3の論文ベンチマークでは、Llama-3.1-8BやLlama-3.3-70Bに対してtemperature 0で4.1〜6.5倍のスピードアップが報告されています（Li et al., 2025）。実環境のA100ベンチマークでは、バッチサイズ4でMT-benchにおいて2.3倍、HumanEvalで2.52倍の高速化が確認されています（E2E Networks）。Medusaは2.2〜3.6倍のスピードアップを、ドラフトモデルなしで実現できます（Cai et al., 2024）。

上図の通り、従来は1トークンずつ逐次生成していたものを、軽量なドラフトモデルで複数候補を先読みし、ターゲットモデルが1回のforward passで並列検証します。これにより、出力品質を一切変えずに推論速度を大幅に改善できます。

Speculative Decodingの動作原理を理解する

Speculative Decodingは、ドラフト→検証→棄却サンプリングの3ステップで動作します。まずこの基本サイクルを押さえましょう。

ドラフト生成：軽量モデルで候補を先読みする

ドラフトモデル（またはドラフトヘッド）は、ターゲットモデルの数十分の一〜数百分の一のパラメータで構成された軽量モデルです。入力コンテキストから5〜12トークン程度の候補列を高速に生成します。

ポイントは、ドラフト生成はターゲットモデルのforward passと比較してはるかに高速であること。ターゲットモデルが1トークン生成する間にドラフトモデルは複数トークンを生成できるため、「投機的に」先読みできます。

並列検証：ターゲットモデルの1回のforward passで一括確認する

ドラフトモデルが提案した候補トークン列を、ターゲットモデルが1回のforward passで検証します。通常のautoregressive生成ではトークンごとにforward passが必要ですが、Speculative Decodingでは候補列全体に対する確率分布をまとめて計算できます。

これは、KV Cacheの仕組みにより、候補列の各位置における確率分布を並列に計算できるためです。GPUの並列計算能力が余っている（memory-boundな）状況でとくに有効です。

棄却サンプリング：出力品質を保証する

検証では棄却サンプリング（rejection sampling）を使い、ドラフトモデルの出力がターゲットモデルの分布と整合するかを確認します。具体的には、ドラフトモデルの確率$D[x]$とターゲットモデルの確率$T[x]$を比較し、以下のルールで受理・棄却を判定します。

受理確率 = min(1, T[x] / D[x])

棄却された場合は、残余分布 $\text{norm}(\text{relu}(T - D))$ から新たにトークンをサンプルします。この仕組みにより、最終出力はターゲットモデル単体の出力と数学的に同一の分布になります。つまり「ロスレス」な高速化です。

注意点:

棄却されたトークン以降の候補はすべて破棄されます。したがって、ドラフトモデルの精度（受理率）が高いほど、1サイクルで受理されるトークン数が増え、スピードアップが大きくなります。受理率が低いと、毎回1〜2トークンしか受理されず効果が薄れます。

Tree Attention：候補を木構造で探索する

EAGLE-3やMedusaなどの発展的手法では、候補トークンを木構造（tree）で管理します。1つの位置に対して複数の候補を提案し、それらを特殊なattention maskで並列検証します。

         [root]
        /   |   \
      t1a  t1b  t1c
      / \    |
   t2a t2b  t2d

各ノードは祖先ノードのみをattendするtree attention maskを使い、1回のforward passですべての経路を同時に検証できます。これにより、線形な候補列と比較して、より多くの候補を効率的に評価できます。

EAGLE-3のアーキテクチャと実装を深掘りする

EAGLE-3（NeurIPS 2025採択、Li et al., 2025）は、2026年時点でSpeculative Decodingの性能を牽引する手法です。前身のEAGLE-1/2から大きくアーキテクチャを刷新し、multi-layer feature fusionとtraining-time testの2つの革新を導入しました。

EAGLE-1/2からの進化：特徴量予測からトークン直接予測へ

EAGLE-1（Li et al., 2024）は、ターゲットモデルの最終レイヤーの隠れ状態を予測する方式でした。ドラフトヘッドがターゲットの特徴量を近似し、それを言語モデルヘッドに通してトークンを生成します。EAGLE-2ではdynamic draft treeを導入し、context-awareな候補木の構築を可能にしました。

しかし、EAGLE-1/2には学習データのスケーリングで性能が頭打ちになるという課題がありました。特徴量レベルの予測は間接的であり、学習データを増やしても受理率の改善が鈍化していたのです。

EAGLE-3はこの制約を打破するため、特徴量予測を廃止してトークンの直接予測に移行しました。

Multi-Layer Feature Fusion：低・中・高レイヤーの統合

EAGLE-3の第1の革新がmulti-layer feature fusionです。従来のEAGLEが最終レイヤーの隠れ状態のみを使っていたのに対し、EAGLE-3はターゲットモデルの複数レイヤーから特徴を抽出して統合します。

具体的な処理は以下の通りです。

  1. ターゲットモデルのforward pass中に、低・中・高レイヤーから隠れ状態を取得
  2. 3つの特徴ベクトルを連結（例: 4096次元 × 3 = 12288次元）
  3. FC層で元の次元に圧縮（12288 → 4096）
  4. ドラフトヘッド（1 Transformer Layer）に入力してトークンを予測

なぜこの設計か:

  • 低レイヤーは構文や基本的な構造パターンを捉える
  • 中レイヤーは単語・フレーズ間の関係性をエンコードする
  • 高レイヤーは意味理解や推論に関わる複雑な表現を持つ
  • 3レイヤーの統合により、ドラフトヘッドがターゲットモデルの振る舞いをより正確に再現できる

Training-Time Test：学習時に推論をシミュレーションする

EAGLE-3の第2の革新がtraining-time testです。通常の教師あり学習では、ドラフトヘッドはターゲットモデルの「正解」特徴量を入力として受け取ります。しかし実際の推論時には、ドラフトヘッド自身が生成した（不完全な）特徴量を次のステップの入力に使います。

この学習と推論のギャップ（exposure bias）が性能劣化の原因でした。training-time testは、学習中にドラフトヘッド自身の予測結果をフィードバックとして使う自己回帰的なシミュレーションを行い、このギャップを解消します。

# training-time testの概念的な擬似コード
# 学習時にドラフトヘッドの自己回帰をシミュレーション
def training_time_test(draft_head, target_features, num_steps=7):
    """
    学習時に推論時の振る舞いをシミュレーションする。
    ターゲットの正解特徴量と、ドラフトヘッド自身の予測を混合して学習する。
    """
    loss = 0
    current_input = target_features[0]  # 最初は正解特徴量

    for step in range(num_steps):
        # ドラフトヘッドで次トークンを予測
        predicted_logits, predicted_features = draft_head(current_input)

        # 正解トークンとのクロスエントロピー損失
        loss += cross_entropy(predicted_logits, target_tokens[step + 1])

        # 次ステップの入力: ドラフト自身の予測を使う（推論時の挙動を模倣）
        if step < num_steps - 1:
            current_input = predicted_features  # 自己生成した特徴量をフィードバック

    return loss / num_steps

ハマりポイント:

EAGLE-3の論文では、training-time testの先読みステップ数を7に設定しています。この値を大きくしすぎるとメモリ消費が増加し学習が不安定になりますが、小さすぎると推論時の長い自己回帰チェーンへの適応が不十分になります。E2E Networksのベンチマークでも、デフォルトの7が安定した選択肢とされています。

ドラフトヘッドの構成と学習手順

EAGLE-3のドラフトヘッドは、ターゲットモデルのアーキテクチャを模した1 Transformer Layerで構成されます。Llama-3.1-8Bの場合、ドラフトヘッドの設定は以下のようになります。

{
  "model_type": "llama",
  "hidden_size": 4096,
  "num_hidden_layers": 1,
  "num_attention_heads": 32,
  "num_key_value_heads": 8,
  "intermediate_size": 14336,
  "hidden_act": "silu",
  "vocab_size": 128256,
  "draft_vocab_size": 32000
}

ターゲットモデルのパラメータに対して5%未満の追加パラメータで済む点が重要です。

学習手順（SpecForgeを使用）:

# 1. 環境構築
git clone https://github.com/sgl-project/SpecForge.git
cd SpecForge
pip install -v .

# 2. 学習データの準備（ターゲットモデルで再生成）
python scripts/regenerate_train_data.py \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --input-file-path ./data/sharegpt.jsonl \
  --output-file-path ./data/sharegpt_llama31_8b.jsonl \
  --batch-size 128 \
  --tp-size 4 \
  --temperature 0 \
  --auto-launch-server

# 3. データセットキャッシュの構築
python scripts/build_eagle3_dataset_cache.py \
  --target-model-path meta-llama/Llama-3.1-8B-Instruct \
  --draft-model-config ./configs/llama3-8B-eagle3.json \
  --train-data-path ./data/merged_train.jsonl \
  --cache-dir ./cache \
  --chat-template llama3 \
  --max-length 2048

# 4. ドラフトヘッドの学習
export NUM_GPUS=4
torchrun \
  --standalone \
  --nproc_per_node $NUM_GPUS \
  scripts/train_eagle3_sgl_online.py \
  --target-model-path meta-llama/Llama-3.1-8B-Instruct \
  --draft-model-config ./configs/llama3-8B-eagle3.json \
  --train-data-path ./data/merged_train.jsonl \
  --tp-size $NUM_GPUS \
  --output-dir ./outputs \
  --num-epochs 10 \
  --batch-size 1 \
  --learning-rate 5e-5 \
  --draft-attention-backend flex_attention \
  --max-length 2048 \
  --total-steps 800000 \
  --warmup-ratio 0.015 \
  --save-interval 10000 \
  --mem-frac 0.4

なぜ学習データをターゲットモデルで再生成するか:

  • 公開データセット（ShareGPT等）はターゲットモデルが生成したものではない
  • ドラフトヘッドが学習する分布と、推論時にターゲットモデルが出力する分布にずれが生じる
  • ターゲットモデル自身で再生成したデータで学習することで、分布のアラインメントが取れる

リソース見積もり:

  • 学習: 4× A100 40GBまたは4× H100 80GBで1〜2日（8B-13Bモデル）
  • 推論: 1× H100/A100で十分（ドラフトヘッドのメモリオーバーヘッドは5%未満）

EAGLE 3.1: attention driftの修正

2026年5月に公開されたEAGLE 3.1は、attention driftと呼ばれる現象を修正したアップデートです。長いコンテキストや特定のchat template使用時にドラフトヘッドの受理率が低下する問題に対し、以下の改善を加えています。

  • ターゲット隠れ状態に対するFC正規化の追加
  • post-norm hidden-state feedbackの導入

これにより、長コンテキストワークロードでEAGLE-3比最大2倍の受理長を達成しています。vLLM v0.22.0+で既存のEAGLE-3チェックポイントとの後方互換性を保ったまま利用可能です。

Medusaの仕組みと導入方法を把握する

Medusa（Cai et al., 2024）は、EAGLE系とは異なるアプローチでSpeculative Decodingを実現します。別個のドラフトモデルを不要とし、ターゲットモデルに直接複数のデコーディングヘッドを追加する点が特徴です。

アーキテクチャ：複数ヘッドによる並列トークン予測

Medusaの設計思想は明快です。Transformerの最終隠れ層の出力に、位置ごとに独立したデコーディングヘッドを追加します。通常の言語モデルヘッド（lm_head）が次の1トークンを予測するのに対し、Medusaヘッドはそれぞれ2番目、3番目、...、k番目の未来のトークンを予測します。

各Medusaヘッドは、1層のFFN（Feed-Forward Network）+ Residual Connectionで構成されるシンプルな構造です。これにより、ドラフトモデルの学習・管理のコストを大幅に削減しています。

Medusa-1 vs Medusa-2：学習戦略の違い

Medusaには2つの学習戦略があります。

項目 Medusa-1 Medusa-2
学習対象 Medusaヘッドのみ（バックボーン凍結） Medusaヘッド + バックボーン（共同fine-tuning）
品質保証 ロスレス（バックボーン不変） 特別な学習レシピで品質維持
スピードアップ 2.2倍以上 2.3〜3.6倍
学習コスト 低い（パラメータ効率的） 高い（フルモデルfine-tuning）
ユースケース 既存モデルに追加したい場合 最大性能を引き出したい場合

トレードオフ:
Medusa-2はスピードアップが大きいものの、バックボーンのfine-tuningを伴うため、元モデルの品質を損なうリスクがあります。論文では「特別な学習レシピでバックボーンの能力を保持する」としていますが、ドメイン特化モデルでの検証は自前で行う必要があります。

Medusaの導入手順

# インストール
pip install medusa-llm

# CLIでの推論（Medusa-1ヘッド付きモデル）
CUDA_VISIBLE_DEVICES=0 python -m medusa.inference.cli \
  --model FasterDecoding/medusa-vicuna-7b-v1.3 \
  --load-in-8bit

# 量子化オプション
# --load-in-4bit: メモリ制約がある場合
# --load-in-8bit: バランスの良い選択

Medusaヘッドの学習（axolotlベース）:

# axolotlライブラリを使った学習
pip install axolotl
accelerate launch -m axolotl.cli.train examples/medusa/config.yml

注意点:

Medusaは2026年7月時点でバッチサイズ1の単一GPU推論に最適化されています。複数ユーザーの同時リクエストを処理するサービング環境では、vLLM経由での利用が推奨されます。

本番環境にデプロイする

EAGLE-3とMedusaの理論を理解したところで、vLLMとSGLangを使った本番デプロイの手順を見ていきましょう。

vLLMでのデプロイ

vLLM v0.22.0以降では、EAGLE-3とMedusaの両方をネイティブサポートしています。設定は --speculative-config フラグで行います。

EAGLE-3でのサービング:

# EAGLE-3を使ったLlama-3.1-8Bのサービング
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --speculative-config '{
    "model": "path/to/eagle3_checkpoint",
    "method": "eagle3",
    "num_speculative_tokens": 5
  }'

# Kimi K2.6での例（EAGLE 3.1、Tensor Parallel=4）
vllm serve nvidia/Kimi-K2.6-NVFP4 \
  --speculative-config '{
    "model": "lightseekorg/kimi-k2.6-eagle3.1-mla",
    "method": "eagle3",
    "num_speculative_tokens": 3
  }'

Medusaでのサービング:

# Medusaヘッド付きモデルのサービング
vllm serve FasterDecoding/medusa-vicuna-7b-v1.3 \
  --speculative-config '{
    "method": "medusa",
    "num_speculative_tokens": 5
  }'

SGLangでのデプロイ

SGLangはEAGLE-3のサポートが特に手厚く、SpecForgeで学習したチェックポイントをそのまま使えます。

# SGLangでのEAGLE-3サービング
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --speculative-draft-model-path ./outputs/eagle3_checkpoint \
  --speculative-algorithm eagle \
  --speculative-eagle-topk 8 \
  --speculative-num-draft-tokens 32

本番ベンチマーク結果

以下は公開されているベンチマーク結果です。

EAGLE-3 / Llama-3.1-8B / A100（E2E Networksの報告）:

バッチサイズ Vanilla（tok/s） EAGLE-3（tok/s） スピードアップ 平均受理長
4 569 1,312 2.30x 4.70
8 1,069 2,102 1.97x 4.69
32 3,252 3,186 0.98x 4.70

EAGLE 3.1 / Kimi K2.6 / GB200（vLLMブログの報告）:

同時ユーザー数 スループット改善
1 2.03x
4 1.71x
16 1.66x

タスク別スピードアップ（バッチサイズ4、A100）:

タスク スピードアップ 備考
HumanEval 2.52x コード生成（予測しやすいパターンが多い）
MT-bench 2.30x 汎用チャット
MATH500 2.22x 数学推論
GSM8K 2.17x 算術推論

よくある間違い:
最初は「バッチサイズが大きいほど高速化する」と考えがちですが、バッチサイズ32以上ではスピードアップがほぼ消失します。これは、大バッチではGPUがcompute-bound（演算律速）になり、Speculative Decodingが活用するmemory-bound（メモリ帯域律速）の余剰計算能力がなくなるためです。

EAGLE-3とMedusaを使い分ける

2つの手法にはそれぞれ得意・不得意があります。プロジェクトの要件に応じて選択しましょう。

手法比較

項目 EAGLE-3 Medusa
スピードアップ 3.0〜6.5x（論文値） 2.2〜3.6x（論文値）
受理率 75%以上 55〜70%
ドラフトモデル 要（1 Transformer Layer） 不要（ヘッド追加のみ）
追加パラメータ ターゲットの5%未満 ヘッド数に比例（少ない）
学習コスト 4× A100で1〜2日 単一GPUで数時間
学習データ 約53万サンプル推奨 ShareGPT等で可
フレームワーク vLLM / SGLang vLLM / 独自CLI
最適バッチサイズ 1〜16 1（現時点）
長コンテキスト EAGLE 3.1で改善済 制限あり

選択ガイドライン

EAGLE-3を選ぶべき場面:

  • レイテンシの最小化が最優先（チャットボット、コード補完、音声エージェント）
  • 70B以上の大規模モデルで効果を最大化したい
  • 学習リソース（4× A100以上）を確保できる
  • vLLM / SGLang での本番サービングを予定している

Medusaを選ぶべき場面:

  • 導入の速さ・手軽さを重視（PoC、プロトタイプ）
  • 学習リソースが限られている（単一GPUで完結）
  • ドメイン特化の既存fine-tunedモデルにそのまま追加したい
  • メモリ予算がタイトで、別個のドラフトモデルを持てない

制約条件:

どちらの手法も、バッチサイズが大きい（32以上）場合や、短い出力（数トークン）しか生成しない用途では効果が限定的です。また、Speculative Decodingはストリーミング出力との相性に注意が必要です。候補をまとめて検証する性質上、トークン単位のストリーミングではなくチャンク単位のストリーミングとなり、体感のfirst-token latencyが変動する場合があります。

よくある問題と解決方法

問題 原因 解決方法
スピードアップが1x程度しか出ない バッチサイズが大きすぎる（compute-bound） バッチサイズを16以下に調整
受理率が論文値より大幅に低い 学習データとターゲットの分布がずれている ターゲットモデルでデータを再生成して再学習
長いプロンプトで受理率が低下 attention drift（EAGLE-3固有） EAGLE 3.1にアップグレード
OOM（GPU Out of Memory） ドラフトヘッドと候補木のメモリ消費 num_speculative_tokens を減らす（5→3）
vLLMで speculative-config が認識されない vLLMのバージョンが古い v0.22.0以上にアップグレード
Medusaのスループットが低い 大バッチ・複数ユーザー環境での最適化不足 vLLM経由で利用するか、EAGLE-3に切り替え

まとめと次のステップ

まとめ:

  • Speculative Decodingはドラフト→並列検証→棄却サンプリングのサイクルで、出力品質を保ったまま推論を2〜6倍高速化する手法
  • EAGLE-3はmulti-layer feature fusionとtraining-time testにより受理率75%以上を達成し、2026年時点のベンチマークで他手法を上回るスピードアップを報告。EAGLE 3.1でattention drift問題も解消済み
  • Medusaはドラフトモデル不要で導入が手軽だが、受理率（55〜70%）とスピードアップ（2.2〜3.6x）はEAGLE-3に劣る
  • バッチサイズ1〜16のレイテンシ重視ワークロードで効果が大きく、バッチサイズ32以上では効果が減衰する
  • vLLM v0.22.0+ / SGLang で本番デプロイが可能

次にやるべきこと:

  • EAGLE-3の公式リポジトリ（SafeAILab/EAGLE）で、使用モデル向けの事前学習済みドラフトヘッドの有無を確認する
  • 事前学習済みヘッドがない場合は、SpecForgeでドラフトヘッドを学習する
  • vLLM / SGLang で --speculative-config を設定し、自社のワークロードでバッチサイズ別のスピードアップを計測する

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?