今回の論文
今回取り上げるのは、Yuhui Li、Fangyun Wei、Chao Zhang、Hongyang Zhang による論文「EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty」です。2024年の ICML 2024 で発表され、PMLR に収録されています。公開元は Proceedings of Machine Learning Research、研究分野は LLM 推論高速化、デコーディング最適化です。URL は https://proceedings.mlr.press/v235/li24bt.html です。
この論文を選んだ理由は、LLM の推論を速くする話でありながら、単なる量子化や軽量化ではなく、「何を先読みすれば高速化しやすいか」という設計そのものを見直しているからです。アプリ開発でも LLM の待ち時間はそのまま UX とコストに効くので、実務に持ち込みやすい考え方が多い論文です。
どんな技術か
EAGLE は、LLM が次のトークンを1個ずつ生成する遅さを改善するための speculative sampling 系の高速化手法です。ただし、普通の speculative decoding のように「小さいモデルで次のトークン列を予測する」のではなく、「元の LLM の中間特徴を先に予測し、その特徴からトークンを出す」という点が大きく違います。
もう少しかみ砕くと、EAGLE は大きい LLM 本体をそのまま使い続けながら、その直前に軽い予測器を差し込む方式です。軽い予測器が「この先の隠れ状態はこうなりそうだ」と数ステップ先まで下書きを作り、元の LLM がまとめて検証します。検証で通ったぶんだけ一気にトークンを確定できるので、1トークンずつ本体を回すより速くなります。
つまり EAGLE の本質は、トークン列を直接当てにいくより、LLM の内部表現を先読みしたほうが当てやすいのではないか、という発想です。この視点が、既存の speculative sampling より高い受理率と速度向上につながっています。
課題
この技術が解決しようとしているのは、自己回帰型 LLM の推論が遅いという、かなり根本的な課題です。
何が難しいのかというと、通常のデコーディングでは次のトークンを1つ出すたびに、巨大なモデル全体をもう一度 forward しなければならないからです。応答が長くなるほど待ち時間は線形に増えますし、大きいモデルほど GPU メモリ帯域の制約も強く受けます。
既存の speculative sampling では、小さいドラフトモデルが先に複数トークンを生成し、大きいターゲットモデルがあとでまとめて検証します。ただし、この方式は「十分に似た小さいドラフトモデル」を別に用意できることが前提になりやすく、7B クラスのような比較的小さいモデルでは、さらに小さくて速いドラフトモデルを見つけにくいという問題があります。また、トークンを直接先読みすると外れやすく、受理率が伸びにくいこともあります。
なぜこの課題を解く必要があるのかというと、チャット、コード補完、エージェント、RAG、社内ツールなど、ほぼすべての LLM アプリでレイテンシが体験価値を左右するからです。モデル品質が同じでも、返答までの時間が半分になれば使いやすさはかなり変わりますし、API コストや GPU 台数の削減にもつながります。
実際の AI システムでは、応答生成が長いほど待ち時間が増え、並列処理時にはスループットも制約されます。特に、対話生成、コード生成、数理推論のように出力が長くなりやすいタスクでは、この問題が顕著です。
用語解説
- Speculative Sampling
- 小さいモデルで複数トークンを下書きし、大きいモデルでまとめて検証する高速化手法です。EAGLE はこの枠組みを使いながら、下書き対象をトークンではなく特徴に切り替えています。
- 自己回帰デコーディング
- 1つ前までの出力を条件に、次のトークンを順番に生成していく方式です。LLM の標準的な推論方法ですが、1トークンごとに大きな計算が必要になるため遅くなりやすいです。
- 隠れ状態・中間特徴
- トークン埋め込みを Transformer が処理した途中で得られる内部表現です。EAGLE では特に LM Head の直前、論文中では second-to-top-layer feature と呼ばれる特徴を予測対象にしています。
- 受理率（acceptance rate）
- ドラフトで提案した候補が、あとからターゲット LLM の検証を通過する割合です。Speculative Sampling 系では、この値が高いほど1回の検証で確定できるトークン数が増え、高速化しやすくなります。
- Tree Attention
- 複数のドラフト候補を木構造のようにまとめて扱う注意計算です。EAGLE ではチェーン状ではなく木構造で下書きと検証を行い、1回の処理でより多くの候補をさばけるようにしています。
技術の仕組み
EAGLE の重要なポイントは、「なぜトークンではなく特徴を予測するのか」と、「特徴予測に含まれる不確実性をどう解くか」です。
基本アイデア
論文の出発点は2つあります。1つ目は、トークン列よりも特徴列のほうが連続的で規則性があり、自己回帰的に予測しやすいという観察です。2つ目は、特徴だけを予測しようとすると、サンプリングのランダム性が混ざって次の特徴が一意に決まらず、そこが性能のボトルネックになるという観察です。
EAGLE はこの2つを踏まえて、特徴列を予測しつつ、1ステップ先にずらしたトークン列も一緒に入力します。これにより、「どのトークンが実際に選ばれたか」という情報を下書き側が取り込めるため、特徴予測の曖昧さを減らせます。
モデル構造
EAGLE はターゲット LLM 本体を fine-tuning しません。追加するのは、ターゲット LLM が出す特徴列と、1ステップ先に進んだトークン列を受け取る軽量な Autoregression Head です。論文では FC 層で特徴とトークン埋め込みを融合し、そのあと単一の Transformer decoder layer で次の特徴を予測します。
この構成はかなり実務的です。大きい LLM の重みを全部作り替えるのではなく、外付けの軽量ヘッドだけを学習すればよいからです。70B 向けでも学習対象は 1B 未満、7B 向けでは 0.24B 程度に収まっています。
下書き生成の流れ
まずターゲット LLM が現在位置までの特徴を持っています。EAGLE のドラフトモデルは、その特徴列と、1ステップ先にシフトしたトークン列を入力として、次の特徴を予測します。予測した特徴を LM Head に通すと次トークン分布が得られるので、そこからトークンをサンプルします。
その後は、今予測した特徴と新しく得たトークンを入力列に追加し、さらに次の特徴を予測します。これを繰り返すことで、トークンを直接当てにいくより軽いコストで数トークン先の候補列を作れます。
なぜ shifted token が効くのか
ここが EAGLE の肝です。たとえば同じ文脈からでも、次に出るトークンが am か always かで、その後の内部表現は変わります。特徴だけを見て次の特徴を当てようとすると、この分岐をうまく扱えません。
EAGLE は、実際にサンプリングされたトークンを1ステップ先の入力として渡すことで、「どの分岐に進んだか」をドラフトモデルに教えます。これにより、特徴予測の不確実性をかなり減らせます。論文でも、feature only より feature + shifted token のほうが大きく改善しています。
検証方法
ドラフト側が提案した複数トークンは、ターゲット LLM が1回の forward でまとめて検証します。各トークンについて、ドラフト分布とターゲット分布の比に基づいて受理するかどうかを決め、途中で却下されたらそこから先は捨てて再サンプルします。
この仕組みによって、最終的な出力分布は元のターゲット LLM と一致します。つまり、近似推論で速くするのではなく、理論上は元の生成分布を保ったまま高速化する設計です。ここは実務でも重要で、速度のために出力品質や挙動が変わりすぎないのが利点です。
Tree Attention の役割
EAGLE はドラフトと検証を木構造で処理します。チェーン状に1本ずつ先読みするのではなく、複数分岐をまとめて扱うので、同じ forward 回数でもより多くの候補をさばけます。
論文のアブレーションでは、Tree Attention を使うことで平均受理長が約 0.6 から 0.8 増え、速度倍率も約 0.3 から 0.5 改善しました。地味に見えますが、推論最適化ではこうした積み上げがかなり効きます。
実験と結果
論文では、EAGLE が本当に速いのか、また受理率やスループットがどう変わるのかを複数タスクで検証しています。
何を検証したのか
主な検証点は3つです。1つ目は、Vicuna や LLaMA2-Chat でどれだけ speedup するかです。2つ目は、HumanEval、GSM8K、Alpaca、MT-bench のようにタスクが違っても効果が出るかです。3つ目は、Tree Attention や shifted token 入力といった構成要素が本当に効いているかです。
データセットと評価指標
評価には、対話品質を見る MT-bench、コード生成の HumanEval、数理推論の GSM8K、指示追従の Alpaca が使われています。主な評価指標は speedup ratio、平均受理長、受理率、スループットです。単に速いかだけでなく、「1回の検証で何トークン前に進めるか」まで見ているのがポイントです。
幅広いモデルで 2.7x から 3.7x 級の高速化
EAGLE は Vicuna 7B/13B/33B、LLaMA2-Chat 7B/13B/70B、Mixtral 8x7B Instruct で評価されています。HumanEval、GSM8K、Alpaca では、多くの条件で 2.7x から 3.7x 程度の speedup が出ています。
たとえば temperature 0 の条件では、LLaMA2-Chat 13B は HumanEval で 3.76x、GSM8K で 3.20x、Alpaca で 3.01x の高速化でした。LLaMA2-Chat 70B でも HumanEval 3.52x、GSM8K 3.03x、Alpaca 2.97x と、かなり大きい改善が出ています。
1回の forward で平均 3 から 4 トークン進める
EAGLE では、ターゲット LLM が1回の検証で平均 3.2 から 4.5 トークン程度を確定できています。通常の自己回帰デコーディングは1回の forward で1トークンしか進めないので、ここが速度差の主因です。
MT-bench の平均受理長を見ると、temperature 0 で LLaMA2-Chat 70B は 3.81、Vicuna 13B は 3.98 でした。つまり、かなり高い割合でドラフト候補がそのまま通っており、特徴予測が実用的な精度に達していることが分かります。
既存の speculative 系より有利
論文では、Lookahead や Medusa とも比較しています。EAGLE はこれらより 1.47x から 2.08x ほど速いと報告されています。理由は単純にモデルを軽くしたからではなく、トークンを直接予測するより、特徴 + shifted token の方が当てやすく、受理率が伸びるからです。
特に 7B モデルのように「さらに小さい妥当なドラフトモデルを見つけにくい」ケースでも、EAGLE は外付けヘッド方式で適用しやすいのが強みです。これは実装上かなり大きい差です。
gpt-fast と組み合わせるとさらに伸びる
論文では、量子化とコンパイルを行う gpt-fast とも組み合わせています。LLaMA2-Chat 7B を単一 RTX 3090 で動かしたケースでは、通常の Hugging Face 実装が 24.5 tokens/s、gpt-fast 単体が 55.1 tokens/s、EAGLE + gpt-fast が 100.2 tokens/s、さらに int4 では 160.4 tokens/s まで伸びています。
この結果から言えるのは、EAGLE は他の最適化を置き換えるというより、推論スタックの上に重ねて効くタイプの改善だということです。実務での価値もここにあります。
アブレーションで見えた重要点
アブレーションでは、Tree Attention によって平均受理長が 0.62 から 0.75 程度改善し、速度倍率も底上げされました。また、feature only、feature + unshifted token、token only、feature + shifted token を比べると、最も効いたのは randomness を扱える shifted token 入力でした。
この結果は重要です。EAGLE の本当の価値は、「特徴を使った」ことだけではなく、「サンプリングで枝分かれした未来を、シフト済みトークンで条件付けた」ことにあります。
何に使える？
EAGLE は研究用のトリックというより、LLM を本番運用するときの速度改善手段としてかなり実践的です。
チャットアプリや社内アシスタントの待ち時間短縮
最も分かりやすい用途です。出力品質を大きく変えずに生成待ち時間を短くしたいとき、EAGLE のような lossless 系高速化は相性がよいです。UI 上の体感差が大きく、同じ GPU 台数でも同時接続を増やしやすくなります。
コード生成や補完
HumanEval で特に高速化が大きかったことから、定型パターンが多いコード生成タスクと相性がよいと考えられます。IDE 補完やコードレビュー支援では、少しの待ち時間短縮でも使い勝手が大きく変わります。
数理推論や長めの回答生成
GSM8K や Alpaca 系でも 3x 前後の改善が出ているので、出力が長くなりやすい QA、手順説明、レポート生成でも効きます。トークン数が伸びるタスクほど、1トークンずつ生成する遅さが効いてくるからです。
既存最適化との組み合わせ
量子化、KV cache 最適化、コンパイル、サービング最適化をすでに入れている環境でも、EAGLE をさらに積める可能性があります。論文で gpt-fast と併用して伸びた点は、実務上かなり大きい示唆です。
小さいモデルでも speculative 系を使いたい場面
従来の speculative decoding は、「十分に速くて十分に似ている別モデル」が必要で、そこが運用のハードルになりがちでした。EAGLE のような軽量ヘッド方式は、その問題をかなり下げます。自前モデルを運用していて、別サイズの姉妹モデルがないケースでも試しやすいです。
開発や事業へのヒント
この論文から得られるヒントは、推論最適化を「もっと軽いモデルにする」だけで考えないことです。元モデルはそのままで、生成の進め方を変えるだけでも大きな改善が出ます。
推論高速化はモデル置換だけではない
プロダクト開発では、遅いとまず小さいモデルへの切り替えを考えがちです。ただ、それは品質低下を伴いやすいです。EAGLE のように、同じモデルの生成経路を最適化する方向なら、品質を保ちながら待ち時間を削減しやすいです。
内部表現を使う設計は応用余地が広い
この論文は「ユーザーに見えるトークン」ではなく、「モデル内部の特徴」を活用したほうが予測しやすい場合があると示しています。これはドラフト生成だけでなく、途中層キャッシュ、早期終了、補助ヘッド設計などにもつながる発想です。
小さな学習で大きな運用改善を狙える
EAGLE は元の LLM 全体を再学習するのではなく、比較的小さい追加ヘッドだけを学習します。運用中のモデルに対して、フル fine-tuning ではなく「高速化用プラグインを後付けする」という考え方は、コスト対効果が高いです。
本番環境では複合最適化で考える
論文の価値は、EAGLE 単独の速度倍率だけではありません。量子化、コンパイル、バッチングと併用できることが重要です。実サービスでは、最適化は単発の銀の弾丸ではなく、積み上げで効かせるものだと分かります。
今後注目したい方向性
今後は speculative decoding も、単に小さいモデルでトークンを先読みする段階から、内部表現や部分構造を使う方向へ進みそうです。EAGLE はその流れをよく示していて、推論時の補助モデル設計が重要テーマになると考えられます。これは推測ですが、同じ発想はマルチモーダルモデルやエージェントの逐次推論にも広がりやすいです。
限界
まず、EAGLE は lossless に近い性質を持つ一方で、追加の学習済みヘッドが必要です。単なるプロンプト工夫や設定変更だけでは導入できません。モデルごとに専用ヘッドを作る必要があるので、運用の初期コストはあります。
次に、ターゲット LLM の内部特徴を扱うため、サービング基盤への組み込み難易度はそれなりに高いです。API 経由で外部の閉じたモデルを使うケースより、自前ホスティングの OSS LLM で導入しやすい技術です。
また、MoE では改善幅がやや小さく、Mixtral 8x7B Instruct では 1.5x 程度にとどまっています。論文でも、検証時に複数トークン分の expert 重みを読む必要があり、dense モデルほど単純に伸びにくいと説明しています。
さらに、バッチサイズが大きくなるほど speedup ratio は下がる傾向があります。スループット自体は約 2 倍まで伸びていますが、低レイテンシ単体最適と高バッチ運用最適は少し性質が違います。
最後に、この論文は主に Vicuna、LLaMA2-Chat、Mixtral で評価されています。より新しい長文特化モデル、マルチモーダルモデル、外部ツール使用を含むエージェント推論で同じ効果がどこまで出るかは、追加検証が必要です。
よくある質問
Q. EAGLE は普通の speculative decoding と何が違いますか？
A. 一番大きい違いは、下書き対象がトークンではなく中間特徴であることです。EAGLE は特徴のほうが予測しやすいと考え、さらに shifted token を入力に加えてサンプリングの不確実性も扱っています。
Q. 出力品質は変わりませんか？
A. 論文の枠組みでは、検証フェーズを通すことで最終的な生成分布は元のターゲット LLM と一致するよう設計されています。つまり、近似的に別の答えを出す高速化ではなく、元モデルの挙動を保ちながら速くするのが狙いです。
Q. どんなモデルでもそのまま使えますか？
A. 原理上は自己回帰型 LLM に広く適用可能ですが、実際には内部特徴にアクセスできることと、専用ヘッドを学習できることが前提です。そのため、外部 API 専用の閉じたモデルより、自前で動かす OSS モデルのほうが導入しやすいです。
Q. 量子化や KV cache 最適化と競合しますか？
A. 基本的には競合というより補完関係です。論文でも gpt-fast と組み合わせて効果を積み上げています。既存の推論最適化を置き換えるより、さらに上乗せできる可能性が高いです。
Q. まず試すなら、どこに注目すべきですか？
A. 実装面では、feature + shifted token という入力設計と、1回の検証で何トークン受理できるかを見ることが重要です。単に speculative 系を入れるだけでなく、受理率をどう上げるかが速度差を決めます。
今日の学び
この論文は、LLM の自己回帰デコーディングが遅く、既存の speculative sampling もドラフトモデルや受理率に限界があるという課題を扱っています。
それに対して、トークンではなく中間特徴を予測し、さらに shifted token でサンプリングの不確実性を吸収することで、高い受理率と 2x から 3x 超の高速化を実現しました。
ここから得られるヒントは、推論最適化では「モデルを小さくする」だけでなく、「何を先読みするか」「どう検証するか」を設計し直す余地が大きいということです。特に OSS LLM を自前運用する開発では、かなり応用しがいのある考え方です。