DFlash と Spec V2 デコーディングの解説（14 分読了）

Modal と Z Lab の DFlash 推測デコーディングモデルを、SGLang の newly default Spec V2 エンジン（Speculative Decoding Version 2）と組み合わせることで、LLM 推論サービングにおいて最先端のレイテンシを実現できます。Qwen 3.5 397B-A17B 向けに共同リリースされた新しい DFlash モデルは、ベンチマークしたすべての設定において、ベースラインモデルおよびネイティブ MTP（Multi-Token Prediction）推測よりも高いスループットを達成します。HumanEval コーディングデータセット上で並行度 1 の条件下では、ベースラインの >4.3 倍、MTP の 1.5 倍のスループットを実現しています。 ![image](https://www.lmsys.org/images/blog/dflash-v2/dflash-headline-perf.webp) ワークロード: Qwen 3.5 397B-A17B (BF16)、HumanEval。設定: グリーディデコーディング、思考機能有効、最大新規トークン数 4096。ハードウェア: Modal 上の 8xB200。受容長はリクエスト間で平均化されています。ドラフトトークン/ブロック数は最大スループットを達成するように選択されました（MTP: 7 ステップ; DFlash: ブロックサイズ 16）。 このコラボレーションを祝し、本モデルを Hugging Face の各組織で三つのリポジトリに公開します: - z-lab/Qwen3.5-397B-A17B-DFlash - modal-labs/Qwen3.5-397B-A17B-DFlash - lmsys/Qwen3.5-397B-A17B-DFlash 以下のコマンドで、ご自身でも本モデルを試すことができます: export SGLANG_ENABLE_OVERLAP_PLAN_STREAM=1 python -m sglang.launch_server \ --model-path Qwen/Qwen3.5-397B-A17B \ --trust-remote-code \ --speculative-algorithm DFLASH \ --speculative-draft-model-path modal-labs/Qwen3.5-397B-A17B-DFlash \ --speculative-dflash-block-size 8 \ --speculative-draft-attention-backend fa4 \ --attention-backend trtllm_mha \ --linear-attn-prefill-backend triton \ --linear-attn-decode-backend flashinfer \ --mamba-scheduler-strategy extra_buffer \ --tp-size 8 \ --max-running-requests 32 \ --cuda-graph-max-bs-decode 32 \ --cuda-graph-backend-prefill tc_piecewise \ --enable-flashinfer-allreduce-fusion \ --mem-fraction-static 0.8 \ --host 0.0.0.0 以下では、推論の劇的な高速化を実現するための DFlash の革新的な拡散＋KV（Key-Value）注入戦略について説明し、その重要性を解説するとともに、[Z Lab](https://z-lab.ai/)、SGLang、および [Modal](https://modal.com/) のチームがどのように協力してこの高速化を誰もが利用可能にしたかについて述べます。 ## KV 注入による並列ドラフティング Transformer ベースの大規模言語モデル（LLM）は強力ですが、その自己回帰的推論プロセスにより推論速度が遅くなります。トークンは一つずつ生成する必要があり、現代のハードウェアには適さないほど [演算強度](https://modal.com/gpu-glossary/perf/arithmetic-intensity) が低いためです。 [Speculative decoding](https://arxiv.org/abs/2211.17192) は、より小さく高速なドラフトモデルを使用して複数のトークンを提案し、それをターゲット LLM が並列に検証することでこのボトルネックを解決します。これにより、モデルの品質への影響はありません。 しかし、[EAGLE シリーズ](https://arxiv.org/abs/2503.01840) や、最近の [Gemma 4](https://blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/) および [DeepSeek-V4](https://www.lmsys.org/blog/2026-04-25-deepseek-v4/) に搭載されたネイティブなマルチトークン予測 (MTP) モジュールなど、多くの推測的デコーディング手法は、依然として逐次的自己回帰に依存しています。ただし、これはターゲットモデルではなくドラフトモデル側での話です。ドラフトモデルがトークンを一つずつ生成する方式は、現代のハードウェアには適しておらず、実現可能な速度向上の限界となっています。 そこで Z Lab は [DFlash](https://arxiv.org/abs/2602.06036) を開発しました。これは軽量なブロック拡散ドラフトモデルを使用し、GPU や TPU が好むように、ドラフトトークンのブロック全体を並列に生成します。Xiaomi の新製品 MiMo v2.5-Pro-UltraSpeed は DFlash を採用することで [1 秒あたり 1000 トークンを超える出力](https://mimo.xiaomi.com/blog/mimo-tilert-1000tps) を実現しています。 推測的ドラフトにブロック拡散を使用するのは容易ではありません。小さなブロック拡散モデルを直接トレーニングしてドラフターとして使用すると受容長が短くなる一方、[SpecDiff-2](https://arxiv.org/abs/2511.00606) のような既存の大規模拡散 LLM をドラフターとして使用すると、メモリ使用量が大幅に増加し、ドラフトコストが高くなります。 DFlash の鍵となる洞察はシンプルです：対象の LLM が文脈を最もよく理解しています。[Medusa](https://arxiv.org/abs/2401.10774)、[EAGLE](https://arxiv.org/html/2503.01840v1)、MTP ([Gloeckle et al., 2024](https://arxiv.org/abs/2404.19737); [Samragh et al., 2025](https://arxiv.org/abs/2507.11851)) などの先行手法に触発され、対象モデルから文脈トークンの隠れ表現（hidden representations）を抽出します。先行研究とは異なり、これらをドラフトモデルの KV キャッシュ（Key-Value Cache）に直接注入します。これにより、ドラフト深度が増加してもよりよくスケーリングします。KV 注入により、ドラフトモデルは文脈全体を一からモデル化する必要がなくなり、対象モデルの後方レイヤーと同じテンソルを使用しながら、純粋に次のトークンブロックの予測に集中できるようになります。 ![image](https://www.lmsys.org/images/blog/dflash-v2/dflash-arch-diagram.webp) この設計により、DFlash は対象 LLM が生成する豊かで非常に関連性の高い文脈特徴を活用しつつ、ドラフトモデルを極めて小さく効率的に保ちます。その結果、DFlash は低いドラフティングレイテンシで高い受容長（acceptance length）を実現します。 ## なぜ DFlash はこれほど高速なのか？ 推測的デコーディングの速度向上は主に 2 つの要因に依存します：1 サイクルあたり何個のドラフトトークンが受け入れられるか、およびドラフトモデルが追加する余分なコストです。DFlash はこの両方を改善します：拡散ドラフティング（diffusion drafting）によりドラフトコストを下げ、KV 注入により受容率を向上させます。 具体的には、同じデータセット上で Qwen 3-4B のために訓練された 5 レイヤーの EAGLE-3 ドラフターと、いくつかの 5 レイヤーの DFlash バリアントドラフターの、エンドツーエンドの受容長さと速度を比較してみましょう。ベースラインの DFlash は、5 レイヤーの EAGLE-3 ドラフターと同程度の受容長さを達成しますが、その超高速な並列ドラフトのおかげで、はるかに高いエンドツーエンドのスピードアップを実現します。結果は「acc_len / speedup」の形式で報告されます。 タスク EAGLE-3 (5 レイヤー) DFlash GSM8K 4.2 / 2.1x** 4.2 / 3.3x** HumanEval 4.3 / 2.2x** 4.0 / 3.2x** MT-Bench 3.1 / 1.4x** 3.0 / 2.2x** **DFlash はドラフトが速い** EAGLE-3 のような自己回帰型ドラフターは、ドラフトトークンを一つずつ生成します。ドラフト長さが伸びるにつれて、ドラフトにかかるコストもほぼ線形に増加します。レイテンシを低く保つため、これらの手法では通常非常に浅いドラフトモデルに依存しており、それがドラフトの品質を制限しています。 DFlash はブロック拡散ドラフターによってこのボトルネックを回避します。これは単一の順方向パスでトークンのブロック全体を並列に生成するため、ハードウェアに極めて優しいドラフトを実現します。4、8、あるいは 16 トークンを生成する 5 レイヤーの DFlash ドラフターは、4 トークンを生成する単一レイヤーの EAGLE-3 ドラフターよりもはるかに低いドラフトレイテンシを有しています。 ![image](https://www.lmsys.org/images/blog/dflash-v2/dflash-vs-eagle-draft-latency.webp) 他の DFlash のアーキテクチャ機能をアブレーション（除去）することで、この技術の独立した影響を観察することができます。DFlash は、より低い受容長さにおいても、その高速なドラフトのおかげで EAGLE-3 よりも高いエンドツーエンドのスピードアップを提供し続けます。 TaskEAGLE-3 (5 layers) DFlash (diffusion only) GSM8K 4.2 / 2.1x**3.5 / 2.9x** HumanEval 4.3 / 2.2x**3.5 / 2.9x** MT-Bench 3.1 / 1.4x**2.6 / 2.0x** **KV injection increases acceptance lengths** Fast drafting only helps if the drafted tokens are accepted。EAGLE-3 は、ドラフトモデルの入力においてのみターゲットモデルの特徴を使用しており、このシグナルはより深いドラフトモデルでは減衰します。 一方、DFlash では、ターゲットの特徴をすべてのドラフト層の KV キャッシュ（Key-Value Cache）に注入します。これにより、生成全体を通じてドラフターがターゲットモデルの文脈に対して強く条件付けられ、より深いドラフターが高品質なドラフトを生成できるようになります。 また、拡散ドラフティングをアブレーション（除去実験）することで、KV 注入の独立した影響も観察できます。自己回帰モードでの DFlash でも、エンドツーエンドベンチマークにおいて高い受容長により、依然として高速化を実現しています。 TaskEAGLE-3 (5 layers) DFlash (injection only) GSM8K 4.2 / 2.1x**4.8 / 2.4x** HumanEval 4.3 / 2.2x**4.6 / 2.3x** MT-Bench 3.1 / 1.4x**3.4 / 1.5x** ## Implementing DFlash in SGLang 上記セクションのベンチマーク数値は、Z Lab の研究開発の一環として行われた DFlash の初期実装に基づくものです。これらの印象的な結果に基づき、Modal と SGLang のチームが Z Lab と協力し、SGLang 推論エンジンにおけるエンドツーエンドのパフォーマンスを最適化しました。 DFlash のようなパフォーマンス最適化技術を研究から本番環境へ導入するには、2 つの基本的な要素が必要です。1 つは高性能エンジン内でその技術を実装すること、もう 1 つはホストスケジューラから GPU 実行に至るまでのエンドツーエンドシステムのパフォーマンスを最適化することです。 SGLang への DFlash の統合は、この観点から 2 つの部分に分けることができます。まず、DFlash は元の（現在は非推奨 [now deprecated](https://github.com/sgl-project/sglang/pull/25464)）V1 スペキュレーティブ・デコーディングエンジンに追加されました。新しいドラフトモデルアーキテクチャを実装するだけでなく、インジェクションをサポートするためにドラフトとターゲット間の KV キャッシュ（Key-Value Cache: キーバリューキャッシュ）の統合も必要でした。次に、DFlash は新しい V2 スペキュレーティブ・デコーディングエンジンにも追加されました。こちらはホストとの同期を減らすことでパフォーマンスが向上しています [reduced synchronization with the host](https://modal.com/blog/host-overhead-inference-efficiency)。 [DFlash の初期実装](https://github.com/sgl-project/sglang/pull/22077) では、既存のスペキュレーティブ・デコーディングエンジンにこの新しいモデルアーキテクチャのサポートを追加しました。これには、ドラフトモデルの実行を制御する DFlashWorker と、それが駆動する実際の DFlashDraftModel の追加が含まれていました。 念のためお伝えしておきますが、SGLang では、モデルワーカープロセス（主にアクセラレータ上で動作）の実行を駆動するために、スケジューラープロセス（主にホスト上で動作）を使用しています。SGLang における推測デコーディングの仕組みにおいて直感に反する点の一つは、ドラフトモデルワーカーがスケジューラーと通信する側であることです（.forward_batch_generation などのメソッドを介して）。これは検証パスのためにターゲットモデルのワーカーをラップし、ドラフトが準備できたらそれを呼び出します。コードやトレースを確認する際は、この点を忘れないでください。 これは DFlash に限ったことではありません。DFlash の主な新機能は、ドラフトモデルとターゲットモデル間の状態を結びつける KV 注入です。EAGLE などのメソッドでは、ドラフトの KV キャッシュはドラフトモデルに完全にプライベートであり、ドラフト自身の潜在変数（latents）に基づく KV プロジェクションに基づいて計算されます。一方、DFlash では、ターゲットモデルの潜在変数がドラフトモデルによって KV プロジェクションを介して渡されます。 これらの潜在変数を保存して貴重な KV キャッシュ領域を圧迫したくありませんし、同じプレフィックスを持つすべてのリクエストがラディックスキャッシュ（radix cache）を共有できるようにしたいと考えています。そのため、ドラフトフォワードパスの残りの部分よりも先にドラフトの KV プロジェクションを実行します – これが「即時マテリアライゼーション」です。これは高速である必要があるため、レイヤーバッチ化された線形プロジェクションと、ノルム＋RoPE の後処理を融合した Triton カーネルを追加しました。 ## Spec V2 とオーバーラップスケジューリングによる DFlash でのホストオーバーヘッドの排除 これは機能し、かつ高速でしたが、さらに速くできることは知っていました。私たちは並行して V2 推測デコーディングエンジンに取り組んでいたので、次のステップは [DFlash を V2 エンジンと組み合わせる](https://github.com/sgl-project/sglang/pull/23000) ことであり、これが現在 SGLang で利用可能な機能です。 V2 エンジンの全体としての主要な目標は、ホストとデバイスの同期ポイントを減らすことです。これは GPU の速度がどれだけ速くてもカーネルがどれだけ優れていても、推論パフォーマンスを[損なう](https://modal.com/blog/host-overhead-inference-efficiency)要因となります。その解決策として*オーバーラップスケジューラ*が提案されています。 具体的には、オーバーラップの機会が 2 つあります。 - GPU がバッチ N-1 の処理を終えた後のホスト側の pop_and_process クリーンアップ（例：停止トークンの検出、リクエストメタデータの更新）は、GPU によるバッチ N の作業と重ねて実行できます； - バッチ N に対するホストの KV アロケーション（prepare_for_decode 内）は、GPU によるバッチ N-1 の作業と重ねて実行できます。 これらの最適化を施した V2 では、Qwen 3-8B を単一の B200 で並行度 32 で実行した場合、パフォーマンスが約 33% 向上し、~11.4 ktok/s から ~15.3 ktok/s に改善されました（[詳細はこちら](https://github.com/sgl-project/sglang/pull/23000)）。 ## 高性能な DFlash ドラフトモデルがさまざまなモデルで利用可能になりました 本日、Qwen 3.5 397B-A17B 向けの新しい DFlash ドラフトモデルをリリースします。GSM8K から HumanEval、MT-Bench まで、またリクエスト並行度が 1 から 32 の範囲にわたるすべてのテスト設定において、このモデルのネイティブな MTP（Multi-Token Prediction）推測よりも高いスループットを実現しています。 ![image](https://www.lmsys.org/images/blog/dflash-v2/dflash-perf-big-sweep.webp) ベンチマークの詳細や、ご自身で数値を再現したい場合は、[Hugging Face リポジトリ](https://huggingface.co/modal-labs/Qwen3.5-397B-A17B-DFlash/tree/main/benchmark)をご覧ください。 Z Lab の [DFlash コレクション on Hugging Face](https://huggingface.co/collections/z-lab/dflash) では、さらに高品質なドラフター（草案生成モデル）を見つけることができます。また、まもなく新しいモデルも登場する予定ですので、ご注目ください！ ## 今すぐ SGLang で DFlash を試す このブログ記事を読んで「乗り遅れたかも」と感じる必要はありません。[コードはこちら](https://github.com/sgl-project/sglang/pull/23000)で確認できます。また、本投稿の冒頭で紹介されたコマンドを使用して DFlash 加速版の SGLang サーバーをデプロイすることも可能です。あるいは、[Modal](https://modal.com/docs/examples/sglang_low_latency) でサーバーを起動することもできます。 ご自身のデータや対象モデル向けに DFlash スペキュレーター（予測モデル）をトレーニングすることも可能です。ブロック拡散と KV 注入を組み合わせたアプローチは、ほとんどのターゲット LLM に適用できます。興味がある場合は、[Z Lab](https://z-lab.ai/) または [Modal](https://modal.com/) までお問い合わせください！ より広く言えば、オープンウェイトモデルの構築者、システム研究者、そしてオープンソースコミュニティの取り組みのおかげで、最適な知能、速度、コストで推論を実行することができます。Z Lab による DFlash などの技術に関する研究や、Modal などのオープンソース貢献者による機能とパフォーマンスの向上など、LLM 推論における世界最高レベルの成果が、SGLang オープンソースエンジンに集約され、あなたが構築・活用するための基盤となっています。 ## 謝辞 Spec V2 と DFlash を SGLang に実装するために貢献いただいたすべての皆様に感謝いたします。 Z Lab: Jian Chen, Yesheng Liang, Zhijian Liu. Modal: David Wang, Charles Frye. SGLang: Qiaolin Yu, Liangsheng Yin, Khoa Pham.

DFlash と Spec V2 デコーディングの解説（14 分読了）

背景や根拠まで確認しますか？

調べる

選ぶ

サイト