从 ICML 论文到你的显卡：llama.cpp 吞下 DFlash，本地推理进入 2 倍速时代

在本地跑大模型的人都有一个共同的痛：token 一个一个往外蹦。过去半年，投机解码（speculative decoding）被寄予厚望，但实际体验一言难尽——有的模型开了反而更慢，有的需要额外下载一个 draft model 却发现接受率惨不忍睹。7 月 8 日，llama.cpp 作者 Georgi Gerganov 宣布了一个让整个 r/LocalLLaMA 社区兴奋的消息：DFlash 正式进入 llama.cpp 主分支。

一句话总结：DFlash 是什么，为什么现在才来

llama.cpp 的投机解码武器库多了一把新枪。在已有的 MTP（多 token 预测）、EAGLE-3 和各种 ngram 方案之外，DFlash 的核心不同在于：它不是让 draft model 一个一个猜下一个 token，而是用一个轻量级扩散模型，一次性并行"画"出一整块候选 token，然后让目标模型批量验证。Qwen3.6-27B 在 DGX Spark 上的实测结果是整体 2.69 倍加速，RAG 场景更是冲到 4.07 倍。

这项技术来自 Z Lab，论文中了 ICML 2026。不到半年，NVIDIA 工程师 Ruixiang Wang 就把它从论文变成了 llama.cpp 的 PR #22105，6 月 28 日正式合入主分支。

技术内幕：扩散模型做 draft，为什么比自回归方案更快

投机解码的瓶颈从来不是验证，而是 draft

要理解 DFlash 的价值，得先理解投机解码的基本逻辑。标准的大模型推理是自回归的——生成第 N 个 token 必须等第 N-1 个 token 算完。投机解码的思路是：用一个小模型（draft model）快速预测接下来好几个 token，然后让大模型一次性并行验证这些候选。验证对了就全收，验证错了就从第一个出错的地方截断重来。

问题出在 draft 环节。目前的主流方案，包括 EAGLE-3 和模型内置的 MTP，draft 阶段仍然是自回归的——draft model 自己也是一个 token 一个 token 地生成。这意味着 draft 的延迟和 draft 长度基本成正比。为了控制延迟，EAGLE-3 只能用极浅的架构（单层 transformer），这严重限制了 draft 质量。

DFlash 的破局思路是：让 draft model 用扩散模型一次性并行生成一整块 token，而不是一个个串行猜。用 Z Lab 论文的数据来说：一个 5 层 DFlash drafter 生成 16 个 token 的延迟，比单层 EAGLE-3 生成 8 个 token 的延迟还低。更深、更强、更快，三者不再互斥。

KV Injection：目标模型的"内功"直接灌给 drafter

光有并行 draft 还不够。一个纯粹的扩散模型做 drafter，接受率并不好看——因为它完全不知道目标模型"在想什么"。DFlash 的第二个关键技巧是 KV Injection：从目标模型的多个中间层提取隐藏特征（hidden states），融合成一个上下文表示，然后直接注入到 draft 模型每一层的 Key/Value 投影中，存在 draft 的 KV cache 里。

这种做法和 EAGLE-3 的本质区别在于：EAGLE-3 只在第一层输入目标特征，信号随着层数增加而衰减；DFlash 的每一层都持续接收到完整的目标模型上下文，draft 模型越深，接受率反而越高。换句话说，DFlash 让 draft 模型不用从头"理解"上下文，而是直接借用目标模型已经算好的"认知"，专心做一件事——预测下一块 token。

llama.cpp 上的实测：代码场景接近 3 倍加速，RAG 场景破 4 倍

PR #22105 中给出了详尽的 benchmark。以 Qwen3.6-27B（Q4_K_M 量化）在 DGX Spark 上跑 SpeedBench 的结果为例：

任务类别	基线速度 (t/s)	DFlash 速度 (t/s)	加速比	接受率
coding	12.63	39.32	3.11x	30.97%
rag	12.54	51.07	4.07x	44.22%
roleplay	12.57	38.02	3.02x	28.29%
writing	12.52	33.33	2.66x	25.61%
reasoning	12.56	30.42	2.42x	22.63%
整体	12.57	33.76	2.69x	25.16%

两个规律一目了然。第一，结构化越强的任务加速越明显——代码和 RAG 受益最大，因为 token 序列的可预测性更高，draft 模型更容易猜对。第二，接受率不是唯一指标——即使接受率只有 25%，端到端速度仍翻了一倍多，这正是并行 draft 带来的"免费午餐"：draft 成本极低，猜对了血赚，猜错了也不亏太多。

社区实测也佐证了这些数字。工程总监 Jackson Atkins 在 AMD Ryzen AI Max+ 395（Strix Halo）上跑 Qwen3.6-27B，速度从 12.6 t/s 翻倍到 24.7 t/s。日本用户 @kayaba_mo 的观察一针见血："体感速度很重要——RAG 和 coding 的等待时间被直接削掉了。"

值得一提的是，DFlash 在开启 thinking 模式（推理模型的长链思考）时依然有效，PR 中的 Qwen3-8B 测试显示 explain 类任务可获得 1.85 倍加速。但对于 MoE（混合专家）架构的模型如 GPT-OSS-20B，加速效果相对有限——因为并行验证阶段会激活比自回归解码更多的 expert，抵消了一部分收益。

NVIDIA 的算盘：RTX Spark 亲自下场，社区协作模式浮出水面

这次集成的特别之处在于贡献者阵容。PR 作者是 NVIDIA 工程师 Ruixiang Wang，reviewer 是 llama.cpp 核心维护者 Johannes Gaessler，最终由 Georgi Gerganov 本人 merge。这不是某个社区爱好者单枪匹马的贡献，而是一次有组织的"厂商-开源"协作。

NVIDIA RTX Spark 官方账号在 Gerganov 推文发布仅一个多小时后就跟进确认："我们与 @ggerganov 合作，将 DFlash 支持添加到 llama.cpp 中，实现了约 2 倍推理加速。"这条推文获得了 618 个赞和 10 万次浏览，比原始推文的传播量还大。Hugging Face（Gerganov 目前的雇主）也转发了原始推文。

这标志着 NVIDIA 对本地 AI 推理生态的投资进入了一个新阶段。过去，硬件厂商对 llama.cpp 的支持主要集中在底层算子优化（如 CUDA kernel、Flash Attention 适配）。DFlash 的合入则代表 NVIDIA 开始直接向 llama.cpp 贡献推理算法层面的创新——把自家研究员参与的前沿论文成果，通过内部工程师落地到最流行的本地推理引擎中。

对 NVIDIA 来说，这笔账很好算：llama.cpp 是消费级 GPU 上最主流的本地 LLM 推理方案，每让 llama.cpp 快一倍，就等于让 RTX 显卡在 AI 场景的体验提升一倍。与其等着社区慢慢移植，不如亲自下场写代码。

投机解码三国杀：DFlash vs MTP vs EAGLE-3

DFlash 的加入让 llama.cpp 的投机解码选项变得异常丰富。目前支持的方案包括 MTP（模型内置多 token 预测头）、EAGLE-3（自回归 draft + 目标特征）、DFlash（扩散 draft + KV 注入）、以及各种 ngram 方案。选哪个，取决于模型和场景。

方案	draft 方式	额外模型	优势场景	局限
MTP	模型内置	不需要	原生支持的模型（Qwen3.6 MoE、Gemma 4 等）	不支持 MTP 的模型完全不能用
EAGLE-3	自回归单层	需要（~1-2GB）	通用场景，兼容性好	draft 本身是串行的，加速比上限 ~2-3x
DFlash	扩散多层	需要（~1-2GB）	结构化输出（代码、RAG）	MoE 模型加速有限，目前可用的 draft model 较少
ngram	无模型	不需要	重复性高的输出	对创造性文本基本无效

一个务实的建议正在社区中形成：对于支持 MTP 的 MoE 模型（如 Qwen3.6-35B-A3B），MTP 通常是首选——无需额外模型，内存效率最高。Jackson Atkins 的测试显示 Qwen3.6-35B-A3B + MTP 在他的 Strix Halo 上跑到 80 t/s，远超 DFlash 加速后的 27B 模型。但对于密集模型（如 Qwen3.6-27B），DFlash 是当前最强的加速方案。

Hugging Face 讨论区里也有用户提醒：接受率（acceptance rate）才是真正的胜负手。Dipankar Sarkar 分享了他的踩坑经历——"以为开了投机解码就能免费 2x，结果 draft 一直猜错，比不用还慢。"换句话说，DFlash 的快不是魔法，它在结构化任务上的出色表现来源于 KV Injection 让 drafter 真正"理解"了目标模型的状态。

llama.cpp 的边界正在被重新定义

Georgi Gerganov 的这条推文，表面的信息是"llama.cpp 多了一个投机解码选项"，但底层信号远比这个丰富。

第一，本地推理引擎正在成为前沿研究的快速落地通道。DFlash 从 ICML 2026 论文到 llama.cpp 主分支只用了不到五个月。这个速度在传统软件工程中几乎不可想象，但它正在成为 AI 基础设施领域的常态——研究社区产出 idea，开源引擎提供实现，硬件厂商提供优化，三方协作的高速公路已经铺好。

第二，投机解码正在从"锦上添花"变成"默认开启"。当 llama.cpp 同时拥有 MTP、EAGLE-3、DFlash 和多种 ngram 方案后，用户面对的不再是"要不要开投机解码"，而是"用哪个方案"。配合 speculative checkpointing（#19493）等底层优化，投机解码的稳定性和易用性在过去几个月大幅提升。Llama.cpp 的官方文档已将投机解码作为核心特性单独成章。

第三，也是最值得关注的：NVIDIA 对 llama.cpp 的投入模式正在升级。从被动适配 CUDA 到主动贡献前沿推理算法，这背后的逻辑很清楚——本地 AI 推理的市场规模正在扩大，而 llama.cpp 是这个市场最重要的基础设施之一。一旦本地推理的速度追上了云端推理的体验，RTX 显卡的 AI 叙事就有了全新的注脚。

Georgi Gerganov 在推文中特别感谢了 NVIDIA 团队和 Ruixiang Wang。一条看似简单的致谢，配上一个 383 赞、72,000 次浏览的公告，折射出的是一个研究论文变成消费级产品的完整链路。这条路两年前还几乎不存在。

参考链接

Georgi Gerganov 推文：
NVIDIA RTX Spark 确认：
llama.cpp PR #22105（DFlash 合入）：
llama.cpp 投机解码文档：
DFlash 论文（ICML 2026）：
Z Lab DFlash 项目页：
LMSYS 博客《下一代投机解码》：

本文由 AREX Agent 基于公开信息和一手推文撰写，仅供行业参考。转载需注明来源。