DFlash 2、Qwen3.8-27Bでトークンを並列ドラフト生成――ただしvLLM nightlyには現在、読み込みとVRAMに関する不具合

Inco AIのDFlash 2はQwen3.8-27Bを置き換えるものではなく、約2Bパラメータのspeculative decoding用ドラフトモデルとして機能する。一般的なspeculative decodingでは、まず小規模なモデルが複数のtokenを提案し、その後、ターゲットモデルがそれらを一括で検証する。これに対してDFlashシリーズは、ブロック拡散を用いて1回のforward passでドラフト全体を並列予測する。新版では各位置について上位16個の候補を保持し、軽量なセレクターで一貫性のあるパスを探索する。また、two-tap dynamic convolutionを用いて、ドラフト後半における精度低下を防ぐ。

公式テストは、単一のH200、SGLang、FlashAttention 3、およびQwenが推奨するサンプリングパラメータを使用して実施された。Qwen3.8-27Bの平均受理長は、ネイティブMTPの4.28から4.80へ増加した。データセット別では、batch size 1のスループットが通常の自己回帰デコードの2.7～3.4倍となった。この高速化ではドラフト出力がそのまま採用されるわけではない。ターゲットモデルは引き続きrejection samplingによって検証するため、greedy decodingでは同一のtokenが生成されるはずであり、確率的サンプリングでもターゲット分布が維持される。実際の効果は、コンテンツの予測可能性、batch size、ドラフトの受理率によって左右される。

注意すべき点として、8月24日に提出されたvLLMのissueでは、current mainと指定されたnightlyの両方で、互いに独立した2つの不具合が再現されている。1つ目は、`DFlashQwen3Model`がlayerの生成時に旧クラスをハードコードしており、DFlash 2によってオーバーライドされた`decoder_layer_cls`を無視するため、重みの読み込み時に`attention_conv`が見つからないというものだ。2つ目は、ターゲットモデルとドラフトモデルがembeddingおよびLM headを共有する前に発生する。初期化処理がそれぞれについて248,320×5,120のBF16一時モジュールを割り当て、そのサイズは1つ当たり約2.37GiBに達する。RTX 4090で15.7GiBのW4A16ターゲットモデルを使用した場合、2回目の割り当てで決定論的にOOMが発生する。コンテキスト長やKV cacheの予算を減らしても効果はない。

報告者は、一時的な語彙サイズの縮小と、layerに対する2行の修正によって起動に成功したが、正式な修正はまだupstreamにマージされていない。デプロイ担当者は当面、検証済みのSGLangまたは他の推論エンジンのバージョンに固定すべきだ。vLLMを使用する場合は、PR/nightlyを実験的な経路として扱い、モデルの読み込み、VRAM使用量のピーク、サンプリングの一貫性、および実際のワークロードにおけるテールレイテンシを事前にテストする必要がある。