vLLM×AMD GPUでEAGLE-3推論を高速化
vLLM と AMD Quark の連携により、AMD Instinct GPU 上で EAGLE-3 の予測デコーディング技術が学習および推論環境で実装され、ハードウェア最適化の新たな道筋が開かれた。
キーポイント
EAGLE-3 と AMD Quark の連携実現
vLLM エンジン上で EAGLE-3 アルゴリズムを AMD Instinct GPU 向けに最適化し、AMD Quark ライブラリを活用して予測デコーディングの学習と推論を可能にした。
非 NVIDIA ハードウェアでの高性能化
従来の NVIDIA 中心だった推論エコシステムにおいて、AMD GPU でも同等レベルの効率性を持つ予測デコーディング技術が動作することを実証した。
vLLM の拡張性と互換性
オープンソース推論フレームワーク vLLM が AMD 独自のハードウェア特性に対応し、多様な GPU アーキテクチャでの柔軟な展開を可能にしていることを示した。
重要な引用
vLLM と AMD Quark を活用し、AMD Instinct GPU 上で EAGLE-3 の予測デコーディングの学習・推論を実現した。
EAGLE-3 Speculative Decoding on AMD Instinct GPUs: Training and Serving with vLLM and AMD Quark
影響分析・編集コメントを表示
影響分析
この成果は、LLM 推論市場におけるハードウェアの多様性を加速させる重要な転換点となります。特に、予測デコーディングのような高度な最適化技術が AMD ハードウェアで実用レベルに達したことは、ベンダーロックインの打破とコスト削減への道を開くものです。業界全体として、より競争力のある推論エコシステムの構築が現実味を帯びてきました。
編集コメント
AMD の推論性能が EAGLE-3 のような先進的なデコーディング技術で実証されたことは、業界の多様化を後押しする重要な一歩です。vLLM の柔軟なアーキテクチャがこうした異種ハードウェアとの親和性を高める鍵となっています。
大規模言語モデル(LLM)の推論は、自己回帰的なデコーディングによって制約を受けることが増えています。プリフィルが高度に最適化されていても、デコーディング段階ではトークンを1 歩ずつ生成する必要があり、各ステップで通常、対象となる大規模モデル全体を実行する必要があります。Kimi-K2.5 や MiniMax-M2.5 のように、エキスパートを混合する(Mixture-of-Experts)構造を持つモデルや、アテンション計算が重いモデルでは、この逐次的な処理パターンがサービススループットを制限し、リアルタイムアプリケーションにおけるレイテンシを増大させます。
スペキュレティブ・デコーディングは、このボトルネックに対処する最も実用的な手法の一つです。これは、対象モデルの出力分布を正確に保ちながら、デコーディング効率を向上させるロスレスな LLM 推論加速技術です。より小型または軽量なドラフトモデルを使用して複数の将来トークンを提案し、元の対象モデルがそれらのトークンを単一の順方向パスで検証します。ドラフトモデルが予測したトークンが、対象モデルも生成するものと同じ場合、それらのトークンはまとめて受け入れられるため、高コストの対象モデルによるデコーディング反復回数を削減できます。
一般的なスペキュレティブ・デコーディングの手法には、小型のドラフトモデル、マルチトークン予測(MTP)、Medusa 型マルチヘッド予測、そして EAGLE-3 や DFlash、最近登場した DSpark などの特徴量レベルでのドラフティング方法が含まれます。既存のスペキュレティブ・デコーディング手法の中で、EAGLE-3 は優れたドラフト品質、高いトークン受容率、一貫して競争力のある推論速度向上効果により、特に注目されています。
本ブログでは、AMD Instinct GPU 上で完結する EAGLE-3 のライフサイクルを解説します。すべて vLLM を基盤とし、AMD Quark チームがエンドツーエンドで提供しています。具体的には以下の 3 つのステップです。
- EAGLE-3 ドラフトモデルのトレーニング:vLLM がターゲットモデルをサーブし、オンポリシーデータの合成やトレーニング中の隠れ状態の抽出、ループ内での受容評価を実行します。
- AMD Quark による量子化:ターゲットとドラフトの両方に対して、MXFP4 と FP8 の day-0 サポートを提供します。
- ROCm/vLLM 上での推論加速:AMD Instinct™ MI355X GPU で Kimi-K2.5 および MiniMax-M2.5 を InferenceX ベンチマークで評価しました。なお、トレーニングセクションの例として用いている MiniMax-M3 の EAGLE-3 ドラフトも、同じパイプラインでトレーニングされています。
なぜスペキュレティブ・ディコーディングと EAGLE-3 が重要なのか
標準的な自己回帰的デコーディングでは、ターゲットモデルの 1 ステップごとに 1 トークンを生成します。もしモデルが 1,000 トークンの出力を必要とする場合、事前処理(prefill)後に推論エンジンはおおよそ 1,000 回のターゲットモデルによるデコード反復を実行することになります。これはコストが高いです。なぜなら、各デコード反復でモデルの重み、アテンション状態、スケジューラ、そして KV キャッシュ機構にアクセスする必要があるからです。
スペキュレティブ・ディコーディングはこのプロセスを変えます:
- ドラフトモデルが複数の候補となる次のトークンを提案します。
- ターゲットモデルはそれらの候補を 1 回のパスで検証します。
- ターゲットモデルの分布と一致するトークンは受け入れられます。
- 生成は、最初に拒否されたトークンから、または受け入れられたブロックの末尾から続行されます。
重要なのは「受容率」です。これは、ターゲットモデルがドラフトモデルの提案するトークンを何個受け入れられるかを示す指標です。
例えば、ドラフトモデルが次の 4 つのトークンを提案した場合を考えましょう。ターゲットモデルがこれら 4 つすべてに合意すれば、1回の検証ステップで 4 つをまとめて受容できます。しかし、3つ目のトークンで不一致が生じれば、最初の 2 つだけが受容され、残りのトークンは再生成する必要があります。
一度により多くのトークンを受容できれば、ターゲットモデルが実行しなければならない高コストなデコードステップは減り、スループットは向上します。重要なのは、ドラフトされたトークンが出力される前に必ずターゲットモデルによって検証される点です。これにより、推論速度を上げつつも、最終的な出力品質には一切影響を与えません。
image 推測的デコードの提案と検証フロー
Figure 1: 推測的デコードの仕組み — ドラフトモデルがγ個のトークンを提案し、ターゲットモデルがこれを1パスで検証します。一致する接頭辞(α)が受容され、α+1個のトークンが発行されます。その後、最初に不一致となったトークンからドラフトを再開します。すべての発行トークンは検証されるため、この高速化は品質の低下を伴いません。
EAGLE は過去数年にわたり継続的に進化を遂げてきました。当初の EAGLE では特徴レベルでの推測デコーディングを実現し、EAGLE-2 でドラフトの品質と採用率を向上させました。そして EAGLE-3 では、ターゲットモデルからの多層の特徴を活用することで、さらに精度と速度向上を達成しています。
EAGLE-3 は、無関係な小型言語モデルに依存するのではなく、ターゲットモデルと密接に連携するドラフトモジュールを訓練します。訓練時のテスト手法を採用し、ターゲットモデルの低・中・高レベルの特徴を組み合わせて活用することで、検証器が採用する可能性が高い候補をドラフトモデルが提案できるようになっています。
実運用における推論において重要なのはシンプルです。EAGLE-3 は検証を通じてターゲットモデルの出力挙動を維持したまま、生成スループットを向上させることができます。
AMD Quark MXFP4: メインストリーム LLM 向けの Day-0 量子化
MXFP4 は、Open Compute Project (OCP) が策定したマイクロスケーリング 4 ビット浮動小数点フォーマットです。4 ビットの要素を小さなブロックにグループ化し、スケールファクターを共有することで、INT4 に近いメモリ使用量を実現しつつ、はるかに優れた数値挙動を維持します。
AMD Instinct MI350 シリーズ GPU(MI350X/MI355X)はネイティブの FP4 行列演算加速をサポートしており、MXFP4 の重みはハードウェアに直接マッピングされます。これにより、大規模な混合专家モデルのデコーディングにおいてボトルネックとなるメモリ帯域幅と容量への負荷を軽減できます。
AMD Quark は AMD が提供するモデル量子化ツールキットです。Quark チームは、主要な大規模言語モデル(LLM)向けに「Day-0」の MXFP4 量子化チェックポイントを提供しており、これらは Hugging Face で公開されています(例:amd/Kimi-K2.5-MXFP4 や amd/MiniMax-M3-MXFP4)。ここでいう Day-0 とは、主要モデルがリリースされた直後に、Quark チームが ROCm や vLLM 上でそのまま動作するハードウェア対応の MXFP4(および FP8)ビルドを即座に提供することを意味します。サードパーティによる量子化の実装を待つことなく、すぐに利用可能です。
これらの公開済みチェックポイントは、EAGLE-3 のドラフトトレーニングにおける目標モデルとして、また推論時のスペキュレティブ・ディコーディングのターゲットとして、そのまま直接使用できる状態になっています。
これらのチェックポイントは、ROCm 上の vLLM で直接利用可能です。FP4 ASM GEMM パス(VLLM_ROCM_USE_AITER_FP4_ASM_GEMM=1)と AITER MoE カーネルを通じて動作するため、MXFP4 のメモリ削減効果を生かしつつ、本番環境で使えるスループットを実現できます。
スペキュレティブ・ディコーディングはロスレスです。ドラフトトークンすべてが提供先のターゲットに対して検証されるため、ターゲットの出力分布が変わることはありません。(図 2)

AMD Quark day-0 量子化フロー
*図 2: AMD Quark の day-0 量子化フロー。主要な大規模言語モデルがリリースされると、Quark チームは Hugging Face に MXFP4 または FP8 ビルドを公開し、ROCm 上の vLLM がこれを直接提供します。*
vLLM を用いた EAGLE-3 ドラフトモデルのトレーニング
AMD Instinct GPU 上で vLLM と AMD Quark を活用し、EAGLE-3 のドラフトモデルをトレーニングして推論する手法について解説します。本稿では、従来の speculative decoding の枠組みを超え、ハードウェア特性に最適化された新しいアプローチを紹介しています。
まず、vLLM のアーキテクチャを活用して、複数のドラフトモデルを並列で実行し、検証プロセスを高速化する仕組みを説明します。AMD Quark は、この環境において計算リソースの効率的な割り当てと、低遅延な推論を実現する鍵となるコンポーネントです。
トレーニングフェーズでは、汎用的な言語モデルを基盤としつつ、特定のタスクやハードウェア構成に特化した微調整(ファインチューニング)を行います。これにより、ドラフトモデルが生成する候補の精度と速度を両立させ、最終的な推論パフォーマンスを最大化します。
また、実運用におけるスケーラビリティについても触れます。大規模な GPU クラスター環境でも安定して動作し、リソース競合を最小限に抑えるための設定例やベストプラクティスを提示しています。これにより、研究開発から本番環境へのスムーズな移行が可能となります。
最後に、今後の展望として、より複雑なモデル構造や新しいハードウェアアーキテクチャへの対応について言及します。EAGLE-3 の技術が、次世代の AI インフラにおいてどのような役割を果たすか、その可能性を探ります。
スペキュレーティブ・ディコーディングを高速化する鍵は、高い採択率を持つドラフトモデルにあります。その訓練はモデル設計の問題であると同時に、システム全体の課題でもあります。当社のパイプラインでは、vLLM は推論エンジンとしてだけでなく、訓練の中核としても機能します。
ここでは、AMD Instinct GPU で訓練した MiniMax-M3 EAGLE-3 ドラフトを具体例として解説します(なお、以下の推論結果で言及されている Kimi-K2.5 や MiniMax-M2.5 の EAGLE-3 ドラフトは、当社が訓練したものではなく、Hugging Face から公開されたオープンソースコミュニティ版です)。
imagevLLM を中核とした EAGLE-3 の訓練・推論パイプライン
Figure 3: vLLM を中核とした EAGLE-3 パイプライン。5 つの工程にわたる一連の流れを、単一の vLLM-on-ROCm ランタイムが支えています。まず Stage 1 では AMD Quark MXFP4/FP8 ターゲットモデルを推論し、オンポリシーデータを合成します。次に Stage 2 でターゲットの隠れ状態(hidden states)を FSDP2 ベースのコールドスタート用ドラフト訓練器へストリーミングし、ループ内での推論評価(serve-eval)を通じて最良のチェックポイントを選定します。その後、Stage 3 でドラフトモデルをエクスポートし、Stage 4 で EAGLE-3 スペキュレーティブ・ディコーディング用にデプロイします。最終的に Stage 5 では、採択長と GPU 単体のスループットを評価します。
- vLLM によるオンポリシーデータ合成。EAGLE-3 のドラフトモデルは、ターゲットの分布内にあるデータから最も効果的に学習します。そこで AMD Quark MXFP4 ターゲットを vLLM-ROCm サーバーとして構築し、オンポリシーな応答を生成します。チャット (/v1/chat/completions) では正確なサービング用チャットテンプレートを使用し、非チャットや分布外データに対する堅牢性を確保するため、テンプレートをバイパスした生テキスト (/v1/completions) も生成します。後で実際にサービス提供する際と同じエンジンとテンプレートでデータを生成することで、トレーニングとサービスの整合性を保ちます。
- vLLM による隠れ状態の抽出。EAGLE-3 はドラフトを、無関係な小規模モデルではなく、ターゲット内部の特徴(低・中・高レベルの隠れ状態および fc_norm)に基づいて条件付けします。vLLM の隠れ状態抽出フックにより、実行中のターゲットエンジンからこれらの補助層を直接取得できます。サポートされているモードは 3 つあり、相互に切り替え可能です。1 つ目はオンラインで、トレーニングとターゲットが同一ノード上に配置される場合です。2 つ目はオフラインで、隠れ状態をディスクにダンプします。3 つ目はストリーミングで、生 vLLM サーバーからディスクを経由せずに隠れ状態をトレーニング側に転送します。このストリーミング機能こそが、420B MXFP4 MoE ターゲットのトレーニングを単一ノード上で現実的なものにする鍵となります。
- コールドスタート FSDP2 によるトレーニング。1 レイヤー構成の EAGLE-3 ドラフトヘッドは、FSDP2 の下でトレーニング時テスト (TTT) ロスと位置減衰重み付けを用いてゼロから学習します。検証器が AMD Quark MXFP4 ターゲットであるため、ドラフトモデルは本番環境で直面する活性化空間に対して正確に学習を行います。
「Serve-eval in the loop」を再び vLLM で実行します。トレーニング中の損失値は実際の受け入れ率を過大評価する傾向があるため、定期的に現在のチェックポイントをエクスポートし、vLLM 上で疑似推論(speculative decoding)を実行して真の平均受け入れトークン数を測定します。そして、この実環境での指標に基づいて最適なチェックポイントを選択します。本番環境で稼働するエンジンと、ドラフトモデルを選定するエンジンは同一です。
エクスポートと vLLM へのデプロイでは、選定されたドラフトモデルを Hugging Face 形式に変換し、vLLM で利用可能なドラフト用ディレクトリに格納します。その後、vLLM-ROCm を用いた EAGLE の疑似推論でデプロイします。これは次節で詳細を測定するパスと完全に一致しています。
vLLM がデータ生成、隠れ状態の抽出、ループ内評価、そしてサービス提供のすべてを担っているため、ドラフトモデルは本番環境のエンジンに対してエンドツーエンドでトレーニングおよび検証されます。これが、トレーニング時に測定した受け入れ率が本番環境でも有効に機能する理由です。
SPEED-Bench におけるドラフト品質:11 のドメインと長文コンテキスト
トレーニング済みの MiniMax-M3 EAGLE-3 ドラフトモデルを、多領域対応の疑似推論ベンチマーク「SPEED-Bench」で評価します。指標には平均受け入れトークン数(AL: Acceptance Length)を採用します。これはターゲット検証ステップごとに生成されるトークンの平均数を示し、値が高いほど高速化効果が高いことを意味します。なお、AL が 1 の場合は速度向上がない状態です。
ドメイン別の受け入れ長(SPEED-Bench 定性評価)
| ドメイン | 受け入れ長 (AL) |
|---|---|
| コーディング | 3.16 |
| 数学 | 3.12 |
| RAG (検索拡張生成) | 3.11 |
| 多言語 | 3.07 |
| 要約 | 2.88 |
| 推論 | 2.87 |
| STEM (科学技術分野) | 2.78 |
| 人文系 | 2.67 |
| QA (質問応答) | 2.57 |
| 文章作成 | 2.29 |
| ロールプレイ | 2.01 |
平均値:2.77
11 のドメイン全体での平均 AL は 2.77、つまりターゲットステップあたり約 2.8 トークンが受け入れられています。特に構造化された技術コンテンツにおいてその性能は顕著で、コーディング(3.16)、数学(3.12)、RAG(3.11)、多言語処理(3.07)と高い数値を記録しています。一方で、あらゆるドラフトモデルにとって予測が最も難しいオープンエンドな文章作成やロールプレイにおいても、AL は 2.0〜2.9 の範囲で安定して維持されています。
さらに重要なのは、プロンプト長が 1K トークンから 32K トークンに拡大しても、受け入れ長がほぼ横ばいである点です(1K で 2.64、32K で 2.63)。つまり、長いコンテキストにおいても速度向上効果が減衰しないことが確認できました。3 つのスペキュレーショントークンを生成する場合、最初のドラフト位置、2 番目、3 番目の受け入れ率はそれぞれ約 75%、55%、41% です。
これらの成果は、vLLM を中核とした私たちのアプローチによるものです。具体的には、ターゲットモデルを通じてオンポリシーデータを生成し、ターゲット自身の特徴量から隠れ状態の監督信号を利用する手法、AMD Quark MXFP4 検証器を正確に想定した冷間開始トレーニング、そして実際のサービス時の受け入れ率に基づいてチェックポイントを選択するという一連のプロセスが奏功しました。(Figure 4)
imageMiniMax-M3 EAGLE-3 の入力長に対する受け入れ長
*Figure 4: SPEED-Bench における MiniMax-M3 EAGLE-3 の受け入れ長は、1K から 32K のコンテキスト範囲でほぼ横ばい(1K で 2.64、32K で 2.63)であり、長いプロンプトでも速度向上効果が減衰しないことを示しています。
One Team, End to End: The AMD Quark Advantage
この研究の顕著な特徴は、ターゲットモデルとドラフトモデルの両方に対するスタック全体を「AMD Quark」という単一のチームが完全に担っている点です。
- ターゲットモデル:day-0 時点での MXFP4/FP8 量子化および ROCm/vLLM によるデプロイメント。
- ドラフトモデル:EAGLE-3 のトレーニング、FP8/MXFP4 量子化、および ROCm/vLLM でのデプロイメント。
- エンドツーエンドの統合:オンポリシーデータ合成、隠れ状態抽出、サービス評価・検証、エクスポート、そして推論加速による serving はすべて vLLM を通じて連携され、一体的に検証されています。
このワンストップ体制により、AMD Instinct ユーザーは、量子化されたターゲットモデルと高受容率のドラフトモデル、さらにチューニング済みの vLLM 推論加速デプロイメントを単一のチームから提供されます。新モデルに対しても Day-0 サポートが用意されており、CUDA ベースのツールを手作業で組み立てる必要はありません。
アクセラレーション結果
以下のドラフト結果セクションでは、1K/1K ワークロード(ISL=1024、OSL=1024)の結果のみを記載します。スピードアップ率は、EAGLE-3 のスループットを、対応する非推論加速ベースラインのスループットで割って算出しています。
Kimi-K2.5 の結果は AMD Instinct MI355X(TP=4)を使用し、ランダムプロンプト、num_prompts=10×並行度、num_warmups=2×並行度、各セルあたり 10 シードで取得したものです。Kimi のチャートでは BF16 と FP8 のドラフトパスを併記しています。BF16 の vLLM v0.19.0 スイープでは MML=2248 を使用し、FP8 スイープでは MML=2304 を使用しています。ここでいう MML(max-model-len)は最大モデル長であり、vLLM モデルが 1 リクエストで処理できるトークンの総数(プロンプト+生成出力)を指します。
Kimi K2.5 EAGLE-3:BF16 と AMD Quark FP8 ドラフト
Docker イメージ:BF16 スイープでは vllm/vllm-openai-rocm:v0.19.0(MML=2248)を、FP8 スイープでは vllm/vllm-openai-rocm:nightly-fb1ac806c55a6dc96fe92261b80c8550e9c39d2f(MML=2304)を使用しています。
対象モデルは amd/Kimi-K2.5-MXFP4 です。BF16 形式のドラフトモデルには lightseekorg/kimi-k2.5-eagle3 を、FP8 形式のドラフトモデルには AMD Quark の FP8 メタデータで量子化し、BF16 版のターゲット言語モデル(LM)ヘッドを共有する amd/kimi-k2.5-eagle3-fp8 を使用します。
この構成では、FP8 ドラフトパスは vLLM の RowWiseTorchFP8ScaledMMLinearKernel(つまり hipBLASLt による行方向スケーリング FP8 GEMM の torch._scaled_mm)を経由して処理されます。これは AITER による事前シャッフル版の FP8 パスとは異なります。一方、ターゲットとなる MXFP4 モデルは、環境変数 VLLM_ROCM_USE_AITER_FP4_ASM_GEMM=1 を設定することで、ROCm の FP4 アセンブリ命令(ASM)パスを利用します。
imageKimi-K2.5 EAGLE-3 処理スループット(AMD Instinct MI355X)
*図 5: AMD Instinct MI355X(TP=4)における Kimi-K2.5 EAGLE-3 の出力スループット(1K/1K、tok/s/GPU)。BF16 と AMD Quark FP8 のドラフトパスは、いずれも speculative なしベースライン(1.69 倍〜1.90 倍および 1.76 倍〜2.00 倍)を上回っています。特に低同時実行時における性能向上が顕著です。
MiniMax M2.5 BF16 EAGLE-3
使用 Docker イメージ: vllm/vllm-openai-rocm:nightly-4eafc729285e459a5fc96efd6f7b313b155cad48
対象モデルは MiniMaxAI/MiniMax-M2.5 です。ドラフトモデルには thoughtworks/MiniMax-M2.5-Eagle3 を使用し、BF16 ドラフトパスで num_speculative_tokens=3、draft_tensor_parallel_size=1 と設定しました。以下の数値は、1K/1K のランダムプロンプトを用いたテスト結果です。TP=4、EP 有効、並行度ごとにシードを 5 つずつ使用し、MiniMax 再現実験と同じベースライン対 EAGLE-3 の構成で測定しています。
image MiniMax-M2.5 の AMD Instinct 上における EAGLE-3 スループット
*図 6: MiniMax-M2.5 の EAGLE-3 出力スループット(tok/s/GPU、1K/1K、TP=4)。BF16 ドラフトパスは、推論なしのベースラインと比較して 1.38 倍から 1.79 倍のスループット向上を示し、特に並行度が低い環境でその効果が顕著です。
Kimi-K2.5 の 1K/1K スイープ全体では、BF16 ベースの EAGLE-3 ドラフトパスが推論なしベースラインに対して 1.69 倍から 1.90 倍のスループット向上をもたらしました。一方、AMD Quark を用いた FP8 ベースの EAGLE-3 ドラフトパスでは、1.76 倍から 2.00 倍の向上が確認されています(図 5)。MiniMax-M2.5 の場合も同様に、BF16 ドラフトパスは並行度 64 から 4 の範囲でベースラインに対し 1.38 倍から 1.79 倍のスループットを実現しました(図 6)。Kimi における FP8 ドラフトパスには、現在統合されている RowWise hipBLASLt ベースの FP8 ドラフトカーネルパスが採用されています。
EAGLE-3 のスペキュレティブ・ディコーディング(推論加速技術)を AMD Instinct GPU で活用すれば、Kimi-K2.5 では 1.69 倍から 2.00 倍、MiniMax-M2.5 では最大 1.79 倍ものスループット向上を実現できます。これは 1K/1K の評価スウィープで確認された結果です。
この技術が実用的なエンドツーエンドのソリューションとなる理由は、3 つの要素が統合されている点にあります。まず、ターゲットモデルとドラフトモデルの両方で AMD Quark が提供する日付ゼロ(Day-0)対応の MXFP4/FP8 量子化を採用していること。次に、オンポリシーデータの合成や隠れ状態の抽出を行い、実際のサービス環境での受け入れ率に基づいてチェックポイントを選定する vLLM を中核としたトレーニングパイプラインです。そして最後に、ROCm と vLLM を組み合わせたスペキュレティブ・ディコーディングによる推論実行です。
ターゲットとドラフトの両方において、量子化からトレーニング、デプロイメントまでを AMD Quark チームが一元管理しているため、AMD Instinct ユーザーは手作業で部品を組み立てるようなものではなく、一貫性のある日付ゼロ対応のスペキュレティブ・ディコーディングスタックを利用できます。
謝辞
本研究成果は、vLLM エコシステムを AMD 上で強化するものです。具体的には、EAGLE-3 のスペキュレティブ・ディコーディングに対する ROCm バックエンドのカバー範囲拡大、再現可能なトレーニングと推論のレシピ提供、すぐに使えるドラフトモデルの公開、そして上流プロジェクトへの協力を促す明確な道筋を示しました。
AMD Quark チーム、AMD ROCm と vLLM の貢献者、InferenceX のメンテナーおよびレビュアー、そして EAGLE-3 研究コミュニティの皆様に感謝申し上げます。特に、InferenceX における EAGLE-3 ベンチマーク統合への貢献があった AMD Andy Luo チームの Haichen Zhang 氏、Chun Fang 氏、Chang Liu 氏に特別な謝意を表します。
追加リソース
- EAGLE-3 プロジェクト
- AMD Quark
- vLLM
原文を表示
Large language model (LLM) inference is increasingly constrained by autoregressive decoding. Even when prefill is highly optimized, the decode phase still generates tokens one step at a time, and each step typically requires running the full target model. For large mixture-of-experts and attention-heavy models such as Kimi-K2.5 and MiniMax-M2.5, this sequential pattern limits serving throughput and increases latency for real-time applications.
Speculative decoding is one of the most practical ways to address this bottleneck. It is a lossless LLM inference acceleration technique that preserves the exact output distribution of the target model while improving decoding efficiency. It uses a smaller or lighter-weight draft model to propose multiple future tokens, then asks the original target model to verify those tokens in a single forward pass. When the draft model predicts tokens that the target model would also produce, those tokens can be accepted together, reducing the number of expensive target-model decode iterations.
Common speculative decoding approaches include small draft models, multi-token prediction (MTP), Medusa-style multi-head prediction, and feature-level drafting methods such as EAGLE-3, DFlash, and the recently introduced DSpark. Among existing speculative decoding methods, EAGLE-3 is particularly attractive due to its strong draft quality, high acceptance rate, and consistently competitive inference speedups.
In this blog, we walk through the complete EAGLE-3 lifecycle on AMD Instinct GPUs, all built on vLLM and delivered end to end by the AMD Quark team: (1) training EAGLE-3 draft models, where vLLM serves the target to synthesize on-policy data, extract training-time hidden states, and run in-the-loop acceptance evaluation; (2) AMD Quark quantization, which provides day-0 MXFP4 and FP8 support for both the target and the draft; and (3) inference acceleration on ROCm/vLLM for Kimi-K2.5 and MiniMax-M2.5 on AMD Instinct™ MI355X GPUs, benchmarked with InferenceX. The same pipeline was used to train our MiniMax-M3 EAGLE-3 draft, which we use as the running example in the training section.
Why Speculative Decoding and EAGLE-3 Matter
Standard autoregressive decoding emits one token per target-model step. If a model needs to generate 1,000 output tokens, the serving engine typically performs roughly 1,000 target-model decode iterations after prefill. This is expensive because each decode iteration touches the model weights, attention state, scheduler, and KV cache machinery.
Speculative decoding changes this process:
- A draft model proposes several candidate next tokens.
- The target model verifies those candidates in one pass.
- Tokens that match the target model distribution are accepted.
- Generation continues from the first rejected token, or from the end of the accepted block.
The key metric is the acceptance rate: how many draft tokens the target model can accept. Imagine the draft model proposes the next four tokens: if the target model agrees with all four, they can be accepted in a single verification step; if it disagrees on the third token, only the first two are accepted, and the remaining tokens must be regenerated. The more tokens that are accepted at a time, the fewer expensive decoding steps the target model needs to perform, resulting in higher throughput. Importantly, every draft token is checked by the target model before being emitted, so speculative decoding speeds up inference without changing the final output quality. (Figure 1)

*Figure 1: How speculative decoding works — the draft proposes γ tokens, the target verifies them in a single pass, the matching prefix (α) is accepted and α+1 tokens are emitted, and drafting resumes from the first rejected token. Every emitted token is verified, so the speedup is lossless.*
EAGLE has been continuously improving over the past few years. It started with feature-level speculative decoding in EAGLE, improved draft quality and acceptance rates in EAGLE-2, and further increased accuracy and speedups in EAGLE-3 by leveraging multi-layer features from the target model. Instead of relying on an unrelated small language model, it trains a draft module that is closely aligned with the target model. It uses training-time testing techniques and combines low-, mid-, and high-level semantic features from the target model, helping the draft model propose candidates that the verifier is more likely to accept.
For production inference, the important point is simple: EAGLE-3 can improve generation throughput while preserving the target model output behavior through verification.
AMD Quark MXFP4: Day-0 Quantization for Mainstream LLMs
MXFP4 is the Open Compute Project (OCP) Microscaling 4-bit floating-point format: 4-bit elements are grouped into small blocks that share a scale factor, giving a memory footprint close to INT4 while keeping far better numerical behavior. AMD Instinct MI350-series GPUs (MI350X/MI355X) provide native FP4 matrix acceleration, so MXFP4 weights map directly onto the hardware and relieve the memory-bandwidth and capacity pressure that dominates large mixture-of-experts decoding.
AMD Quark is AMD’s model-quantization toolkit, and the Quark team provides day-0 MXFP4 quantized checkpoints for mainstream LLMs, published on Hugging Face (for example, amd/Kimi-K2.5-MXFP4 and amd/MiniMax-M3-MXFP4). Day-0 means that when a major model is released, the Quark team ships a hardware-ready MXFP4 (and FP8) build that runs on ROCm/vLLM out of the box, rather than waiting for third-party quantization to catch up. These published checkpoints are ready to use directly as the target for both EAGLE-3 draft training and speculative-decoding inference.
These checkpoints are consumed directly by vLLM on ROCm through the FP4 ASM GEMM path (VLLM_ROCM_USE_AITER_FP4_ASM_GEMM=1) and AITER MoE kernels, so users get the memory savings of MXFP4 together with production-grade throughput. Speculative decoding is lossless: every draft token is verified against the served target, so it leaves the target’s output distribution unchanged. (Figure 2)

*Figure 2: AMD Quark day-0 quantization flow — when a mainstream LLM ships, the Quark team releases an MXFP4/FP8 build on Hugging Face that vLLM on ROCm serves directly.*
Training EAGLE-3 Draft Models with vLLM
A high-acceptance draft is what makes speculative decoding fast, and training one is as much a systems problem as a modeling problem. In our pipeline, vLLM is not just the inference engine — it sits at the center of training too. We use the MiniMax-M3 EAGLE-3 draft we trained on AMD Instinct GPUs as the running example. (The Kimi-K2.5 and MiniMax-M2.5 EAGLE-3 drafts in the inference results below are open-source community drafts from Hugging Face, not trained by us.) (Figure 3)

*Figure 3: The vLLM-centric EAGLE-3 pipeline. A single vLLM-on-ROCm runtime powers the whole loop across five stages — it serves the AMD Quark MXFP4/FP8 target to synthesize on-policy data (Stage 1), streams the target hidden states to the FSDP2 cold-start draft trainer and runs in-loop serve-eval to select the best checkpoint (Stage 2), after which the draft is exported (Stage 3), deployed for EAGLE-3 speculative decoding (Stage 4), and evaluated for acceptance length and per-GPU throughput (Stage 5).*
- On-policy data synthesis, served by vLLM. EAGLE-3 drafts learn best from data in the target’s own distribution. We stand up the AMD Quark MXFP4 target as a vLLM-ROCm server and generate on-policy responses through it — both chat (/v1/chat/completions, using the exact serving chat template) and raw /v1/completions (template-bypassed) for non-chat and out-of-distribution robustness. Generating data with the same engine and template we later serve with keeps training and serving consistent.
- Hidden-state extraction, provided by vLLM. EAGLE-3 conditions the draft on the target’s internal features — low-, mid-, and high-level hidden states plus an fc_norm — rather than on an unrelated small model. vLLM’s hidden-state extraction hook exposes these auxiliary layers directly from the running target engine. We support three interchangeable modes: online (target co-located with the trainer), offline (hidden states dumped to disk), and streaming (hidden states streamed from a live vLLM serve to the trainer with no disk dump). Streaming is what makes training a 420B MXFP4 MoE target practical on a single node.
- Cold-start FSDP2 training. The single-layer EAGLE-3 draft head is trained from scratch with a training-time-test (TTT) loss and position-decay weighting under FSDP2. Because the verifier is the AMD Quark MXFP4 target, the draft learns against exactly the activation space it will face at deploy time.
- Serve-eval in the loop, again on vLLM. The in-training loss overstates real acceptance, so we periodically export the current checkpoint, serve it under vLLM speculative decoding, measure the true acceptance length, and select the best checkpoint by that served metric. The engine that will run in production is the same engine that picks the draft.
- Export and deployment on vLLM. The selected draft is exported to Hugging Face format, folded into a vLLM-ready draft directory, and deployed with vLLM-ROCm EAGLE speculative decoding — the exact path measured in the next section.
Because vLLM drives data generation, hidden-state extraction, in-loop evaluation, and serving, the draft is trained and validated against its production engine end to end — which is exactly why the acceptance we measure in training holds up in production.
Draft quality on SPEED-Bench: 11 domains and long context
We evaluate the trained MiniMax-M3 EAGLE-3 draft on SPEED-Bench, a multi-domain speculative-decoding benchmark, using acceptance length (AL) — the mean number of tokens emitted per target verification step (higher is better; AL = 1 means no speedup).
Acceptance length by domain (SPEED-Bench qualitative):
DomainAcceptance length (AL)
Coding3.16
Math3.12
RAG3.11
Multilingual3.07
Summarization2.88
Reasoning2.87
STEM2.78
Humanities2.67
QA2.57
Writing2.29
Roleplay2.01
Average2.77
Across 11 domains the draft averages AL 2.77 — roughly 2.8 accepted tokens per target step. It is strongest on structured, technical content — coding (3.16), math (3.12), RAG (3.11), and multilingual (3.07) — and still holds AL 2.0-2.9 on open-ended writing and roleplay, the hardest cases for any draft to predict. Just as important, acceptance length is essentially flat as the prompt grows from 1K to 32K tokens (2.64 to 2.63), so the speedup does not decay on long context. At three speculative tokens, the first, second, and third draft positions are accepted about 75%, 55%, and 41% of the time (cumulative). These results are the payoff of our vLLM-centric recipe: on-policy data generated through the target, hidden-state supervision from the target’s own features, cold-start training against the exact AMD Quark MXFP4 verifier, and checkpoint selection by real served acceptance. (Figure 4)

*Figure 4: MiniMax-M3 EAGLE-3 acceptance length is essentially flat from 1K to 32K context on SPEED-Bench (2.64 at 1K to 2.63 at 32K) — the speedup does not decay on long prompts.*
One Team, End to End: The AMD Quark Advantage
A distinctive aspect of this work is that a single team — AMD Quark — owns the entire stack for both the target and the draft model:
- Target model: day-0 MXFP4/FP8 quantization and ROCm/vLLM deployment.
- Draft model: EAGLE-3 training, FP8/MXFP4 quantization, and ROCm/vLLM deployment.
- End-to-end integration: on-policy data synthesis, hidden-state extraction, serve-eval, export, and speculative serving are all wired through vLLM and validated together.
This one-stop ownership means that customers on AMD Instinct receive a quantized target, a matching high-acceptance draft, and a tuned vLLM speculative-decoding deployment from a single team — with day-0 support for new models — instead of hand-assembling CUDA-centric tooling.
Acceleration Results
The following draft results section lists only the 1K/1K workload, with ISL=1024 and OSL=1024. Speedup is computed as EAGLE-3 throughput divided by the corresponding no-speculative-decoding baseline throughput. Kimi-K2.5 results use AMD Instinct MI355X, TP=4, random prompts, num_prompts=10 x concurrency, num_warmups=2 x concurrency, and 10 seeds per cell. The Kimi chart shows the BF16 and FP8 draft paths together; the BF16 vLLM v0.19.0 sweep uses MML=2248, while the FP8 sweep uses MML=2304. Here, MML (max-model-len) is the maximum context length — the total number of tokens (prompt + generated output) that a vLLM model can process in a single request.
Kimi K2.5 EAGLE-3: BF16 and AMD Quark FP8 Drafts
Docker images: BF16 sweep uses vllm/vllm-openai-rocm:v0.19.0 (MML=2248); FP8 sweep uses vllm/vllm-openai-rocm:nightly-fb1ac806c55a6dc96fe92261b80c8550e9c39d2f (MML=2304).
Target model: amd/Kimi-K2.5-MXFP4. BF16 draft model: lightseekorg/kimi-k2.5-eagle3. FP8 draft model: amd/kimi-k2.5-eagle3-fp8, quantized with AMD Quark FP8 metadata and sharing the BF16 target LM head. In this setup, the FP8 draft path dispatches through vLLM RowWiseTorchFP8ScaledMMLinearKernel, i.e. torch._scaled_mm over hipBLASLt row-wise scaled FP8 GEMM, rather than the AITER preshuffled FP8 path. The target MXFP4 model uses the ROCm FP4 ASM path via VLLM_ROCM_USE_AITER_FP4_ASM_GEMM=1.

*Figure 5: Kimi-K2.5 EAGLE-3 output throughput (tok/s/GPU) at 1K/1K on AMD Instinct MI355X (TP=4). Both the BF16 and AMD Quark FP8 draft paths beat the no-speculative baseline (1.69x-1.90x and 1.76x-2.00x respectively); the gain is largest at low concurrency.*
MiniMax M2.5 BF16 EAGLE-3
Docker image: vllm/vllm-openai-rocm:nightly-4eafc729285e459a5fc96efd6f7b313b155cad48
Target model: MiniMaxAI/MiniMax-M2.5. Draft model: thoughtworks/MiniMax-M2.5-Eagle3, BF16 draft path with num_speculative_tokens=3 and draft_tensor_parallel_size=1. The numbers below use 1K/1K random prompts, TP=4/EP enabled, and 5 seeds per concurrency, with the same baseline-vs-EAGLE-3 setup used for the MiniMax reproduction.

*Figure 6: MiniMax-M2.5 EAGLE-3 output throughput (tok/s/GPU) at 1K/1K (TP=4). The BF16 draft path delivers 1.38x-1.79x over the no-speculative baseline, again strongest at low concurrency.*
Across the Kimi-K2.5 1K/1K sweep, the BF16 EAGLE-3 draft path delivers 1.69x to 1.90x throughput over the no-speculative-decoding baseline, while the AMD Quark FP8 EAGLE-3 draft path delivers 1.76x to 2.00x throughput (Figure 5). For MiniMax-M2.5, the BF16 EAGLE-3 draft path delivers 1.38x to 1.79x throughput over baseline across concurrency 64 to 4 (Figure 6). The FP8 draft path for Kimi uses the currently integrated RowWise hipBLASLt FP8 draft-kernel path.
Summary
Speculative decoding with EAGLE-3 delivers lossless, significant throughput gains on AMD Instinct GPUs — 1.69x to 2.00x for Kimi-K2.5 and up to 1.79x for MiniMax-M2.5 in our 1K/1K sweeps. What makes this practical end to end is the combination of (1) AMD Quark day-0 MXFP4/FP8 quantization for both target and draft, (2) a vLLM-centric training pipeline that synthesizes on-policy data, extracts hidden states, and selects checkpoints by real served acceptance, and (3) ROCm/vLLM speculative serving. Because a single team — AMD Quark — owns quantization, training, and deployment for both target and draft, AMD Instinct users get a coherent, day-0 speculative-decoding stack rather than a hand-assembled one.
Acknowledgements
This work strengthens the vLLM ecosystem on AMD: it adds ROCm backend coverage for EAGLE-3 speculative decoding, reproducible training and serving recipes, a ready-to-use draft model, and clear paths for upstream collaboration.
We would like to thank the AMD Quark team, the AMD ROCm and vLLM contributors, the InferenceX maintainers and reviewers, and the EAGLE-3 research community for their work and feedback. Special thanks to AMD Andy Luo’s team members including Haichen Zhang, Chun Fang, and Chang Liu for their contributions to the InferenceX EAGLE-3 benchmark integration.
Additional Resources
- EAGLE-3 project
- AMD Quark
- vLLM
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み