AI评测,正在变成新的算力瓶颈

这件事值得开发者关注，不是因为又多了一个行业焦虑词，而是因为它会直接影响团队怎么选模型、怎么设计评测集、怎么控制推理预算，以及怎么判断一个 AI 产品到底有没有变好。

过去说 AI 评测，很多人想到的是在固定数据集上跑一遍模型，然后得到准确率、通过率或榜单名次。这类评测当然还重要，但它们已经不能覆盖今天的模型使用方式。 现在的 AI 应用更像一个组合系统：模型会调用工具、检索文档、写代码、执行中间步骤、反思结果，甚至在一个任务里进行多轮行动。评测这样的系统，就不能只看模型对一道题的最终答案，还要看它每一步是否合理、是否稳定、是否会被 scaffold 影响，以及同一个任务重复运行时是否出现巨大波动。 这就是 agent evaluation 变贵的根本原因。一次评测不再只是一次前向推理，而可能是多轮 rollout、多次工具调用、多种配置组合，再叠加重复实验来估计可靠性。 从已有案例看，评测已经越过了一个成本阈值：有智能体榜单为了覆盖多个模型和多个 benchmark，花费约 4万美元 跑了 21730 次 agent rollout；单次在前沿模型上跑 GAIA 这样的任务，在缓存前成本可达到 2829 美元；还有针对 agent 配置的大规模 sweep，发现同样任务下仅 scaffold 选择就可能带来 33 倍成本差异。 这说明一个很现实的问题：以后评测贵不贵，不只取决于模型价格，也取决于你怎么组织任务、怎么搭 scaffold、怎么设置停止条件，以及要不要为了可靠性重复运行。

训练时代的瓶颈很好理解：参数更多、数据更多、训练时间更长，算力开销自然上升。但在推理和 agent 时代，评测成本的增长更隐蔽。 模型能力提升后，大家不再满足于测“会不会回答”，而是要测“能不能完成任务”。这会带来三类额外开销。 第一，推理时计算被放大。一个智能体任务可能需要搜索、规划、调用工具和多轮检查，单个样本的成本远高于普通问答。 第二，评测维度变多。除了正确率，还要看成本、延迟、鲁棒性、失败类型、安全边界和可复现性。每增加一个维度，往往意味着更多样本、更多重复运行或更多人工/自动判分。 第三，评测进入研发循环。像 Pythia 这类模型检查点研究显示，开发者可能会在大量 checkpoint 上反复评测模型。对小模型来说，评测甚至可能成为整个开发周期中最主要的计算开销之一。

这对团队的影响很直接：如果没有评测预算管理，研发会陷入两种极端。要么为了省钱只测少量样本，结果上线后遇到不可控长尾；要么全量盲跑，把预算消耗在对排序帮助很小的重复确认上。

好消息是，并不是所有评测都必须全量运行。静态 benchmark 上已经出现了不少压缩思路。 例如，有研究发现，在 HELM 这类综合评测中，100 到 200 倍的计算削减仍能保留接近的模型排序；Flash-HELM 的思路是先用便宜评测粗筛，再把高分辨率计算花在最有希望的候选上。另一些工作则尝试把大规模题集压缩成少量 anchor items：MMLU 可从 14000 个样本压缩到 100 个锚点样本，误差约 2%；Open LLM Leaderboard 也可从 29000 个样本压到 180 个。 这些结果传递了一个重要信号：很多静态评测里的计算，其实是在重复确认已经能推断出的排名。 但这套逻辑不能无脑搬到 agent 评测里。智能体评测的问题更复杂：任务执行路径不稳定，工具调用可能失败，scaffold 对结果影响很大，同一个模型在不同封装下表现可能完全不同。更麻烦的是，很多 agent 任务的样本成本高，且结果噪声大。你越想获得可靠结论，越需要重复运行；越重复运行，成本越高。 这也是为什么 评测压缩 会成为重要方向，但它不是万能药。静态题库可以抽样、分层、锚定；智能体评测则需要同时处理任务复杂度、运行随机性和系统配置差异。

对开发团队来说，重点不是追求“评测越全越好”，而是建立一个有预算意识的评测漏斗。

如果你正在做模型选型、RAG 应用、代码智能体或内部 AI 工具，建议从三个层面开始改造评测流程。

选型阶段的目标是快速缩小候选范围，不需要一开始就跑最贵的全量任务。你可以先用小样本覆盖核心场景，重点看模型是否存在硬伤：不遵守格式、工具调用失败、关键领域知识不足、成本明显过高。 上线前评测则要更严格。此时模型候选已经很少，应把预算花在真实任务链路、失败模式分析和重复运行上。尤其是 agent 产品，不要只看一次成功演示，要看多次运行后的稳定性。

很多团队只比较模型，却忽略 scaffold。事实是，在 agent 任务里，提示词模板、工具描述、规划策略、重试机制和终止条件都会显著影响成本与结果。 如果同样任务因为 scaffold 不同出现数量级成本差异，那么评测就不能只写“某模型得分多少”。更合理的记录方式是：模型版本、scaffold 版本、任务集、运行次数、平均成本、失败类型一起保存。否则，团队很难复现实验，也无法判断下一次改动到底改善了什么。

小样本不是随便抽几道题。有效的低成本评测应该覆盖真实业务里最容易出问题的任务：多步骤推理、工具调用边界、权限敏感操作、长上下文输入、非标准格式输出。 这类样本数量可以少，但要有诊断价值。它们的作用不是给出最终排名，而是帮助团队快速发现不值得继续投入高成本评测的方向。

强调评测成本，并不是说评测应该少做。恰恰相反，随着 AI 系统进入生产环境，评测会变得更重要。 第一，它能减少盲目换模型。很多团队看到新模型发布就想迁移，但真实收益往往取决于业务任务、提示词、工具链和成本结构。一个分层评测系统可以告诉你：新模型到底是在关键任务上更强，还是只是榜单更好看。 第二，它能降低上线风险。尤其在客服、代码、数据分析、金融合规等场景，单次 demo 成功没有太大意义。持续评测可以暴露稳定性问题、长尾失败和回归风险。 第三，它能帮助团队优化成本。评测不仅评质量，也应该评成本。不同模型、不同 scaffold、不同重试策略之间，可能存在巨大的推理费用差异。把这些差异量化出来，才可能做工程决策。 第四，它会推动 AI 工程流程成熟。过去大家谈 MLOps，更多关注训练、部署和监控；现在 EvalOps 会变成同样重要的一环。评测集管理、自动判分、抽样策略、缓存机制、回归测试，都会成为 AI 产品团队的基础能力。

评测成本高，不代表可以粗糙评测。这里有几个风险需要避免。 第一，过度压缩可能掩盖长尾问题。静态 benchmark 的排序可以被少量 anchor item 近似，但真实业务往往关心的是少数高风险失败。样本太少，可能把最危险的情况漏掉。 第二，agent 评测的噪声更大。一次运行失败，可能是模型能力问题，也可能是工具异常、提示词不稳、环境状态变化或随机路径选择。没有重复运行，就很难判断失败性质；但重复运行又会提高成本。 第三，自动评测本身可能引入偏差。用模型给模型打分很方便，但评审模型的偏好、提示词和判分标准都会影响结果。对于关键场景，仍需要人工抽检或更严格的验证机制。 第四，评测可能反过来绑定研发方向。如果团队只优化某个榜单或内部测试集，模型和产品很容易变成“为测试而优化”，在真实用户任务中未必更好。

从当前趋势看，AI 评测正在经历一次角色变化：它不再是论文、榜单或发布会里的附属物，而会变成团队每天都要维护的工程系统。 对个人开发者来说，最务实的做法是从小而稳定的评测集开始。不要一上来追求覆盖所有能力，先把你最关心的 20 到 50 个真实任务沉淀下来，记录模型、提示词和输出变化。哪怕样本不多，只要持续版本化，也比凭感觉换模型可靠得多。 对团队来说，评测预算应该像云资源预算一样被管理。哪些任务适合低成本快速筛选，哪些任务必须高成本重复验证，哪些结果需要人工复核，都应该在流程里明确，而不是靠工程师临时决定。 未来一段时间，模型能力还会继续提升，推理时计算也会继续扩大。随之而来的不是“评测自动变简单”，而是评测会越来越像软件工程里的 CI/CD：你不能没有它，也不能让它无限制消耗资源。 AI评测成为算力瓶颈，本质上是在提醒开发者：模型时代的竞争，不只是训练谁更强，也是谁能用更低成本、更高可信度判断“它到底有没有变好”。