ForeSpark：并行投机解码的联合预算调度新方案

投机解码（Speculative Decoding）是加速大语言模型（LLM）推理的重要技术，而并行草稿器（Parallel Drafter）因其能在单次前向传播中生成一整块草稿令牌，尤其适合高负载的LLM服务场景。然而，现有系统在优化吞吐时往往只控制验证的令牌数量，草稿阶段仍固定生成完整块，导致大量计算被浪费。近日一篇名为《ForeSpark: Joint Draft and Verification Budget Scheduling for Parallel Speculative Decoding》的论文提出了一种工作 conserving 投机（Work-Conserving Speculation, WCS）设计，通过联合分配草稿与验证预算，在保持输出分布不变的前提下显著提升吞吐。

并行投机解码的瓶颈：草稿浪费与预算耦合

并行草稿器一次性生成整块草稿令牌，避免了自回归草稿的串行开销，但这也带来一个新问题：草稿长度在单次前向传播前就已确定，无法像自回归草稿那样根据上下文动态调整。论文作者观察到，在高负载服务场景下，草稿阶段可消耗高达40%的步骤时间，而其中大部分草稿令牌最终因未被验证而被丢弃。这意味着宝贵的算力被用于生成无用的候选令牌。

现有系统虽然通过优化goodput（每秒接受的令牌数）来减少拒绝草稿对算力的挤占，但仅控制验证令牌数量，每个请求仍会生成完整草稿块。更复杂的是，草稿长度与验证长度在批次内相互耦合，必须为每个请求联合选择，同时保证决策的计算开销足够低。自回归草稿器的长度控制策略无法直接迁移，因为并行草稿器在单次传播前就锁定了长度。

投机解码的基本流程是：用一个较小的草稿模型快速生成若干候选令牌，再交给目标大模型并行验证，接受与目标模型分布一致的前缀。并行草稿器（如Medusa、Lookahead Decoding）不同于逐令牌生成的自回归草稿器，它在一次前向传播中同时输出多个位置的候选令牌，因而草稿长度必须在推理前静态确定。这种“一次性出块”的特性牺牲了长度灵活性：当上下文简单、接受率低时，整块草稿中大量令牌会被拒绝并丢弃，造成算力空转。理解这一点是把握文中“草稿浪费”问题的前提——浪费并非源于草稿模型不够准，而是源于长度决策与批次调度脱节。

goodput（有效吞吐）指单位时间内被目标模型实际接受的令牌数，而非草稿阶段生成的令牌总数。在投机解码的服务场景中，若只追求原始吞吐，系统可能生成大量最终被拒绝的草稿，挤占本可用于验证其他请求的算力，导致端到端有效产出下降。因此现有系统常以goodput为优化目标，通过限制每步验证的令牌数来抑制拒绝带来的浪费。但正如原文所指出的，仅优化验证端而不控制草稿端，goodput的提升存在天花板，这也正是ForeSpark引入联合预算的动机。

ForeSpark的核心设计：三组件实现工作守恒

为了解决上述矛盾，论文提出工作守恒投机（WCS）设计，并实现了原型系统ForeSpark。WCS的核心思想是联合分配每个请求的草稿预算与验证预算，让计算资源只花在“值得”的令牌上。ForeSpark通过三个关键组件实现这一目标：

1. 上下文感知的预草稿估计器

该组件利用目标模型的上下文特征，预测每个候选草稿长度的接受概率。与依赖历史统计的简单启发式不同，它从目标模型的内部表示中提取信息，为后续的联合调度提供依据。这使得系统能在草稿生成前就大致判断哪些长度更可能被接受，从而避免盲目生成完整块。

接受概率是投机解码中的核心量：对草稿令牌(x)，其被目标模型接受的概率通常取(\min(1, p_{\text{target}}(x)/p_{\text{draft}}(x)))，以保证最终输出分布与目标模型完全一致。这一拒绝采样机制解释了为何投机解码“不改变输出分布”。预草稿估计器要做的，是在草稿尚未生成时，依据目标模型隐藏状态等上下文特征预测不同草稿长度下的累计接受率，从而把长度决策从“事后统计”前移到“事前预估”。预测越准，调度器越能在批次内把草稿预算分配给高接受率的请求。

2. 轻量级联合草稿-验证调度器

调度器通过全局排序为每个请求选择草稿长度和验证长度。由于草稿与验证长度在批次内耦合，单独优化任一维度都可能导致全局次优。全局排序机制在保证决策计算廉价的同时，实现了批次级别的联合优化。论文强调，该调度器在每一步都能快速完成决策，不会成为新的开销瓶颈。

3. 草稿后预算分配

在草稿生成后，系统将验证预算分配给最有希望的令牌。这意味着即使草稿块中有些令牌接受概率较低，验证资源也会优先用于那些最可能被接受的候选，进一步提升有效吞吐。

实测性能：吞吐显著提升，负载容忍度更高

ForeSpark在vLLM上实现，并与当前先进的DSpark系统进行了对比。在匹配的每请求生成速率下，ForeSpark的吞吐量相比DSpark最高提升1.77倍，相比自回归解码最高提升2.49倍，且不改变输出分布——这一点对生成质量至关重要。

除了吞吐提升，ForeSpark在延迟服务等级目标（SLO）下展现出更强的负载容忍能力，可维持的请求速率最高达到DSpark的1.51倍。这意味着在相同的延迟约束下，ForeSpark能服务更多并发请求，对于实际部署的LLM服务系统具有直接价值。

对LLM服务系统的启示

ForeSpark的工作揭示了投机解码在服务场景中的一个关键洞察：草稿与验证不是独立的两个阶段，而是需要联合优化的资源分配问题。传统方法将草稿视为固定开销，只优化验证端，而ForeSpark通过动态调整草稿长度，从源头减少了浪费。

这种“工作守恒”的思路——即确保每一步计算都尽可能产生被接受的令牌——可能启发更多面向服务系统的推理优化研究。随着LLM部署规模扩大，这类细粒度的预算调度技术将变得越来越重要。论文在vLLM上的实现也表明，该方案具备与现有服务框架集成的可行性，为后续的工程化落地提供了参考。

对于关注LLM推理加速的开发者和研究者，ForeSpark提供了一个新视角：在并行草稿器日益普及的背景下，重新审视草稿阶段的资源分配策略，或许能释放出可观的性能红利。