推論與開源執行環境
DFlash 2 讓 Qwen3.8-27B 並行起草 token，但 vLLM nightly 目前存在載入與顯存錯誤
DFlash 2 以候選路徑選擇器及動態卷積改善區塊擴散草稿，在單請求測試中讓 Qwen3.8-27B 達到自回歸解碼的 2.7 至 3.4 倍吞吐量。最新可重現問題顯示 vLLM nightly 會建立錯誤的 decoder layer，並在共用詞表權重前暫時多配置近 4.74GiB，24GB 顯示卡可能無法啟動。
Inco AI 的 DFlash 2 不取代 Qwen3.8-27B，而是作為約 2B 參數的 speculative decoding 草稿模型。一般推測解碼先由較小模型提出多個 token，再讓目標模型一次驗證；DFlash 系列則以區塊擴散在一次 forward pass 並行預測整段草稿。新版在每個位置保留前 16 個候選，再由輕量選擇器尋找連貫路徑，並用 two-tap dynamic convolution 避免草稿後段準確率衰退。
官方以單張 H200、SGLang、FlashAttention 3 及 Qwen 建議的取樣參數測試，Qwen3.8-27B 的平均接受長度由原生 MTP 的 4.28 增至 4.80。按不同資料集計算，單批次吞吐量是普通自回歸解碼的 2.7 至 3.4 倍。這種加速不會直接採用草稿輸出：目標模型仍透過拒絕取樣驗證，因此貪婪解碼應產生相同 token，隨機取樣則保留目標分布。實際收益仍取決於內容可預測程度、批次大小與草稿接受率。
值得注意的是，8 月 24 日提交的 vLLM 問題報告在 current main 與指定 nightly 重現兩項獨立錯誤。第一項是 `DFlashQwen3Model` 建立 layer 時硬編碼舊類別，忽略 DFlash 2 覆寫的 `decoder_layer_cls`，導致載入權重時找不到 `attention_conv`。第二項發生在目標與草稿共用 embedding、LM head 之前：初始化仍各自配置一個 248,320×5,120 的 BF16 暫存模組，每個約 2.37GiB。在 RTX 4090 搭配 15.7GiB W4A16 目標模型時，第二次配置會確定性 OOM；縮短上下文或 KV cache 預算亦無效。
回報者以縮小暫存詞表及兩行 layer 修正成功啟動，但上游尚未合併正式修補。部署者目前應固定已驗證的 SGLang 或其他引擎版本；若使用 vLLM，則需把 PR/nightly 視為實驗路徑，先測試模型載入、顯存峰值、取樣一致性及真實工作負載下的尾延遲。