花更多算力搜索就能选出更好动作？审计发现82%的候选动作结果完全一样

一个让人尴尬的发现

你训练了一个世界动作模型（World Action Model, WAM），它能同时生成动作、预测未来状态、还给每个候选动作打分。听起来很完美——在推理时多花点算力，生成 N 个候选动作，用价值函数挑最好的那个执行，性能不就上去了吗？

这就是所谓的 test-time scaling（测试时扩展）的核心承诺。

但 CMU、MIT、哈佛、斯坦福的一群研究者决定认真审计一下：多花的算力到底买了什么？

他们用 Cosmos Policy 在 RoboCasa 上做了实验。结果令人震惊：

• 可部署的价值选择器比随机选择还差 1.66 个百分点
• 即使开了上帝视角（hindsight oracle），也只能多赚 1.40 pp，而且置信区间跨过了零
• 82% 的状态中，所有候选动作的结果完全相同——根本没有选择空间

换句话说：你花了 8 倍的算力去搜索，结果发现大部分时候 8 个候选动作的结局一模一样，而你的价值函数还比抛硬币更差。

不是"选择器不行"，是"没有可选的"

这篇论文（arXiv: 2610.41970）最深刻的洞察不是"价值函数不好用"，而是引入了一个被所有人忽略的概念：选择空间（selection headroom）。

想象你在一家餐厅点菜。菜单上 8 道菜，你请了个美食评论家帮你选最好吃的。但如果这 8 道菜其实都是同一道菜的不同摆盘呢？评论家再厉害也选不出花来。

这正是 Cosmos Policy 在 RoboCasa 上的情况。研究者把每个状态下的 8 个候选动作都执行了一遍，发现 82% 的状态下所有候选动作要么全成功、要么全失败。候选动作在几何空间里确实不同（动作向量的分散度正常），但它们在任务结果上没有区别。

这就像 8 个人往同一个方向走，虽然步伐大小略有不同，但都到了同一个终点。

上帝视角的上限

为了确认"不是选择器不够好，而是没有可选的"，研究者设计了一个 hindsight oracle（事后先知）：它知道每个候选动作的实际结果，总是挑成功的那个。

结果呢？oracle 只比随机选择好 1.40 个百分点，而且在 episode 级别的 bootstrap 置信区间是 [-0.25, +3.40]——跨过了零。

这意味着即使你有一个完美的选择器，在这个配置下也几乎赚不到什么。选择空间本身就这么小。

更细致的分析发现：263 个状态中只有 48 个状态存在任何候选间的结果差异，而这 48 个中只有 20 个是"稳定可分"的（同一个候选在两次重复中都成功而另一个都失败）。但 label-shuffle 零假设期望约 14.8 个稳定可分状态——观察到的 20 个只比随机期望多一点点。

FLOPs 省了 47%，实际快了 15%

第二个审计维度更让人泄气。

既然选择没用，那省算力呢？token pruning（token 剪枝）可以砍掉 47.9% 的 per-forward FLOPs，听起来很可观。

但研究者坚持做了一件很少有人做的事：直接量端到端延迟。

结果：

• 部署路径上只快了 1.15 倍（目标是 1.5 倍）
• 即使排除未来图像解码，也只有 1.25 倍

为什么？因为一个查询的总时间 1241.8 ms 中，5 个 DiT 前向传播占 530.7 ms（可以被剪枝加速），但 VAE 编码（238.0 ms）和未来图像解码（434.4 ms）是 不可约减的。你把可加速的部分砍了一半，但那部分只占总时间的一小部分。

这就像你花大力气把高速公路的某一段从 2 车道扩到 4 车道，但整条路最堵的是收费站和出口匝道。扩的那段确实快了，但总行程时间几乎没变。

功率门：不跑无法分辨效果的实验

更令人敬佩的是，研究者在做联合分配实验前设了一个 pre-registered power gate（预注册功率门）：先用小样本估计噪声水平，算出要达到预注册效果量需要的样本量。如果噪声太大、效果太小，就不跑完整实验。

结果联合分配效果的系统分量是 0.0045，而每状态噪声均值是 0.0066——信号比噪声还小。他们如实报告"inconclusive"（无法定论），而不是强行解释一个可能是噪声的结果。

这种学术诚实太少见了。大部分论文遇到这种情况会调参数直到 p<0.05。

最阴险的发现：渲染腐败与算力正相关

第三个审计维度是一个真正的"鬼故事"。

研究者在实验过程中发现 RoboCasa/robosuite 模拟器有一个 静默渲染腐败 bug：

机制

当环境做硬重置时，模拟器会创建一个新实例，但旧实例还留在那里等垃圾回收。当旧实例被 GC 回收时，它的 OpenGL 上下文被释放——但此时活跃的是另一个上下文。旧上下文的释放静默地破坏了当前环境的 framebuffer。

后续渲染返回的是损坏的观测：冻结的画面或噪声帧。没有报错，没有异常。

腐败率与推理算力正相关

这是最让人后背发凉的部分：

你花的算力越多，遇到腐败的概率越高。

这意味着：如果你在规划模式下看到性能"提升"了，你无法确定那是真的提升还是渲染腐败导致的测量误差。算力越多，测量越不可信。

官方数字不受影响

研究者很仔细地验证了官方报告的 67.1% 直接策略数字基本不受影响（腐败效应约 +0.25 pp，上限 +0.6 pp，而且方向是低估成功）。但问题在于：这个 bug 只在算力密集的规划路径上才大规模爆发，而官方基准恰好不测规划路径。

这就像一座桥的质检报告说"承重合格"——但质检只测了空载，满载时桥墩有 65% 的概率出现裂缝。

研究者发布了 framebuffer sentinel 检测器、修复补丁和复现脚本。

前提链审计：不靠成功率判断

这篇论文最大的方法论贡献不是任何一个负面结果，而是提出了 premise-first audit（前提优先审计）框架。

传统做法的问题

大部分论文评估 test-time scaling 的方式是：跑一下，看成功率有没有提高。如果有，就声称有效。

但这无法区分三种情况：

1. 选择信号确实存在，选择器抓住了它 → 真提升
2. 选择信号不存在，但模拟器有 bug 导致某些 episode "碰巧"成功 → 假提升
3. 选择信号存在但选择器没抓住，算力白花了 → 无提升

成功率数字看起来一样，但原因完全不同。

前提链

研究者把 test-time scaling 拆成三个独立前提：

1. 决策信号前提：候选动作之间是否存在可利用的结果差异？
2. 效率实现前提：名义 FLOPs 节省是否转化为端到端加速？
3. 评估完整性前提：评估路径在额外算力下是否仍然可靠？

每个前提独立审计，不靠最终成功率来反推。如果前提 1 失败（82% 状态无差异），那不管成功率显示什么，选择机制在这个配置下都没用。如果前提 3 失败（65% 腐败率），那任何成功率数字都不可信。

这和"评测盲区定律"完全一致：成功率是标量，但性能是向量。标量看起来一样，向量可能指向完全不同的方向。

预注册：先承诺再实验

论文的另一个亮点是 pre-registered methodology：

• 在看数据之前，先固定决策阈值和重复一致性门
• 用功率分析决定是否值得跑完整实验（不够就不跑，省时间和算力）
• 如实报告门未通过的结果（而不是悄悄删掉换一个能通过的实验）

hindsight oracle 的 episode 级置信区间跨过了零，他们就如实说"weak, inconclusive evidence"（微弱、不确定的证据），而不是找借口说"虽然跨零但点估计是正的"。

联合分配实验的功率门没过，他们就不跑完整 factorial，报告"inconclusive rather than evidence of no effect"（无法定论，而非证明无效）。

这种做法在 RL/robotics 领域几乎是异类。大部分论文的做法是：跑 10 个 seed，挑最好的 3 个报告均值，不提另外 7 个。

对工程实践的启示

1. 先量选择空间，再训练选择器

如果你要部署 best-of-N 规划，第一步不是训练更好的价值函数，而是检查候选动作之间有没有结果差异。如果 82% 的状态没有差异，你的选择器再好也没用。

这可以通过 hindsight oracle 估计：对每个状态执行所有候选，看结果是否不同。如果差异太小，应该把精力放在候选生成策略上（生成更多样化的候选），而不是选择器上。

2. 永远量端到端延迟

FLOPs 节省是最容易"自欺"的指标。47.9% 的 FLOPs 砍掉了，但端到端只快 15%。原因是有不可约减的编码/解码开销。

在部署前，直接量完整查询的 wall-clock 时间。不要用 FLOPs 减少比例来推算加速比。

3. 检查模拟器在算力密集路径下的可靠性

大部分模拟器 bug 在低算力路径下不暴露。你的 benchmark 可能显示"一切正常"，但一旦你开始做规划（每个查询多次前向传播），bug 就大规模爆发。

在报告任何 test-time scaling 收益之前，先验证评估路径在额外算力下仍然可靠。framebuffer sentinel 的思路（预填标记，渲染后检查是否被覆盖）可以推广到其他模拟器。

4. 预注册你的实验

在看数据之前固定决策标准。如果效果太小、噪声太大，就如实报告"无法定论"。这比强行 p-hack 出一个"显著"结果有价值得多——因为"无法定论"是一个可操作的信息：你需要更大的样本量或更低的噪声，而不是更聪明的解释。

这篇论文的位置

这篇论文不是在说"test-time scaling 没用"。作者非常明确地声明了范围：结论仅适用于 Cosmos Policy 在 RoboCasa 上的测试配置。

但它提供了一套 审计方法论，可以应用到任何 test-time scaling 场景：

• 候选之间有没有真正的差异？
• 名义节省有没有变成实际加速？
• 评估路径在额外算力下还可靠吗？

三个问题，独立回答，不靠成功率反推。

这和整个"评测盲区"研究脉络一脉相承：标量指标（成功率、FLOPs、AUROC）会系统性掩盖结构性问题。唯一可靠的审计方式是把标量拆回向量，逐个维度检查。

论文: When Does Test-Time Search Help World Action Models? An Empirical Audit of Candidate Selection and Simulator Integrity

作者: Jun Liu (CMU), Dajie Sun (UC Berkeley), Zhenglun Kong (Harvard), Zhenjiang Fan (Stanford), Peiyan Dong (MIT), Fan Yang (Fujitsu), Wenbin Zhang (FIU), Geng Yuan (UGA), Xue Lin (NEU), Yanzhi Wang (CMU), Dong Huang (CMU/EmbodyX)

核心贡献: 前提链审计方法论 + 三个负面结果 + 渲染腐败检测器与修复

适用场景: 任何使用 test-time scaling 的 WAM/Agent 系统——在声称"算力换性能"之前，先审计三个前提