vLLM、推測的デコーディングによる並列処理手法「Parallel All the Way Down」を発表
vLLM と Speculators が P-EAGLE、DFlash、DSpark の三つの最先端並列ドラフティングアルゴリズムを正式にサポートし、RedHatAI HuggingFace Hub で利用可能になった。
AI深層分析を開く2026年7月29日 06:52
AI深層分析
キーポイント
並列ドラフティングアルゴリズムのオープンソース化
vLLM と Speculators が P-EAGLE、DFlash、DSpark の三つの最先端並列ドラフティングアルゴリズムを正式にサポートし、RedHatAI HuggingFace Hub で利用可能になった。
推論速度のボトルネック解消
従来の逐次ドラフト生成に起因する構造的限界を超え、単一の検証モデル順方向パスで複数の候補トークンを検証することで、大規模言語モデル(LLM)サービスのメモリ帯域幅ボトルネックを緩和する。
既存手法との性能比較
P-EAGLE や DFlash などの並列ドラフティングアルゴリズムは、EAGLE-3 などの逐次生成ドラフティングアルゴリズムと比較して、数学的推論やコード生成タスクにおいて顕著なパフォーマンス向上を示す。
再帰的ドラフトの根本的な制約
EAGLE-3などの先進的な手法も依然として自己回帰的ドラフトに依存しており、候補トークン列を生成する際にトークンごとに順次フォワードパスを実行しなければならない。
モデルサイズと運用のトレードオフ
ドラフティングコストが推測長さに比例して線形増加するため、検証時間の節約を相殺しないようモデルを極小化する必要がある。また、最適な推測長(K)の設定は使用ケースやサーバー負荷に応じて頻繁な調整を要する複雑な運用課題となる。
重要な引用
Speculative decoding has emerged as a core optimization technique for mitigating memory-bandwidth bottlenecks in Large Language Model (LLM) serving.
Today, we are excited to showcase how Speculators and vLLM are moving beyond these limitations by providing full open-source support for three state-of-the-art parallel drafting algorithms: P-EAGLE, DFlash and DSpark.
To propose a sequence of candidate tokens, the speculator architecture must generate them sequentially, executing a separate forward pass for every single token.
Because the drafting cost scales linearly with the speculation length, speculator models are forced to remain extremely small and lightweight to avoid consuming the execution time saved during verifier-model verification.
編集コメントを表示
編集コメント
並列ドラフティング技術の実用化は、大規模モデルの運用コスト削減において極めて重要なステップである。vLLM がこれらのアルゴリズムをオープンソースとして公開したことは、開発コミュニティにおける性能競争をさらに加速させる要因となるだろう。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
1. イントロダクション
スペキュレティブ・ディコーディング(推測デコーディング)は、大規模言語モデル(LLM)のサービスにおけるメモリ帯域幅のボトルネックを緩和する中核的な最適化技術として確立されました。検証用モデルによる単一の順方向計算で複数の候補トークンを同時に検証できるため、実システムでも大幅な推論速度の向上を実現しています。
しかし、インフラストラクチャが進化する中で、従来のスペキュレティブ・フレームワークは、ドラフトトークンの生成方法に起因する構造的な限界に直面しています。そこで今回、Speculators と vLLM が、これらの限界を突破し、最先端の並列ドラフトアルゴリズム 3 つに対して完全なオープンソースサポートを提供することを発表できることを嬉しく思います。それが P-EAGLE、DFlash、そして DSpark です。
image図 1. P-EAGLE、DFlash、DSpark などの並列ドラフト生成アルゴリズムは、EAGLE-3 に代表される逐次ドラフト生成アルゴリズムと比較して、大幅な性能向上をもたらします。上記のスペキュレーターモデルは、RedHatAI HuggingFace Hub の Speculators Collection で確認できます。
image図 1. P-EAGLE、DFlash、DSpark などの並列ドラフト生成アルゴリズムは、EAGLE-3 に代表される逐次ドラフト生成アルゴリズムと比較して、大幅な性能向上をもたらします。上記のスペキュレーターモデルは、RedHatAI HuggingFace Hub の Speculators Collection で確認できます。
image図 1. P-EAGLE、DFlash、DSpark などの並列ドラフト生成アルゴリズムは、EAGLE-3 に代表される逐次ドラフト生成アルゴリズムと比較して、大幅な性能向上をもたらします。上記のスペキュレーターモデルは、RedHatAI HuggingFace Hub の Speculators Collection で確認できます。
2. 再帰的ドラフトの限界
EAGLE や MTP といったフレームワークの登場は、推測的デコーディング(speculative decoding)における大きなパラダイムシフトを意味しました。これらは、推定モデルが表面的なテキストから盲目的に予測するよう強制する従来の手法とは異なり、EAGLE は推定アーキテクチャが検証モデルの豊かな内部隠れ状態(hidden states)に直接アクセスできることを示し、トークンの受容率を劇的に向上させました。
この画期的な進展にもかかわらず、EAGLE-3 といった高度な後継バージョンでも、依然として根本的な制約である「自己回帰的ドラフト生成(auto-regressive drafting)」の下で動作しています。候補となるトークン系列を提案するためには、推定アーキテクチャがそれらを順次生成する必要があり、各トークンごとに個別のフォワードパスを実行しなければなりません。
この自己回帰的な設計は、実運用において以下の 2 つの重大なトレードオフをもたらします。
- モデルサイズの制約:ドラフトにかかるコストが推測長さに比例して増加するため、検証モデルによる確認で節約された実行時間を帳消しにしないよう、推定モデルは極めて小さく軽量なものに制限せざるを得ません。
- 複雑な運用チューニング:線形スケーリングの制約により、実務上でドラフトできるトークン数は大きく制限されます。最適な推測長(K)の選択は、特定のユースケースやリアルタイムのサーバー負荷に応じてエンジニアリングチームが絶えず調整しなければならない敏感な変数となっています。
image図 2: パラレルドラフトでは、1 ステップで複数の候補トークンを生成するのに対し、自己回帰型ドラフトでは 1 ステップごとに 1 トークンずつ生成します。
3. パラレルドラフトへの転換
パラレルドラフトは、ドラフトフェーズでの逐次実行を完全に排除することで、このトレードオフを根本から再構築します。単一のトークンを生成するステップをループさせるのではなく、パラレルドラフトアルゴリズムでは候補となるトークンのブロック全体を並列に予測します。
ドラフトフェーズを 1 つの順方向パス(フォワードパス)に集約することで、提案トークンの生成にかかるレイテンシが、推定するトークン数から独立します。このアーキテクチャ上の転換は、生産環境でのサービス提供を以下の 2 つの点で簡素化します。
- 表現力の向上: スペキュレーターモデルがブロックごとに 1 回だけ実行されるため、開発者はより大規模で堅牢性が高く、表現力豊かなドラフトアーキテクチャを利用できます。こうした深層のスペキュレーターモデルは、逐次的なレイテンシのペナルティを導入することなく、より複雑な文脈を捉え、高い採択率を実現します。
- パラメータ調整の簡素化: ドラフトコストとブロック長の関係が独立することで、サーバー負荷の変動に応じて推定パラメータを手動で微調整する運用上の負担がなくなります。
並列ドラフト生成の概念自体は以前から研究されており、Medusa や PARD がその代表的な先例です。これらに続く P-EAGLE、DFlash、DSpark は、EAGLE の成功要因となった「検証器の内部状態(hidden states)を活用する」という洞察を踏まえつつ、並列実行と組み合わせることでさらに発展させたモデルです。
4. 仕組みの深層:推論・トレーニングアーキテクチャ
P-EAGLE、DFlash、そして DSpark はすべて、検証器モデルの内部状態を元にドラフトトークンを並列生成する点で共通していますが、その実現方法にはそれぞれ独自のアプローチがあります。図 3 ではこれら 3 つのアーキテクチャが比較されています。
image図 3. P-EAGLE、DFlash、DSpark の比較。P-EAGLE は検証器からの内部状態を、スペキュレーターモデルの入力として取り込みます。DFlash は内部状態を KV キャッシュへ投影します。DSpark は DFlash をベースに、逐次補正機能と信頼度推定機能を追加した構成です。
これら 3 つの手法に共通する課題がトレーニングです。並列スペキュレーターは、学習シーケンス上のすべてのトークン位置で「次の K トークンを予測」する必要があります。シーケンス長を N、先読みウィンドウを K とすると、単純に全行列に対して損失を計算しようとすると、メモリと計算コストが現実的な範囲を超えて増大してしまいます。各アルゴリズムはこの課題に対し、異なるアプローチで対応しています。
P-EAGLE
P-EAGLE は、検証モデルの隠れ状態を入力特徴量として活用するという EAGLE の基盤をそのまま踏襲しています。しかし、これらの特徴量を逐次消費してトークンを予測するのではなく、複数の未来位置に同時にマッピングし、単一の並列ステップで候補トークンのシーケンス全体を出力します。
学習の扱いやすさを保つため、P-EAGLE はドラフトブロックのスパース化を実装しています。これは、先読み次元(K)に沿ってトークンを一定の減衰率で削除し、最適化の焦点を最も重要な直近のトークンに集中させつつ、損失計算から遠くの未来位置を剪定する手法です。
DFlash
DFlash は検証特徴量のルーティング方法を変えています。隠れ状態を標準的な入力として渡すのではなく、投影して speculator モデルの KV キャッシュへ直接注入します。これにより、入力シーケンス長を増やすことなく、speculator のアテンション機構を検証モデルの状態に厳密に条件付けできます。その結果、ブロック拡散を通じて高精度な候補トークンのブロックを生成することが可能になります。
学習においては、DFlash はシーケンス長のスパース化を実装しています。長さ N のシーケンス全体で各トークン位置におけるブロック損失を計算するのではなく、タイムライン上のランダムなアンカーポイントを選択し、これらの交差点でのみブロック予測を計算します。これにより GPU メモリを節約しつつ、代表的なカバレッジを維持します。
DSpark
DSpark は DFlash の並列バックボーンを基盤とし、さらに 2 つの独自技術を追加しました。まず、軽量な自己回帰補正ヘッド(autoregressive correction head)をアーキテクチャに統合し、未来のトークンが過去のトークンにもっと強く依存するように条件付けられるようにしました。これにより、並列生成のスループットメリットと、自己回帰的な微調整による逐次一貫性を両立させています。
2 つ目の課題は、推論後の検証コストです。並列ドラフティングでは安価に多くのドラフトトークンを生成できますが、検証側(verifier)はそれらすべてを処理する必要があります。DSpark は検証前にドラフトトークンの信頼度をスコアリングする「信頼度ヘッド」を導入し、受け入れられる可能性が高いトークンだけを検証側に転送します。これにより、無駄な計算リソースの消費を防ぎ、エンドツーエンドのスループットが向上しました。
5. 推論パフォーマンス
図 1 は、EAGLE-3 と比較した並列ドラフティングアルゴリズムによる性能向上を示しています。ここでは 3 つの異なるモデルと、それぞれに対応する並列ドラフティングアルゴリズムを紹介しています。
| モデル | アルゴリズム | ユースケース | ハードウェア |
|---|---|---|---|
| Qwen3-8B | P-EAGLE | 数式推論 (GSM8k) | 1xA100 |
| Qwen3-30B-A3B | DFlash | コーディング (HumanEval) | 2xA100 |
| gemma-4-31B-it | DSpark | コーディング (HumanEval) | 2xA100 |
いずれの場合も、並列ドラフト生成は EAGLE-3 を大きく上回る性能を示します。モデルやタスク、ハードウェア構成によって効果の度合いは異なりますが、ぜひご自身のワークロードでベンチマークを実施していただくことをお勧めします。
6. vLLM と Speculators を活用した本番環境での運用
最先端の並列ドラフト生成アルゴリズムを実際のサービスに組み込むには、安定した最適化済みのインフラスタックが不可欠です。Speculators リポジトリは、これらの次世代モデルをトレーニング・評価するための統一されたエコシステムを提供しており、vLLM と完全に連携しています。
並列バックドの推論エンジンを起動するのは、初期化時に適切な設定フラグを渡すだけと非常に簡単です:
vllm serve Qwen/Qwen3-30B-A3B \
--tensor-parallel-size 2 \
--reasoning-parser qwen3 \
--speculative-config '{
"model": "RedHatAI/Qwen3-30B-A3B-speculator.dflash",
"num_speculative_tokens": 7,
"method": "dflash"
}'
単一トークンの生成からブロックレベルの並列ドラフト生成へと移行することで、推論パイプライン全体が並列化され、ハードウェアの利用効率が最大化されます。これにより、損失のない持続的な高速化を実現できます(拒否サンプリングを通じて検証モデルの出力分布を正確に維持するため、品質は標準的なデコーディングと数学的に同等です)。
7. はじめに
並列ドラフト機能は、今日では完全にサポートされており、オープンソースで本番環境でもすぐに利用可能です。コミュニティの皆様には、リポジトリの探索や、ドキュメントに記載されたトレーニングパスを活用して独自の並列推論器(speculators)を構築し、vLLM 上でネイティブにベンチマークすることをご提案します。
- リポジトリ:Speculators
- 事前学習済み推論器:HuggingFace の Speculators Collection
- トレーニングガイド:Speculator tutorials
原文を表示
1. Introduction
Speculative decoding has emerged as a core optimization technique for mitigating memory-bandwidth bottlenecks in Large Language Model (LLM) serving. By validating multiple candidate tokens in a single verifier-model forward pass, it allows production systems to achieve substantial inference speedups.
However, as serving infrastructure evolves, traditional speculative frameworks face a structural ceiling rooted in the way draft tokens are generated. Today, we are excited to showcase how Speculators and vLLM are moving beyond these limitations by providing full open-source support for three state-of-the-art parallel drafting algorithms: P-EAGLE, DFlash and DSpark.



2. The Limits of Recursive Drafting
The introduction of frameworks like EAGLE and MTP marked a major paradigm shift in speculative decoding. Instead of forcing the speculator model to guess blindly from surface-level text, EAGLE demonstrated that a speculator architecture could tap directly into the verifier model’s rich internal hidden states, dramatically increasing token acceptance rates.
Despite this breakthrough, advanced iterations like EAGLE-3 still operate under a fundamental constraint: auto-regressive drafting. To propose a sequence of candidate tokens, the speculator architecture must generate them sequentially, executing a separate forward pass for every single token.
This auto-regressive design introduces two major trade-offs in production:
- Constraints on Model Size: Because the drafting cost scales linearly with the speculation length, speculator models are forced to remain extremely small and lightweight to avoid consuming the execution time saved during verifier-model verification.
- Complex Operational Tuning: Linear scaling heavily limits the number of drafted tokens in practice. Choosing the optimal speculation length (K) becomes a sensitive variable that engineering teams must constantly adjust depending on the specific use case and real-time server loading.

3. The Shift to Parallel Drafting
Parallel drafting fundamentally re-engineers this trade-off by eliminating sequential execution from the drafting phase entirely. Rather than looping through single-token generation steps, parallel drafting algorithms predict an entire candidate block of tokens concurrently.
By flattening the drafting phase into a single forward pass, the latency of generating proposals is decoupled from the number of tokens speculated. This architectural shift simplifies production serving in two distinct ways:
- Capacity for Expressiveness: Because the speculator model only runs once per block, developers can utilize larger, more robust, and more expressive draft architectures. These deeper speculator models capture more complex context and yield higher acceptance rates without introducing a sequential latency penalty.
- Simplified Parameter Tuning: Decoupling drafting cost from block length removes he operational burden of hyper-tuning speculation parameters based on fluctuating server loads.
Parallel drafting as a concept has been explored before — Medusa and PARD are notable earlier examples. P-EAGLE, DFlash, and DSpark build on this foundation by combining parallel execution with deep verifier-state conditioning, the insight that made EAGLE so successful.
4. Under the Hood: Inference & Training Architecture
P-EAGLE, DFlash, and DSpark all build upon the verifier model's hidden states to generate draft tokens in parallel, but each takes a different path to get there. Figure 3 illustrates their architectures side-by-size.

A shared challenge across all three is training. Any parallel speculator must perform next-K prediction at every token position along a training sequence. For a sequence of length N and a lookahead window of K, naively computing losses across the full matrix causes memory and compute costs to scale prohibitively. Each algorithm addresses this differently.
P-EAGLE
P-EAGLE builds directly on EAGLE's foundation of using the verifier model's hidden states as input features. Instead of consuming those features to predict tokens sequentially, P-EAGLE maps them across multiple future positions simultaneously, outputting an entire sequence of candidate tokens in a single parallel step.
To keep training tractable, P-EAGLE implements draft block sparsification: it drops tokens along the lookahead dimension (K) according to a decaying rate, concentrating optimization on the most critical immediate tokens while pruning distant future positions from the loss calculation.
DFlash
DFlash routes verifier features differently. Rather than feeding hidden states in as standard inputs, DFlash projects them and injects them directly into the KV-cache of the speculator model. This tightly conditions the speculator's attention mechanism on the verifier's exact state without expanding the input sequence length, enabling it to generate a highly accurate block of candidate tokens via block diffusion.
For training, DFlash implements sequence length sparsification. Instead of calculating block loss at every token position across a sequence of length N, it selects random anchor points along the timeline and computes block predictions exclusively at these intersections — preserving GPU memory while maintaining representative coverage.
DSpark
DSpark takes DFlash's parallel backbone and layers two additional innovations on top. First, it augments the architecture with a lightweight autoregressive correction head, allowing future tokens to be more strongly conditioned on past tokens. This combines the throughput benefits of parallel generation with the sequential coherence of autoregressive refinement.
Second, DSpark addresses a downstream bottleneck: verification cost. Parallel drafting can generate many draft tokens inexpensively, but the verifier must still process all of them. DSpark introduces a confidence head that scores draft tokens before they reach the verifier, selectively forwarding only those likely to be accepted. This reduces wasted verification compute and improves end-to-end throughput.
5. Inference Performance
Figure 1 illustrates the performance gains provided by parallel drafting algorithms when compared to EAGLE-3. Three distinct models and parallel drafting algorithms are displayed:
ModelAlgorithmUse caseHardware
Qwen3-8BP-EAGLEMath reasoning (GSM8k)1xA100
Qwen3-30B-A3BDFlashCoding (HumanEval)2xA100
gemma-4-31B-itDSparkCoding (HumanEval)2xA100
In all cases, parallel drafting shows significant improvement over EAGLE-3. Performance will vary across models, tasks, and hardware configurations — we encourage the community to benchmark on their own workloads.
6. Production Serving with vLLM and Speculators
Integrating state-of-the-art parallel drafting algorithms into production requires a stable, optimized infrastructure stack. The Speculators repository provides a unified ecosystem to train and evaluate these next-gen models, fully integrated with vLLM.
Launching a parallel-backed speculative engine is as straightforward as passing the appropriate configuration flags at initialization:
By moving from single-token generation to block-level parallel drafting, your inference pipeline becomes parallel all the way down—maximizing hardware utilization and delivering sustained, lossless acceleration. (Speculative decoding preserves the verifier model's output distribution exactly via rejection sampling, so quality is mathematically identical to standard decoding.)
7. Get Started
Parallel drafting is fully supported, open-source, and production-ready today. We invite the community to explore the repository, utilize our documented training pathways to build your own parallel speculators, and benchmark them natively in vLLM.
- Repository: Speculators
- Pre-trained speculators: Speculators Collection on HuggingFace
- Training guides: Speculator tutorials
AI算出
主要ニュースainew評価標準
本記事は vLLM が独自に開発した並列処理手法と関連アルゴリズムの公開という具体的な技術的イノベーションを報じており、AI/ML の核心テーマである推論速度最適化に関する重要なニュースです。ただし、発表元が海外ベンダーであり、日本企業や日本語圏特有の事情(価格、規制、ローカライズ)に言及がないため、日本の関連性は低めに見積もります。
6つの評価軸を見る
- AI関連度
- 100
- 情報源の信頼性
- 25
- 新規性
- 75
- 調べる価値
- 75
- 重複の少なさ
- 100
- 日本での有用性
- 25
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み