LLM推論を最大8.5倍高速化するDFlash — 品質劣化なし

LLMの推論速度を上げるために、モデルの差し替えや量子化を試してきた人は多いかもしれません。DFlashは別のアプローチで、推論の仕組みそのものを変えることで品質をまったく落とさずにスループットを最大6倍以上引き上げます。

この記事でわかること

• 投機的デコーディングの限界とDFlashが解決すること
• ブロック拡散モデルが従来のドラフト生成と何が違うか
• 対応モデルとvLLM／SGLangでの導入手順
• どんな用途で効果が出て、どんな場合は使わない方がいいか

https://github.com/z-lab/dflash

LLM推論の根本的なボトルネック

TransformerベースのLLMは、テキストを1トークンずつ逐次生成します。あるトークンを生成するには直前のトークンが必要で、並列化できない仕組みです。

GPUは毎秒数百兆回の演算が可能ですが、LLMの推論はメモリ帯域に律速されているため、計算資源の大半が遊んでいる状態になります。「GPUは速いのに、メモリが追いつかないために手持ち無沙汰」という構造的な問題です。

投機的デコーディングでは不十分だったこと

この問題を解決する手法の一つが投機的デコーディング（Speculative Decoding）です。小さな「ドラフトモデル」が複数トークンを先読みし、大きな「ターゲットモデル」がそれをまとめて検証します。正解トークンがまとめて採用されれば、ターゲットモデルの順伝播回数が減り、推論が速くなります。

しかし従来の投機的デコーディング（EAGLE-3など）には依然として問題がありました。ドラフトモデル自体が1トークンずつ逐次生成するため、K個の候補トークンを生成するためにK回の逐次ステップが必要だったのです。ドラフト段階のボトルネックが残っていました。

DFlashはここに踏み込みます。

DFlashが変えたこと：ドラフト生成を1ステップで並列化

DFlashは、自己回帰型のドラフトヘッドをブロック拡散モデルに置き換えました。これにより、K個の候補トークンを1回の順伝播でまとめて生成できます。

流れはこうです。

1. ターゲットモデルが最初のトークンを通常通り生成する
2. DFlashのドラフトモデルがターゲットモデルの隠れ状態を受け取る
3. ブロック拡散の1ステップでK個のマスクされた位置を同時に埋める
4. ターゲットモデルがK個全てを1回の順伝播でまとめて検証する
5. 受け入れられた先頭トークン列を採用し、はじかれた位置からリサンプリングする

EAGLE-3でK=8とすると、ドラフト段階で8回の逐次ステップが走ります。DFlashなら1回です。ドラフトのコストがほぼ一定になるため、Kを大きくするほど効率が上がる特性があります。

対応モデルとベンチマーク

https://github.com/z-lab/dflash

DFlashの利用には、ターゲットモデルに対応した専用ドラフトチェックポイントが必要です。現時点でHugging Face（z-labオーガニゼーション）で公開されている主なモデルは次の通りです。

Spheronの検証では、H100 PCIeでLlama 3.3 70B FP8を動かした場合、通常デコードが約1,200トークン/秒、EAGLE-3が約3,600トークン/秒に対し、DFlashは約9,000トークン/秒という結果が出ています（参考）。出力1Mトークンあたりのコストは通常デコードの約$0.47から$0.06まで下がる計算です。また、前世代の最高性能手法であるEAGLE-3と比べても約2.5倍の高速化が確認されています。

vLLMでの導入手順

DFlashはvLLM（nightlyビルド）とSGLang、Hugging Face Transformersから利用できます。vLLMの場合、--speculative-configにJSONを渡すだけです。

vllm serve Qwen/Qwen3.5-27B \
  --speculative-config '{"method": "dflash", "model": "z-lab/Qwen3.5-27B-DFlash", "num_speculative_tokens": 15}' \
  --attention-backend flash_attn \
  --max-num-batched-tokens 32768

num_speculative_tokensはDFlashでは高めに設定できます。ドラフト生成が逐次ではなく並列なので、K=15でも1回の順伝播で済むからです。高い同時リクエスト数での性能劣化を防ぐため、--speculative-disable-by-batch-size 32も合わせて指定しておくことを推奨します。32リクエストを超えると自動で通常デコードに切り替わり、高負荷時の挙動が安定します。

SGLangの場合は--speculative-algorithm DFLASHで有効化できます。マルチターンのエージェントワークロードではSGLangのRadixAttentionとDFlashの組み合わせが特に効果的です。

どんな場合に有効か

DFlashが効果を発揮するのは、バッチサイズが小さく（1〜4リクエスト程度）、応答が比較的長い場面です。命令追従タスクやコード生成ではドラフトモデルの受け入れ率が高くなり、高いスループット改善が期待できます。

一方、同時リクエスト数が32を超えるケースや、出力が50トークン以下の短い応答が多い場合は、投機の準備コストが利益を上回るため通常デコードの方が有利です。また、対象モデルにDFlashチェックポイントが存在しない場合は、EAGLE-3が現時点での最善の代替手段です。

チェックポイントの最新一覧はHugging Faceのz-labオーガニゼーション（https://huggingface.co/z-lab）で確認できます。

まとめ

DFlashはLLM推論のボトルネックを「ドラフト生成の並列化」で解消したオープンソースプロジェクトです。モデルの品質に一切手を加えず、推論フレームワークの設定変更だけで標準デコードに対して最大6倍以上のスループット向上を実現します。Qwen3.5、Llama 3.1、Kimi-K2.5向けのドラフトチェックポイントが既に公開されており、今すぐvLLMかSGLangで試せます。