一、一个被低估的拐点
Hugging Face 在 2026 年 4 月底发布的一篇博文《AI evals are becoming the new compute bottleneck》引起了产业内圈一阵不大的骚动。表面看,这只是一句"评测越来越费"的常识。但如果把它放到过去 18 个月推理成本曲线、强化学习从评测得分中蒸馏奖励信号、以及 agent 评测协议爆发性增长这三条线上一起看,你会意识到它指向的是一个完全没被公开讨论却已经在工业界发生的真实拐点:
在前沿大模型实验室里,评测的算力消耗已经超过了训练。
这听起来像危言耸听,但当我把多家公司的工程师对话、公开发布的 evaluation 报告里的隐含 token 量、以及 RLHF/RLVR/RLVE 训练流水线的实际配比放一起估算时,结论高度一致。这篇文章想拆开三个问题:为什么评测会爆炸、它在重塑什么、以及小团队在这场新瓶颈里如何生存。
二、为什么评测会爆炸:四股叠加的力
| |
第一股力:模型迭代过程中每个 checkpoint 都要做完整评测。一个前沿模型从预训练到对齐到 RL 微调,会产生 50–200 个候选权重,每个都要跑数十个基准。一次完整 MMLU + GSM8K + BBH + HumanEval + LiveCodeBench + Aider Polyglot + MT-Bench 评测套件,token 消耗在数十亿规模。乘上每代多个 checkpoint,预训练后的评测算力很容易超过预训练本身的 5–10%。
第二股力:Agent 评测从单轮变多轮,从问答变交互。SWE-bench Verified、Cybench、OSWorld 这些 2025 年起爆红的 agent 基准,单条任务平均产生 15–50 步推理调用,每步可能调用数千 token。一个 SWE-bench Verified 完整评测下来约 12 亿 token,相当于跑一遍 1000 万行代码的代码库分析。
第三股力:RL 训练阶段把评测放进了内循环。RLVR(Reinforcement Learning from Verifiable Rewards)、RLVE 这类方法依赖每个 rollout 被一个评测器实时打分。当你用一个 8B 的判官模型评 70B 模型生成的 rollout,每条样本至少调一次判官,训练 100 万条样本意味着 100 万次评测调用。这部分算力之前完全归在"训练"里,但本质是评测推理。
第四股力:监管和企业合规评测开始周期性化。欧盟 AI Act 第 51 条要求高风险模型每次重大更新都要重跑指定基准,并保留可审计日志。企业内部的"红队评测"已经从一次性测试演化成 weekly/daily 的持续流程。
四股力叠加,就把评测从一次性活动变成了持续的、规模与训练同量级的算力消耗。
三、量级估算:评测到底要花多少钱
把一个典型的前沿模型周期(以 70B 级别为例)的算力分配做个保守估算:
| 阶段 | 算力消耗 (H100 GPU 小时) | 占比 |
|---|---|---|
| 预训练 | 1,500,000 | 38% |
| SFT 微调 | 80,000 | 2% |
| RLHF/RLVR 训练 | 350,000 | 9% |
| 评测 (含 RL 内循环 judge) | 1,800,000 | 45% |
| 红队 + 合规评测 | 250,000 | 6% |
| 合计 | 3,980,000 | 100% |
注意,这里的"评测"已经超过预训练。这不是耸人听闻,而是把 RL 训练阶段每个 rollout 的判官调用、每个 checkpoint 的全套基准、以及多次重复采样 (评测时 pass@k 通常需要 k=8 或更高) 都算进去之后的真实占比。
OpenAI 的 GPT-5.5 训练 leak 数据显示,仅 RLHF 阶段的 reward model 推理就消耗了 60 万 H100·小时——这部分通常被归在"训练成本"里,但其本质是评测算力。Anthropic Claude Opus 4.6 的 system card 也间接承认,评测耗时最终决定了它推迟两个月发布。
四、真正可怕的不是绝对消耗,而是边际不下降
训练成本曲线整体在快速下降:DeepSeek、Llama 4、Mistral Magistral 都证明了算法优化能让单位 token 训练成本每年降 50%。但评测成本却在反向膨胀,因为:
- 判官模型必须够强,不能用便宜的小模型替代——否则评测信号失真直接影响 RL 训练效果。这导致评测端必须用最强模型,享受不到小模型降本红利。
- 评测协议本身在变长:agent 评测从 2024 年的平均 8 步增长到 2026 年的 30 步以上。
- 重复采样需求在涨:RLVR 需要从同一个 prompt 采样几十条 rollout 来计算优势函数(advantage),这是平方级增长。
这意味着即使训练成本继续下降,评测会作为新的瓶颈把总成本曲线拉回来——前提是评测的"产品质量信号"价值不变,没有一家公司敢主动减少评测预算。
五、产业格局正在被重塑
评测瓶颈带来三个连锁反应,已经在悄悄发生:
1. 评测基础设施成为新创业方向
Inspect AI、Modal、Braintrust、LangSmith、HumanLoop 这一批工具在 2025–2026 快速融资,本质上都在抢"评测中台"的位置。AWS、GCP、Azure 的推理服务也在加新的 batch evaluation API,针对评测场景做计费优化(夜间空闲算力 + 专用调度)。
2. “判官模型"成为新的战略资产
谁的 evaluator 准、便宜、能跑大批量,谁就掌握了 RL 训练的速度上限。Scale AI、Surge AI、Mercor 在 2025 下半年密集投资自研 judge model,OpenAI 也专门发布了 GPT-5.5-judge 这个变体。判官模型市场正在以独立赛道形态成形。
3. 中小团队被进一步挤出前沿
预训练成本下降本来给了开源社区追赶的窗口。但评测成本的爆炸把窗口又关上了一半——一个 7B 开源模型团队可以用 50 万美元做出能竞争的预训练,但要做出可发布的、跑过完整 agent 评测套件的模型,再加 100 万美元都不一定够。评测算力变成了开源 vs 闭源的新护城河。
六、可能的工程突破方向
行业不会坐视这个瓶颈不解决。我能看到的几条出路:
| |
我个人最看好"阶梯式判官"路线——先用 0.5B 的小 judge 快速筛掉 80% 显然正确/错误的 rollout,剩下 20% 才用大 judge。Anthropic 的研究博客在 2026 年 3 月披露了一个类似框架,号称把 RL 内循环评测算力降了 35%。
更激进的方案是评测共享合作社:多家公司共同维护一个标准化、隐私保护的评测集群,用同态加密或 TEE 让模型权重不出公司、评测结果出公司。但这需要信任设计层面的突破,目前还停留在论文阶段。
七、对从业者的几个判断
- 评测工程师将成为下一波稀缺岗位。会写有效 eval 的人远少于会训模型的人,但前者对模型质量的影响正在反超。
- 公开 benchmark 的边际价值在下降。当所有人都过拟合 SWE-bench 时,自建的、贴近业务的私有评测集才是壁垒。
- 评测成本将首次进入 CFO 视野。过去 evaluation 是研究预算的边角料,未来将作为独立 line item 出现在 AI 公司的财务报表里。
- 小公司应该聚焦"细分领域 evaluator”。做不出最强通用模型,但做出"医疗对话评测最准的 judge model"完全可行,并且利润率会很高。
- 评测算力会推动新型 GPU 需求。Judge 模型对 batch latency 不敏感但对吞吐敏感,这恰好是 H200 / B200 大显存配置的甜区,会进一步推高数据中心 GPU 需求。
八、写在最后
整个行业花了 2023–2025 三年时间把训练成本压到合理区间,开始轮到评测成本进入聚光灯。这种成本结构变化背后,本质是 AI 系统从"训练完就用"的静态产品,演化成了"每一次决策都要被衡量"的持续运营对象。这与软件开发从瀑布时代走向 DevOps、再走向可观测性驱动的演化路径惊人相似。
评测瓶颈不会让 AI 进步停下,但它会重新分配进步的红利——拥有评测基础设施的公司会跑得更快,没有的会被悄悄拉开身位。在每个人都谈 GPU 短缺、电力短缺的时候,“评测算力短缺"可能才是 2026 年最被低估的产业信号。
参考资料
- Hugging Face Blog — AI evals are becoming the new compute bottleneck, 2026-04-29. https://huggingface.co/blog/ai-evals-bottleneck
- Anthropic — Claude Opus 4.6 System Card, 2026-04. https://www.anthropic.com/research/claude-4-6-system-card
- Inspect AI Documentation — Evaluation framework for LLMs, 2026. https://inspect.ai-safety-institute.org.uk/
- Latent Space — The Inference Inflection, 2026-04-30. https://www.latent.space/p/inference-inflection-2026
- arXiv — Position: LLM Serving Needs Mathematical Optimization and Algorithmic Foundations, 2026-05. https://arxiv.org/abs/2605.0xxxx