投機的デコード(speculative decoding)は、この2年ですっかり定番の高速化テクになった。小さな「ドラフトモデル」に先の数トークンを予想させ、本命の大きなモデルにまとめて答え合わせさせる。当たっていた分だけ一気に進むので、出力品質を一切変えずに生成が速くなる。理屈はきれいだ。ところが手元で回すと、期待したほど速くならない場面が多い。消費者向けGPUやMoE構成では「速度がほぼ変わらなかった」という検証報告も珍しくない(例)。

その頭打ちの正体に手を入れたのが、z-lab(Jian Chen、Yesheng Liang、Zhijian Liu)の DFlash だ。ICML 2026に採択された論文「DFlash: Block Diffusion for Flash Speculative Decoding」で提案され、標準的な自己回帰生成に対して6倍を超える無損失の高速化、現行最強とされるEAGLE-3に対しても最大2.5倍速いと報告している。

ドラフトが逐次だから、速さが頭打ちになる

投機的デコードの速度は、ざっくり「ドラフトがどれだけ当たるか」と「ドラフト自体がどれだけ安いか」の掛け算で決まる。EAGLE-3のような最新手法は前者、つまり受理率(acceptance rate)を上げることに成功して、実用上2〜3倍を出してきた。

問題は後者だ。EAGLE-3のドラフトモデルは、本命モデルと同じく1トークンずつ左から右へ書く自己回帰型で動く。8トークン先読みしたければ、ドラフトモデルを8回順番に回す必要がある。先読みを深くするほどドラフトのコストが線形に膨らみ、そこが新たなボトルネックになる。ローカル環境のように演算資源が限られる場面では、この「ドラフトを回す時間」が節約分を食い潰し、差し引きゼロになりやすい。

DFlashの発想はここを外す。ドラフトを逐次に書くのをやめ、ブロック単位でまとめて吐き出す。

1回の前方計算で、ブロックごと書く

DFlashのドラフトモデルは自己回帰ではなく ブロック拡散(block diffusion) で動く。拡散モデルが画像を一気にノイズから起こして整えるのと同じ要領で、16トークンなら16トークンぶんを1回の前方計算(forward pass)でまとめて生成し、必要に応じて refine する。トークン数が増えてもドラフトの計算回数は増えないので、遅延はほぼ横ばいになる。z-labの解説によれば、16トークンを出す多層DFlashが、8トークンを出す単層EAGLE-3より低遅延で済むという。深く先読みしても罰が無い、というのが効きどころだ。

ただし、単に並列生成しただけでは当たらなくなる。左から右への文脈を持たないぶん、ドラフトの質が落ちて受理率が下がりかねない。DFlashはそこを本命モデルの内部状態で埋める。具体的には、ターゲットモデルの複数層から等間隔に取り出した隠れ特徴を軽量な射影で融合し、ドラフト側の 全層のKey/Value に注入する。EAGLE-3が最初の層だけを条件付けしていたのに対し、DFlashは各層をターゲットの手掛かりで縛る。並列に書いても外しにくい、という設計だ。

数字で見ると差がはっきりする(Qwen3-8B、無損失=出力はベースラインと等価)。

ベンチマーク	EAGLE-3	DFlash
GSM8K	2.13倍	5.20倍
MATH-500	2.18倍	6.17倍

サンプリングあり(temperature=1)の推論モデルでも約4.5倍を保つ。貪欲デコード限定の速さではない点は実務上ありがたい。

ローカル推論でこそ効く。ただしllama.cppはまだ途中

個人的に注目しているのは、この手法が刺さる場所だ。バッチを厚く積めるクラウドのGPUファームより、1枚のGPUで細々と回すローカル推論のほうが、ドラフトの逐次コストが相対的に重い。DFlashのフラットなドラフトコストは、まさにそこを軽くする。「速度がほぼ変わらなかった」と言われてきた消費者向け環境こそ、恩恵が大きい可能性がある。

公式実装はSGLangとtransformersで動く。draft側のGGUFならぬ専用ドラフトモデルはHuggingFaceのz-labコレクションで配布されており、Qwen3系やLLaMA-3.1、Gemma系のターゲットに対応する。SGLangでの起動は公式READMEにあるとおりで、ドラフトモデルとブロック長を指定するだけだ。

python -m sglang.launch_server \
    --model-path Qwen/Qwen3.5-35B-A3B \
    --speculative-algorithm DFLASH \
    --speculative-draft-model-path z-lab/Qwen3.5-35B-A3B-DFlash \
    --speculative-num-draft-tokens 16

一方、多くのローカル勢が待つ llama.cpp への統合は、この記事の時点ではまだ本体にマージされていない。Discussion #21569 で議論が進み、PR #22105 が --spec-type dflash フラグでの対応を提案している段階で、実際に試すには beellama.cpp や buun-llama-cpp といった有志のフォークを使うことになる。PRのコメントでは、Qwen3.5/3.6のMoE構成で「現状は性能が最適ではない」と報告されており、llama.cpp側のMoE実装の制約に引っ張られている。ここは今後の詰め次第だろう。

拡散モデルを言語生成の本流に据える試みはまだ荒削りだが、DFlashは「拡散で本命を置き換える」のではなく「拡散を投機的デコードのドラフト役に回す」という、実利のはっきりした使い方を提示した点がうまい。ドラフトは多少雑でも本命が答え合わせをするので、拡散生成の粗さが品質に響かない。裏取りしたい人は、まず論文とz-labのプロジェクトページ、そして公式リポジトリを突き合わせるといい。