面向 LLM 服务测试时扩展的推测搜索优化

该 arXiv 论文指出，测试时扩展通过在推理阶段增加计算提升 LLM 在数学、编程等难题上的准确率，而推测执行可加速推理路径探索。但作者发现推测执行给 LLM 服务系统带来两个新问题：候选路径搜索空间爆炸，以及对候选的频繁细粒度验证。为此提出 SpecScale 服务系统，用提前剪枝、去重冗余计算、延后细粒度验证三项技术平衡延迟与计算开销，在 MATH 与 Olympiad 上吞吐和延迟均显著优于非推测与近期推测方案，且答案质量不变。

此前推测执行研究多关注加速推理路径探索本身，而本文把问题转向服务系统层面：一旦引入推测执行，候选路径会爆炸式增长、验证任务变得高频细粒度，反而可能拖垮服务效率。这意味着测试时扩展的瓶颈从算法搜索转向系统调度与资源分配，SpecScale 说明服务系统设计已成为该方向能否落地的关键变量。

推测执行会并行生成大量候选路径，路径数量随推理步数快速膨胀，同时每个候选都需验证，形成大量细粒度任务，导致 GPU 等算力被重复消耗、调度碎片化。SpecScale 据此采取三条机制：提前剪枝质量低的候选，减少无效路径；对冗余候选做计算去重，避免同一中间状态被重复计算；将细粒度验证延后批量处理，以吞吐换延迟。三者共同在延迟与计算开销之间做折中。

对提供 LLM 推理服务的团队而言，该方向提示不能只优化单次生成速度，还需在服务层管理候选路径数量与验证调度，否则增加测试时计算可能带来成本上升而收益有限。若 SpecScale 思路可复现，产品可在数学、编程等推理场景中增加推理计算而不等比增加 GPU 开销，从而改善响应延迟与单位成本，但具体收益幅度需结合本团队负载验证。

• 在内部推理服务中测试候选路径提前剪枝策略，用答案质量基本不变为前提，测量吞吐与延迟变化
• 为数学、编程类高价值场景设计可开关的推测执行档位，按任务难度选择是否延后细粒度验证
• 建立冗余候选路径去重的中间状态缓存，降低重复计算带来的 GPU 成本

• SpecScale 相比非推测与近期推测方案的具体吞吐、延迟提升幅度和测试配置未在证据中给出
• 提前剪枝是否会影响难题上的最终答案质量，证据仅称保留答案质量，未给出分项数据
• 三项技术在多大模型、多大并发下仍有效，证据未说明
• 是否有开源实现或可复现细节，证据未提及