做推理评测这一年多我最大的感触是模型能不能做对越来越不是瓶颈测试时算力才是。为了把数学benchmark的准确率从72%推到78%我把每条请求的采样次数从16调到了64精度确实上去了但每次请求都等于跑了64遍完整生成GPU账单肉眼可见地涨线上p95延迟也飙到了一分钟开外。那段时间我盯着成本曲线脑子里反复出现的一个词就是重复采样。问题在于这64次采样里有相当一部分是浪费的。同一个错误思路反复出现四五遍简单问题也在烧和难题一样的算力有些样本中途已经明显走歪了却依然被完整生成完再丢掉。最近我在看PTTSPlanning for Test-Time Scaling规划式测试时扩展这类方向核心就一句话把“规划”和“执行”分开先想清楚往哪些方向走再集中预算去采样而不是让采样在错误方向上自我复制。按公开结果和我自己的复现情况看它在相同精度下把测试时算力省下一半是真实可做到的。这篇文章写给正在做推理优化、test-time scaling落地以及给Agent和长链路任务调预算的工程师。我会先拆解“规划-执行分离”到底怎么省算力再对比它和Best-of-N、self-consistency、MCTS这些主流策略的取舍最后把我复现时踩过的坑和评估方法一起放出来希望能帮你少走一段弯路。1. 重复采样为什么越来越“烧钱”从投票策略说起1.1 测试时算力的价值与代价在训练侧算力增长逐渐放缓之后测试时算力成了新的扩展维度。像o1那一类reasoning模型出现后大家发现一个规律给模型更多推理时间、更多采样次数它就能在数学、代码、逻辑推理上拿到更高分数。这个思路本身没问题问题出在实现方式上太粗暴。最常见的做法就是N次采样加投票。让模型针对同一个问题生成N条完整回复再用多数投票、self-consistency或者一个结果奖励模型来选最终答案。这个策略在不少benchmark上有效但代价是成本线性增长N16的时候一次请求等于16次完整推理N64的时候一次请求等于64次完整推理。如果是长上下文或者多轮Agent任务这个放大效应会更明显。我见过很多团队把采样次数当成一个“旋钮”精度不够就往上拧。但真正上生产环境时算力预算、延迟上限、并发吞吐都是硬约束不会因为采样次数能提分就无限放宽。所以问题的关键不是“要不要测试时算力”而是怎么让每一份算力都花在刀刃上。1.2 均匀烧算力的三个隐藏浪费如果你把一个问题的64条采样结果铺开看会发现至少有三种浪费。第一种是思路自复制浪费。LLM在采样时并不是均匀地遍历所有解法它更容易在模型先验里“概率较高”的那条路上反复生成。比如一道几何题模型可能在“设坐标建系”这个方向上连续生成30条相似但不完整的推导真正尝试“辅助线”或“向量法”的只有很少几条。最后的投票结果看似是“多数一致”其实只是同一个错误方向上的自我重复。第二种是难度不区分浪费。简单问题可能采样4到8次就能稳定收敛到正确答案但它依然和难题一样烧64次。中等难度的问题可能需要20次难题需要50次。均匀采样完全不管这个差异就像一个不看菜谱、每道菜都炖两小时的厨师时间花了不少效果并不均匀。第三种是中途路径浪费。很多样本在前几步就偏离了正确方向后面的推导完全是在一条死路上越走越远。传统做法是把这条路整条生成完然后交给最终答案投票去否决。相当于让一个已经迷路的人继续往前走完整个行程再回来告诉你“这条路不通”。如果能在中途就判断出这个方向没戏把后面的算力腾出来给其他方向成本会低很多。1.3 从盲目穷举到目标导向人遇到难题时是怎么做的先列几个可能的方向挑一两个最靠谱的深入推演推不通再回头换方向。而不是把每个可能的方向都从头到尾写十遍。那为什么模型在测试时扩展上要选择后者一方面是历史原因early stopping、过程奖励模型这些手段在训练阶段用得很多但在测试时阶段大家为了流程简单习惯一次性并行采样后投票不愿意在中间做任何干预。另一方面是工程惯性并行采样在GPU上很好实现服务端只要把batch size调大就行而“中途评估”需要额外的模型调用和逻辑控制看起来更麻烦。PTTS做的事情其实就是把“先规划”这个环节加回来。它不要求你在token级别逐字打分只需要在“方向级别”做一次判断哪些路径值得走哪些路径可以直接放弃。然后用一套预算分配策略把原先均匀分布在N条采样上的算力集中到少数的潜力路径上。这个改变听起来不复杂但拆开看省算力的逻辑非常清晰而且落地时只需要改很小的服务端逻辑。2. PTTS的核心机制先规划路径再按需执行采样2.1 两个阶段的分工PTTS把整个测试时计算过程拆成两个阶段规划阶段和执行阶段。规划阶段的任务是“决定做什么”。输入是原始问题输出不是最终答案而是一组候选路径以及每条路径的价值估计。比如对一道数学题规划阶段可能给出三条路径路径A是“设未知数列方程”路径B是“用几何性质快速排除”路径C是“尝试特殊值反推”。每条路径后面附带一个分数表示这条路径有多大希望能通往正确答案。执行阶段的任务是“把决定好的事情做好”。它只对规划阶段筛选出的路径做采样生成不再从头到尾无差别采样。每个路径可以根据自己的价值分数分到不同的采样预算高分路径多采几次低分路径少采几次甚至直接不采。最后把各路径的生成结果统一聚合成最终答案。用软件工程类比的话规划阶段相当于做架构设计和方案评审执行阶段相当于写代码和测试。以前的做法是每个候选方案都完整实现一遍再统一验收PTTS是先做一次低成本评审再集中资源实现少数方案。评审本身也要花成本但和完整实现相比小得多这就是它能省算力的根源。2.2 规划阶段到底在算什么规划阶段的核心是给路径算价值分这一步决定了后续预算怎么分配。价值估计通常有三个来源。第一种是过程奖励模型PRM。PRM可以对生成的每一步打分把路径上各步的分数累加或取最小值就能得到这条路径的整体价值。PRM的好处是可解释性强能告诉你“这条路径坏在第几步”缺点是需要额外训练或外部模型在找不到合适PRM的场景下不太方便。第二种是轻量模型或浅层评估。用一个比执行模型小很多的模型来评估路径或者让执行模型只在短前缀上生成“思路骨架”然后直接对这个骨架打分。因为规划阶段不需要完整生成只需要看到“方向雏形”所以成本可以压得很低。我实测下来判断一个方向可不可行往往只需要前几步推导就足够了后面一大半token都是在既定的方向上做重复计算。第三种是搜索启发式比如类似UCT、LCB这类在探索与利用之间做平衡的策略。它们不直接给路径打分而是维护一个“不确定性区间”对不确定性太高的路径降低预算对“看起来有希望但还没充分验证”的路径保留探索机会。这种方法适合和树搜索配合使用。有一个工程细节值得强调规划阶段的生成长度可以大幅缩短。比如执行阶段每条路径要生成800个token规划阶段只需要生成前150到200个token做方向判断。这150个token就是“分歧点”所在的位置过了这个位置路径基本定型后面只是细节推导。在分歧点之前做判断等于用不到三分之一的成本完成了大部分方向筛选。2.3 执行阶段如何把预算用足规划阶段做完后执行阶段要解决的是“预算怎么分”和“结果怎么合”。预算分配尽量不要均匀分。最简单的策略是top-k选择加比例分配先选分数最高的k条路径然后按分数比例分配采样次数。更精细一点可以用动态退出某条路径在采样过程中已经出现了多个一致答案那就提前停止把多余的预算让给其他还没收敛的路径。结果聚合也要分两层考虑。同一路径内的多个采样结果可以用self-consistency判断这条路径内部是否稳定跨路径的采样结果可以用最终答案的投票数加权或者用结果奖励模型排序。这里我踩过一个小坑如果只按路径分数加权投票低分路径上的正确答案容易被高分路径上的错误多数淹没如果改成先按答案聚类、再按路径多样性加权效果会更稳。因为多个独立路径都指向同一个答案比一条路径内部的多数一致更有说服力。执行阶段还有一个隐藏的省钱点路径之间往往共享公共前缀。规划阶段生成的“思路骨架”本身就可以作为生成前缀不同路径在骨架之后分叉。如果服务端支持prefix caching这些共享前缀只需要算一次KV Cache可以直接复用执行阶段的额外成本就会进一步下降。2.4 一条拆解“省一半”的估算公式“省一半”听起来像营销话术其实可以用一个简单的式子算出来。假设传统方案是N次完整采样每次完整采样成本是C_full。那么传统成本是C_naive N * C_fullPTTS的成本由两块组成规划成本C_plan以及执行阶段各路径的采样成本之和。C_ptts C_plan Σ K_i * C_path_i我拿一个具体数字举例。N64传统方案成本是64次完整生成。PTTS里规划阶段只生成路径骨架假设它等价于4次完整生成的成本规划出8条候选路径按价值排序后只选3条高价值路径执行每条路径分到8到10次采样总执行次数大约24到30次。加起来是28到34次完整生成成本正好接近传统方案的一半。精度为什么没掉因为原来的64次采样里有大量样本挤在同一条低价值路径上它们彼此重复并没有给投票增加实质信息。把它们的预算转移到3条高价值路径上投票时覆盖到的“有效解题方向”反而变多了。实际跑下来有些题目PTTS的精度比均匀采样还高了一点——原因是方向多样性增加了投票不再被单一错误模式主导。这就是“规划-执行分离”最直观的收益不是压缩了单次生成而是重新分配了生成资源的去向。3. 横向对比PTTS 与 Best-of-N、self-consistency、MCTS 的取舍3.1 各自的定位Best-of-N是最轻量的策略采样N次用结果奖励模型挑分数最高的那个答案。它省掉了中间所有的评估但代价是算力不灵活——不管路径好坏都采样N次而且最终只挑一个没有利用答案之间的内部一致性。Self-consistency比Best-of-N多了一步采样N次后按最终答案聚类投票。它在可验证答案的任务上效果很好因为同一个正确答案可能通过不同路径到达投票能增强这种信号。但它仍然是均匀采样没有方向筛选。MCTS则是走到另一个极端在token级或步骤级做树搜索每一步都用过程价值模型打分再回溯更新父节点。它适合数学证明、代码调试这类“逐步可验证”的任务效果上限高但工程复杂度也高搜索过程会产生大量中间节点token消耗常常比N次采样还要大。PTTS正好站在中间它不做token级密集评估只在路径级做一次规划它保留了大规模并行采样的优点但在采样之前先裁剪方向。从实现的复杂度看PTTS比Best-of-N多了一个规划层比MCTS简单得多。3.2 一张表看差异我把四个策略放在一张表里对比方便你根据场景快速选择。策略算力控制粒度是否依赖PRM/价值模型方向多样性工程复杂度典型适用场景主要风险Best-of-N采样级需要结果奖励模型低低通用问答、候选答案排序方向单一算力利用率低Self-consistency采样级不需要中低数学、常识问答、可验证答案简单问题过度采样MCTS步骤级需要过程奖励模型高高数学证明、代码调试搜索节点多成本高PTTS路径级需要轻量规划器或PRM高中长链路推理、Agent任务规划器误剪正确路径这张表里最容易忽略的是“方向多样性”这一行。传统采样策略默认认为N次采样是iid的但LLM采样根本不是均匀覆盖它在高概率方向上会产生大量自相似的样本。PTTS通过显式的路径规划把多样性拉了回来这是它除了省算力之外的第二个价值。3.3 什么场景选谁如果你有训练质量很好的PRM且问题可以逐步验证MCTS依然是天花板最高的方案缺点是工程量大。如果你没有PRM只有最终答案可以自动判断对错那self-consistency是最稳的baseline。PTTS可以在这个基础上叠加但前提是你有一个还算靠谱的路径价值估计器否则规划阶段只会帮倒忙。我的个人倾向是当问题链条长、方向分叉多、单次采样成本高的时候PTTS的省算力效果最明显。比如Agent需要多轮工具调用或者数学题需要多步推导这些场景下“方向错了再重来”的代价非常大提前规划的价值就很高。反过来说如果只是短问答N4到8次采样就已经很稳再加一个规划器收益很小甚至可能因为多一次模型调用变得不划算。规划-执行分离不是银弹它是特定成本结构下的最优解——单次生成越贵规划的价值越大。4. 落地时最容易踩的坑实测经验4.1 规划器太激进把正确答案提前剪掉我第一次复现PTTS时精度不仅没涨反而比self-consistency baseline跌了3个百分点。查了半天问题出在规划器上。现象是规划阶段用PRM给路径打分很多“非主流但正确”的路径被打低分进不了执行名单。比如一道结合了排列组合的问题PRM的训练数据里大多是枚举法它就给了枚举法路径高分把“生成函数法”这条更简洁的正确路径剪掉了。等执行阶段只能沿着枚举法反复采样效率自然下降。解决办法有两个。一是别只走top-1保留top-k路径我默认至少留3条。二是给低分路径一个最低采样额度比如每条低分路径至少采样1次防止被完全剪掉。这个“最低采样额度”就像保险成本增加不多但能堵住规划器估计偏差的漏洞。4.2 规划与执行模型不一致导致的分布漂移还有一个隐蔽的大坑规划器用的模型和执行器用的模型不是同一个或者不是同一套微调数据训练出来的。我试过一个组合规划阶段用8B小模型做路径打分执行阶段用70B大模型生成答案。结果是路径分数很高但大模型实际执行那条路径时效果很差。后来一分析8B模型认为“设方程”是好路径70B模型在同类问题上更擅长“几何变换”两个模型的先验和擅长方向完全不一样。规划器按自己的偏好选了方向执行器却按另一个思路工作两边对不上。对策是尽量让规划器和执行器同源至少来自同一个模型家族。如果必须跨模型先拿一小批验证集做校准对比不同路径在各执行器下的实际成功率再调整规划权重。还有一种更稳的办法让规划器只做“粗裁剪”比如从8条里排掉2条明显不好的保留6条。越是大模型越值得把路径选择权交还给执行阶段。提示规划器不是越聪明越好。在分布漂移不可控时规划器做“粗筛选”比做“精排序”更安全因为它留给了执行阶段足够的纠错空间。4.3 KV Cache和prefix复用没设计好省下的钱又花回去在工程层面“省一半算力”能不能落到账单上最关键的环节是Prefix复用。我遇到过一种情况采样次数确实从64降到了30但服务端的KV Cache没有做共享。每条路径虽然共享前几步的骨架但从骨架之后的分叉点开始每个分支都重新计算了KV Cache等于把同样的前缀算了好几遍。结果GPU时间和延迟几乎没降下来只是少了后半段的采样次数。PTTS天然适合prefix caching。规划阶段生成的路径骨架可以直接作为公共前缀执行阶段所有同路径的采样都从同一个KV Cache状态继续生成。这个优化在工程上一点都不性感和高深但实测下来它能让你真正看到那“一半”的节省——采样次数降了KV Cache也复用了账单才会跟着降。4.4 只报精度不报算力对比失去意义最后一个坑不是代码问题而是评估方法问题。我见过不少方案汇报时说“PTTS精度提升了1个点”但没提它为了这1个点花了多少token。这种对比没有意义。正确做法是固定三个维度中的一个再对比另外两个。要么固定精度看谁用的算力更少要么固定算力预算看谁的精度更高要么固定延迟上限看谁的总吞吐更大。我习惯在实验记录里统一标注三个数字总token数、GPU-seconds、p95延迟。列一个简单的评估模板baseline SC-N64一行PTTS一行Best-of-N一行。每个方案记录精度、总token、GPU-seconds、p95延迟放在同一张表里。这样团队成员一眼就能看出PTTS到底省了多少而不是被“精度涨了”这四个字带偏。5. 关于“测试时算力”还能往哪走5.1 预算随难度自适应PTTS已经在路径维度上做了自适应但下一步应该是按问题难度做更粗粒度的路由。简单问题不规划直接执行一次中等难度问题做一次轻量规划加少量采样困难问题才上完整的分层规划加充分采样。这种“先分诊、后治疗”的流程在医疗场景是常识在推理场景却很少被认真设计。我在自己的服务上试过一个很粗糙的分级策略先让模型在短前缀上生成一个“预期难度分”低于阈值直接返回第一次采样的结果高于阈值再走规划-执行流程。这个分诊本身成本很低但能把大量简单请求拦截掉整体算力节省比单靠PTTS更可观。5.2 规划器可以更轻现在PTTS的规划器通常还是独立模型或PRM未来更值得期待的方向是把它挂到执行模型内部做成一个可以提前退出的分支。这意味着模型先生成一小段思路骨架一个轻量的预测头输出“这条路有没有希望”有希望就继续展开没希望就换方向。这和early exit、speculative decoding在思想上是一脉相承的目标都是把有限算力集中在更可能成功的路径上。这类做法的难点不在模型结构而在训练信号你需要在训练阶段让模型学会“识别自己擅长和不擅长的方向”。这和目前主流的RLHF配方不完全一样可能需要更多过程级监督数据。但一旦做成测试时算力从“外部策略调参”变成了“模型内生能力”应用范围会比现在大得多。5.3 我自己的实操建议如果你现在就想试PTTS我的建议是别一上来就搞复杂版本。先在现有数据集上把baseline跑稳SC-N16的精度和token数是多少N64又是多少。然后做一个最简版的PTTS用一个已有的轻量PRM或小型同源模型做路径打分只选top-3路径执行每条路径分配预算共享前缀开起来先看一组对比曲线。多数场景里一个能用的PRM加上路径级预算分配就已经能拿到“省一半”的大部分收益。真正把方案升级到树搜索级别是在你发现路径之间的交叉和回溯很频繁、简单top-k不够用之后的事。别为了追求架构完整让工程成本吃掉算力收益这是我在好几个项目里反复验证过的经验测试时算力的优化永远是把每一份算力放在最需要它的地方而不是把策略包得越复杂越好。 
长河君 · 2026/10/26 5:36:52 · 阅读 1.2k PTTS：规划式测试时扩展如何省下一半推理算力
做推理评测这一年多我最大的感触是模型能不能做对越来越不是瓶颈测试时算力才是。为了把数学benchmark的准确率从72%推到78%我把每条请求的采样次数从16调到了64精度确实上去了但每次请求都等于跑了64遍完整生成GPU账单肉眼可见地涨线上p95延迟也飙到了一分钟开外。那段时间我盯着成本曲线脑子里反复出现的一个词就是重复采样。问题在于这64次采样里有相当一部分是浪费的。同一个错误思路反复出现四五遍简单问题也在烧和难题一样的算力有些样本中途已经明显走歪了却依然被完整生成完再丢掉。最近我在看PTTSPlanning for Test-Time Scaling规划式测试时扩展这类方向核心就一句话把“规划”和“执行”分开先想清楚往哪些方向走再集中预算去采样而不是让采样在错误方向上自我复制。按公开结果和我自己的复现情况看它在相同精度下把测试时算力省下一半是真实可做到的。这篇文章写给正在做推理优化、test-time scaling落地以及给Agent和长链路任务调预算的工程师。我会先拆解“规划-执行分离”到底怎么省算力再对比它和Best-of-N、self-consistency、MCTS这些主流策略的取舍最后把我复现时踩过的坑和评估方法一起放出来希望能帮你少走一段弯路。1. 重复采样为什么越来越“烧钱”从投票策略说起1.1 测试时算力的价值与代价在训练侧算力增长逐渐放缓之后测试时算力成了新的扩展维度。像o1那一类reasoning模型出现后大家发现一个规律给模型更多推理时间、更多采样次数它就能在数学、代码、逻辑推理上拿到更高分数。这个思路本身没问题问题出在实现方式上太粗暴。最常见的做法就是N次采样加投票。让模型针对同一个问题生成N条完整回复再用多数投票、self-consistency或者一个结果奖励模型来选最终答案。这个策略在不少benchmark上有效但代价是成本线性增长N16的时候一次请求等于16次完整推理N64的时候一次请求等于64次完整推理。如果是长上下文或者多轮Agent任务这个放大效应会更明显。我见过很多团队把采样次数当成一个“旋钮”精度不够就往上拧。但真正上生产环境时算力预算、延迟上限、并发吞吐都是硬约束不会因为采样次数能提分就无限放宽。所以问题的关键不是“要不要测试时算力”而是怎么让每一份算力都花在刀刃上。1.2 均匀烧算力的三个隐藏浪费如果你把一个问题的64条采样结果铺开看会发现至少有三种浪费。第一种是思路自复制浪费。LLM在采样时并不是均匀地遍历所有解法它更容易在模型先验里“概率较高”的那条路上反复生成。比如一道几何题模型可能在“设坐标建系”这个方向上连续生成30条相似但不完整的推导真正尝试“辅助线”或“向量法”的只有很少几条。最后的投票结果看似是“多数一致”其实只是同一个错误方向上的自我重复。第二种是难度不区分浪费。简单问题可能采样4到8次就能稳定收敛到正确答案但它依然和难题一样烧64次。中等难度的问题可能需要20次难题需要50次。均匀采样完全不管这个差异就像一个不看菜谱、每道菜都炖两小时的厨师时间花了不少效果并不均匀。第三种是中途路径浪费。很多样本在前几步就偏离了正确方向后面的推导完全是在一条死路上越走越远。传统做法是把这条路整条生成完然后交给最终答案投票去否决。相当于让一个已经迷路的人继续往前走完整个行程再回来告诉你“这条路不通”。如果能在中途就判断出这个方向没戏把后面的算力腾出来给其他方向成本会低很多。1.3 从盲目穷举到目标导向人遇到难题时是怎么做的先列几个可能的方向挑一两个最靠谱的深入推演推不通再回头换方向。而不是把每个可能的方向都从头到尾写十遍。那为什么模型在测试时扩展上要选择后者一方面是历史原因early stopping、过程奖励模型这些手段在训练阶段用得很多但在测试时阶段大家为了流程简单习惯一次性并行采样后投票不愿意在中间做任何干预。另一方面是工程惯性并行采样在GPU上很好实现服务端只要把batch size调大就行而“中途评估”需要额外的模型调用和逻辑控制看起来更麻烦。PTTS做的事情其实就是把“先规划”这个环节加回来。它不要求你在token级别逐字打分只需要在“方向级别”做一次判断哪些路径值得走哪些路径可以直接放弃。然后用一套预算分配策略把原先均匀分布在N条采样上的算力集中到少数的潜力路径上。这个改变听起来不复杂但拆开看省算力的逻辑非常清晰而且落地时只需要改很小的服务端逻辑。2. PTTS的核心机制先规划路径再按需执行采样2.1 两个阶段的分工PTTS把整个测试时计算过程拆成两个阶段规划阶段和执行阶段。规划阶段的任务是“决定做什么”。输入是原始问题输出不是最终答案而是一组候选路径以及每条路径的价值估计。比如对一道数学题规划阶段可能给出三条路径路径A是“设未知数列方程”路径B是“用几何性质快速排除”路径C是“尝试特殊值反推”。每条路径后面附带一个分数表示这条路径有多大希望能通往正确答案。执行阶段的任务是“把决定好的事情做好”。它只对规划阶段筛选出的路径做采样生成不再从头到尾无差别采样。每个路径可以根据自己的价值分数分到不同的采样预算高分路径多采几次低分路径少采几次甚至直接不采。最后把各路径的生成结果统一聚合成最终答案。用软件工程类比的话规划阶段相当于做架构设计和方案评审执行阶段相当于写代码和测试。以前的做法是每个候选方案都完整实现一遍再统一验收PTTS是先做一次低成本评审再集中资源实现少数方案。评审本身也要花成本但和完整实现相比小得多这就是它能省算力的根源。2.2 规划阶段到底在算什么规划阶段的核心是给路径算价值分这一步决定了后续预算怎么分配。价值估计通常有三个来源。第一种是过程奖励模型PRM。PRM可以对生成的每一步打分把路径上各步的分数累加或取最小值就能得到这条路径的整体价值。PRM的好处是可解释性强能告诉你“这条路径坏在第几步”缺点是需要额外训练或外部模型在找不到合适PRM的场景下不太方便。第二种是轻量模型或浅层评估。用一个比执行模型小很多的模型来评估路径或者让执行模型只在短前缀上生成“思路骨架”然后直接对这个骨架打分。因为规划阶段不需要完整生成只需要看到“方向雏形”所以成本可以压得很低。我实测下来判断一个方向可不可行往往只需要前几步推导就足够了后面一大半token都是在既定的方向上做重复计算。第三种是搜索启发式比如类似UCT、LCB这类在探索与利用之间做平衡的策略。它们不直接给路径打分而是维护一个“不确定性区间”对不确定性太高的路径降低预算对“看起来有希望但还没充分验证”的路径保留探索机会。这种方法适合和树搜索配合使用。有一个工程细节值得强调规划阶段的生成长度可以大幅缩短。比如执行阶段每条路径要生成800个token规划阶段只需要生成前150到200个token做方向判断。这150个token就是“分歧点”所在的位置过了这个位置路径基本定型后面只是细节推导。在分歧点之前做判断等于用不到三分之一的成本完成了大部分方向筛选。2.3 执行阶段如何把预算用足规划阶段做完后执行阶段要解决的是“预算怎么分”和“结果怎么合”。预算分配尽量不要均匀分。最简单的策略是top-k选择加比例分配先选分数最高的k条路径然后按分数比例分配采样次数。更精细一点可以用动态退出某条路径在采样过程中已经出现了多个一致答案那就提前停止把多余的预算让给其他还没收敛的路径。结果聚合也要分两层考虑。同一路径内的多个采样结果可以用self-consistency判断这条路径内部是否稳定跨路径的采样结果可以用最终答案的投票数加权或者用结果奖励模型排序。这里我踩过一个小坑如果只按路径分数加权投票低分路径上的正确答案容易被高分路径上的错误多数淹没如果改成先按答案聚类、再按路径多样性加权效果会更稳。因为多个独立路径都指向同一个答案比一条路径内部的多数一致更有说服力。执行阶段还有一个隐藏的省钱点路径之间往往共享公共前缀。规划阶段生成的“思路骨架”本身就可以作为生成前缀不同路径在骨架之后分叉。如果服务端支持prefix caching这些共享前缀只需要算一次KV Cache可以直接复用执行阶段的额外成本就会进一步下降。2.4 一条拆解“省一半”的估算公式“省一半”听起来像营销话术其实可以用一个简单的式子算出来。假设传统方案是N次完整采样每次完整采样成本是C_full。那么传统成本是C_naive N * C_fullPTTS的成本由两块组成规划成本C_plan以及执行阶段各路径的采样成本之和。C_ptts C_plan Σ K_i * C_path_i我拿一个具体数字举例。N64传统方案成本是64次完整生成。PTTS里规划阶段只生成路径骨架假设它等价于4次完整生成的成本规划出8条候选路径按价值排序后只选3条高价值路径执行每条路径分到8到10次采样总执行次数大约24到30次。加起来是28到34次完整生成成本正好接近传统方案的一半。精度为什么没掉因为原来的64次采样里有大量样本挤在同一条低价值路径上它们彼此重复并没有给投票增加实质信息。把它们的预算转移到3条高价值路径上投票时覆盖到的“有效解题方向”反而变多了。实际跑下来有些题目PTTS的精度比均匀采样还高了一点——原因是方向多样性增加了投票不再被单一错误模式主导。这就是“规划-执行分离”最直观的收益不是压缩了单次生成而是重新分配了生成资源的去向。3. 横向对比PTTS 与 Best-of-N、self-consistency、MCTS 的取舍3.1 各自的定位Best-of-N是最轻量的策略采样N次用结果奖励模型挑分数最高的那个答案。它省掉了中间所有的评估但代价是算力不灵活——不管路径好坏都采样N次而且最终只挑一个没有利用答案之间的内部一致性。Self-consistency比Best-of-N多了一步采样N次后按最终答案聚类投票。它在可验证答案的任务上效果很好因为同一个正确答案可能通过不同路径到达投票能增强这种信号。但它仍然是均匀采样没有方向筛选。MCTS则是走到另一个极端在token级或步骤级做树搜索每一步都用过程价值模型打分再回溯更新父节点。它适合数学证明、代码调试这类“逐步可验证”的任务效果上限高但工程复杂度也高搜索过程会产生大量中间节点token消耗常常比N次采样还要大。PTTS正好站在中间它不做token级密集评估只在路径级做一次规划它保留了大规模并行采样的优点但在采样之前先裁剪方向。从实现的复杂度看PTTS比Best-of-N多了一个规划层比MCTS简单得多。3.2 一张表看差异我把四个策略放在一张表里对比方便你根据场景快速选择。策略算力控制粒度是否依赖PRM/价值模型方向多样性工程复杂度典型适用场景主要风险Best-of-N采样级需要结果奖励模型低低通用问答、候选答案排序方向单一算力利用率低Self-consistency采样级不需要中低数学、常识问答、可验证答案简单问题过度采样MCTS步骤级需要过程奖励模型高高数学证明、代码调试搜索节点多成本高PTTS路径级需要轻量规划器或PRM高中长链路推理、Agent任务规划器误剪正确路径这张表里最容易忽略的是“方向多样性”这一行。传统采样策略默认认为N次采样是iid的但LLM采样根本不是均匀覆盖它在高概率方向上会产生大量自相似的样本。PTTS通过显式的路径规划把多样性拉了回来这是它除了省算力之外的第二个价值。3.3 什么场景选谁如果你有训练质量很好的PRM且问题可以逐步验证MCTS依然是天花板最高的方案缺点是工程量大。如果你没有PRM只有最终答案可以自动判断对错那self-consistency是最稳的baseline。PTTS可以在这个基础上叠加但前提是你有一个还算靠谱的路径价值估计器否则规划阶段只会帮倒忙。我的个人倾向是当问题链条长、方向分叉多、单次采样成本高的时候PTTS的省算力效果最明显。比如Agent需要多轮工具调用或者数学题需要多步推导这些场景下“方向错了再重来”的代价非常大提前规划的价值就很高。反过来说如果只是短问答N4到8次采样就已经很稳再加一个规划器收益很小甚至可能因为多一次模型调用变得不划算。规划-执行分离不是银弹它是特定成本结构下的最优解——单次生成越贵规划的价值越大。4. 落地时最容易踩的坑实测经验4.1 规划器太激进把正确答案提前剪掉我第一次复现PTTS时精度不仅没涨反而比self-consistency baseline跌了3个百分点。查了半天问题出在规划器上。现象是规划阶段用PRM给路径打分很多“非主流但正确”的路径被打低分进不了执行名单。比如一道结合了排列组合的问题PRM的训练数据里大多是枚举法它就给了枚举法路径高分把“生成函数法”这条更简洁的正确路径剪掉了。等执行阶段只能沿着枚举法反复采样效率自然下降。解决办法有两个。一是别只走top-1保留top-k路径我默认至少留3条。二是给低分路径一个最低采样额度比如每条低分路径至少采样1次防止被完全剪掉。这个“最低采样额度”就像保险成本增加不多但能堵住规划器估计偏差的漏洞。4.2 规划与执行模型不一致导致的分布漂移还有一个隐蔽的大坑规划器用的模型和执行器用的模型不是同一个或者不是同一套微调数据训练出来的。我试过一个组合规划阶段用8B小模型做路径打分执行阶段用70B大模型生成答案。结果是路径分数很高但大模型实际执行那条路径时效果很差。后来一分析8B模型认为“设方程”是好路径70B模型在同类问题上更擅长“几何变换”两个模型的先验和擅长方向完全不一样。规划器按自己的偏好选了方向执行器却按另一个思路工作两边对不上。对策是尽量让规划器和执行器同源至少来自同一个模型家族。如果必须跨模型先拿一小批验证集做校准对比不同路径在各执行器下的实际成功率再调整规划权重。还有一种更稳的办法让规划器只做“粗裁剪”比如从8条里排掉2条明显不好的保留6条。越是大模型越值得把路径选择权交还给执行阶段。提示规划器不是越聪明越好。在分布漂移不可控时规划器做“粗筛选”比做“精排序”更安全因为它留给了执行阶段足够的纠错空间。4.3 KV Cache和prefix复用没设计好省下的钱又花回去在工程层面“省一半算力”能不能落到账单上最关键的环节是Prefix复用。我遇到过一种情况采样次数确实从64降到了30但服务端的KV Cache没有做共享。每条路径虽然共享前几步的骨架但从骨架之后的分叉点开始每个分支都重新计算了KV Cache等于把同样的前缀算了好几遍。结果GPU时间和延迟几乎没降下来只是少了后半段的采样次数。PTTS天然适合prefix caching。规划阶段生成的路径骨架可以直接作为公共前缀执行阶段所有同路径的采样都从同一个KV Cache状态继续生成。这个优化在工程上一点都不性感和高深但实测下来它能让你真正看到那“一半”的节省——采样次数降了KV Cache也复用了账单才会跟着降。4.4 只报精度不报算力对比失去意义最后一个坑不是代码问题而是评估方法问题。我见过不少方案汇报时说“PTTS精度提升了1个点”但没提它为了这1个点花了多少token。这种对比没有意义。正确做法是固定三个维度中的一个再对比另外两个。要么固定精度看谁用的算力更少要么固定算力预算看谁的精度更高要么固定延迟上限看谁的总吞吐更大。我习惯在实验记录里统一标注三个数字总token数、GPU-seconds、p95延迟。列一个简单的评估模板baseline SC-N64一行PTTS一行Best-of-N一行。每个方案记录精度、总token、GPU-seconds、p95延迟放在同一张表里。这样团队成员一眼就能看出PTTS到底省了多少而不是被“精度涨了”这四个字带偏。5. 关于“测试时算力”还能往哪走5.1 预算随难度自适应PTTS已经在路径维度上做了自适应但下一步应该是按问题难度做更粗粒度的路由。简单问题不规划直接执行一次中等难度问题做一次轻量规划加少量采样困难问题才上完整的分层规划加充分采样。这种“先分诊、后治疗”的流程在医疗场景是常识在推理场景却很少被认真设计。我在自己的服务上试过一个很粗糙的分级策略先让模型在短前缀上生成一个“预期难度分”低于阈值直接返回第一次采样的结果高于阈值再走规划-执行流程。这个分诊本身成本很低但能把大量简单请求拦截掉整体算力节省比单靠PTTS更可观。5.2 规划器可以更轻现在PTTS的规划器通常还是独立模型或PRM未来更值得期待的方向是把它挂到执行模型内部做成一个可以提前退出的分支。这意味着模型先生成一小段思路骨架一个轻量的预测头输出“这条路有没有希望”有希望就继续展开没希望就换方向。这和early exit、speculative decoding在思想上是一脉相承的目标都是把有限算力集中在更可能成功的路径上。这类做法的难点不在模型结构而在训练信号你需要在训练阶段让模型学会“识别自己擅长和不擅长的方向”。这和目前主流的RLHF配方不完全一样可能需要更多过程级监督数据。但一旦做成测试时算力从“外部策略调参”变成了“模型内生能力”应用范围会比现在大得多。5.3 我自己的实操建议如果你现在就想试PTTS我的建议是别一上来就搞复杂版本。先在现有数据集上把baseline跑稳SC-N16的精度和token数是多少N64又是多少。然后做一个最简版的PTTS用一个已有的轻量PRM或小型同源模型做路径打分只选top-3路径执行每条路径分配预算共享前缀开起来先看一组对比曲线。多数场景里一个能用的PRM加上路径级预算分配就已经能拿到“省一半”的大部分收益。真正把方案升级到树搜索级别是在你发现路径之间的交叉和回溯很频繁、简单top-k不够用之后的事。别为了追求架构完整让工程成本吃掉算力收益这是我在好几个项目里反复验证过的经验测试时算力的优化永远是把每一份算力放在最需要它的地方而不是把策略包得越复杂越好。