SpecScale：推理分支提前展开后，怎样避免越跑越慢？

笔记日期： 2026-10-22
论文： Taming Speculative Search for Test-Time Scaling in LLM Serving
作者： Jinwoo Jeong, Woohyung Choi, Myeongjae Jeon, Jeongseob Ahn
版本与日期： arXiv:2609.39334v1，2026-09-30
一手来源： 版本页面、论文全文

1. 我的阅读主线：提前开工，为什么可能让所有人更慢？

设想一个数学推理服务：为了提高答案质量，同一道题同时探索四条解题路径。一条路径很快写完当前推理步骤，另一条却还在展开长长的计算。常规搜索会等四条都完成，再给它们评分、挑选值得保留的路径。已经完成的那条，只能暂时等着。

推测搜索的想法很自然：既然下一步迟早要做，就让先完成的候选先往下展开。如果它最终入选，这些工作已经做好；如果没入选，再把提前生成的内容丢掉。对于只有一个请求、还有空闲算力的场景，这种办法很容易奏效。

但繁忙的服务端并不缺可以执行的工作。其他用户的请求也在等 GPU。一个后来被淘汰的推测分支，提前占用的不是“免费时间”，而是别的请求本来可以使用的计算、显存和验证机会。于是，一个请求内部少等了几次，并不代表整个服务更快。它可能只是把等待转移给了其他请求。

SpecScale 正是从这个矛盾出发。它把优化分成三个相互影响的部分：提前剪枝 EP，尽快终止已经注定落选的候选及其后代；计算去重 CD，让完全相同的 token 前缀共享一次模型计算，同时保留多次独立采样；延迟验证 LV，把零碎的过程奖励模型评分合并成更有效率的批次。

这篇论文最值得读的地方，不是某个孤立的加速数字，而是它说明了一个系统问题：搜索决定尚未确定时，系统应该付出多少代价去维持这些可能性？ 提前展开越多，后续决定就越重要；验证越晚，可能白做的工作也越多。三个机制正是在调节这个关系。

论文摘要中的最高吞吐提升是相对朴素推测方案的 2.18 倍，以及相对所评测 FastTTS 配置的 1.87 倍。对应的 Qwen2.5-7B、MATH、八条 beam 实验，完整系统为 466 output tokens/s，朴素推测为 214，FastTTS 为 249，而非推测基线是 327。相对最后这个基线，提升约为 1.43 倍。后面会反复使用这组数，因为只记住倍数、不记住分母，很容易高估收益。

本笔记覆盖 v1 的全部 14 页，包括实验细节和参考文献；该版本没有单独附录。图 1、图 3、图 9 使用原论文局部图，其他图是对明确实验数值的重绘，或注明假设的教学示例。文中的概率推导、成本模型和建议评测方式属于阅读分析，不是额外实验结果。

1.1 它与 token 推测解码、SpecReason 各有什么不同？

这里“推测”的对象，是父候选还没有通过搜索筛选时，就提前生成的后续推理分支。它不等同于小模型先猜若干 token、再由目标模型逐 token 验证的推测解码。SpecScale 中，生成模型负责写出推理候选，过程奖励模型 PRM 负责对完成的步骤评分，系统再据此决定保留哪些路径。

它也与前一天读的 SpecReason 不同。SpecReason 关心较小模型提出的一个推理步骤，能否被较大模型接受；SpecScale 关心已有的多路径搜索，怎样在共享 GPU 上更有效率地推进。前者首先面对语义是否可接受的问题，后者首先面对候选筛选、重复计算和调度的问题。二者都跨过了单 token 的粒度，但不能把它们的正确性论证互相套用。

2. 先把三个基础概念讲清楚

2.1 Beam 数量是逻辑预算，不等于实际运行的序列数

论文用 $N$ 表示 beam size，用 $M$ 表示 expansion width，并保留 $k=N/M$ 个候选。一次筛选边界上，系统比较 $N$ 个候选步骤，选出最好的 $k$ 个父候选，再从每个父候选展开 $M$ 条延续，得到下一轮的 $N$ 条逻辑路径。

例如 $N=8$、$M=4$，就是每轮保留两个父候选，各展开四条延续。这里的“八条”是搜索算法的逻辑规模。启用推测执行后，某些候选在当前轮尚未决出胜负时，下一层甚至更后面的子分支已经存在，因此实际活跃序列数可能超过八条。启用计算去重后，多条逻辑路径又可能暂时由同一条物理序列表示。

所以，beam size、GPU 一次处理的物理输入数、KV cache 中实际保存的状态，是三个相关但不相同的量。理解这一点，才能看懂为什么 SpecScale 能在不直接缩小逻辑搜索预算的情况下减少物理工作，也才能避免把“八条 beam”误读成固定八个解码输入。

PRM 对一个已经完成的推理步骤及其上下文给出分数。本文讨论的分数位于 $[0,1]$。这个范围不意味着它已经校准成“数学正确的概率”，1.0 也不意味着证明完全正确。它只是该评分器的最高输出值。后面的严格剪枝，只需要保持评分排序规则，不需要假设评分器永远正确。

论文还说明最终答案选择使用步骤分数的加权和，但没有仅凭这一描述就足以恢复所有权重细节的信息。因此本文不额外补出一个并未给定的完整最终评分公式。

2.2 生成和验证，喜欢的批处理形状不同

自回归生成需要逐 token 推进，每一步读取模型权重、已有 KV 状态，再得到新的 token。这里的 PRM 验证则是对评分上下文做一次 prefill 型前向计算，不是再自回归生成一段长篇评语。两种阶段使用 GPU 的方式不同，适合的批量大小也不同。

在单卡上调用 PRM，会占用原本可以用于生成的执行时间。如果每完成一个候选步骤，就立刻发起一个很小的评分调用，验证工作会被切得很碎。固定调度成本、启动成本和低占用率，都可能让这种“尽快知道结果”的策略变得昂贵。论文的动机实验显示，朴素推测会让验证调用次数增加到基线的大约两到三倍。

连续批处理能把已经准备好的序列放进同一次生成迭代；前缀 KV 共享能避免重复保存已有历史。但这两者并没有自动解决全部问题：它们既不一定合并相同当前前缀上的重复前向计算，也不会替系统决定一个完成步骤应该等多久再评分。

2.3 吞吐、请求延迟、答案质量必须分别看

吞吐实验回答的是：在工作足够多时，单位时间可以完成多少计算产出。请求延迟回答的是：用户从提交问题到拿到答案等了多久。准确率回答的是：答案是否正确。这三个目标不能互相代替。

论文中的 normalized output latency，是端到端请求延迟除以生成的 output token 数。它不是相邻两个输出 token 之间的时间，不是首 token 延迟，也不是原始请求延迟的 P99。如果某种搜索方式改变了生成 token 的数量，分母也会变化。因此，归一化指标可以帮助比较服务效率，却不能单独证明某个固定质量要求下的用户尾延迟一定更好。

3. 从工作量和依赖关系理解“越并行越慢”

可以先用一个简单的分析模型帮助建立直觉。设有 $W$ 单位有用 GPU 工作，受依赖关系限制的关键路径长度为 $S$，有效处理能力为每秒 $C$ 单位工作。那么总时间至少满足

$$T\geq\max\left(\frac{W}{C},S\right). \tag{1}$$

这个式子不是拟合论文数据的性能预测器。真实 GPU 在不同阶段的有效算力不同，还受到显存、批量形状和调度开销的影响。不过，它足以区分两类瓶颈：一种是总工作量太大，另一种是依赖链太长，即使有空闲资源也无法提前执行。

推测执行试图缩短第二种瓶颈。提前做下一步，可能把原本串行的两段计算重叠起来，但也会产生被丢弃的工作 $W_{\mathrm{waste}}$。于是有相应的下界

$$T_{\mathrm{spec}}\geq \max\left(\frac{W+W_{\mathrm{waste}}}{C},S_{\mathrm{spec}}\right). \tag{2}$$

在预期的重叠场景中，$S_{\mathrm{spec}}$ 可以小于 $S$。但这是依赖关系层面的机会，并不保证资源竞争下的实际完成时间也会缩短。若系统原本主要被关键路径限制，多做一点工作可能值得；若系统原本已经被总工作量限制，多出来的工作就会直接挤占服务能力。

这解释了为什么单请求实验的直觉到了高并发场景可能失效。单个请求等 PRM 的时候，GPU 可能没有其他事情可做；高并发时，即使这个请求暂时停下来，其他请求仍然能够继续。此时再提前生成大量不确定的分支，未必是在填补空闲，反而可能是在给满负荷的资源增加负担。

验证延迟还会放大这种负担。假设一个最后会被淘汰的分支，以每秒 $r$ 个 token 的速度继续生成，而系统在 $d$ 秒之后才知道它落选，那么这条分支大约额外生成了 $rd$ 个 token。如果它还能继续展开后代，总浪费可能比单分支估计更大。

因此，“验证晚一点”有两种相反效果：它可能让评分批次更大、更便宜，同时也可能让无效分支多活一会儿。SpecScale 并不是简单地把一切做得更早，而是在不同位置选择什么时候等待、什么时候推进。

论文的动机数据与这个解释一致：若干设置里，步骤之间等待的中位占比约为 20% 到 55%，说明确实存在可隐藏的空档；但朴素推测也增加了活跃候选数量，并随着并发提升逐渐暴露出吞吐问题。真正需要判断的是，消除这些等待是否改善了共享资源的整体使用效率。

4. 提前剪枝：严格成立的部分，与会改变选择的部分

4.1 为什么一个候选可以在本轮结束前就被判出局？

先固定一次筛选轮次，并假设一个候选完成步骤后的评分不再改变。用 $V_t$ 表示时刻 $t$ 已经评分的候选集合。当至少有 $k$ 个候选完成评分后，定义当前阈值为这些分数中的第 $k$ 大值：

$$\tau_t=\operatorname{kthmax}\{s_i:i\in V_t\}. \tag{3}$$

后续新的评分进入集合，只会让第 $k$ 大的分数保持不变或者上升，不会下降：

$$V_t\subseteq V_{t+1} \quad\Longrightarrow\quad \tau_{t+1}\geq\tau_t. \tag{4}$$

现在看一个已经评分的候选 $j$。如果 $s_j<\tau_t$，就说明至少已经有 $k$ 个候选严格优于它。还没有到达的分数，无论高还是低，都无法抹掉这 $k$ 个已经存在的更高分候选。最终前 $k$ 名不可能有它。因此，它提前生成的后代也不再有保留价值，可以停止。

这里的“严格小于”不能随意改成“小于等于”。如果一个候选恰好与阈值同分，它是否入选取决于并列时的处理规则。类似地，不能因为一个祖先的分数低，就推断尚未评分的后代一定低。证明针对的是当前这一轮用于筛选的已知分数，不是对未来推理质量的单调性假设。

图 1. 原论文 v1 第 6 页 Figure 8，$N=M=4$，因此只保留一个候选。B 得分 0.7，D 得分 0.5 后可直接剪除；C 后来得到 1.0。最后一幅还使用了下文讨论的满分提前结束策略。

4.2 用一组小数字验证推导

设 $k=2$，最先到达的两个分数是 0.80 和 0.50。此时阈值为 0.50。如果另一个候选已经得到 0.45，它就可以出局，不必等待其他人。后面如果依次出现 0.62、0.74、0.40，阈值会升到 0.62，再升到 0.74，最后保持不变。那个 0.45 的候选不可能因为最后来了一个更低分的人而重新进入前二。

这个论证不要求 PRM 把所有数学步骤评对，也不要求 0.80 代表 80% 的正确概率。它保证的是相对于这套固定评分与选择规则，不会剪掉一个本来能严格进入前 $k$ 的低分候选。即使评分规则本身不好，剪枝也可以忠实地保留它的选择。

所以，算法是否保持既有搜索决定，与搜索决定是否产生正确答案，是两个不同的问题。前者能用排序性质证明，后者需要任务实验。把这两层分开，后面就不会把“安全剪枝”误读成“数学正确性得到保证”。

图 2. 为解释证明构造的 $k=2$ 示例，并非运行轨迹。随着评分到达，第 2 高分只会上升或不变，低于现有阈值的候选无法重新进入前二。

4.3 凑齐满分就结束，是另一个性质不同的策略

SpecScale 还会在已经有 $k$ 个候选得到 1.0 后，直接完成本轮选择。理由看似充分：其他候选不可能超过 1.0。但没有超过，不代表不能打平。后来到达的满分候选，可能恰好是基线并列规则会选中的那个。

设只保留一个候选。A 最先完成，得分 1.0；B 完成较晚，也会得到 1.0，而基线规则在并列时优先选 B。提前结束会选择 A、取消 B。保留候选的分数仍然是最高分，但保留的推理历史已经改变。下一轮的生成和最终答案也可能跟着改变。

论文在准确率讨论中明确承认了这一点。严格低于阈值的剪枝，可以基于固定排名规则解释；满分提前结束，则可能改变并列候选的身份。后者的合理性主要由实测质量与性能共同支持，不能沿用前者的严格等价论证。

这也解释了评分分布为什么会影响系统表现。论文观察到，Qwen 配置比 Llama 配置更常得到满分，因此更容易触发立即结束。如果换一个更少输出精确 1.0 的 PRM，即使它的排序更可靠，也未必带来同样多的提前结束机会。“评分器更好”与“评分器更容易加速服务”不是同一个目标。

4.4 算法 1：收到分数后怎样决定停止哪些分支

下面把两个规则分开写。编号伪代码是对方法语义的整理，不限定某个具体系统的数据结构。

算法 1：处理一个固定筛选轮次中的已验证分数
输入：候选 c、分数 s(c)、保留数 k、已验证集合 V
1. 将 c 及其固定分数加入 V。
2. 若 |V| >= k，计算已验证分数中的第 k 大值 tau。
3. 对每个已验证且 s(j) < tau 的候选 j，停止它及其推测后代。
4. 与 tau 同分的候选，继续交给既定并列规则处理。
5. 可选的满分捷径：若 V 中已有 k 个分数为 1.0 的候选，
   按捷径的并列规则选择其中 k 个，取消其他候选并结束本轮。
6. 否则，等必要评分到齐后，用基线选择和并列规则结束本轮。
7. 展开保留的父候选；只释放已无人引用的共享状态。

最后一步是理解内存收益时不可忽视的条件：取消一条逻辑路径，不意味着这条路径的前缀状态全部由它独占。其他路径可能还引用相同 KV。加入计算去重后，逻辑候选、共享前缀和实际物理序列之间的对应关系会更复杂，必须在语义上保持一致。

5. 计算去重：共享一次计算，但不能共享一次随机结果

5.1 四条逻辑路径，可以暂时只算一条

假设四条候选当前的 token 历史完全相同，并且使用同一个模型、相同的条件状态与采样设置。它们下一步的 logits 分布也相同。没有必要把这份确定性计算重复做四次；可以只算一次 logits，然后从这个分布中独立采样四次。

如果三个样本抽到同一个 token，第四个抽到另一个 token，那么下一轮只需维护两个不同的物理前缀，分别代表三条和一条逻辑路径。论文用 potential size 描述一条物理序列所代表的逻辑路径数。代表三条路径的那条序列，下次继续只做一次前向，但仍然要抽三次独立样本。

关键在于“独立”。如果只抽一次，再把同一个结果复制四份，四条路径就被人为绑在一起，搜索多样性会被破坏。SpecScale 共享的是产生分布的确定性计算，不是采样的随机结果。相同前缀只有在真正抽到不同 token 时，才需要分裂成不同的物理输入。

图 3. 原论文 v1 第 6 页 Figure 10。四次抽样产生三个 “of” 和一个 “that”，于是下一步的物理前缀只有两个，但逻辑路径仍然是四条。

5.2 为什么分组不必改变采样分布？

设相同前缀的下一 token 分布为 $p_v$，当前有 $m$ 条逻辑路径。对每个 token $v$，记抽到它的次数为 $n_v$，并满足 $\sum_v n_v=m$。独立采样得到这组计数的概率是多项分布：

$$\Pr\{(n_v)_v\} =\frac{m!}{\prod_v n_v!}\prod_v p_v^{n_v}. \tag{5}$$

先独立抽样，再把结果相同的样本分组，不会改变这组计数的概率。到了下一步，同一组中的前缀仍然相同，可以再次计算一次条件分布、独立抽取对应次数的样本、再按结果拆组。逐 token 重复这个过程，就得到一个自然的归纳解释：分组改变的是路径的物理表示，不必改变逻辑采样的概率语义。

不过，这个解释有前提。所谓“相同前缀”，必须对应相同的完整条件状态。若两条路径使用不同的 token 约束、惩罚项或采样参数，就不能只看可见文字相同而合并。若并列筛选依赖候选身份，而不只依赖文本和分数，身份信息也必须在物理分组后仍有意义。

此外，概率语义相同，并不等于不同批量形状下的每次浮点运算和随机数消耗顺序都逐位相同。这里有用的主张是：在相同条件分布下，保留规定数量的独立抽样。它比“重复文字可以随便合并”严格，也比“整次物理执行完全一样”更准确。

5.3 一步之后，预计会留下几个不同前缀？

定义指示变量 $I_v$：只要 $m$ 次抽样中至少有一次出现 token $v$，就令 $I_v=1$。不同 token 前缀的数量是 $U=\sum_v I_v$。token $v$ 一次都没出现的概率为 $(1-p_v)^m$，因此

$$\mathbb{E}[U] =\sum_v\mathbb{E}[I_v] =\sum_v\left[1-(1-p_v)^m\right]. \tag{6}$$

这里不需要假设不同 $I_v$ 之间独立。期望的线性性本来就允许把每个 token 的出现概率直接相加。这个细节很有帮助：我们只是在计算一共出现多少种结果，不是在把这些出现事件当作彼此独立的事件相乘。

举一个纯教学例子：只有两个可能 token，概率分别为 0.75 和 0.25，共独立采样四次。那么

$$\mathbb{E}[U] =\left(1-0.25^4\right)+\left(1-0.75^4\right) =1.6796875. \tag{7}$$

也就是说，四条逻辑延续，平均只形成约 1.68 种不同的下一步前缀。$4/1.6796875\approx2.38$ 可以帮助理解物理前缀计算次数可能减少多少，但不能直接当作墙钟加速比。采样、分组、kernel 的批量形状以及后续路径继续分裂，都会改变实际耗时。

如果分布很分散，多数抽样结果都不同，$U$ 就接近 $m$，去重空间很小。如果概率集中在少数 token 上，碰撞更多，物理工作就更容易共享。论文在温度 0.8 的设置中观察到约 25% 到 50% 的候选共同 token，这给机制提供了经验依据，但共同 token 比例本身仍不足以预测完整服务的吞吐。

图 4. 根据公式（6）计算的分析曲线，分布假设写在图例中，不是模型实测。分布越分散、样本之间越少碰撞，能减少的重复计算越少。

5.4 算法 2：只在结果分叉时创建不同物理路径

算法 2：推进一组完全相同的逻辑前缀
输入：共享前缀 x、逻辑成员集合 C，其中 |C| = m
1. 确认所有成员对应同一个下一 token 条件分布。
2. 对物理前缀 x 执行一次生成模型前向计算。
3. 按共同采样设置得到下一 token 分布。
4. 独立抽取 m 次 token，每个逻辑成员得到自己的样本。
5. 按抽到的 token 对 C 分组，得到各个 C_v。
6. 为每个非空 C_v 保留一个前缀 x + v，记录其成员和数量。
7. 下一次解码迭代中，每个不同物理前缀只执行一次计算。
8. 保持逻辑成员的筛选、终止和取消语义一致。

论文还按 potential size 对采样工作分组，以处理不同物理序列需要不同抽样次数的问题。这说明 CD 不是加一个缓存查找就结束了，而是重新安排“物理模型输入”和“逻辑采样轨迹”的对应方式。

5.5 它与前缀 KV 共享解决的不是同一层重复

常规前缀 KV 共享可以让四条候选引用相同的历史缓存，但它们仍然可能作为四个当前解码输入，重复计算完全相同的下一 token logits。CD 进一步合并这部分前向计算，同时保留四次抽样。

反过来，如果四条候选已经各自多出了不同 token，那么它们当前的 logits 通常不能再合并；但共同历史的 KV 仍然可以共享。因此，两种方法不是替代关系，而是在不同层次减少重复。

这也引出一个很重要的实验对照：非推测搜索同样可以使用 CD。如果只把完整 SpecScale 与没有 CD 的非推测基线比较，就会把“管理推测工作带来的收益”和“所有多路径搜索都可能得到的去重收益”混在一起。后面的批判性分析会讨论为什么需要补上非推测加 CD 的对照。

6. 延迟验证：分数晚一点知道，整个系统反而可能更快

6.1 为什么不在每个步骤完成后立刻评分？

完成一个推理步骤，只说明它已经可以评分，不说明立刻评分一定最划算。如果稍等片刻，和其他请求刚完成的步骤一起送进 PRM，就可能让 GPU 用更高的效率完成相同类型的计算。

论文对 PRM 做了批量效率测量，在其 A100 配置中，约 2,048 个输入 token 附近开始进入吞吐饱和区间。LV 因而积累已经完成、尚未评分的任务，跨请求组成验证批次。这里的 token 是评分上下文的输入 token，不是刚刚生成的一个步骤的输出 token 数；评分上下文可能包含之前的推理以及模板内容。

它不是无条件等到积攒够 2,048 才执行。论文给了三种替代触发条件：待验证输入 token 的总量达到所选阈值；同一个父候选下的兄弟分支都已经完成当前步骤；或者某个验证任务被推迟的次数已经到达限制。三者是“或”的关系，任何一种发生，都可以推动验证。

论文实验中使用的最大推迟次数为六。这个数字的单位不是毫秒。六次可以被调度器考虑的机会，在不同生成批量长度和不同竞争情况下，对应的实际时间并不一样。它有助于避免任务一直被后来的工作挤掉，但不能直接解释成一个严格的墙钟时间上限。

兄弟分支完成条件也很重要。若一轮搜索需要比较的候选都已经完成，再继续等一个与这轮无关的大批次，就可能白白延长搜索屏障。这个触发条件体现了 LV 并不只考虑 GPU 批量效率，也考虑搜索依赖是否已经具备推进条件。

6.2 先看批量为什么划算，再看等待为什么有代价

用一个简化模型来解释：假设验证 $B$ 单位输入 token 的成本为 $a+bB$。其中 $a$ 是固定成本，$b$ 是每单位输入的边际成本，则处理效率为

$$q(B)=\frac{B}{a+bB}. \tag{8}$$

对 $B$ 求导可以得到

$$\frac{dq}{dB}=\frac{a}{(a+bB)^2}>0, \qquad\lim_{B\to\infty}q(B)=\frac{1}{b}. \tag{9}$$

批量变大时，固定成本被更多 token 分摊，所以效率提高；但增益逐渐变小，最后受边际成本限制。真实 PRM 的批量曲线当然比这个模型复杂，受矩阵形状、上下文长度和显存影响，因此论文采用实测曲线选择阈值，而不是直接套这个公式。

接着看另一侧。若待验证输入以平滑速率 $\lambda_v$ 到达，纯粹依靠阈值凑满 $B$ 大约需要 $B/\lambda_v$ 时间。假设输入均匀到达，平均积攒等待近似为

$$\mathbb{E}[D]\approx\frac{B}{2\lambda_v}. \tag{10}$$

这个式子忽略了兄弟完成触发、推迟次数限制、突发到达和离散请求大小，所以不能拿来预测论文的实际延迟。它只是把冲突写出来：更大批量让评分本身更有效率，却也让系统更晚知道谁应该被剪掉。

把它和前面的 $rd$ 估计连起来，就能看出孤立优化 PRM 吞吐为什么不够。假如为了凑更大批次，多等了若干时间，而这段时间里无效分支仍然继续展开，那么验证省下的计算可能被额外生成吃掉，甚至还要付出更高 KV 占用。完整系统的最佳阈值，未必是单看验证吞吐得到的最大批量。

图 5. 使用 $a=1$、$b=0.1$、输入到达速率为 1 的假设性分析图，单位都是任意单位。它不是原论文的 PRM 测量，也没有包含其他触发条件，只用于解释为什么批量增大并非没有代价。

6.3 算法 3：什么时候触发一次 PRM 批次？

算法 3：决定是否运行过程奖励模型验证
输入：已完成但未评分的队列 Q、输入 token 阈值 B_max、
      推迟次数限制 d_max、各候选之间的兄弟关系
1. 将新完成的步骤及评分上下文加入 Q。
2. 统计 Q 中待验证输入 token 的总量。
3. 检查是否存在一个兄弟组，其成员都已完成当前步骤。
4. 检查是否有待验证任务到达推迟次数限制。
5. 若 token 阈值、兄弟完成条件或次数限制任一触发，
   组成包含适用待验证任务的 PRM 批次并执行。
6. 将分数送回对应筛选轮次，执行算法 1，并移除已取消工作。
7. 否则保留任务，更新相应推迟记录。
8. 与生成和搜索推进交替重复。

这份伪代码强调的是策略语义，不代表某个具体调度接口。精确的队列计数方式、一个触发事件如何带上其他待评分任务，都会影响实际批次组成。因此不能只知道“阈值是 2,048”，就认为已经描述了整个 LV 行为。

论文的敏感性实验给出了很清楚的边界。在所述研究中，阈值从 256 变化到 4,096，最好的已报告点在 2,048；提高到 4,096 后，吞吐反而低于关闭 LV、只用 EP+CD 的基线。验证信息确实会“过期”：在系统等待它期间，无效工作可能已经做得太多了。

7. 三个优化不能当成互不影响的加速倍数

EP、CD、LV 很容易被读成三个可以分别打开的开关，然后把各自倍数相乘。但更准确的理解是，它们改变彼此面对的工作负载。EP 降低活着的推测分支数量；CD 降低表示这些逻辑分支所需的物理输入数；LV 改变系统何时知道哪些分支应该结束。

例如，一个候选已经完成本步骤，但评分还在队列里，它的后代可能继续生成。部分后代又可能和其他逻辑路径共享一个物理前缀。后来 PRM 给它低分时，系统应该取消属于这个父候选的逻辑后代，却不能误伤同一物理表示里仍然有效的其他成员。若共享状态释放过早会破坏正确性，若从不释放又失去了显存收益。

这种关系说明，搜索前沿、物理解码批次和 KV 状态所有权，需要描述同一组逻辑对象。它不是论文排序证明的一部分，却是理解该设计为何具有系统复杂性的必要背景。减少路径的逻辑工作，与回收路径占用的物理资源，并不总发生在完全同一个时刻。

批量效率也会相互影响。CD 减少了重复输入，但在原本很小的工作负载上，也可能让一次生成批次更小。去掉一个重复前向，在已经饱和的大模型设置中可能很有价值；在还有许多闲置计算能力的小模型设置中，其墙钟收益可能小得多。论文不同模型下的增量收益确实不同，不能仅凭减少的序列数量线性估计速度。

还有一个容易忽视的问题：某个分数在便宜之前，可能已经非常有价值。当 KV 接近上限、未决后代快速增长时，立刻验证以便剪掉一批分支，可能比再等一个更高效的 PRM 批次更划算。论文的固定触发条件是一种实用折中，但更一般的问题是状态相关的：为了让评分更便宜，当前系统愿意承受多少不确定工作？

这个视角也解释了为什么应观察未决分支的生命周期，而不只是观测某个模型调用的速度。一个验证调用本身没有变慢，但如果它排队的位置变了，后面产生的无效生成和显存压力就可能很不一样。调度改变的是整个依赖图上的工作，而不只是单个模块的耗时。

8. 实验条件：先知道比较对象，再读加速数字

主要平台是单张 80 GB NVIDIA A100，主机使用 Intel Xeon Gold 6326。论文列出的软件环境包括 PyTorch 2.9、CUDA 12.8，并在共同的服务框架中使用连续批处理、paged attention、前缀 KV 共享和 FlashInfer。共同框架很重要，否则某个系统的优势可能只是因为底层引擎更强。

生成与验证组合包括：Qwen2.5-3B、Qwen2.5-7B 搭配 Qwen2.5-Math-PRM-7B；Llama3.2-3B、Llama3.1-8B 搭配 Llama3.1-8B PRM。主要任务是随机抽取的 1,000 道 GSM8K、MATH-500，以及论文所述的 OlympiadBench。本文不进一步推断未明确描述的任务子集处理细节。

主要搜索设置使用四条或八条 beam、展开宽度四、最多 40 次展开、温度 0.8。主要实验的最大并发请求数为 32，另有实验单独改变 beam 数量和并发上限。这里的预算和温度都与候选重叠程度、验证频率及答案质量有关，因此不是可以略过的背景参数。

吞吐实验把请求一起提交，测试系统工作充足时的处理能力。服务延迟实验则使用 Poisson 到达，随着请求速率上升观察归一化端到端延迟。前者偏向饱和容量，后者才能显示到达与排队的影响。不能把前者的最高吞吐提升，直接说成任何负载下的请求延迟提升。

FastTTS 的比较还需要单独限定。作者把其中的 speculative candidate selection 与 lookahead verification 重做进共同框架，并解释所比较的公开版本只支持 batch size 1。论文没有纳入 preemptible scheduling 与 dynamic prefix-aware scheduling，理由是它们针对受限设备场景。

作者还报告，在 Qwen2.5-7B、MATH、若干 beam 设置下，做过 batch 1 吞吐相近的一致性检查，但相关详细数值未展开。这些说明表明，比较对象是论文采用的具体 FastTTS 配置，不能扩展成对任何 FastTTS 部署的普遍结论。

我认为这个处理可以理解：要在同一批处理环境下比较机制，确实需要适配。与此同时，读者必须保留这个限定。既不能忽略作者为统一环境所做的工作，也不能把一个适配后的比较，解释成所有配置之间都已经得出最终结论。

9. 吞吐结果：先修复推测带来的退步，再超过非推测基线

图 6 重绘了原论文中 Qwen2.5-7B、MATH 的明确柱状图数字。四条 beam 时，完整 SpecScale 是 786 output tokens/s，非推测基线是 558。八条 beam 时，两者分别为 466 和 327。搜索预算变大后，吞吐整体下降，但完整方案仍然保留了相当明显的相对优势。

图 6. 根据 v1 第 9 页 Figure 13(b) 已标出的数值重绘。模型组合为 Qwen2.5-7B-Instruct 与 Qwen2.5-Math-PRM-7B，硬件为单张 A100 80 GB。EP、CD、LV 按顺序累加。

对于八条 beam，三个最容易混淆的比值分别是

$$\frac{466}{214}\approx2.18,\qquad \frac{466}{249}\approx1.87,\qquad \frac{466}{327}\approx1.43. \tag{11}$$

214 对应朴素推测，249 对应所评测的 FastTTS，327 对应非推测搜索。所以“2.18 倍”有很大一部分是在修复朴素推测带来的退步：朴素推测仅有 $214/327\approx0.65$ 倍的非推测吞吐。完整系统先把这个负收益扭转过来，再超过原来的基线。

消融结果也说明，提前剪枝并不能独自解释完整收益。八条 beam 时，EP 是 338，加入 CD 后为 414，再加入 LV 后为 466。相对 EP，CD 的增量约为 $414/338\approx1.22$；相对 EP+CD，LV 的增量约为 $466/414\approx1.13$。这些比值只属于这组实验，不能当作三个模块固有的通用加速率。

Qwen2.5-3B、MATH、八条 beam 的数值又有所不同：非推测 317，EP 375，EP+CD 411，完整系统 479。这里 CD 相对 EP 的增量约为 1.10 倍，比 7B 设置更小。这与论文提出的解释相符：较小模型可能尚未充分利用计算资源，减少一些重复工作不一定按同样比例缩短运行时间。

Llama 结果尤其值得保留在阅读结论中。有些 MATH 和 Olympiad 设置里，单独加入 EP 后仍然低于非推测基线。论文把这一现象与更少的满分评分联系起来：不能频繁提前结束整轮筛选，验证负担就没有充分下降。继续加入 CD 与 LV 才得到完整收益。

因此，这项方法依赖的是几个分布共同形成的条件：候选什么时候完成、相同前缀有多少、PRM 多常给满分、验证批量是否划算。只说“推理有树结构，所以可以推测”还远远不够。

10. 准确率、等待和显存：分别得出了什么？

10.1 准确率接近，不代表答案逐个相同

原论文 Table 2 使用 Qwen2.5-3B。四条 beam 时，非推测基线在 GSM8K、MATH-500、OlympiadBench 上分别为 92.99%、74.03%、27.18%；完整系统为 93.49%、75.43%、27.94%。八条 beam 时，基线分别为 94.70%、76.24%、30.40%，完整系统为 94.09%、76.82%、31.48%。

图 7. 原论文 Table 2 的差值重绘，单位为百分点，生成模型为 Qwen2.5-3B。表中没有提供置信区间或多次随机运行的波动范围。

这些数据支持“在已测任务上维持相近答案质量”的描述，但不支持“每个答案都完全保留”。八条 beam 的 GSM8K 下降 0.61 个百分点，四条 beam 的 MATH 上升 1.40 个百分点。带有随机采样、且可能改变并列候选的搜索，结果本来就可能向两侧变化。

中间消融也不是准确率逐级上升。例如只开 EP，八条 beam 的 MATH 从 76.24% 到 79.21%，增加 2.97 个百分点；同设置的 Olympiad 却下降 1.01 个百分点。若没有配对随机种子和不确定性估计，很难把这些变化完全拆成候选选择变化、采样波动与搜索预算交互的贡献。

还有一个重要范围区别：准确率表使用 3B 生成模型，而前面恢复最高吞吐比值的例子使用 7B。两个结果各自都有效，但不能不加说明地合并成同一个“质量完全对齐的吞吐工作点”。如果在同一模型、同一预算、同一任务上同时给出质量与性能，会更有说服力。

10.2 少等待不是最终目标，少花总时间才是

原论文 Figure 15 分析 Qwen2.5-7B、MATH、四条 beam。非推测基线中，生成占总时间的 65.0%，验证占 27.8%。朴素推测的对应数值上升为 76.2% 和 43.8%，但它们的分母仍然是基线的总时间，不是朴素推测自己的总时间。

这个分母很容易读错。如果把每一组数都当作该方法内部的时间占比，就会疑惑为什么加起来能超过 100%。正确读法是：所有方法都用同一个基线时间单位，直接显示某一组件变贵还是变便宜。

EP+CD 的生成和验证时间分别为基线总时间的 46.7% 和 32.8%；加入 LV 后，变成 48.9% 和 20.5%。生成部分略微变贵，验证部分明显下降。这与延迟决策的解释完全一致：多等一会儿，可能让无效分支多生成一点；但验证批次更高效，省下的时间超过了代价。

图 8. 原论文 v1 第 11 页 Figure 15(a) 的生成与验证数字重绘。分母统一为非推测基线总时间。其他开销未画出，因此不能把两根柱子的和当作完整运行时间。

论文还讨论了验证 prompt 模板带来的 tokenization 等剩余成本。基线中约 7% 的其他开销里，大约 40% 与 tokenization 有关。主要 GPU 阶段优化之后，这些主机侧工作占剩余时间的比例可能更显眼。这再次说明，不能仅凭某个 GPU 阶段省了一半，就推断端到端也省一半。

10.3 为什么更大的验证阈值反而失败？

Qwen2.5-3B、MATH-500 的敏感性实验中，2,048 输入 token 的阈值相对关闭 LV 的 EP+CD，分别带来约 1.09 倍和 1.14 倍吞吐，对应四条与八条 beam。继续增加到 4,096，两组都掉到没有 LV 的基线以下。

这不是“批量越大，GPU 越慢”的简单结论。批量本身也许仍然更有效率，但在积攒它的过程中，生成、剪枝和搜索推进付出了更高代价。应该优化的是整个系统的总成本，而不是把验证模块的单位 token 吞吐推到最高。

图 9. 原论文 v1 第 11 页 Figure 16。虚线是不开 LV 的 EP+CD。2,048 是这组硬件、模型与工作负载中的经验工作点，不是理论证明的可移植常数。

10.4 服务曲线和扩大搜索预算的结果

在服务曲线中，完整 SpecScale 能在归一化延迟明显上升之前承受更高请求率。Qwen2.5-7B、四条 beam 的图中，约 75 ms/output token 附近，SpecScale 可以达到约每秒 1.6 个请求，而 FastTTS 在近似归一化延迟下约为每秒 0.8 个请求。这是图上的近似工作点比较，不是逐请求截止时间保证。

另一个实验把最大并发从 16 提升到 128。四条 beam 的情况下，非推测基线与 FastTTS 大约在 64 附近饱和，而 SpecScale 在报告范围内还能继续受益。减少推测浪费和内存占用，确实可以为更多并发留下空间；不过，这仍是特定单卡工作负载与准入方式下的结果。

在 Qwen2.5-7B、MATH 的 beam 扩展实验里，beam 达到 32 时，非推测归一化延迟约 330 ms，SpecScale 约 195 ms，KV 占用约减少 22%。$330/195\approx1.69$ 是速度比；相对于基线的延迟减少约为 41%。它们是同一组近似值的不同表达，不能把 1.69 倍误说成延迟减少 69%。

这些数据也不自动意味着能耗降低同样比例。实验给出了延迟和 KV 结果，没有给出对应能耗测量。减少工作可能有利于能耗，但这只能作为进一步研究的问题，不能把没有测量的指标补进结论。

11. 局限与失效边界

11.1 证据主要来自 PRM 引导的数学搜索

论文的主要结果围绕 GSM8K、MATH-500 和 OlympiadBench。若换成需要调用工具、修改文件或操作外部环境的 agent，提前执行的动作未必能够撤回，一个分支也可能改变其他分支看到的世界。它们同样具有树状推理，不代表可以直接使用相同推测策略。

数学文本候选可以丢弃，外部动作却可能留下副作用。因此，适用性不能只由“有没有搜索树”判断，还要看候选执行是否纯粹生成、分支之间是否相互隔离、取消是否真能停止代价。这些额外条件不是本论文实验已经覆盖的内容。

11.2 严格剪枝保持的是局部排序决定

阈值证明假设本轮完成步骤的评分固定不变。如果一种搜索会回头更新旧分数，加入依赖整个候选集合的多样性惩罚，或使用跨轮的路径约束，原来的次序统计量论证就未必适用。需要重新说明“至少有 $k$ 个更好候选”是否始终成立。

并列处理也是语义的一部分。低于阈值可以严格排除，等于阈值不能直接照搬。满分捷径则明确放松了候选身份保持。把这些差别留在方法描述里，比一句笼统的“不会影响结果”更准确。

11.3 去重依赖完整条件分布相同

文字相似不够，token 历史和相关条件必须相同。若约束或采样状态不同，合并计算可能改变概率语义。另一方面，如果模型总是产生很分散的延续，逻辑路径很快分叉，就没有多少重复前向可消除，分组开销反而更难摊薄。

因此，CD 的收益不仅取决于 beam 数量，还取决于条件分布集中程度、候选重合的持续长度、生成批量是否已饱和。一个高重叠任务上的加速，不能只按 beam 数比例外推到另一种任务。

11.4 PRM 同时决定质量和工作负载

PRM 的排序能力决定搜索是否朝正确方向走；它输出满分的频率决定满分捷径能否经常触发；上下文长度和模板决定评分输入规模；批量曲线又决定延迟合并是否划算。换一个 PRM，可能同时改变所有这些因素。

这意味着性能结论应绑定生成器与验证器的组合。只写“使用一个 7B PRM”，不足以描述其服务行为。同参数量模型的分数分布和上下文开销都可能不同。评分器改进也可能带来更好答案、却减少提前终止机会，两者并不矛盾。

11.5 计数限制不是严格尾延迟保证

推迟次数限制能提供调度上的进展条件，但不同机会之间可能间隔很长。低请求率、极不均匀的步骤长度、竞争中的长评分任务，都可能改变实际等待时间。现有服务曲线不能替代一个对每类请求都成立的公平性或墙钟延迟界。

11.6 单卡结果不能直接覆盖分布式系统

把生成和验证放到不同设备，可能减少两类阶段的相互打断，也可能新增传输、同步和远程排队成本。多节点聚合也许更容易凑出大验证批次，却可能使取消决定返回得更晚。这些方向都有合理性，但论文没有直接给出对应实验。

11.7 质量差异的不确定性还没有完整量化

准确率表给出了有价值的点估计，却没有置信区间，也没有覆盖全部吞吐模型组合。因此可支持的结论是“已测设置下答案质量相近”，不是“完整变换保证质量不变”。对于可能改变并列候选的优化，这个表述边界尤其重要。

12. 批判性分析：我还希望看到哪些决定性对照？

12.1 把严格剪枝和满分捷径拆开评估

我最希望补充的是三个策略的配对比较：不提前剪枝；只剪掉严格低于已验证阈值的候选；在此基础上加入满分提前结束。第一组对比隔离了原则上应保持固定轮次前 $k$ 结果的取消行为，第二组对比才暴露满分捷径额外带来的性能收益与选择变化。

为什么值得专门做？因为完成顺序可能悄悄成为一种偏好。较短、较快的候选更容易成为最先得到满分的那几个。如果推理长度与题目难度或解题方式相关，那么捷径可能偏向某些轨迹，即使它们在 PRM 评分上完全并列。

一个有解释力的结果，应该记录哪些候选被替换、它们的长度分布如何变化，以及最终准确率差异在多个随机种子下是否稳定。仅统计“有多少个 1.0”，还不能知道这种隐含偏好会不会影响探索。这里不是说捷径一定有害，而是它改变了什么，需要被单独测量。

12.2 补上“非推测搜索 + CD”

CD 是对相同逻辑前缀重复计算的一般优化，不专属于推测搜索。更完整的对照应包含非推测+CD、推测+CD、推测+EP+CD，以及完整系统，同时保持底层前缀缓存和逻辑采样语义一致。

这个对照可以区分两个问题：推测在控制浪费后是否仍值得做；多路径生成原本是不是就做了大量重复前向。如果一个工作负载的搜索屏障等待很少，非推测+CD 可能已经获得大部分收益，并提供更简单的操作点。如果完整 SpecScale 在这个更强基线之上仍然明显领先，就更能说明额外调度复杂性的价值。

现有消融很好地解释了 EP、CD、LV 怎样逐步改善一个推测系统，但还不足以完全回答“是否需要先采用推测执行”这个设计选择。把这两种问题分清，能避免把一般优化的收益全部归给某种特定执行方式。

12.3 用满足时限的正确答案数量衡量服务价值

部署视角下，我希望固定生成器、PRM、搜索预算和目标准确率，再同时报告原始请求端到端延迟，以及单位时间内完成的正确答案数量。一个可考虑的指标是

$$G_{\mathrm{correct}}(L) =\frac{\#\{\text{正确完成且延迟不超过 }L\text{ 的请求}\}} {\text{测量时长}}. \tag{12}$$

这是本文提出的评测建议，不是论文已经报告的指标。它的好处是，不把多生成的 output token 自动当成有用产出，并且把用户能接受的时间要求写进定义。与此同时，还应报告总准确率、完成率和延迟分位数，因为单一聚合数仍可能掩盖哪些请求被延后。

对于随机搜索，配对种子和多次运行也很重要。它们能帮助判断某种质量与吞吐提升是否稳定，而不是一次采样恰好走到更有利的路径。任务难度分层同样值得做：简单题可能有更多前缀重叠和满分评分，收益不一定代表困难题的体验。

这个建议并不是否定 output tokens/s。后者对分析计算效率很有用。问题在于，当系统本身可以改变搜索轨迹和生成长度时，还需要一个更靠近最终任务目标的量，把计算效率与实际交付价值连接起来。

12.4 验证阈值应该感知“继续不知道结果”的代价

4,096 阈值失败的结果，提示了一个值得探索的控制信号：除了当前待验证 token 数，还要看未决分支带来的工作和显存成本。一个候选有大量活跃后代、占用很多 KV 时，延迟否决它的代价，比没有后代的候选更大。

可能的自适应方式是，把等待时间、未决后代数量或预计工作量、显存压力组合成一个预算。预算越紧，越应该早点验证；资源宽松时，才容许更积极地聚合。兄弟完成条件仍然可以保留，以免已经能够推进的搜索轮次继续空等。

当然，复杂策略不是天然更好。若预测和维护这些信号本身很贵，或者负载波动使控制器反复抖动，就可能抵消收益。实验必须与简单固定阈值比较，证明额外控制成本值得。一个朴素但稳定的策略，往往比解释不清的动态决策更容易服务真实工作负载。

我也会把墙钟等待上限与推迟次数上限分开。前者对应服务承诺，后者对应调度器考虑任务的机会。分开定义以后，系统的进展条件和用户的延迟要求都更容易评测，也更不容易在文档里被混为一谈。

12.5 最值得迁移的思路，是信息与依赖工作的相对时间

一个 PRM 分数之所以有价值，不只是它判断了一段推理，更因为它可以阻止未来的无效计算。让这个分数晚一点到达，可能让评分本身便宜，却也让依赖它的工作在不确定状态下运行更久。共享前缀计算则降低了同时保留多种可能性的物理成本。

这个解释比某个最高加速倍数更能迁移到其他系统。要理解一种策略为什么随着负载变化而成功或失败，应观察：落选分支活了多久、逻辑路径对应多少物理序列、PRM 批次大小如何分布、未决决定占用了多少显存。这些量一起描述了系统为不确定性付出的代价。

若将来把方法扩展到不同模型、不同设备或更复杂搜索，我会优先检查这些机制量是否仍处在有利区间。它们比“是否支持推测执行”更接近性能的原因，也能提示哪些情况下应该少推测、早点验证，或者直接使用更简单的非推测策略。

13. 结论

SpecScale 的贡献，是把推测推理搜索放回共享服务资源的条件下考虑：落选分支不能无限期活着，相同前缀不应该反复做相同前向，PRM 评分也不应该被切成大量低效小调用。三个问题一起处理，才让减少搜索屏障真正转化为服务收益。

阅读时需要保留三条边界。严格低于阈值的剪枝有局部排序证明，满分提前结束可能改变并列候选；计算去重共享模型计算，但必须保留独立抽样与完整条件语义；延迟验证用更晚的信息换更好的批量效率，且有效范围有限。实验支持已测设置下相近的答案质量，而不是完整系统对候选和答案的精确保持。

我的最终理解是：不要只优化“下一条分支多快能开工”，还要优化“一个尚未确定的搜索决定，会让系统多付出多少工作”。SpecScale 在单张繁忙 GPU 上清楚展示了这个差别，也留下了更强基线、尾延迟以及自适应验证值得继续研究的问题。

参考资料

1. Jinwoo Jeong, Woohyung Choi, Myeongjae Jeon, Jeongseob Ahn. Taming Speculative Search for Test-Time Scaling in LLM Serving. arXiv:2609.39334v1，2026-09-30。本文方法描述、实验配置与实测数值的一手依据。
2. 固定版本 PDF。本文使用的原图位置：第 6 页 Figures 8、10，第 9 页 Figure 13，第 11 页 Table 2 与 Figures 15、16。自行构造的分析示例和建议评测，已在对应段落中区分。