别只算训练和推理成本：AI 评测正在变成新的算力账单，先把这 4 层预算拆开

别只算训练和推理成本：AI 评测正在变成新的算力账单，先把这 4 层预算拆开

很多团队做模型迭代时，会认真算训练显存、推理 QPS、API 单价，却把评测当成“跑完再看一下分数”。这个直觉正在失效。近期 Hugging Face EvalEval Coalition 的文章里，HAL 这类 agent leaderboard 一轮公开评测已经花到数万美元级别；一旦你把模型数、任务数、prompt 模板、seed、重试次数全乘起来，评测会比一次微调更像真正的预算黑洞。

这篇不讲“怎么刷榜”，也不做排行榜复读。我更想回答一个工程问题：普通团队该怎样设计评测层级，避免每次改 LoRA、RAG prompt 或 agent scaffold 都把完整 benchmark 重跑一遍？

1. 评测成本不是一个数字，而是一串乘法

先看一个最小公式：

总调用次数 = 模型数 × 任务数 × 样本数 × prompt 模板数 × seed 数 × 重试次数 总 token = 总调用次数 × (平均输入 token + 平均输出 token)

这个公式看起来普通，但它解释了为什么很多团队一开始觉得“就跑几个 benchmark”，最后账单完全失控。

我在本地做了一个非常小的预算估算，不涉及真实模型推理，只看维度相乘后的量级：

constscenarios=[{name:'smoke',models:2,tasks:2,samples:100,templates:1,seeds:1,retries:1,prompt:550,output:128},{name:'weekly_regression',models:8,tasks:8,samples:1000,templates:2,seeds:3,retries:1,prompt:650,output:256},{name:'agent_eval_with_retry',models:4,tasks:5,samples:300,templates:2,seeds:2,retries:3,prompt:1200,output:900}]for(constsofscenarios){constcalls=s.models*s.tasks*s.samples*s.templates*s.seeds*s.retriesconstinput=calls*s.prompt/1e6constoutput=calls*s.output/1e6console.log(s.name,calls,input.toFixed(2),output.toFixed(2))}

输出结果是：

注意这里还没有算 judge model、工具调用、网页浏览、代码执行、沙盒运行、失败重试后的日志存储，也没有算多轮 agent 的上下文膨胀。

作者判断 1：评测预算失控通常不是因为某个 benchmark 太贵，而是因为团队没有把评测维度当成配置管理。模型、任务、样本、prompt、seed、retry 只要有两个维度被随手扩大，成本就会从“还能接受”变成“没人愿意每天跑”。

2. 公开案例已经说明：评测不再只是训练后的附属动作

Hugging Face 在 2026 年 4 月发布的 EvalEval Coalition 文章直接把问题点出来：AI evals 正在变成新的 compute bottleneck。

文章列了几个很有代表性的公开案例：

这和传统深度学习时代不一样。

以前我们很容易把成本分成两类：

现在更准确的分法应该是：

作者判断 2：如果你的团队已经在做 agent、RAG、多 prompt 路由或多 checkpoint 微调，却还没有一张“评测预算表”，那你现在缺的不是更大的 benchmark，而是评测工程治理。

3. 静态 benchmark 可以抽样，agent eval 没那么容易压缩

静态 LLM benchmark 有一个好消息：很多任务可以做抽样、分层、粗到细筛选。

Hugging Face 那篇文章提到，HELM、tinyBenchmarks、Flash-HELM 等工作都在尝试用更少样本保留足够的排名信息。思路并不复杂：如果很多样本对模型排序贡献不大，就先用低成本集合筛出候选，再对少数模型做高分辨率评测。

这对普通团队很有启发。

比如你要比较 8 个内部模型，不应该第一步就全量跑：

8 个模型 × 8 个任务 × 1000 样本 × 3 seeds × 2 prompt 模板

更合理的是：

第 1 层：smoke，2 个任务 × 每任务 20 条，只看能不能跑通 第 2 层：pilot，核心任务 × 每任务 100 条，看方向是否明显错误 第 3 层：candidate，保留 top 2-3 个模型，扩大样本和模板 第 4 层：release，全量任务 + 固定 seed + 样本级日志 + 可复现报告

但是 agent eval 没这么轻松。

agent 评测里，一条样本不是“一次前向得到一个答案”。它可能包括：

问题输入 -> agent 规划 -> 工具选择 -> 网页 / 代码 / 检索 / shell 调用 -> 多轮观察 -> 失败重试 -> 最终答案 -> judge model 或规则评分

这会带来三个后果：

作者判断 3：agent eval 里最危险的不是模型贵，而是你把 scaffold 和 retry 当成“运行细节”。它们必须和模型版本一样被记录，否则同一个模型换一套工具预算，分数和账单都不可比较。

4. 从 lm-evaluation-harness 看：评测框架已经把“省钱开关”暴露出来了

我把EleutherAI/lm-evaluation-harnessclone 到本地看了一遍。它不是新项目，但它的工程演进很能说明评测已经从“脚本”变成“系统”。

README 里几个点值得注意：

• 支持大量标准 academic benchmarks，并且是 Hugging Face Open LLM Leaderboard 的后端之一。
• 后端不只 Hugging Face transformers，还支持 vLLM、SGLang、API model、adapter、local model。
• 2025 年底以后 CLI 被拆成run、ls、validate子命令，评测配置开始更像可管理的工程对象。
• base package 不再默认带 transformers/torch，需要按lm_eval[hf]、lm_eval[vllm]、lm_eval[api]选择后端。

真正和成本有关的是这些参数：

lm-eval run\--modelhf\--model_argspretrained=gpt2\--taskshellaswag\--limit100\--output_path./results\--log_samples\--use_cache./cache/model_responses\--cache_requeststrue

几个参数不要混：

我还看了lm_eval/caching/cache.py。它会用 cache key、路径前缀和 hash 生成缓存文件名，并且考虑了文件名过长的问题。这个细节说明一件事：评测缓存不是“随便存个 JSON”，而是需要稳定 key、可复用路径和清理策略。

我建议团队至少把下面这些字段写进每次评测结果：

{"model":"your-model-name-or-checkpoint","model_revision":"git-or-hf-revision","task_suite":"smoke-v1","prompt_template":"chat-template-v3","num_fewshot":5,"generation_kwargs":{"temperature":0,"max_new_tokens":256},"seed":"0,1234,1234,1234","cache_key":"model+task+prompt+gen_kwargs","sample_log_path":"./results/samples.jsonl"}

没有这些字段，后续你会遇到三个问题：

• 分数变了，不知道是模型变了还是 prompt 变了。
• 成本变了，不知道是任务变多了还是输出变长了。
• 缓存命中了，不知道命中的是不是旧模板。

5. 从 Lighteval 看：业务评测贵在“自定义任务”，不是贵在安装

我也 clone 了 Hugging Face 的lighteval。它的 README 里有两个信号：

• 支持 1000+ evaluation tasks。
• 支持accelerate、vllm、sglang、endpoint、custom model 等多种入口。

这说明 Lighteval 更像一个“评测工作台”：你可以接本地模型，也可以接 endpoint；可以跑标准任务，也可以写自定义任务。

但真正让业务团队花时间的不是安装，而是自定义任务定义。

Lighteval 的自定义任务文档要求你明确：

defprompt_fn(line:dict,task_name:str):returnDoc(task_name=task_name,query=line["question"],choices=[f"{c}"forcinline["choices"]],gold_index=line["gold"],)

然后再定义：

LightevalTaskConfig(name="myothertask",prompt_function=prompt_fn,hf_repo="your_dataset_repo_on_hf",hf_subset="default",evaluation_splits=["test"],few_shots_split="train",metrics=[metric],generation_size=256,stop_sequence=["\n","Question:"],)

这些字段背后其实就是评测预算字段：

作者判断 4：业务评测集不要从“题库越大越好”开始。先把 prompt、metric、stop、样本级日志和版本号跑通，再扩大样本。否则你只是在用更多成本制造不可解释的分数。

6. 普通团队应该把评测拆成 4 层，而不是一套 benchmark 跑到底

我更建议把评测拆成四层：

这四层的关键不是“样本多少”，而是每层回答的问题不同。

smoke 不回答效果，只回答连通性

smoke 层只应该看：

• tokenizer / chat template 是否报错；
• 模型能不能输出；
• stop sequence 是否生效；
• judge 是否能解析；
• 结果文件是否能落盘。

这里用--limit 20很合理。

但 smoke 结果不能写进报告，更不能拿来发结论。--limit的价值是省时间，不是给你一个缩水版排行榜。

pilot 负责砍掉明显错误方向

pilot 层适合比较：

• 两套 prompt；
• 两个 LoRA checkpoint；
• 两个 RAG chunk 策略；
• 两个 agent scaffold；
• 两套 tool budget。

如果 pilot 都明显退化，就不要进入 regression。

这里的重点是保存样本级输出。因为 pilot 的目标不是拿一个漂亮均值，而是看错在哪里。

regression 要固定，不要每天临时改题

regression 是最容易被团队搞坏的一层。

常见错误是：今天加 50 道题，明天换一个 judge，后天改 prompt，最后模型分数变化完全不可解释。

我的建议是：

regression-v1/ tasks.json samples.jsonl prompt_template.md judge_config.json generation_config.json README.md

如果要换题，升版本：regression-v2。不要悄悄改regression-v1。

release 层要贵得有理由

release 层可以贵，但必须贵得有理由。

比如：

• 这次结果要对外发布；
• 这次模型要进入线上主链路；
• 这次改动会影响大客户；
• 这次分数将作为模型选型依据；
• 这次需要和历史版本做长期可比。

如果只是日常试 prompt，别碰 release 层。

7. Agent eval 要额外记录 6 个字段

如果你评测的是 agent，只记录model_name和benchmark_score基本不够。

我建议额外记录：

一个更完整的记录长这样：

{"model":"agent-model-a","scaffold_version":"browser-agent-v4","tool_allowlist":["browser","python","retrieval"],"max_steps":30,"retry_policy":{"max_retries":2,"retry_on":["timeout","tool_error"]},"judge_model":"rule-or-llm-judge-name","token_budget":{"input_max":200000,"output_max":50000},"wall_time_budget":"30m","cost_budget":"per-suite-limit"}

这不是形式主义。

如果不记录这些字段，你很容易得出错误结论：

• 以为模型 A 比模型 B 强，其实 A 的工具预算更大。
• 以为新 prompt 更好，其实只是 retry 次数翻倍。
• 以为分数稳定，其实 judge 模型版本变了。
• 以为成本下降，其实只是 stop sequence 提前截断了有效答案。

8. 我的推荐落地路径：先建预算表，再接框架

如果你现在准备给团队做一套评测系统，我建议顺序是这样：

第一步：先列预算维度

不要先选框架，先写清楚：

模型数： 任务数： 每任务样本数： prompt 模板数： seed 数： 最大输出长度： 是否使用 judge： 是否允许 retry： 是否需要工具调用： 是否保存样本级日志：

这一步做完，你会发现很多“想全跑”的需求根本不可持续。

第二步：建 smoke 套件

smoke 套件应该小到每次 CI 或每次模型加载改动都敢跑。

目标不是证明模型好，而是尽快发现：

• 模型路径错；
• tokenizer 不匹配；
• chat template 不兼容；
• 输出格式解析失败；
• judge 规则崩了；
• 结果目录没写权限。

第三步：业务题库先做 100 条，而不是 1 万条

100 条高质量业务样本，通常比 1 万条来源混乱的题更有价值。

每条样本至少包含：

{"id":"case-001","input":"...","expected_behavior":"...","metric":"exact_match/rubric/judge","difficulty":"easy/medium/hard","domain":"customer_service/rag/code/agent","source":"internal/redacted/public","version":"v1"}

第四步：再接 lm-eval、Lighteval 或自研 harness

框架选择可以按场景来：

我的倾向是：不要为了“统一框架”牺牲可解释性。业务评测最重要的是样本、配置和日志可追溯；框架只是执行层。

9. 新手最容易踩的 5 个坑

坑 1：把--limit的结果当正式分数

--limit很适合 smoke，但不适合发布结论。因为它可能只取数据前 N 条，样本分布不一定代表完整任务。

更稳的做法是：固定抽样文件，而不是每次随手--limit 100。

坑 2：只保存均值，不保存样本级输出

均值只能告诉你“掉了 3 分”，不能告诉你为什么掉。

样本级输出能回答：

• 是格式错；
• 是知识错；
• 是长上下文漏检；
• 是工具没调用；
• 是 judge 误判；
• 是 stop sequence 提前截断。

坑 3：prompt 改了，但评测版本号没改

prompt 是评测定义的一部分，不是运行参数的小尾巴。

同一批样本、同一个模型、不同 prompt，应该视为不同 eval config。

坑 4：agent 重试策略没有写进结果

agent retry 很容易让成功率上涨，同时成本也上涨。

如果只汇报成功率，不汇报 retry 次数、平均 step、平均 token，就会误导决策。

坑 5：LLM judge 没有抽查

LLM judge 不是天然客观指标。

建议至少抽查：

• judge 是否偏向长答案；
• 是否被格式噪声影响；
• 是否对中文/英文答案标准不一致；
• 是否对工具日志泄漏敏感；
• 是否与人工小样本一致。

10. 最后给一份可执行清单

如果只能带走一份清单，我建议这样做：

我的最终判断是：2026 年做模型工程，评测不再是“训练后的一行命令”，而是和训练、推理同级的系统。你可以不做复杂 leaderboard，但不能没有分层评测；你可以不追求全量 benchmark，但必须知道每一次评测在回答什么问题、花了多少成本、能不能复现。

真正成熟的团队，不是每次都跑最大评测集，而是知道什么时候该跑 20 条、什么时候该跑 200 条、什么时候才值得烧完整套 benchmark。

参考与延伸阅读

1. Hugging Face Blog: AI evals are becoming the new compute bottleneck
   https://huggingface.co/blog/evaleval/eval-costs-bottleneck
2. EleutherAI / lm-evaluation-harness
   https://github.com/EleutherAI/lm-evaluation-harness
3. lm-evaluation-harness CLI Reference
   https://github.com/EleutherAI/lm-evaluation-harness/blob/main/docs/interface.md
4. Hugging Face / Lighteval
   https://github.com/huggingface/lighteval
5. Lighteval documentation: adding a custom task
   https://huggingface.co/docs/lighteval/main/en/adding-a-custom-task
6. OpenAI Evals
   https://github.com/openai/evals
7. HELM: Holistic Evaluation of Language Models
   https://arxiv.org/abs/2211.09110
8. tinyBenchmarks: evaluating LLMs with fewer examples
   https://arxiv.org/abs/2402.14992
9. MLE-Bench
   https://arxiv.org/abs/2410.07095
10. The Well: a large-scale collection of diverse physics simulations for machine learning
    https://arxiv.org/abs/2412.00568