我在llama.cpp中测试了最新合并的DFlash在Qwen 3.6 27B本地AI上的表现。36K上下文速度提升4.44倍。以下是我的发现（RTX 6000 PRO）。

嘿，各位。一个月前我发布了MTP基准测试（Gemma 4上3.34倍）。DFlash支持刚刚合并到llama.cpp（PR #22105），于是我在同一台机器上对Qwen 3.6 27B进行了测试，在每个草稿长度上都超过了我最好的MTP数据。DFlash是来自z-lab的块扩散推测解码方法。它不是逐个草拟token，而是在单次传递中填充一个由15个token组成的块（当前限制）。你可以从仓库获取docker compose，一键在你的硬件上作为Llama服务器运行。https://preview.redd.it/pltg3n2i7ubh1.png?width=1700&format=png&auto=webp&s=3aa3306e95908b1c8eddb504c13865e9fbf17bb3 基准配置： - 速度：NVIDIA aiperf合成扫描，ISL = OSL 在512 / 4K / 12K / 36K，固定长度（标准差0），忽略EOS + 固定min_tokens，使每个请求生成完整大小 - 每个大小的请求数：30 / 10 / 5 / 3（上下文越大越少，但36K下3次运行仍约生成110K token），每组测量前预热请求：2 / 2 / 1 / 1，随机种子42 - 贪婪解码（温度0，top-k 1，top-p 1.0），并发数1，即“在家自用”场景。 排行榜（快速配置对比，代码位于benchmark/leaderboard.py）： - 所有运行和所有配置使用相同的短提示 - 每个配置运行10次，每次运行生成1500个token，上下文限制3000 - 温度0，top-k 1，种子1234，前缀缓存关闭，忽略EOS - tok/s来自llama.cpp自身的计时，接受率来自draft_n / draft_n_accepted - 每次运行追加到CSV，排行榜保留每个配置的最佳平均值 https://preview.redd.it/4oh5rqgt5ubh1.png?width=1030&format=png&auto=webp&s=3183585fe446b00d2da2fb40e0a9e5c1abb3a919 质量测试： - MATH-500前100题，两个配置使用相同的子集，种子固定，关闭推理。也打算运行LiveCodeBench但需要检查ai perf和包的一些问题。 使用的模型： - 目标模型：unsloth/Qwen3.6-27B-GGUF（UD-Q4_K_XL）通过llama.cpp服务器（Docker） - 草稿模型：Alittlehammmer/Qwen3.6-27B-DFlash-GGUF-llama.cpp（Q8_0，约1.9GB），合并后架构 硬件：AMD Ryzen 9 9950X | NVIDIA RTX PRO 6000 Blackwell | 96GB VRAM | CUDA 13 | Ubuntu 最佳结果：36K上下文下273.04 vs 61.47 tok/s = 4.44倍提速。最佳排行榜配置为n_max=12，256 tok/s（3.64倍）。同一模型下我最好的MTP配置为190 tok/s（2.70倍）。 关于质量：上次我无法测量退化，你们正确地提出了这个问题，所以这次我测量了。基本得分为87% vs DFlash 86%（MATH-500，100题），7个科目中有6个完全相同，一个预代数问题不同。DFlash运行时速度为270 vs 72 tok/s（3.75倍）。我只运行了100题，因为之前有一些失败，而且我需要用电脑做其他事情。从架构上看，贪婪解码时应该是无损的，因为目标模型会验证每个草拟的token，但我这次想实际测量一下，而不是仅从设计上争论。我认为这一个错误在误差范围内，因为这是早期实现。 关于VRAM：这次也测量了。加载DFlash后26GB vs 基准21GB，所以约5GB开销（Q8草稿权重+缓冲区）。 总结： 1. 加速比随上下文增大而增长，这与我们习惯的情况相反：512上下文时1.44倍，4K时2.70倍，12K时3.40倍，36K时4.44倍。通常模型在上下文变大时会变慢。这里差距变大是因为基线下降而DFlash保持稳定。我还在98K上下文中运行了一个推理服务器，速度仍有241 tok/s。 2. DFlash在相同机器上每个草稿长度都超过了MTP。每个周期的接受率相似（tau约为7.3 vs 6.7），但MTP每个草拟token要支付一次前向传递，而扩散草稿模型在一次传递中填充整个块。输出相同的token，草稿成本仅一小部分。 3. 更低的接受率可以更快：n_max=12时43%的接受率超过了n_max=2时91%的接受率。重要的是每次验证传递接受的token数，而不是接受百分比。 注意：当前的llama.cpp实现将草稿token限制为15个。 为什么有效：解码是带宽受限而非计算受限。与我之前的MTP帖子相同。每次解码步骤都会重新读取权重，你的GPU大部分时间在等待内存，所以草稿模型将成本分摊到多个接受的token上。DFlash的额外技巧是目标模型的隐藏状态被注入到每一层草稿模型（KV注入），因此草稿模型即使在大的块中也能保持准确，而不会在几个token后衰减。 对于本地使用，这几乎是免费的性能，但有两点需要注意： 注意一：我快速用nvtop测试，带草稿模型和不带草稿模型之间大约有5GB VRAM差异，但我稍后需要确认，因为当时不是唯一在运行的程序，我还在录制。所以不是那么专业的测试哈哈。 注意二：这是低并发时的优势。我还没有测试高批次生产服务，在那里扩散传递可能会开始竞争计算资源。 还有一个能为你节省一小时的故障排除提示：你的草稿GGUF架构必须是dflash。标记为dflash-draft的仓库是合并前的，无法加载。 https://preview.redd.it/6kafythk4ubh1.png?width=1700&format=png&auto=webp&s=119da75b6d1f3b4887a715935fe6aa25de508c6d 📦 资源：GitHub、一键Docker部署、排行榜+扫描脚本、所有CSV和图表：https://github.com/lukaLLM/DFlash 你们的使用情况和速度如何？这对于像DGX Spark这样的本地128GB AI盒子来说，看起来是相当不错的设置，可以在当前经济条件下获得更好的速度。