现有的推测解码系统（Speculative Decoding）仍存在不少性能损耗。
单请求场景下，目标模型权重读取占据大部分推理时间，但每轮接受的Token数量有限；批量请求场景下，每个请求额外产生的验证计算又会削弱加速效果；此外，不同模型架构、GPU硬件和服务负载存在差异，很难依靠一种通用优化方案解决所有问题。
为此，来自加州大学伯克利分校、普林斯顿大学、斯坦福大学和英伟达的研究人员开源了一个优化推测解码的RSI框架SpecPilot。
该框架让AI Agent自主寻找推测解码中的性能瓶颈，并针对不同模型、GPU和服务场景发现优化算法。
在无需额外训练、且不损失模型输出质量的前提下，SpecPilot将单请求场景下相对自回归解码的加速比，从原始DFlash2的4.46倍提升至10.87倍；在批处理场景下，DSpark则从1.94倍提升至3.93倍。
01
整体优化流程
图1：SpecPilot 闭环的一轮流程。
如上图所示，SpecPilot采用循环迭代的方式开展优化，每一轮包含五个阶段，且每轮都从上一轮的最终系统出发（新部署则从stock加记忆条目出发），因此整个循环是递归的。
Phase 0：性能瓶颈分析。
首先，SpecPilot通过成本模型计算当前系统与理论性能上限之间的差距，判断最值得优化的方向。
具体来说，成本模型将性能上限分解为三个因子的乘积，从三个维度评估性能损耗：
接受数量因子（τ因子）：当前系统接受的Token数量与精确回放中最优best-first树在最佳节点预算下可接受数量之间的差距。
内核因子：剖析得到的实际步时间与各类内核（目标模型GEMM、循环层、注意力、起草器、Prefill等）字节下限之和的比值。字节下限取该内核的FLOP时间（按60%峰值稠密计算吞吐量计算）与字节时间（按90%峰值带宽计算）中的较大值，用于衡量实际内核执行效率与理论性能之间的差距。
开销因子：实际步时间与剖析步时间的比值，衡量性能分析未覆盖的额外开销。
每轮开始时，成本模型都会基于记录的草稿格（Lattice）和性能剖析数据重新计算这三个因子，其中最大的因子代表当前最值得优化的性能缺口。
通过这种方式，系统能够动态识别性能瓶颈究竟来自Token接受数量不足、内核执行效率低下，还是剖析之外的额外开销，并跟随瓶颈在不同轮次间的转移。
Phase 1：Agent并行探索。
主Agent根据Phase 0的成本模型结果，从最大的性能缺口出发规划多个优化方向，并为不同方向分配独立的子Agent，在不同GPU上并行开展实验。
子Agent首先利用成本最低的证据（如精确回放、微基准测试或单GPU计时）评估优化方向的潜在收益。只有扣除运行时开销后，预计收益仍至少达到3%的方向，才会继续进行算法实现。
随后，子Agent将优化方案实现为代码补丁，即隐藏在选项背后的代码修改，其默认配置仍能复现Stock系统的行为。
这些补丁必须先在开发请求上通过正确性检查和Token Forcing，再交由独立控制器进行性能测量。
Phase 2：优化集成。
不同优化方案可能单独收益有限，但组合起来能够产生更大的效果。
因此，SpecPilot设置了专门的集成子Agent，将经过验证的代码补丁叠加到当前最佳系统中，并按照相同的性能评估规则测量组合后的整体收益，判断是否值得保留。
Phase 3：GPU内核调优。
内核子Agent对集成后的系统进行性能剖析，优先调优距离各自字节下限最远的内核，进一步减少权重读取和计算过程中的性能损耗。
Phase 4：最终验证。
每轮优化结束后，系统都会进行一次「密封终测」：使用未参与开发的请求，对优化后的系统与Stock进行性能对比，并对输出以及最长4096 Token的长输出重新执行Token Forcing。
只有同时满足性能提升和正确性要求的方案，才能进入最终版本；任一检查失败，都会导致该版本被拒绝。
这里还有一个值得注意的细节：论文专门设计了故障注入实验，在2048 Token之后人为加入Logit偏置。由于开发阶段的输出通常止于2048 Token，因此只有密封终测中的长输出才能触发这些故障。这也验证了长输出Token Forcing对于发现隐蔽错误的重要性。
性能提升的判定规则
SpecPilot将修改系统的智能体与负责测量的控制器隔离。控制器运行“配对测试”，两个系统在两块GPU上服务相同的请求，并在两次运行间交换GPU，以消除硬件差异。
补丁只有在收益的95%置信下限超过1%加上两倍的stock自身计时噪声（H100单请求下小于0.1%），才会被采纳；若其输出与当前最佳系统存在分歧，门槛则提高到约3%。
结构化记忆
每轮验证通过并被采纳的优化都会被整理成结构化记忆条目，包括相对于其依赖条目的代码差异、变体注册记录、正确性约束与配置选项、以及实验结果、适用限制和未测试范围。
一条记忆只有在将其与全部依赖项一起应用于Stock系统后，能够精确复现其来源系统的代码，才会被保留。
当这些记忆被复用于新部署时，系统仍会重新调优并测量其性能，但不会将复用的优化算作新的发现。
这套记忆系统既服务于后续迭代，也支持跨模型和硬件平台迁移。新部署的第一轮优化，就可以直接从Stock系统加上主Agent挑选的已验证记忆条目开始。
论文披露，截至论文实验时，SpecPilot的结构化记忆已经积累了140条经过验证的优化条目，每条最多包含12个依赖项，覆盖论文评测的全部部署设置，其中15条专门针对sm_120架构。
02
四项核心优化技术
（1）W12：无损12-bit权重格式
针对单请求场景下目标模型权重读取占据大量推理时间的问题，研究团队提出W12权重格式。
其基本思路是利用BF16权重在同一输出通道内指数分布相对集中的特点，将每个权重编码为12 bit，包括符号位、4-bit指数偏移和7-bit尾数。
对于超出预设指数范围的权重，则通过额外的稀疏列表进行精确恢复。
与普通权重压缩不同，W12能够在加载时逐位恢复原始权重，不改变模型计算结果。同时，研究团队设计了专用GEMM内核，在寄存器中直接完成权重解码，避免额外解码过程带来的性能损耗。
图2：W12。
（2）混合架构的Best-first Tree Verification
针对传统推测解码只验证一条草稿链、容易提前停止的问题，研究团队引入Best-first树验证机制。
它不再只选择一条候选路径，而是根据每个节点在父节点条件下的对数概率，为候选节点排序，优先保留累计路径得分最高的节点。
面对包含Gated DeltaNet（GDN）循环层的混合架构模型，研究团队沿每条根路径重新计算状态，并设计WY验证内核，利用张量核心并行处理多条路径。
图3：best-first tree。
（3）两级验证（Two-Level Verification）
研究团队进一步提出两级验证机制。
第一轮使用W12中嵌套的8-bit权重视图执行低精度验证，得到一条候选Token链，但不直接接受Token，也不更新目标模型状态。
随后，草稿模型从候选链末端继续生成新的草稿，最终由一次完整的精确验证统一检查候选链和新生成的草稿。
由于只有精确验证阶段才能接受Token，因此该机制能够在保持无损的前提下，增加每次精确验证接受的Token数量。
图 4：两级验证。
（4）三种批处理优化机制
针对批量请求中每增加一个验证节点都会带来额外计算的问题，团队设计了三种机制：
共享节点预算： 多个请求共享固定验证节点数量，优先分配给路径概率更高的候选节点。
动态草稿长度： 根据每个请求近期的Token接受情况和草稿置信度，动态选择16、12或8个草稿位置。
Prompt Admission： 将等待调度的新请求Prompt分段加入验证计算，复用已有权重读取过程，但仅在调度器原本需要等待时执行。
三种机制均不改变最终精确验证过程，通过合理分配计算资源提高批量推理效率。
03
对比实验与结果分析
如表1所示，在单请求场景下，SpecPilot在所有测试配置中的速度都超过了原始系统（Stock）的两倍。
其中，Qwen3.8-27B在RTX PRO 6000上取得平均10.87倍加速，相比原始DFlash2的4.46倍提升明显。
如表2所示，在批处理场景中，SpecPilot同样表现出较好的优化效果。
以FP8精度的Qwen3.8-27B为例，DFlash2原始系统相对自回归解码的平均加速比为2.02倍，使用SpecPilot后提升至3.90倍；DSpark则从1.94倍提升至3.93倍。
