代码编辑推测解码兼顾提速与输出一致

在 RTX 3050 8 GB 上运行 7B 模型，代码编辑能达到 489.8 tok/s，而且开启加速前后输出完全相同。这是 SonicBoom v0.0.5 给出的结果。关键不只是显卡跑得快，而是它利用了代码编辑中大量复制原文件的特点。

对本地 AI 编程工具开发者，这篇更新值得看的有两点：哪些任务适合推测解码，以及怎样避免加速改变生成结果。不过，这组成绩离通用聊天性能结论还有距离。

489.8 tok/s，测的到底是什么

作者使用 RTX 3050 8 GB，模型为 Qwen2.5-7B-Instruct Q4_K_M，两个运行时使用同一份 GGUF。对照的 llama.cpp 版本是 43fe9c64281，参数为 -ngl 99 -fa on，并采用作者称为 llama-server 八种推测模式中最快的 ngram-mod。

工作负载是 10 轮代码编辑，每轮修改一个 100–300 行的源文件，采用贪心解码（greedy）。

SonicBoom 的推测解码吞吐达到 489.8 tok/s，作者称这是自身普通解码的 12.7 倍。开启和关闭推测解码时，10 / 10 轮输出一致。

原文还列出了普通解码和预填充成绩：上下文为 512 / 4K 时，解码为 40.6 / 38.2；预填充 512 / 8K tokens 时，按墙钟时间测得的读数为 1557 / 1200。作者承认，普通解码和预填充仍略落后于 llama.cpp。

489.8 tok/s 是特定代码编辑任务下的推测解码成绩，不能直接当作模型的通用生成速度。

原文没有给出完整的逐轮耗时、接受率和 llama.cpp 对照成绩，因此无法仅凭这些数字判断日常使用能快多少。

为什么复制旧代码，反而成了加速机会

推测解码（speculative decoding）的做法是先提出一串候选 token，再交给目标模型验证，减少逐个生成的开销。

这里的候选生成器没有使用另一个小模型，而是长匹配 n-gram，每次最多提出 63 个 token。可以把它理解成：从已有文本中寻找较长的匹配片段，猜测接下来会继续出现什么。

代码编辑很适合这种方式。修改一个函数时，模型输出的文件往往仍包含大量原始代码。只要候选片段连续命中，就能一次验证多个 token。

因此，作者认为它适合编辑、修订和重构。原文还报告 coding chat 获得 4.4× 加速，但没有展开该任务的具体测试条件。这个差距也提示我们：输出越依赖复制输入，越可能吃到这套方法的收益。

批量验证，为什么还能保持输出一致

候选 token 最终经过模型验证，不代表结果就一定与逐步解码完全相同。计算批次、归约顺序或内核选择发生变化，都可能影响浮点结果。

作者给出了三个约束：

• 量化矩阵乘法保持列不变性（column-invariant），避免批处理方式改变对应计算结果。
• 验证阶段的注意力按绝对位置划分 key，并以固定顺序归约各行。
• 所有影响数值结果的内核选择，都在模型加载时确定并锁定。

按作者的表述，一个包含 64 行的验证批次，其第 i 行与第 i 步普通解码具有相同的比特结果。这也是他们默认开启推测解码的理由。

这里要区分两层证据：10 / 10 轮一致是这次工作负载的实测结果；更广泛的逐比特一致性，则依赖上述实现约束持续成立。原文没有提供覆盖其他硬件的验证结果。

我的判断

我认可它把「输出不变」作为加速目标。对代码编辑工具，速度提升如果伴随生成结果变化，就会增加回归定位和行为比较的难度。

它的适用前提也很明确：任务包含大量可复用文本，并且测试采用 greedy。不能据此推断随机采样、从零生成代码或开放式问答也有同样收益。

与小模型生成候选的方案相比，n-gram 直接利用已有文本，但更依赖任务中的重复片段。本文没有两类方案的对照数据，无法判断谁在一般编程任务中更划算。

硬件覆盖同样有限。作者目前只有 sm_86，并邀请拥有至少 8 GB 显存的其他 NVIDIA 显卡用户复测。两台同型号 GPU 机器比较 token hash 的检查只是可选测试入口，不能当作跨机器一致性已经得到证明。

能拿来做什么

• 为本地代码编辑工具选推理后端时，可以用真实的前端或 Node 文件修改任务复测，同时记录吞吐、整轮耗时和输出一致性。
• 设计评测集时，应把保留大量原文的局部修改，与从零生成代码分开测试，避免用一种任务的成绩代表全部 AI 编程体验。
• 如果准备接入 SonicBoom，可以保留关闭推测解码的基线，并在相同输入、模型和 greedy 设置下比较 token 序列；跨机器部署时，再补充原文提出的 token hash 检查。