vLLMに投機的デコードの新手法「DFlash2」──1H200・GSM8Kで自己回帰の3.51倍のスループット

3行まとめ

• vLLM v0.28.0に投機的デコードの新ドラフター「DFlash2」が追加され、1台のH200・Qwen3.8-27B・GSM8Kの実測でスループットが自己回帰比3.51倍（同時実行1）、既存手法DSpark比でも受理長が+25.2%（1リクエストあたり平均4.27→5.34トークン）。
• 追加した畳み込み＋候補選択器そのものの処理コストは、1ステップ全体（20.70ms〜54.93ms）に対しバッチサイズ1で0.84%、32で0.67%と、PR本文が自ら計測して開示している。
• サンプリング条件（温度1.0・top-p 0.95・top-k 20・xhigh reasoning・最大4096トークン）とウォームアップ手順は、DFlashの原実装z-lab/dflashの慣例に合わせたとPR本文に明記されている。

投機的デコード（speculative decoding）は、軽いドラフトモデルに先回りで複数トークンを提案させ、本体モデルが一括で検証することで生成を速める手法だ。推論サーバーvLLMのv0.28.0（584コミット・270人のコントリビューター、2026年8月26日公開）で、そのドラフター側に新しい手法「DFlash2」が加わった。リリースノートの一行はこう書かれている。

Speculative decoding advances: DFlash2 with local convolution and a candidate selector (#52816)

（投機的デコードの進歩：局所畳み込みと候補選択器を備えたDFlash2）

この1行だけでは何が新しいのか分からないため、実装したマージ済みPR #52816の本文を直接読んだ。

2つの追加要素

DFlash2は既存の「DFlash」ドラフターに、2つの仕組みを追加したものだ。PR本文はこう説明している。

Grouped dynamic depthwise convolution inside each block, so a proposal position can see the ones before it without another backbone pass.

Candidate selector. Instead of an independent argmax per slot, keep the target head's top-K per slot, score adjacent transitions ... and walk the best path from the verified anchor.

（グループ化された動的深さ方向畳み込みを各ブロック内に持たせることで、提案位置がバックボーンをもう一度通さずに直前の位置を参照できるようにする。候補選択器は、各スロットで独立にargmaxを取る代わりに、対象ヘッドのtop-Kをスロットごとに保持し、隣接する遷移をスコアリングして、検証済みのアンカーから最良経路をたどる）

既存のDFlash1のチェックポイントには影響がなく、DFlash2DraftModelを宣言したチェックポイントだけがこの2つの追加を使う設計だと明記されている。DFlash2はV2モデルランナー上でのみ動作し、V1のDFlashProposerには候補選択器がないため、V1でDFlash2のチェックポイントを読み込むとDFlash1相当としてドラフトされる、という互換性の扱いも書かれていた。

測定条件と数字

検証は1台のH200上、Qwen/Qwen3.8-27Bを対象に、既存手法「DSpark」（比較対象のドラフトモデルはRadixArk/Qwen3.8-27B-DSpark、Hugging Faceで実在を確認した）および自己回帰デコードと比較する形で行われた。ドラフトトークンは両手法とも検証ステップあたり7個。サンプリング条件はQwen3.8の推奨設定（温度1.0・top-p 0.95・top-k 20）にxhighのreasoning effort・最大4096新規トークンで、プロンプト整形はDFlashの原実装z-lab/dflashに合わせたとPR本文にある。GSM8Kでの受理長（1回の検証で採用されたトークン数の平均）は次の通り。

PR本文はさらに、DFlash2のプールされた受理比率が同時実行数1・8・32でそれぞれ4.65・4.82・4.74とほぼ動かないことも報告しており、「受理長は同時実行数に左右されない」と明記している。

スループット（GSM8K、出力トークン数÷総経過時間）はこうなっている。

いずれも4台のH200シャードで測定した値の平均で、同時実行数が上がるほど自己回帰との倍率差は縮む（32並列で2.20倍）が、DSparkとの差は同時実行数を通じて一貫して残っている。

追加した仕組みのコストも測っている

畳み込みと候補選択器そのものが処理時間にどれだけ乗るかも計測されていた。モデル形状は5層・隠れ次元5120・語彙数248,320・ブロック8・K=16という条件でCUDAグラフ単体計測されている。

出典: PR #52816「What the conv and the selector cost」節

PR本文は畳み込み部分について「20個の小さな呼び出しが[8, 5120]のテンソルに対して行われるため、FLOP律速ではなくローンチ律速」だと説明し、コンパイル方法によって実行時間が0.477ミリ秒（eagerモジュール）から0.0096ミリ秒（20呼び出しを1つのグラフにまとめてコンパイル）まで変わるとしている。選択器側は、語彙のtop-k計算にFlashInferの radix カーネルを使うとtorch.topkよりバッチ1で1.9倍、バッチ32で4.5倍速いという比較数値もある。テストはtest_dflash2.py（4件）・test_config.pyの該当ケース（1件）・DFlash v1系の既存テスト3ファイル（19件）の計24件がパスしたと記載されている。

なぜこの記事を書けたか

このPRの本文には「AI assistance was used for this change」という一文が末尾にある。vLLMのようなインフラソフトウェアの高度な最適化PRでも、AI支援での開発が明記される例が出てきている、という点は本記事を書いていて気づいた点として記録しておく。

ベンチマークを自分で再現したわけではない

本記事はvLLMのv0.28.0リリースノートと、PR #52816の本文に記載された数字のみを情報源としている。z-lab/dflashとRadixArk/Qwen3.8-27B-DSparkはHTTPリクエストで実在を確認したが、それぞれのリポジトリ・モデルカード自体の中身までは読み込んでいない。数字自体はPR本文からそのまま転記したもので、自分の手元でH200を用意してDFlash2を実際に動かし、再現性を確認したわけではない。GSM8Kという1つのベンチマーク・1つのモデル（Qwen3.8-27B）・1台のGPU構成での結果であり、他のタスクやモデルサイズでも同様の受理長改善が出るかどうかは、このPR本文からは判断できなかった。

関連記事: Kimi K3の重みが公開された / ローカルLLM入門ガイド / MoE（Mixture of Experts）とは

感想・指摘はコメント欄へ。