大模型评测无中立基准：配置变量如何左右榜单排名

榜单上明明排名第一的模型，买回来自己一测，结果完全对不上号。这个问题在过去一年里被反复讨论过：同一个模型，在不同的榜单、不同的评测脚本、不同的推理配置下，排名能波动好几个身位。很多人第一反应是“榜单有水分”，但更准确的说法应该是：模型评测不存在一个真正中立的基准。

这次我们就把这个问题拆开聊。所谓“无中立基准”，不是在否定所有模型评测的价值，而是要说明一个事实：任何一次模型排名，都是在一堆具体配置约束下产生的局部结论。采样温度、系统提示词、few-shot 示例、量化精度、推理后端、解码参数、评测集版本，任何一个变量变了，排名都可能改写。这篇文章会从配置变量拆解、复现流程、配置矩阵设计、批量评测工程化、资源占用和排查方法几个角度展开，帮你在面对模型榜单时判断“哪些结论能用，哪些结论只是配置的产物”。

如果你平时关注大模型评测、要做模型选型，或者要自己搭一套可复现的评测流程，这篇内容可以直接收藏。

1. 核心结论速览

2. 为什么不存在所谓“中立基准”

“中立基准”这个说法听起来很合理：找一个公开数据集，把模型都放上去跑，按分数排序，谁分高谁就强。但实际操作过评测的人都知道，这个流程里的每一个环节都需要做选择，而每一个选择都有可能影响最终排名。

先看最简单的几个问题：输出用贪婪搜索还是采样？温度设 0 还是 0.7？top_p 用默认值还是自定义？这些问题看起来只是“推理参数”，但它们会直接改变模型生成的内容。对多项选择题、数学题、代码题这类有标准答案的评测集，温度变化可能只会造成小幅波动；但对开放式问答、摘要生成、偏好类评测，采样参数一变，模型输出差异会非常大。

再往上还有提示词层面的选择。同一个评测集，用不加修饰的原始问题，和加一段“Let‘s think step by step”的指令，模型的得分往往不同。有些模型已经针对某种指令格式做了强化，换一种格式成绩就下滑。这本质上不是模型变弱了，而是评测配置偏离了模型的“舒适区”。

从更宏观的角度看，评测集本身也不中立。公开榜单依赖的测试集是否干净、有没有被训练数据污染、题目难度分布是否均匀、评分是用规则还是用大模型当裁判，这些因素叠加在一起，导致榜单分数很难作为模型能力的精确刻度。

所以准确的说法是：模型评测结果 = 模型能力 + 评测配置 + 评测集特性 + 随机性。榜单只展示最终分数，不展示背后的配置组合，排名自然会出现“换个配置就翻转”的现象。

3. 最容易导致排名漂移的配置变量

下面按影响程度从高到低拆解。这些配置不是理论上的“可能影响”，而是实际评测中经常直接改变名次的关键变量。

3.1 采样参数：temperature、top_p、top_k、repetition_penalty

生成阶段最关键的参数是温度。温度越低，输出的随机性越小；温度越高，模型越容易“发挥”，但也越容易跑偏。评测中如果所有模型都用默认温度跑，可能对某些模型有利，对另一些模型不利。

这里要说一个关键点：评测时最怕的是“每个模型都用自己官方推荐的参数”。商业模型文档里给的默认参数往往经过调优，开源模型的默认参数可能没有那么讲究。对比时必须统一参数，否则你比较的不是模型能力，而是“模型 + 官方调参”的组合效果。

3.2 系统提示词与用户提示词模板

这是排名漂移的重灾区。同一个模型，用 Llama 系列的 chat template，和用基础的 “You are a helpful assistant” 模板，输出风格完全不同。有些模型在训练时对特定 chat template 做了大量对齐，换模板后指令遵循能力会明显下降。

评测时一定要检查两件事：

• 是否使用模型自带的 chat template。
• 所有模型的系统提示词是否完全一致，或者是否各自使用了官方推荐提示词。

更推荐的做法是：先做一组“无系统提示词”的 baseline，再做一组“统一系统提示词”的对照测试。只给一个最终分数，很难判断模型在哪种模板下表现好。

3.3 few-shot 示例的选择

Few-shot 示例对模型能力的发挥有非常大的引导作用。示例的数量、顺序、格式、内容领域都会影响输出。

举例来说，同样评测代码生成，如果 few-shot 示例里给的是 Python 代码，模型更可能输出 Python；如果给的是 JSON，模型可能把输出格式也带偏。评测集设计者通常只提供题目，不会规定 few-shot 怎么选，所以很多榜单复现者在这里默认用了不同配置，结果自然不一致。

评测建议：要么所有模型都用 0-shot，要么给每个模型使用相同的固定 few-shot 示例集。示例的选择要基于评测集的官方说明，不要自行增删。

3.4 模型量化与精度

同一个模型，FP16 和 INT8 的实际表现有明显差异。量化会损失部分精度，尤其在数学推理、代码生成、长文本任务中。你在一张 3090 上跑 FP16 的模型，和在消费级显卡上跑 INT4 的模型，分数很可能不一样。

如果评测目的是“对比模型能力”，应该尽量使用同一种精度和推理引擎。如果评测目的是“模拟用户真实使用环境”，那可以设置多档量化配置分别对比，但不要混在一个榜单里。

3.5 推理后端与框架版本

同一个模型，用 Transformers 加载、用 vLLM 加载、用 llama.cpp 加载，生成结果都可能不同。原因在于这些后端的采样实现、算子精度、注意力实现并不完全一致。框架版本迭代也会影响结果，比如 Transformers 4.38 和 4.45 之间可能修改了某些模型实现细节。

所以复现别人榜单时，即使拿到了同样的评测代码，如果 transformers 版本对不上，结果也可能对不上。发布评测结果时，应该把框架版本写清楚，比如 transformers==4.45.2、vllm==0.6.3.post1。

3.6 解码长度与停止词

很多评测任务里，模型生成的答案过长或过短都会影响打分。如果停止词设置不当，模型可能把答案继续往下补，把多余内容也算进回答里。如果是代码题，截断位置不同可能导致语法不完整，直接判零分。

评测时应根据数据集要求设置 max_tokens，并统一停止词。如果评测集本身没有指定，建议做一轮“最大输出长度分布”分析，把异常长输出和异常短输出先筛出来看一遍。

3.7 硬件环境与并发推理

这部分影响相对小，但在大规模评测中不可忽略。GPU 型号不同，float16 的精度结果可能有微小误差；并发推理时，vLLM 连续批处理可能导致部分请求排队，输出在语义层面保持一致，但个别请求可能因为上下文长度限制被截断。如果评测脚本对超时、重试、失败请求的处理规则不同，也会影响最终分数。

3.8 评测集预处理与答案匹配

还有一个容易被忽略的坑：评测集里的换行、空格、大小写、HTML 标签、LaTeX 公式是否被规范化。答案匹配阶段，如果采用字符串精确匹配，两个模型可能因为格式问题差出几个点；如果用大模型评分，评分 prompt 的不同更是直接影响分数。

4. 复现评测结果时的标准操作流程

理解了配置变量的影响，下一步是建立一套可复现的评测流程。不管你是要复现公开榜单，还是自己对比多个模型，都应该按下面这个流程来做。

4.1 锁定配置

先写一份评测配置清单，把下面这些项写死：

{ "model": "model-a", "model_path": "/data/models/model-a", "dtype": "float16", "backend": "vllm", "backend_version": "0.6.3.post1", "sampling_params": { "temperature": 0.0, "top_p": 1.0, "top_k": -1, "repetition_penalty": 1.0, "max_tokens": 1024, "stop": null }, "prompt_template": "chat-template-default", "system_prompt": "", "few_shot": 0, "dataset": "example-eval-set", "dataset_version": "2025-01-01", "shuffle_seed": 42 }

这份配置有两个作用：一是保证自己跑出来的结果可以复现，二是将来对比其他模型时，除了 model 字段，其他字段必须保持一致。

4.2 编写评测脚本

这里给出一个通用的评测流程脚本，核心逻辑是：加载配置、批量请求模型、保存原始输出、离线评分。

import json import time from openai import OpenAI # 以 OpenAI 兼容接口为例，实际使用需替换 base_url 和 model 名称 client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) def generate(prompt, config): response = client.chat.completions.create( model=config["model"], messages=[ {"role": "system", "content": config["system_prompt"]}, {"role": "user", "content": prompt} ], temperature=config["sampling_params"]["temperature"], top_p=config["sampling_params"]["top_p"], max_tokens=config["sampling_params"]["max_tokens"], stop=config["sampling_params"]["stop"] ) return response.choices[0].message.content def load_questions(path): with open(path, "r", encoding="utf-8") as f: return json.load(f) def run_eval(config, questions, output_path): results = [] for i, item in enumerate(questions): try: answer = generate(item["question"], config) results.append({ "id": item.get("id", i), "question": item["question"], "answer": answer, "reference": item.get("reference", "") }) except Exception as e: results.append({ "id": item.get("id", i), "question": item["question"], "answer": "", "reference": item.get("reference", ""), "error": str(e) }) # 防止请求频率过高，实际并发场景可去掉这行 time.sleep(0.2) with open(output_path, "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) if __name__ == "__main__": cfg = json.load(open("eval_config.json", encoding="utf-8")) questions = load_questions("questions.jsonl") run_eval(cfg, questions, f"eval_results/{cfg['model']}.json")

实际使用时要根据你的接口路径、模型名、评测集格式调整。核心原则是：原始输出先保存下来，评分单独做，不要把生成和评分混在一起。

4.3 安装依赖

如果你用 vLLM 部署本地推理服务，可以这样创建虚拟环境并安装依赖：

python -m venv eval_env source eval_env/bin/activate pip install --upgrade pip pip install vllm==0.6.3.post1 pip install openai pip install transformers==4.45.2

如果你使用的是第三方推理服务，把 vllm 替换成对应的 SDK 即可。注意不要在一个已经装了很多包的环境里直接装新包，版本冲突会非常耗时。

4.4 评分与记录

评分环节建议独立于生成环节。生成结果保存后，再用规则评分或模型评分脚本统一处理。这样模型生成的中间结果不会被评分逻辑污染，也方便后续换评分方式重新算分。

5. 用“配置矩阵”评估排名稳定性

只跑一组配置，然后直接说“A 比 B 强”，是很危险的结论。正确做法是设计一个配置矩阵，把关键变量分别调整，看排名是否稳定。

5.1 配置矩阵设计

比如你想考察温度和系统提示词的影响，可以设计这样一个矩阵：

每个模型都跑这 6 组配置，最后得到的不只是一条排名，而是一组排名。如果模型 X 在全部 6 组配置下都排在模型 Y 前面，那结论就比较可靠。如果只在某一组配置下领先，差距又很小，那就要警惕排名是配置的产物。

5.2 多轮采样与方差统计

即使固定了配置，LLM 生成仍可能有随机性。温度大于 0 时更明显。建议每个配置至少跑 3 轮，计算平均分和标准差。代码逻辑可以参考下面这样：

import json import statistics data = [ {"config": "A", "model": "model-x", "score": 72.5}, {"config": "A", "model": "model-x", "score": 73.1}, {"config": "A", "model": "model-x", "score": 71.8}, ] grouped = {} for row in data: key = (row["config"], row["model"]) grouped.setdefault(key, []).append(row["score"]) summary = [] for key, scores in grouped.items(): summary.append({ "config": key[0], "model": key[1], "mean": round(statistics.mean(scores), 2), "stdev": round(statistics.stdev(scores), 2) if len(scores) > 1 else 0.0, }) for s in sorted(summary, key=lambda x: (x["config"], -x["mean"])): print(s)

跑完这个统计，你能更清楚地看到：哪些模型的分数非常稳定，哪些模型分数高但方差大。方差大的模型，一次评测的排名可能只是运气好。

5.3 查看单题差异

只看平均分还不够。把每道题的得分拉出来看，找出“关键翻转题”：也就是模型 X 和模型 Y 得分差距最大的题目。如果翻转集中在某一个题号区间，可能说明评测集的题目顺序、难度分布对结果有影响，或者模型对题目的提示词格式存在系统性偏好。

6. 批量评测任务的工程化改造

当你真正开始评测 10 个模型、每个模型跑 6 组配置，就不再是“跑个脚本”那么简单了，而是一个批量任务工程问题。

6.1 任务拆分与队列

建议把评测过程拆成三个层级：

• 模型配置层：每个模型 + 配置组合作为一个 task。
• 请求层：每个 question 作为一个 item。
• 输出层：所有原始输出落盘，失败请求记录日志。

可以用一个简单的队列脚本控制并发，避免一次性把 1000 个请求打进来把服务打死。

# 用 GNU parallel 做并发控制，每个任务单线程，8 并发 cat task_list.txt | parallel -j 8 'python run_single_eval.py --model {} --config eval_config.json'

如果你用 Python 写任务调度，也可以用 concurrent.futures 或 Celery。但注意评测任务大多是 IO 密集型加少量 CPU 解析，最简单的方式就是文件队列加并发控制。

6.2 失败重试与断点续跑

评测任务最怕跑到一半崩掉，前面的结果全部白费。所以在脚本里一定要做断点续跑。一个简单做法是：输出文件以模型名和配置编号命名，生成前先检查输出文件是否已存在，存在则跳过。

import os def already_done(output_path): return os.path.exists(output_path) and os.path.getsize(output_path) > 0 if already_done(output_path): print("skip", output_path) else: run_eval(cfg, questions, output_path)

这样即使进程中断，重启后只需要重新跑还没完成的任务。

6.3 API 调用超时与频率控制

如果通过 HTTP 接口调用模型服务，需要处理超时、连接失败、限流等问题。建议在请求外层加上超时和重试：

import requests def call_with_retry(url, payload, max_retries=3, timeout=120): for attempt in range(max_retries): try: resp = requests.post(url, json=payload, timeout=timeout) resp.raise_for_status() return resp.json() except Exception as e: print(f"attempt {attempt + 1} failed: {e}") time.sleep(2 ** attempt) return None

重试时使用指数退避，不要脚本一报错就疯狂重试，造成服务端压力。

6.4 数据安全与权限边界

批量评测时要注意：不要把公司内部数据、用户隐私数据、未授权文本直接通过外部接口发送。如果是本地模型还好，如果是远程 API 服务，需要先确认数据权限和使用边界。评测产生的中间结果文件，也要设置好访问权限，不要放在公共可读目录。

7. 资源占用与性能观察

评测模型的资源占用很难用一个固定数字描述，因为不同模型、不同精度、不同推理引擎差异很大。但这不意味着观察资源占用没有方法。

7.1 本地推理场景

如果模型部署在本地 GPU 上，用 nvidia-smi 持续记录显存和利用率：

nvidia-smi --query-gpu=index,memory.used,utilization.gpu,temperature.gpu --format=csv -l 5

这里重点看两个指标：

• 显存峰值：决定这块 GPU 能不能跑起这个模型和评测上下文。
• 显存余量：如果剩余显存过小，连续批处理时可能出现 OOM。

启动评测前先单独做一次“空转加载”测试，看模型加载后占用多少显存，再叠加评测的上下文长度，确认不会 OOM。

7.2 API 服务场景

如果模型部署成 OpenAI 兼容服务，还需要观察每个请求的耗时、吞吐和排队情况。可以简单打印每个请求的耗时：

start = time.time() answer = generate(prompt, config) elapsed = time.time() - start print(f"question {i}: {elapsed:.2f}s, answer length={len(answer)}")

如果单个请求耗时过长，通常有两个原因：输入上下文太长导致 prefilled 阶段耗时增加，或服务端并发排队严重、GPU 计算资源被打满。

7.3 如何降低评测开销

降低评测成本的方法比较直接：

• 降低多轮重复次数：先跑 1 轮粗筛，选出有潜力的模型，再对前几名跑 3 轮确认。
• 控制输入输出长度：评测集如果包含超长文档，优先做摘要式评测，而不是全量输入。
• 使用更小的评测子集：先跑一个代表性的子集估算分数，再全量跑。
• 合理设置并发：并发太低浪费 GPU，并发太高容易 OOM，通常从 1 逐步往上调。

8. 常见问题与排查方法

9. 最佳实践：发布或参考模型榜单前

先说明一下边界：评测中如果涉及图像、语音、视频、人脸、声音等素材，必须确认素材来源合法，已获得授权；评测数据如果包含未公开内容，要考虑隐私和合规风险。这里更多是从工程角度给出自检清单。

如果你打算发布一份模型对比结果，建议先做一次自检：

• 是否记录了模型版本、量化精度、推理框架版本？
• 是否固定了采样参数，并说明温度、top_p、max_tokens？
• 是否统一了系统提示词和聊天模板？
• 是否发布了评测数据集的版本和预处理方式？
• 是否报告了多次采样的均值和方差，而不是只给一个最高分？
• 是否对比了几组配置下的排名稳定性，而不是只跑一组默认配置？

如果你只是参考别人的榜单，也要先看对方是否提供了上述信息。如果没有，把它当成一个“特定配置下的参考结果”，不要当成绝对能力排名。

另外一个容易被忽略的问题是：评测集本身的版权和使用条款。如果你要发布评测结论，尤其是把评测集内容作为示例输出展示，需要确认是否允许。评测完的中间文件如果包含原始输入，也要妥善保管。

10. 总结与下一步

回到开头那句话：无中立基准。模型排行榜的分数，本质上是“模型能力、评测配置、评测集特性、随机性”四者的混合产物。今天这篇文章里，最值得你行动的一点是：以后评测模型时，不要只跑一组默认配置就下结论，至少把温度、系统提示词、few-shot 这三个变量各测一遍，看看排名动不动。

先验证的第一步是 temperature 和提示词模板对得分的影响，这是最容易复现、也最容易让人信服的“配置漂移”实验。最容易踩的坑是框架版本不一致和量化精度混用，这两个问题经常让同一个人在不同时间跑出两个互相矛盾的结果。

下一步可以做的扩展方向是：把你自己的评测配置整理成一份标准配置文件，像管理代码一样管理评测配置，每次评测强制加载同一份配置。如果能做到“分数可复现、配置可追溯”，那你手里的榜单排名才会真正有参考价值。

建议收藏备用。后续如果你也在做模型评测，遇到“榜单复现不了”“排名不稳”的问题，可以按这篇文章的思路重新把配置梳理一遍。