私は推測デコード（speculative decoding）のための教育用の実装リポジトリに取り組んできました:
https://github.com/shreyansh26/Speculative-Decoding
既存のライブラリをラップすることが目的ではなく、提案者（proposer）の設計の違いをより調べやすくするために、共通のデコード/評価契約の裏側で、いくつかの推測デコード手法をゼロから実装します。
これまでに実装した手法:
- EAGLE-3
- Medusa-1
- 標準のドラフトモデル推測
- PARD / 並列ドラフトモデル
- n-gram プロンプト参照
- サフィックスデコーディング
このリポジトリには、適用可能な範囲で学習経路と推論経路の両方があります。学習済みの提案者では、ターゲットモデルとして Qwen/Qwen2.5-7B-Instruct を使い、手法に応じて小さな学習済み/推測用ヘッドまたはドラフトモデルを使用しています。学習不要の手法では、提案者はプロンプト/生成コンテキストから構築します。
このリポジトリで明示したかったことがいくつかあります:
- 提案者の品質と検証コストの違い。
- 高い受理率が必ずしも高いスループットにつながらない理由。
- 自回帰（autoregressive）ドラフトモデルより受理率が低くても、PARD のような手法がなぜ速くなり得るのか。
- EAGLE/Medusa 風の学習済みヘッドが、ドラフトモデル推測とどう違うのか。
- プロンプトに再利用可能な構造が含まれている場合に、n-gram やサフィックスデコーディングのような単純な手法がどう振る舞うか。
このリポジトリには、ベンチマークの要約、コマンドライン、チェックポイント/エクスポート、実装メモが含まれています。計算制約のため、いくつかの結果は意図的に小さな学習データ重複（train-overlap）の評価スライスになっています。そのため、数値は広範な一般化の主張ではなく、実装/挙動のベンチマークとして扱うのがよいと思います。
私は主に、アルゴリズムとシステムの境界で推測デコードを理解したい人のための学習リソースとしてこれを作りました。つまり、提案者がどのように学習されるのか、ドラフトトークンがどのように生成されるのか、ターゲットの検証がどのように行われるのか、何がキャッシュされるのか、そしてスピードアップが実際にどこから生まれるのか、という点です。
[link] [comments]
