DFlash 投机解码登陆 llama.cpp，Qwen3.6-27B 长上下文实测 4.44 倍提速

DFlash（基于块扩散 drafter 的投机解码方案）近期正式合并进 llama.cpp（PR #22105），来自 z-lab。社区用户随即在 RTX PRO 6000 Blackwell 上对 Qwen3.6-27B 进行了系统实测。结果显示，在 36K 上下文长度下，DFlash 把生成速度从 61.47 tok/s 提升到 273.04 tok/s，达到 4.44 倍加速；同时 MATH-500 准确率从 87% 略降至 86%，几乎无损。

速度表现：加速倍数随上下文延长而放大

与直觉相反的是，DFlash 的加速收益不是随上下文缩小，而是越来越大：

512 上下文：1.44 倍
4K 上下文：2.70 倍
12K 上下文：3.40 倍
36K 上下文：4.44 倍
98K 推理场景：仍可达到约 241 tok/s

原因在于基线随上下文增长而衰减，DFlash 则保持稳定，因此差距持续拉宽。在该用户此前对 Gemma 4 的 MTP 测试中，最佳为 3.34 倍，本次 DFlash 在同一台机器上击败了 MTP 在所有 draft length 下的成绩，最佳 leaderboard 配置（n_max=12）达到 256 tok/s（3.64 倍），优于其最佳 MTP 的 190 tok/s（2.70 倍）。

质量与显存：基本无损，多约 5GB 开销

作者专门回应了此前关于质量退化的质疑，在 MATH-500 前 100 题上做了对照测试：

基线模型：87%
DFlash 配置：86%
7 个细分科目中 6 个结果完全一致，仅 1 道 prealgebra 题不同（作者认为是早期实现误差范围内的波动）

从原理上看，greedy 解码下目标模型会逐 token 校验 drafter 输出，理论上应无损，作者表示「这次选择实际测一遍，而非只从设计上论证」。

显存方面，启用 DFlash 后 VRAM 占用从 21GB 升至 26GB，多出的约 5GB 主要来自 Q8 量化的 drafter 权重与缓冲区。

关键设计：块扩散 + KV 注入

DFlash 与传统投机解码的关键差异在于 drafter：

MTP 等方法每轮只能起草 1 个 token，而 DFlash 的扩散 drafter 单次可填充一整块 token（当前实现上限 15 个）。
目标模型的 hidden states 通过 KV 注入到 drafter 的每一层，使 drafter 在大块长度下仍能保持准确，不会像普通 drafter 那样在数个 token 后迅速衰减。
作者还指出一个反直觉现象：在 n_max=12 配置下接受率仅 43%，却比 n_max=2（接受率 91%）更快——真正决定收益的是每次验证接受的 token 数，而非接受率本身。

局限与使用注意

DFlash 目前主要面向本地低并发场景，存在两点需要注意：

VRAM 增量约 5GB，使用前需确认显存余量。
高并发尚未验证：扩散 drafter 的额外前向可能与批量推理竞争算力，作者尚未在生产级 batch 场景下测试。

部署提示：必须使用架构标记为 dflash 的 GGUF 模型，带 dflash-draft 标签的仓库为合并前版本，无法加载。

完整的 Docker 一键部署、leaderboard 与 sweep 脚本、所有 CSV 与图表已在作者 GitHub 仓库（lukaLLM/DFlash）开源。