你让本地 AI 读一份很长的材料，再写一份同样长的回答。越写到后面，它通常越慢：上下文——模型当前能参考的输入和已生成内容——不断增长，计算和中间结果读写也越来越重。DFlash 想减少这种等待。它先快速起草一批文字，再交给主模型集中核对。如今，这套方案已经进入主流本地推理引擎 llama.cpp。
官方 PR #22105 显示，DFlash 支持已于 2026 年 6 月 28 日合并。不过，本文标题中的 4.44 倍来自 Reddit 用户 FantasticNature7590 的一次自测，并非 llama.cpp 或 DFlash 团队给出的独立复现结果。
先起草一块，再统一检查
DFlash 用的是推测解码（speculative decoding）。可以把它理解成编辑和助理配合写稿：便宜、快速的草稿过程先猜若干 token——模型生成文字时处理的基本单位——主模型再并行验证。猜中的部分可以整批采用，于是主模型一次向前推进多步，同时保持它原本的输出分布。
DFlash 的草稿过程是 z-lab 的 block diffusion drafter。普通草稿方法按从左到右的顺序逐个猜 token；它则同时处理一整块候选 token，并在修正中完成这块草稿。在这次 llama.cpp 测试里，一次最多填充 15 个 token。直观地说，它不是让助理一个字一个字递交，而是先交来一小段，再让主模型统一审阅。
这在长上下文里尤其值得看。上下文越长，注意力计算以及 KV Cache 的读写通常越重。KV Cache 可以理解为模型阅读和写作时保留的“草稿纸”，存放已经算过的中间结果，避免反复重算。若草稿猜得准，DFlash 就能减少昂贵的主模型调用次数，长文本也更容易放大这部分收益。
4.44 倍是怎么测出来的
据 FantasticNature7590 的 Reddit 测试帖，测试使用 RTX 6000 PRO，主模型是 Qwen 3.6 27B 的特定量化版本，草稿模型是对应的 DFlash 版本。测试只有一个并发请求，并采用贪心解码，也就是每一步都直接选择概率最高的结果。
测试把输入长度和输出长度都设为 512、4K、12K 和 36K。在输入、输出均为 36K 的一档，作者报告 DFlash 达到 4.44 倍加速。这是“自己在家运行服务”的单用户场景，不代表多人同时请求时也会得到相同结果。
作者还称，DFlash 在所有受测 draft length——每轮尝试起草的长度——上，都超过了自己此前最好的 MTP 测试成绩。但供稿没有提供完整原始数据，也没有解释 MTP 基线的具体配置，因此目前只能把它视为作者对两轮个人测试的比较。
质量检查使用 MATH-500 数学题集的前 100 题，两种配置采用相同子集，固定随机种子，并关闭推理模式。这个设计至少保证了比较对象一致，但帖子没有给出具体得分，不能据此断言加速完全不影响质量。
真正的进展是进入常用工具链
4.44 倍是醒目的数字，但更重要的变化是 DFlash 已经进入 llama.cpp。llama.cpp 是主流的本地大模型推理引擎，重点支持消费级 CPU、GPU 和量化模型。新解码方法进入这里，意味着它不再只停留在独立演示中，而是可以接入常见的本地部署工具链。
这也让后续复核更现实。不同显卡、模型、上下文长度和草稿长度都可以继续测试。推测解码的效果本来就取决于草稿命中率与验证成本之间的平衡，因此“已经并入”比单次跑分更有长期意义。
局限与未知
- 4.44 倍只有一个独立信源。36K 档仅测了 3 次；作者称合计生成约 11 万个 token，但样本请求数仍然很小。
- 作者使用自制 Docker 与 benchmark 流程。正文没有给出完整原始数据、基线每秒 token 数、误差范围，也没有提供可复现结果。
- 这个数字只适用于特定硬件、模型版本、单并发、贪心解码以及输入输出均为 36K 的条件，不能泛化为所有长上下文任务。