投机解码(speculative decoding)是当前 LLM 推理最实用的加速手段之一:让轻量的 draft 模型先草拟一段 token,目标大模型一次前向验证完,省掉自回归逐 token 的等待;并行 draft 模型进一步把提速做大,一次前向就草拟一整块。但 arXiv 新论文 SpecPilot 指出,各家发布出来的投机解码系统,实际跑出的加速往往只是「应得加速」的一部分——剩下的余量,被三个工程问题吃掉了。
三个被浪费的加速空间
论文把浪费归纳为三点。第一,单请求场景下,每一步验证只接受少量 token,却要读完目标模型的全部权重,读权重的开销远超接受的收益。第二,一旦上 batch,每个请求都要做一遍验证,加速比相对自回归解码大致减半。第三,投机解码强部署相关:换一个目标模型、draft 模型、GPU 或 serving 配置,最优参数组合就变了,不存在万能配置——这正是一般论文给不了、工程团队又没人力逐一去调的部分。
让 agent 循环自己找优化
作者的解法是把「调优」这件事本身交给一个 agent 循环。每一轮,先用成本模型定位当前系统与性能上限之间最大的差距;多个并行 agent 各自探索一个优化方向,把成功的集成进系统;另有专门的 kernel 子 agent,负责调优离内存带宽上限最远的内核。两道安全设计值得注意:一是 token forcing,把每个输出 token 与原始系统逐一对照,专门用来抓 agent 的 reward hacking;二是结构化记忆,把验证过的机制带到新一轮循环和新部署,不重复交学费。这里的原系统(stock)即未加 SpecPilot 的 DFlash2 或 DSpark 原版,与优化后引擎跑同一 serving。
实测:同样的硬件,加速比翻倍以上
这个循环挖出了一批通用机制:无损的 12-bit 权重格式、面向混合循环架构目标的 tree verification、两级验证,以及三种 batch 机制。评估覆盖 4 个目标模型(公开表格含 Qwen3.8-27B 与 Muse-Glimmer-30B)、3 个 draft 模型(DFlash2 与 DSpark 等)、2 种 GPU 平台(H100 与 RTX PRO 6000)和 5 个基准(gsm8k、humaneval、math500、mbpp、mt-bench),口径为每请求生成 2048 个新 token、按请求取加速比几何平均,batch 并发 16、20、24:单请求下,相对自回归解码的加速比从原系统的 4.46 倍提到 10.87 倍;batch 下从 1.94 倍提到 3.93 倍,每个部署都翻倍以上,单请求每步提交的 token 数也从约 4.4-5.2 提到约 12.6-13.1。全程无训练、无质量损失:解码保持贪心,每个 token 由目标模型拍板,严格 lossless。
代码已按 Apache 2.0 开源(基于 SGLang 衍生),仓库放出 6 个部署的引擎与复现脚本,论文由 Kunjun Li 等 10 位作者完成:arXiv 论文、GitHub 仓库。
所以呢
这篇论文值得记的不是 10.87 这个数字,而是它验证的工程范式:部署特定的系统优化,人力成本高到没人做得全,而 agent 循环可以把这块「余量」自动化挖出来。更有意思的是作者对自家 agent 的态度——产出再好,也要逐 token 对照原系统防作弊。对推理成本敏感的团队来说,与其等下一代模型,不如先算算现有部署里还剩几倍没挖出来。