DFlash 2: ドラフトを並列に維持する

エージェント時代のボトルネックは推論です。エージェントは読み込み、計画し、ツールを呼び出しますが、それはしばしば数時間または数日かかります。それらはチャットがかつて到達しなかった速度でトークンを消費します。それらのトークンはすべて、モデル全体での完全なフォワードパスを必要とします。Inco AIでは、明日のトークン経済学にスケールされた推論スタックを構築しています。この記事は、そのプレビューです。私たちのチームは1月にDFlashをリリースしました。現在、SGLang、vLLM、TensorRT-LLM、llama.cppで動作しています。NVIDIAはBlackwell GPUで最大15倍のスループットを測定しました。GoogleはTPUで毎秒3倍のトークンを報告しました。Artificial Analysisでそのモデルにとって最速であるCoreWeaveのプロダクションKimi K2.7 Codeエンドポイントは、デフォルトでDFlashを実行しています。エコシステムは現在、それを基盤として構築しています。NVIDIA、Red Hat、ModalはすべてDFlashドラフターを公開しています。Meta（Muse Glimmer）、Poolside（Laguna）、Xiaomi（MiMo-V2.5-Pro）、NVIDIA（Nemotron 3.5 Lightning）は、独自のモデルで公式ドラフターを出荷しています。Hugging Faceでは、DFlashモデルは350万回以上ダウンロードされています（2026年8月現在）。 スペキュラティブデコーディングは、現代の推論スタックのコア部分です。小さなドラフトモデルがトークンブロックを推測し、ターゲットモデルがそのブロック全体を1回のフォワードパスで検証します。良い推測は1回のパスを複数のトークンに変えます。悪い推測は単に破棄されます。しかし、長年、ドラフト自体はオートリグレッシブでした。一度に1つのトークンずつです。DFlashはそれを1パスにしました。ブロック全体、すべての位置が並列に予測されます。 DFlash 2は、oMLXを備えたApple M5 MaxでQwen3.8-27Bのドラフトを行っており、オートリグレッシブデコーディングと並べて表示されています。DFlash 2は、並列ドラフトをさらに一歩進めます。検証パスごとの出力が20%以上増加し、サイクルレイテンシは約1%増加しますが、出力は証明済みで変更されません。ベンチマーク全体でゲインは16〜25%です。本日リリースされたQwen3.8-27Bドラフターにより、SGLangはバッチサイズ1でオートリグレッシブデコーディングの2.7〜3.4倍のスループットでサービスを提供します。 各位置を独立して予測することは、2つの領域に余裕を残します。適切なトークンを選択することと、ブロックの最後まで精度を維持することです。DFlash 2は、1パス設計を犠牲にすることなく、両方を回復します。 今すぐ実行する DFlash 2は既に主要な推論エンジンで実行されています。 SGLang vLLM lama.cpp oMLX pip install "sglang[all] @ git+https://github.com/sgl-project/sglang.git#subdirectory=python" python -m sglang.launch_server \ --model-path Qwen/Qwen3.8-27B \ --speculative-algorithm DFLASH \ --speculative-draft-model-path incoai/Qwen3.8-27B-DFlash2 \ --speculative-num-draft-tokens 8 pip install -U "vllm @ git+https://github.com/vllm-project/vllm.git@refs/pull/52816/head" vllm serve Qwen/Qwen3.8-27B \ --speculative-config '{ "method": "dflash", "model": "incoai/Qwen3.8-27B-DFlash2", "num_speculative_tokens": 7 }' git clone https://github.com/ggml-org/llama.cpp.git cd llama.cpp git fetch origin pull/27342/head:pr-27342 git switch pr-27342 # NVIDIA CUDA cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON cmake --build build -j # Apple Silicon cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON cmake --build build -j ./build/bin/llama-server \ -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \ -hfd incoai/Qwen3.8-27B-DFlash2-GGUF:Q4_K_M \ --spec-type draft-dflash \ --spec-draft-n-max 7 DFlash 2サポート付きのプリビルドoMLXをダウンロードしてインストールします。 Qwen3.8-27BをDFlash 2で実行するには： oMLX Model Downloaderを開き、以下をダウンロードします。 mlx-community/Qwen3.8-27B-4bit incoai/Qwen3.8-27B-DFlash2 Model Managerを開き、mlx-community/Qwen3.8-27B-4bitを編集します。 以下の設定でDFlashを設定します。 DFlash: 有効 Draft model: incoai/Qwen3.8-27B-DFlash2 Draft quantization: 有効 Runtime block size: 5 Verify mode: dflash 設定を保存し、ターゲットモデルをロードします。 正しいトークンはすでにそこにあります DFlashは各位置を独立して並列に予測します。各選択はそれ自体で妥当です。しかし、それらが一致するようには何もされておらず、不整合なブロックは検証で短縮されます。DominoやDSparkのような最近の手法は、各位置のフルボキャブラリ分布を書き換えるシーケンシャルヘッドで一貫性を購入します。しかし、その高価なオートリグレッシブ補正は本当に必要なのでしょうか？いいえ。証拠はDFlash自身の候補リストにすでにあります。最初の位置を取ってみましょう。DFlashのトップピックは85.4%の時間で正しいですが、正しいトークンは99.5%の時間でトップ16の候補に含まれています。トップピックが間違っている場合でも、正しいトークンは通常リストにあります。 | Metric | 0 | 1 | 2 | 3 | 4 | 5 | 6 | |---|---|---|---|---|---|---|---| | Acceptance length | 85.4% | 80.3% | 79.4% | 78.3% | 77.5% | 75.9% | 72.9% | | Recall@1 | 4.27 | | | | | | | | Recall@16 | 99.5% | 97.3% | 94.8% | 92.6% | 90.8% | 89.4% | 87.8% | | | 6.79 | | | | | | | 表1. 各ドラフト位置におけるRecall@1（トップピックが正しい頻度）とRecall@16（正しいトークンがトップ16に含まれる頻度）、ただし前のすべての位置が正しいことを条件とします。GSM8Kでの5層Qwen3-4B DFlash。Acceptance lengthには、検証者の次のトークンが含まれます。トップ16から常に正しい候補を選択するオラクルは、Acceptance lengthを4.27から6.79に引き上げます。そのギャップは純粋な選択のヘッドルームです。候補の中から正しいパスを選択するだけで済みます。 Diffusionisgood ⟨mask⟩⟨mask⟩⟨mask⟩ Independent Top-1 Picks for✗same word, twice position 1 decoding speculative slow ⋮ position 2 decoding thinking models ⋮ position 3 ⟨eos⟩ again… ⋮ all adjacent pairs scored at once → one path kept accepted output for target-decoded token mask token accepted draft selected path 図1. 1サイクルでのセレクター。DFlash単独では、各位置がトップピックを保持します。ここでは2つの隣接要素が同じ単語を選択し、繰り返しが検証で消滅します。DFlash 2は各位置のトップ候補を保持し、セレクターはそれらを通過する一貫したパスをトレースします。ここでは、ブロック全体が生き残ります。 軽量パスセレクター 一貫性は主に局所的です。候補の一致度は、直前のトークンに主に依存するため、隣接ペアをスコアリングすれば十分です。DFlash 2は各位置でトップ16の候補を保持し、すべての隣接ペアをスコアリングします。前のトークンがaaaで現在の候補がbbbの場合、St(a,b)=Ut(b)+⟨A(a)⊙H(ht),B(b)⟩。 St​(a,b)=Ut​(b)+⟨A(a)⊙H(ht​),B(b)⟩。 スコアは2つの部分からなります。最初のUt(b)Ut​(b)はDFlash自身のロジットです。つまり、ドラフターがbbbを単独でどれだけ気に入っていたかです。2番目の部分は、bbbがaaaにどれだけうまく続くかを尋ねます。AAAとBBBは各トークンにコンパクトな256次元の埋め込みを提供し、2つの埋め込みはコンテキストゲートH(ht)H(ht​)の下で一致します。これは、一致のどの部分がカウントされるかを決定します。本質的に、これは隣接候補に対する低ランク双線形アテンションです。スコアリングは完全に並列のままです。各位置のすべての隣接ペアは、追加のバックボーンまたはLMヘッドパスなしで、一度にスコアリングされます。唯一のシーケンシャルな作業は、事前計算されたスコアの最終的なウォークです。最後の検証済みトークンから開始して、各ステップで最良の後続を貪欲にたどり、同じスコアからサンプリングし、拒否サンプリングは正確なターゲット分布を復元します。 | Method | Params | Latency | T = 0 | T = 1 | |---|---|---|---|---| | DFlash | —— | —— | 4.27 | 3.78 | | + DSpark correction | +77.8M | +9.6% | 4.49 | 4.08 | | + path selection (ours) | +2.0M | +0.6% | 4.61 | 4.25 | 表2. パス選択のみ（畳み込みなし）でのAcceptance length。5層Qwen3-4B on GSM8K。オーバーヘッドはプレーンDFlashに対する相対値です。ドラフターに追加されるパラメータ、および追加されるドラフト-検証サイクルレイテンシ。セレクターは、両方の設定でDSpark補正を、約40倍少ないパラメータと16倍低いレイテンシオーバーヘッドで上回ります。選択は予測よりも安価です。そしてまだ余地があります。オラクルは6.79に達します。ペアワイズスコアリングは、私たちが考えた中で最もシンプルなセレクターであり、探求すべきことはたくさんあると信じています。 サフィックス減衰は局所的な問題です また、上記のすべてのリコール行がブロックの終わりに近づくにつれて低下することにも気づきました。オラクルでさえ減衰します。完璧な選択でも、精度は最初の位置の99.5%から最後の位置の87.8%に低下します。候補自体が枯渇しているため、どのセレクターもそれを修正することはできません。これをサフィックス減衰と呼び、これはバックボーンの問題です。1つの疑念は容量です。5層のバックボーンは、依存関係を維持するには小さすぎる可能性があります。