我测试了 llama.cpp 在 Qwen 3.6 27B 上的所有推测性解码方法：MTP ~2.7x, DFlash ~3.7x, n-gram 堆叠在真实编码中达到 ~6x。本地 AI 获胜。我在 RTX 6000 PRO 上的发现。

嘿，各位，上周我在这里发布了 DFlash 的基准测试结果（4.44x 在 36K 上下文下）：https://www.reddit.com/r/LocalLLaMA/comments/1uq0h4o/i_tested_freshly_merged_dflash_in_llamacpp_on/。其中 u/exact_constraint 的评论提到还有 n-gram 查找草稿器（ngram-mod, ngram-map-k4v）。我发现它们可以堆叠在 DFlash 之上，所以我测试了整个堆叠的性能。简而言之：在多样的单次提示下它们没有增加任何效果，在迭代编码中它们将 DFlash 从 3.7x 提升到 6x，而且它们几乎不消耗 VRAM。另外，我必须纠正上次帖子中的两个数字，因为我发现 aipref 失败了，这就是第 5 点。什么是 n-gram 草稿：它就像一个复印机。它取模型最后生成的 N 个 token，在现有上下文中搜索完全相同的 token 模式，然后逐字提出后续内容作为草稿。ngram-mod 使用 24-token 的查找键，并链式生成 48 到 64 个 token 的草稿，一次记住一个 token。ngram-map-k4v 使用 12-token 的键，每个键最多记住 4 个后续内容，并且仅当其中一个后续内容占主导地位（至少是其他总和的两倍）时才进行草稿。此版本中的草稿路由器首先尝试 k4v，然后是 mod，最后回退到 DFlash，第一个非空草稿赢得该轮次。目标模型仍然验证每个草稿 token，因此在贪婪模式下输出无损。没有草稿权重，查找表位于主机 RAM 中。设置：目标：unsloth/Qwen3.6-27B-GGUF (UD-Q4_K_XL) 通过 llama.cpp 服务器（Docker），镜像 server-cuda13，构建 b9859。草稿：Alittlehammmer/Qwen3.6-27B-DFlash-GGUF-llama.cpp (Q8_0, ~1.9GB)，单 GPU，目标和草稿都在同一张卡上，开启 flash attention，f16 KV 缓存，ctx 256k 用于速度测试。我使用的标志：--spec-type draft-dflash,ngram-mod,ngram-map-k4v 以及 --spec-draft-n-max 15（此版本的最大值）。每个草稿器的调优保持构建默认值：--spec-ngram-mod-n-match 24, n-min 48, n-max 64; --spec-ngram-map-k4v-size-n 12, size-m 48, min-hits 1。贪婪模式（温度 0, top-k 1），并发数 1，关闭推理（大多数情况下），一次只在一张 GPU 上运行一个服务器。我运行的内容：迭代编码基准测试（仓库中的 benchmark/bench_ngram.py）：18 个固定提示作为一次累积对话发送。第 1-9 轮逐步构建一个 Gradio 聊天应用功能，第 10-18 轮是对完成代码的维护（完全重新生成，文档字符串传递，重命名，错误修复，重构为类，pytest 测试，审查和修复）。我编写这个基准测试是因为没有公开基准测试涵盖多轮“模型编辑自己的代码”的工作负载，而这正是 n-gram 的目标。从 llama.cpp 自身的计时块测量，一次一个堆叠。真实提示 A/B 测试：通过 aiperf 以相同顺序重放相同的 100 个 LiveCodeBench 提示，对比 DFlash 与 DFlash+ngram，自然 EOS，种子 42。合成扫描：aiperf ISL = OSL 在 512 / 4K / 12K / 36K，ignore_eos + min_tokens 固定，30 / 10 / 5 / 3 个请求，丢弃预热。无损性：完整的 MATH-500（这次全部 500 道题）和官方 LiveCodeBench 工具（58 道题，2024 年 8 月窗口）。VRAM：nvidia-smi 在加载过程中以 4 Hz 采样计算内存，三个提示，以及拆卸。硬件：AMD Ryzen 9 9950X | NVIDIA RTX PRO 6000 Blackwell | 96GB VRAM | CUDA 13 | Ubuntu。最佳结果：在 18 轮编码会话中，321.5 对 53.5 tok/s 解码 = 6.01x 使用完整堆叠。仅在维护轮次（编辑现有代码，日常使用场景）中，它运行在 385 tok/s，是基线的 7.5 倍。https://preview.redd.it/qrorl17ssndh1.png?width=1700&format=png&auto=webp&s=b0b138d6cc624d4f32e75ced5630418f8c584986。总结：n-gram 的优势随着会话进行而增长，而基线在下降。基线解码从 62.8 -> 48.9 tok/s，随着对话填充 KV 缓存。n-gram 堆叠在同一轮次中加速，从 166 -> 325 tok/s，因为更多上下文意味着更多可复制的内容。完全消融（解码 tok/s）：基线 53.5，单独 DFlash 198.7 (3.71x)，DFlash + map-k4v 200.6 (3.75x)，DFlash + ngram-mod 304.3 (5.68x)，完整堆叠 321.5 (6.01x)。所以 ngram-mod 完成了几乎所有 n-gram 工作，比单独 DFlash 提升 53%；map-k4v 单独增加约 1%，在 mod 之上增加约 6%。到结束时，92% 的输出 token 来自接受的草稿，每个输出 token 的开销约为 1.8 个草稿 token。在各种单次提示上，n-gram 没有任何增加：相同的 100 个 LiveCodeBench 提示以相同顺序：单独 DFlash 176.1 对完整堆叠的 170.3 tok/s 每用户，草稿接受率 47% 对 42%，以及第二个 token 的时间 30.5 对 69.1 毫秒，因为 n-gram 缓存开始时为空，需要上下文中有 token 才能复制任何内容。如果你的工作负载是多样的单次提示，单独 DFlash 是更好的默认选择。它只是一个标志的切换，切换没有任何代价。https://preview.redd.it/27vpsnhetndh1.png?width=2039&format=png&auto=webp&s=0deee6f50082007290b9addfd4e0ac564b223b0d。n-gram 草稿器在 GPU 上实际上是免费的：nvidia-smi 在整个生命周期中：基础 33,256 MiB，DFlash 38,810 MiB（+5,554 MiB，所以我上次用 nvtop 目测的约 5GB 是对的），DFlash + ngram 38,810 MiB。与 MiB 完全相同。也没有加载时间成本，查找表位于主机 RAM 中。https://preview.redd.it/o284760itndh1.png?width=1360&format=png&auto=webp&s=8447c9b32c04cef68136fef457b000af458c6d5b。仍然无损，现在在完整的 MATH-500 和真实的 LiveCodeBench 上测量。https://preview.redd.it/vn8jm2fntndh1.png?width=1700&format=png&auto=webp&s=c816e6920a0ee2330ac08c013c85e80ee85c96dd。上次你们正确要求超过 100 道题。完整 500 道题：基础 440/500 (88.0%) 对 DFlash 435/500 (87.0%)，每个科目相差不超过 2 道题，两边都没有未解析的答案，并且在测量时 DFlash 以 254.7 tok/s (3.49x) 生成。500 道题的墙上时间：基础 2 小时 17 分钟对 DFlash 44.7 分钟。官方 LCB 工具在 2024 年 8 月窗口：基础 11/58 对 DFlash 12/58，这次 DFlash 多对一道题。两个差距都是批处理验证中翻转边界 token 的浮点噪声，而不是实际的准确率影响。关于绝对 LCB 分数的警告：lcb_runner 静默限制 max_tokens 为 2000，并且这个模型在写代码之前会用纯散文推理（即使关闭推理），所以 47/58 和 46/58 的生成在代码块之前被截断并自动失败，而每个符合限制的答案都通过了。对上次帖子的更正：DFlash 在 36K 下是 4.71x (289.3 tok/s)，而不是 4.44x。我之前的运行使用了 LLAMA_CTX=40960，窗口在约 8.2k 输出 token 时静默填充，导致响应被截断。在 compose 默认 ctx 256k 下重新扫描，使用完整的 36,864-token 输出，数字上升了。"q8_0 KV 缓存在这个配置下慢 15-17%（中位数从 824 降到 682 tok/s），并且草稿接受率从 89% 降到 79%。所以 f16 仍然是默认值。仔细用合成扫描测试 n-gram，我差点发布了垃圾数据。完整的扫描显示 +ngram 在 36K 下达到 520.9 tok/s，是基线的 8.47 倍，是单独 DFlash 的 1.80 倍，在完全对称的运行中。听起来很棒。然后我检查了模型实际生成的内容。被 ignore_eos 强制超过自然停止后，贪婪的 36k 输出以真正的 Love's Labour's Lost 续篇开始，然后锁定在一个两行的 ARMADO/MOTH 循环中，重复约 1,514 次。98.3% 的输出 12-gram 是重复的，92% 的草稿接受率（35,898/38,908），重放时服务器端解码 748 tok/s。它也夸大了单独 DFlash 的数字。将 8.47x 视为长退化输出的上限；诚实的多轮数字是上面的 6x。在较短的规模上，随机合成散文实际上是 n-gram 最差的情况（9-14% 接受率），但堆叠在 4K 和 12K 下仍然领先：231.4 和 328.0 tok/s，而单独 DFlash 为 191.5 和 234.0 tok/s。https://preview.redd.it/0kpvmc8bundh1.png?width=1700&format=png&auto=webp&s=c6bb32dfc05a35f55325724b80a865bb19da8417。📦 资源：GitHub，一个命令的 Docker 部署，18 轮基准测试，所有扫描，CSV 和图表：https://github.com/lukaLLM/DFlash_Qwen3.6_27B_LlamaCPP。完整视频，包含 mod 和 k4v 实际如何草稿的视觉演示，以及实时运行：https://youtu.be/zNUoHONUHGk。附注：我滥用 AI 来组织所有这些内容。任何在比构建默认值更大的关键/链大小上运行 ngram-mod 的人——