跑同一个 benchmark 能差出 6 个百分点——Anthropic 工程师把"基础设施噪声"变成一个新变量

但如果同一个 agent 模型在不同的容器资源配置下，成绩本身就能差出 6 个百分点（p<0.01）——那 4 个百分点的差距其实只是噪声。

这是 Anthropic 工程师 Gian Segato 在 4 月 24 日的一篇技术稿里给出的结论。Nicholas Carlini、Jeremy Hadfield、Mike Merrill、Alex Shaw 是合作者。

什么叫"基础设施噪声"

LLM benchmarks 现在都有一套规范化的 setup——固定模型、固定 prompt、固定温度。但 agentic benchmarks（让模型用工具、写代码、跑测试）多了一个之前被忽略的维度：容器资源配置。

具体说，evaluator 跑每个 task 时会给被评估的 agent 一个 sandboxed container。这个 container 配置里有两个关键参数：

• 保证分配（guaranteed allocation）：这一容器至少能用多少 CPU/RAM
• 硬上限（hard kill threshold）：超过这个值，container 立刻 OOM-kill

按 evaluator 的常规做法——这两个值常常被设成相等。表面上看是"严格资源限制"，实际上 Segato 团队发现了这件事的副作用：

> "there's zero headroom for transient spikes: a momentary memory fluctuation can OOM-kill a container"

也就是说——agent 实际上能不能完成 task，部分取决于它有没有运气避开瞬时内存峰值——这件事和模型能力没关系。

三个数字

把文章里的具体数字摆出来：

• 6 个百分点：在 Terminal-Bench 2.0 上，最低资源配置和最高资源配置之间的成绩差，p<0.01
• 5.8% → 0.5%：基础设施错误率（基础设施原因导致 task 失败的比例），从严格 enforcement 改到 uncapped 后的下降
• 3 个百分点：Segato 给出的"应该被怀疑"门槛——leaderboard 上低于 3pp 的差距都不算 signal

第一个数字说的是噪声的量级。第二个说的是这个噪声大部分时间不是模型表现差，而是 container 被 OS 干掉了。第三个是给所有读 benchmark 的人的一句话：3pp 以下，不要解读。

SWE-bench 没那么严重——为什么

文中专门对照了一组 SWE-bench Verified 的实验：5 倍 RAM 比 baseline 只带来 1.54 个百分点的成绩波动。同样的资源放大，Terminal-Bench 2.0 波动是它的 4 倍。

差异来自任务结构：

• SWE-bench：每个 task 是修一个 GitHub issue，agent 主要在 read+edit 文件，内存用量稳定
• Terminal-Bench 2.0：每个 task 涉及 build/test/debug 整套 pipeline，会调用大型 dependency、跑 subprocess、有真实的内存峰值

也就是说——任务越接近真实工程工作流，infrastructure noise 越显著。这个反向相关性的副作用是：越想测"agent 在真实场景的表现"的 benchmark，越被 infrastructure 配置主宰。

推荐做法

文章末段给出一个可操作的 fix：

1. 保证分配 ≠ 硬上限——必须分别设置
2. 容差带（headroom）≈ 3 倍——baseline 资源 × 3 作为硬上限。这个比例下基础设施错误率从 5.8% 掉到 0.5%，但模型自身的成绩波动只有 p=0.40（不显著）
3. 资源配置应该是 first-class 实验变量——和模型版本、prompt、温度并列在 eval 报告里被显式记录

这件事的影响面

它会动摇过去 18 个月里很多被引用过的"agent 提升"。任何 agentic eval 工程师——不管做的是 OpenAI Tasks、HumanEval-X，还是自家 leaderboard——都需要重新看一遍自己的容器配置。Segato 给出的"3 pp 怀疑门槛"，意味着 leaderboard 上至少 1/3 的能力提升声明应该重新验证。

也有它没解决的部分：这一研究只覆盖了 Anthropic 自己的 sandboxed environment 配置选择，真实生产环境（用户在自己机器上跑 agent）噪声会更大——那个语境下门槛可能从 3 pp 再往上调到 5 pp。

如果你是 benchmark 的作者，这一周该加一项优先级：你的 benchmark 的 container resource 文档现在写在哪里？设了 hard kill 但没设 guarantee？——不解决这两件事，你的 benchmark 在 Segato 这套标准下基本上是不可重现的。