你让 AI 写一段长文，它通常要一个词一个词往外吐，像每写一个字都要停下来核对。推测解码想把这段等待压短：先让较快的“草稿”机制一次提出几个候选 token——也就是模型生成文字时使用的基本单位，再由主模型并行验收。DFlash2 现在正式合入 llama.cpp，让这套加速办法从社区测试走进了常用的本地推理引擎。更值得看的是，另一套实现已开始移植它，Qwen 低比特配置也出现了实际运行记录。一条从算法、引擎到个人设备的落地链条，正在成形。
本刊 8 月 20 日曾介绍 DFlash2 的并行草稿和候选选路，并记录它在 llama.cpp、vLLM 上的早期测试。本期的变化不再只是“有人试过”，而是代码正式进入主线。不过，本文涉及的速度数字主要来自相关 GitHub PR 中的单方测试；低比特运行记录则来自一名 Reddit 用户，证据强度需要分开看。
先猜几个，再让主模型拍板
llama.cpp 是一套本地推理引擎——负责加载模型、管理内存，并让模型在具体硬件上运行的软件。算法接入这类引擎后，普通用户才更容易真正用上。
据 ggml-org/llama.cpp PR #27342，合入的 DFlash2 支持新增了 local convolution（局部卷积）与 candidate selector（候选选择器）。它会利用每个 token 产生的多个 logits——模型给不同候选打出的原始分数，再按候选预计被主模型接受的概率加权选择。可以把它理解为：草稿员不只多写几个版本，还会先判断哪个版本最可能过审，把核验机会用在更有希望的候选上。
这对 non-greedy sampler 尤其有利。sampler 是根据模型分数选择下一个 token 的规则；greedy sampler 每次只拿最高分选项，非 greedy sampler 则保留一定随机性。候选不再只有一条笔直路线时，怎样选路就更重要。
ik_llama.cpp 的 PR #2345 随后移植了 ggml-org/llama.cpp 的这套实现。移植者使用不同模型量化、硬件、提示集和参数测试，也观察到 DFlash2 相比 DFlash v1 整体提高了接受率与生成速度。这能交叉印证改进方向，但两边的具体速度不能直接拼在一起比较。该 PR 还提到，DFlash2 已有适配 Qwen 3.8 27B 与 Muse Glimmer 30B 的模型。
两倍速，关键在长上下文没有塌掉
最醒目的结果来自 Qwen3.8-27B UD-Q4_K_XL、gfx1151/Vulkan 与 llama-benchy 0.4.0 的组合。这里的 t/s 表示每秒生成多少 token，数值越高，输出越快。
不用推测解码时，模型在上下文深度 0、8k 和 32k 下分别达到 11.81、11.44 和 10.54 t/s。DFlash2 将 draft width——一次铺开的草稿候选宽度——设为 4 后，对应速度为 26.39、21.58 和 21.11 t/s。也就是说，从短提示到 32k 长上下文，它都大致保持了基础解码的两倍速度。
对照更能说明问题。DFlash v1 在宽度 5 时，速度从浅上下文的 21.09 t/s 降至 32k 下的 10.75 t/s，只剩基础解码的约 1.02 倍。DFlash2 的价值不只是起跑更快，而是长上下文里没有同样失速。
但候选并非越多越好。32k 深度下，DFlash2 宽度 4 达到 21.11 t/s，宽度 7 只有 16.32 t/s，前者快约 29%；浅上下文时两者则很接近。候选铺得更宽，会增加准备与核验成本，长上下文下这笔成本可能盖过收益。
提示内容，也会改变加速幅度
同一份测试还提醒我们，速度不是算法独有的固定属性。使用代码语料时，DFlash2 从浅上下文到 32k 的速度衰减约 47%；换成 Gutenberg prose，也就是古登堡计划的散文语料，衰减约 20%。草稿是否容易被接受，与模型正在续写什么内容密切相关。因此，“某模型快两倍”不能脱离提示语料、上下文长度和参数单独理解。
DFlash2 与 MTP——另一类一次预测多个未来 token 的办法——谁更快，目前也没有统一答案。ik_llama.cpp 的移植者称，DFlash2 在 spec-bench 的标准代码提示上更具竞争力；llama.cpp PR 的讨论却称，单张 RTX 3090 上它没有显著优于 MTP。两组设置不同，现有材料不足以判定普遍胜负。
低比特让它靠近消费级硬件
低比特量化用更少位数表示模型权重，有时也压缩缓存，以减少存储、显存和内存占用；代价是质量、速度与硬件兼容性可能随方案变化。
一名 Reddit 用户报告，Qwen 3.8 27B QAT Q2、DFlash2 Q2_K_S-MIX 与 Q5 KV 的组合可运行到 200K context，约占 13—14GB RAM；把上下文降至 100K，则可装入 12GB 显卡。它说明低比特配置已经出现可运行线索，但这只是个人体验，没有可复现实验或质量基准。该用户关于能力超过 Sonnet 4.6、质量退化很小的判断，现阶段不能当作可靠结论。
局限与未知
- llama.cpp 的关键测试仅运行两次，推测解码各组误差约为 ±1.0 至 ±2.5 t/s。除 32k 下宽度 4 与 7 的差距外，多数细小差异可能没有明显超出噪声。
- 测试预填充使用默认
-ub 512，而材料称该权重的最优值为-ub 256，因此结果可能比可达到的上限低几个百分点。 - DFlash2 已完成主线合入和跨实现移植，但不同硬件、语料与量化配置下的速度，以及低比特方案的实际质量，仍需要更系统的独立验证。