榜单上明明排名第一的模型买回来自己一测结果完全对不上号。这个问题在过去一年里被反复讨论过同一个模型在不同的榜单、不同的评测脚本、不同的推理配置下排名能波动好几个身位。很多人第一反应是“榜单有水分”但更准确的说法应该是模型评测不存在一个真正中立的基准。这次我们就把这个问题拆开聊。所谓“无中立基准”不是在否定所有模型评测的价值而是要说明一个事实任何一次模型排名都是在一堆具体配置约束下产生的局部结论。采样温度、系统提示词、few-shot 示例、量化精度、推理后端、解码参数、评测集版本任何一个变量变了排名都可能改写。这篇文章会从配置变量拆解、复现流程、配置矩阵设计、批量评测工程化、资源占用和排查方法几个角度展开帮你在面对模型榜单时判断“哪些结论能用哪些结论只是配置的产物”。如果你平时关注大模型评测、要做模型选型或者要自己搭一套可复现的评测流程这篇内容可以直接收藏。1. 核心结论速览维度说明核心观点模型排行榜不存在绝对中立基准排名结果是配置组合下的局部结论最容易影响排名的配置采样参数、提示词模板、few-shot 示例、量化精度、推理后端、解码长度排名波动来源配置差异大于模型真实能力差异时排名会被配置“绑架”复现榜单的正确方式锁定全部配置项记录评测环境多轮采样统计均值和方差推荐做法用配置矩阵观察排名稳定性而不是只跑一组默认参数适合读者模型选型人员、AI 应用开发者、评测脚本维护者、关注榜单的算法工程师安全提醒评测数据需要确认版权和隐私边界接口评测要注意密钥管理和合规使用2. 为什么不存在所谓“中立基准”“中立基准”这个说法听起来很合理找一个公开数据集把模型都放上去跑按分数排序谁分高谁就强。但实际操作过评测的人都知道这个流程里的每一个环节都需要做选择而每一个选择都有可能影响最终排名。先看最简单的几个问题输出用贪婪搜索还是采样温度设 0 还是 0.7top_p 用默认值还是自定义这些问题看起来只是“推理参数”但它们会直接改变模型生成的内容。对多项选择题、数学题、代码题这类有标准答案的评测集温度变化可能只会造成小幅波动但对开放式问答、摘要生成、偏好类评测采样参数一变模型输出差异会非常大。再往上还有提示词层面的选择。同一个评测集用不加修饰的原始问题和加一段“Let‘s think step by step”的指令模型的得分往往不同。有些模型已经针对某种指令格式做了强化换一种格式成绩就下滑。这本质上不是模型变弱了而是评测配置偏离了模型的“舒适区”。从更宏观的角度看评测集本身也不中立。公开榜单依赖的测试集是否干净、有没有被训练数据污染、题目难度分布是否均匀、评分是用规则还是用大模型当裁判这些因素叠加在一起导致榜单分数很难作为模型能力的精确刻度。所以准确的说法是模型评测结果 模型能力 评测配置 评测集特性 随机性。榜单只展示最终分数不展示背后的配置组合排名自然会出现“换个配置就翻转”的现象。3. 最容易导致排名漂移的配置变量下面按影响程度从高到低拆解。这些配置不是理论上的“可能影响”而是实际评测中经常直接改变名次的关键变量。3.1 采样参数temperature、top_p、top_k、repetition_penalty生成阶段最关键的参数是温度。温度越低输出的随机性越小温度越高模型越容易“发挥”但也越容易跑偏。评测中如果所有模型都用默认温度跑可能对某些模型有利对另一些模型不利。参数影响方式评测时建议temperature温度升高长尾输出概率变大开放式任务得分波动明显固定为 0 或 0.2降低随机性top_p控制候选词累积概率影响输出多样性固定为 0.9 或 1.0所有模型保持一致top_k限制候选词数量影响生成稳定性和多样性可选但必须统一repetition_penalty影响重复率对代码和长文本评分有影响统一设置为 1.0 或模型默认值max_tokens截断会影响答案完整性导致漏答设置足够长确认所有模型都能输出完整答案这里要说一个关键点评测时最怕的是“每个模型都用自己官方推荐的参数”。商业模型文档里给的默认参数往往经过调优开源模型的默认参数可能没有那么讲究。对比时必须统一参数否则你比较的不是模型能力而是“模型 官方调参”的组合效果。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 版本对不上结果也可能对不上。发布评测结果时应该把框架版本写清楚比如 transformers4.45.2、vllm0.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_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) def generate(prompt, config): response client.chat.completions.create( modelconfig[model], messages[ {role: system, content: config[system_prompt]}, {role: user, content: prompt} ], temperatureconfig[sampling_params][temperature], top_pconfig[sampling_params][top_p], max_tokensconfig[sampling_params][max_tokens], stopconfig[sampling_params][stop] ) return response.choices[0].message.content def load_questions(path): with open(path, r, encodingutf-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, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: cfg json.load(open(eval_config.json, encodingutf-8)) questions load_questions(questions.jsonl) run_eval(cfg, questions, feval_results/{cfg[model]}.json)实际使用时要根据你的接口路径、模型名、评测集格式调整。核心原则是原始输出先保存下来评分单独做不要把生成和评分混在一起。4.3 安装依赖如果你用 vLLM 部署本地推理服务可以这样创建虚拟环境并安装依赖python -m venv eval_env source eval_env/bin/activate pip install --upgrade pip pip install vllm0.6.3.post1 pip install openai pip install transformers4.45.2如果你使用的是第三方推理服务把 vllm 替换成对应的 SDK 即可。注意不要在一个已经装了很多包的环境里直接装新包版本冲突会非常耗时。4.4 评分与记录评分环节建议独立于生成环节。生成结果保存后再用规则评分或模型评分脚本统一处理。这样模型生成的中间结果不会被评分逻辑污染也方便后续换评分方式重新算分。5. 用“配置矩阵”评估排名稳定性只跑一组配置然后直接说“A 比 B 强”是很危险的结论。正确做法是设计一个配置矩阵把关键变量分别调整看排名是否稳定。5.1 配置矩阵设计比如你想考察温度和系统提示词的影响可以设计这样一个矩阵配置编号temperaturesystem_promptfew-shotA0.0无0-shotB0.0通用助手提示词0-shotC0.3无0-shotD0.3通用助手提示词0-shotE0.7无3-shotF0.7通用助手提示词3-shot每个模型都跑这 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, keylambda 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_retries3, timeout120): for attempt in range(max_retries): try: resp requests.post(url, jsonpayload, timeouttimeout) resp.raise_for_status() return resp.json() except Exception as e: print(fattempt {attempt 1} failed: {e}) time.sleep(2 ** attempt) return None重试时使用指数退避不要脚本一报错就疯狂重试造成服务端压力。6.4 数据安全与权限边界批量评测时要注意不要把公司内部数据、用户隐私数据、未授权文本直接通过外部接口发送。如果是本地模型还好如果是远程 API 服务需要先确认数据权限和使用边界。评测产生的中间结果文件也要设置好访问权限不要放在公共可读目录。7. 资源占用与性能观察评测模型的资源占用很难用一个固定数字描述因为不同模型、不同精度、不同推理引擎差异很大。但这不意味着观察资源占用没有方法。7.1 本地推理场景如果模型部署在本地 GPU 上用 nvidia-smi 持续记录显存和利用率nvidia-smi --query-gpuindex,memory.used,utilization.gpu,temperature.gpu --formatcsv -l 5这里重点看两个指标显存峰值决定这块 GPU 能不能跑起这个模型和评测上下文。显存余量如果剩余显存过小连续批处理时可能出现 OOM。启动评测前先单独做一次“空转加载”测试看模型加载后占用多少显存再叠加评测的上下文长度确认不会 OOM。7.2 API 服务场景如果模型部署成 OpenAI 兼容服务还需要观察每个请求的耗时、吞吐和排队情况。可以简单打印每个请求的耗时start time.time() answer generate(prompt, config) elapsed time.time() - start print(fquestion {i}: {elapsed:.2f}s, answer length{len(answer)})如果单个请求耗时过长通常有两个原因输入上下文太长导致 prefilled 阶段耗时增加或服务端并发排队严重、GPU 计算资源被打满。7.3 如何降低评测开销降低评测成本的方法比较直接降低多轮重复次数先跑 1 轮粗筛选出有潜力的模型再对前几名跑 3 轮确认。控制输入输出长度评测集如果包含超长文档优先做摘要式评测而不是全量输入。使用更小的评测子集先跑一个代表性的子集估算分数再全量跑。合理设置并发并发太低浪费 GPU并发太高容易 OOM通常从 1 逐步往上调。8. 常见问题与排查方法问题现象可能原因排查方式解决方案复现的榜单分数和官方结果差很多采样参数、系统提示词、few-shot 不一致对照官方评测脚本的 config 和 prompt 模板严格复现官方配置不要用默认值不同推理框架结果不一致后端实现、算子精度、采样逻辑有差异固定同一个后端记录框架版本评测时统一使用 vLLM 或 Transformers量化模型分数明显低量化精度损失或量化后的采样结果漂移对比 FP16 与 INT8/INT4 分数明确标注量化精度不要把不同精度混在一起排名温度设为 0 仍出现随机结果推理框架未完全禁用采样或算子存在不确定性检查采样参数是否真正生效设置 temperature0 的同时确认 top_p1.0、top_k-1显存不足模型上下文超过可用显存运行 nvidia-smi 观察启动评测前后的显存变化降低并发、减小 max_token、换更小精度API 调用超时输入过长或服务端排队打印单请求耗时观察服务端负载缩短输入、增加超时时间、降低并发批量评测中断网络波动或服务端崩溃记录失败日志输出文件按模型配置拆分设计断点续跑机制模型分数方差很大温度过高、评测集题目少、评分 prompt 不稳定多轮采样计算标准差温度调低增加题目数固定评分 prompt评测集疑似被污染模型在训练阶段见过测试题抽查高分题的输出观察是否具有记忆特征换用新出的测试集或预留未见过的自建题目9. 最佳实践发布或参考模型榜单前先说明一下边界评测中如果涉及图像、语音、视频、人脸、声音等素材必须确认素材来源合法已获得授权评测数据如果包含未公开内容要考虑隐私和合规风险。这里更多是从工程角度给出自检清单。如果你打算发布一份模型对比结果建议先做一次自检是否记录了模型版本、量化精度、推理框架版本是否固定了采样参数并说明温度、top_p、max_tokens是否统一了系统提示词和聊天模板是否发布了评测数据集的版本和预处理方式是否报告了多次采样的均值和方差而不是只给一个最高分是否对比了几组配置下的排名稳定性而不是只跑一组默认配置如果你只是参考别人的榜单也要先看对方是否提供了上述信息。如果没有把它当成一个“特定配置下的参考结果”不要当成绝对能力排名。另外一个容易被忽略的问题是评测集本身的版权和使用条款。如果你要发布评测结论尤其是把评测集内容作为示例输出展示需要确认是否允许。评测完的中间文件如果包含原始输入也要妥善保管。10. 总结与下一步回到开头那句话无中立基准。模型排行榜的分数本质上是“模型能力、评测配置、评测集特性、随机性”四者的混合产物。今天这篇文章里最值得你行动的一点是以后评测模型时不要只跑一组默认配置就下结论至少把温度、系统提示词、few-shot 这三个变量各测一遍看看排名动不动。先验证的第一步是 temperature 和提示词模板对得分的影响这是最容易复现、也最容易让人信服的“配置漂移”实验。最容易踩的坑是框架版本不一致和量化精度混用这两个问题经常让同一个人在不同时间跑出两个互相矛盾的结果。下一步可以做的扩展方向是把你自己的评测配置整理成一份标准配置文件像管理代码一样管理评测配置每次评测强制加载同一份配置。如果能做到“分数可复现、配置可追溯”那你手里的榜单排名才会真正有参考价值。建议收藏备用。后续如果你也在做模型评测遇到“榜单复现不了”“排名不稳”的问题可以按这篇文章的思路重新把配置梳理一遍。
榜单上明明排名第一的模型买回来自己一测结果完全对不上号。这个问题在过去一年里被反复讨论过同一个模型在不同的榜单、不同的评测脚本、不同的推理配置下排名能波动好几个身位。很多人第一反应是“榜单有水分”但更准确的说法应该是模型评测不存在一个真正中立的基准。这次我们就把这个问题拆开聊。所谓“无中立基准”不是在否定所有模型评测的价值而是要说明一个事实任何一次模型排名都是在一堆具体配置约束下产生的局部结论。采样温度、系统提示词、few-shot 示例、量化精度、推理后端、解码参数、评测集版本任何一个变量变了排名都可能改写。这篇文章会从配置变量拆解、复现流程、配置矩阵设计、批量评测工程化、资源占用和排查方法几个角度展开帮你在面对模型榜单时判断“哪些结论能用哪些结论只是配置的产物”。如果你平时关注大模型评测、要做模型选型或者要自己搭一套可复现的评测流程这篇内容可以直接收藏。1. 核心结论速览维度说明核心观点模型排行榜不存在绝对中立基准排名结果是配置组合下的局部结论最容易影响排名的配置采样参数、提示词模板、few-shot 示例、量化精度、推理后端、解码长度排名波动来源配置差异大于模型真实能力差异时排名会被配置“绑架”复现榜单的正确方式锁定全部配置项记录评测环境多轮采样统计均值和方差推荐做法用配置矩阵观察排名稳定性而不是只跑一组默认参数适合读者模型选型人员、AI 应用开发者、评测脚本维护者、关注榜单的算法工程师安全提醒评测数据需要确认版权和隐私边界接口评测要注意密钥管理和合规使用2. 为什么不存在所谓“中立基准”“中立基准”这个说法听起来很合理找一个公开数据集把模型都放上去跑按分数排序谁分高谁就强。但实际操作过评测的人都知道这个流程里的每一个环节都需要做选择而每一个选择都有可能影响最终排名。先看最简单的几个问题输出用贪婪搜索还是采样温度设 0 还是 0.7top_p 用默认值还是自定义这些问题看起来只是“推理参数”但它们会直接改变模型生成的内容。对多项选择题、数学题、代码题这类有标准答案的评测集温度变化可能只会造成小幅波动但对开放式问答、摘要生成、偏好类评测采样参数一变模型输出差异会非常大。再往上还有提示词层面的选择。同一个评测集用不加修饰的原始问题和加一段“Let‘s think step by step”的指令模型的得分往往不同。有些模型已经针对某种指令格式做了强化换一种格式成绩就下滑。这本质上不是模型变弱了而是评测配置偏离了模型的“舒适区”。从更宏观的角度看评测集本身也不中立。公开榜单依赖的测试集是否干净、有没有被训练数据污染、题目难度分布是否均匀、评分是用规则还是用大模型当裁判这些因素叠加在一起导致榜单分数很难作为模型能力的精确刻度。所以准确的说法是模型评测结果 模型能力 评测配置 评测集特性 随机性。榜单只展示最终分数不展示背后的配置组合排名自然会出现“换个配置就翻转”的现象。3. 最容易导致排名漂移的配置变量下面按影响程度从高到低拆解。这些配置不是理论上的“可能影响”而是实际评测中经常直接改变名次的关键变量。3.1 采样参数temperature、top_p、top_k、repetition_penalty生成阶段最关键的参数是温度。温度越低输出的随机性越小温度越高模型越容易“发挥”但也越容易跑偏。评测中如果所有模型都用默认温度跑可能对某些模型有利对另一些模型不利。参数影响方式评测时建议temperature温度升高长尾输出概率变大开放式任务得分波动明显固定为 0 或 0.2降低随机性top_p控制候选词累积概率影响输出多样性固定为 0.9 或 1.0所有模型保持一致top_k限制候选词数量影响生成稳定性和多样性可选但必须统一repetition_penalty影响重复率对代码和长文本评分有影响统一设置为 1.0 或模型默认值max_tokens截断会影响答案完整性导致漏答设置足够长确认所有模型都能输出完整答案这里要说一个关键点评测时最怕的是“每个模型都用自己官方推荐的参数”。商业模型文档里给的默认参数往往经过调优开源模型的默认参数可能没有那么讲究。对比时必须统一参数否则你比较的不是模型能力而是“模型 官方调参”的组合效果。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 版本对不上结果也可能对不上。发布评测结果时应该把框架版本写清楚比如 transformers4.45.2、vllm0.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_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) def generate(prompt, config): response client.chat.completions.create( modelconfig[model], messages[ {role: system, content: config[system_prompt]}, {role: user, content: prompt} ], temperatureconfig[sampling_params][temperature], top_pconfig[sampling_params][top_p], max_tokensconfig[sampling_params][max_tokens], stopconfig[sampling_params][stop] ) return response.choices[0].message.content def load_questions(path): with open(path, r, encodingutf-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, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: cfg json.load(open(eval_config.json, encodingutf-8)) questions load_questions(questions.jsonl) run_eval(cfg, questions, feval_results/{cfg[model]}.json)实际使用时要根据你的接口路径、模型名、评测集格式调整。核心原则是原始输出先保存下来评分单独做不要把生成和评分混在一起。4.3 安装依赖如果你用 vLLM 部署本地推理服务可以这样创建虚拟环境并安装依赖python -m venv eval_env source eval_env/bin/activate pip install --upgrade pip pip install vllm0.6.3.post1 pip install openai pip install transformers4.45.2如果你使用的是第三方推理服务把 vllm 替换成对应的 SDK 即可。注意不要在一个已经装了很多包的环境里直接装新包版本冲突会非常耗时。4.4 评分与记录评分环节建议独立于生成环节。生成结果保存后再用规则评分或模型评分脚本统一处理。这样模型生成的中间结果不会被评分逻辑污染也方便后续换评分方式重新算分。5. 用“配置矩阵”评估排名稳定性只跑一组配置然后直接说“A 比 B 强”是很危险的结论。正确做法是设计一个配置矩阵把关键变量分别调整看排名是否稳定。5.1 配置矩阵设计比如你想考察温度和系统提示词的影响可以设计这样一个矩阵配置编号temperaturesystem_promptfew-shotA0.0无0-shotB0.0通用助手提示词0-shotC0.3无0-shotD0.3通用助手提示词0-shotE0.7无3-shotF0.7通用助手提示词3-shot每个模型都跑这 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, keylambda 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_retries3, timeout120): for attempt in range(max_retries): try: resp requests.post(url, jsonpayload, timeouttimeout) resp.raise_for_status() return resp.json() except Exception as e: print(fattempt {attempt 1} failed: {e}) time.sleep(2 ** attempt) return None重试时使用指数退避不要脚本一报错就疯狂重试造成服务端压力。6.4 数据安全与权限边界批量评测时要注意不要把公司内部数据、用户隐私数据、未授权文本直接通过外部接口发送。如果是本地模型还好如果是远程 API 服务需要先确认数据权限和使用边界。评测产生的中间结果文件也要设置好访问权限不要放在公共可读目录。7. 资源占用与性能观察评测模型的资源占用很难用一个固定数字描述因为不同模型、不同精度、不同推理引擎差异很大。但这不意味着观察资源占用没有方法。7.1 本地推理场景如果模型部署在本地 GPU 上用 nvidia-smi 持续记录显存和利用率nvidia-smi --query-gpuindex,memory.used,utilization.gpu,temperature.gpu --formatcsv -l 5这里重点看两个指标显存峰值决定这块 GPU 能不能跑起这个模型和评测上下文。显存余量如果剩余显存过小连续批处理时可能出现 OOM。启动评测前先单独做一次“空转加载”测试看模型加载后占用多少显存再叠加评测的上下文长度确认不会 OOM。7.2 API 服务场景如果模型部署成 OpenAI 兼容服务还需要观察每个请求的耗时、吞吐和排队情况。可以简单打印每个请求的耗时start time.time() answer generate(prompt, config) elapsed time.time() - start print(fquestion {i}: {elapsed:.2f}s, answer length{len(answer)})如果单个请求耗时过长通常有两个原因输入上下文太长导致 prefilled 阶段耗时增加或服务端并发排队严重、GPU 计算资源被打满。7.3 如何降低评测开销降低评测成本的方法比较直接降低多轮重复次数先跑 1 轮粗筛选出有潜力的模型再对前几名跑 3 轮确认。控制输入输出长度评测集如果包含超长文档优先做摘要式评测而不是全量输入。使用更小的评测子集先跑一个代表性的子集估算分数再全量跑。合理设置并发并发太低浪费 GPU并发太高容易 OOM通常从 1 逐步往上调。8. 常见问题与排查方法问题现象可能原因排查方式解决方案复现的榜单分数和官方结果差很多采样参数、系统提示词、few-shot 不一致对照官方评测脚本的 config 和 prompt 模板严格复现官方配置不要用默认值不同推理框架结果不一致后端实现、算子精度、采样逻辑有差异固定同一个后端记录框架版本评测时统一使用 vLLM 或 Transformers量化模型分数明显低量化精度损失或量化后的采样结果漂移对比 FP16 与 INT8/INT4 分数明确标注量化精度不要把不同精度混在一起排名温度设为 0 仍出现随机结果推理框架未完全禁用采样或算子存在不确定性检查采样参数是否真正生效设置 temperature0 的同时确认 top_p1.0、top_k-1显存不足模型上下文超过可用显存运行 nvidia-smi 观察启动评测前后的显存变化降低并发、减小 max_token、换更小精度API 调用超时输入过长或服务端排队打印单请求耗时观察服务端负载缩短输入、增加超时时间、降低并发批量评测中断网络波动或服务端崩溃记录失败日志输出文件按模型配置拆分设计断点续跑机制模型分数方差很大温度过高、评测集题目少、评分 prompt 不稳定多轮采样计算标准差温度调低增加题目数固定评分 prompt评测集疑似被污染模型在训练阶段见过测试题抽查高分题的输出观察是否具有记忆特征换用新出的测试集或预留未见过的自建题目9. 最佳实践发布或参考模型榜单前先说明一下边界评测中如果涉及图像、语音、视频、人脸、声音等素材必须确认素材来源合法已获得授权评测数据如果包含未公开内容要考虑隐私和合规风险。这里更多是从工程角度给出自检清单。如果你打算发布一份模型对比结果建议先做一次自检是否记录了模型版本、量化精度、推理框架版本是否固定了采样参数并说明温度、top_p、max_tokens是否统一了系统提示词和聊天模板是否发布了评测数据集的版本和预处理方式是否报告了多次采样的均值和方差而不是只给一个最高分是否对比了几组配置下的排名稳定性而不是只跑一组默认配置如果你只是参考别人的榜单也要先看对方是否提供了上述信息。如果没有把它当成一个“特定配置下的参考结果”不要当成绝对能力排名。另外一个容易被忽略的问题是评测集本身的版权和使用条款。如果你要发布评测结论尤其是把评测集内容作为示例输出展示需要确认是否允许。评测完的中间文件如果包含原始输入也要妥善保管。10. 总结与下一步回到开头那句话无中立基准。模型排行榜的分数本质上是“模型能力、评测配置、评测集特性、随机性”四者的混合产物。今天这篇文章里最值得你行动的一点是以后评测模型时不要只跑一组默认配置就下结论至少把温度、系统提示词、few-shot 这三个变量各测一遍看看排名动不动。先验证的第一步是 temperature 和提示词模板对得分的影响这是最容易复现、也最容易让人信服的“配置漂移”实验。最容易踩的坑是框架版本不一致和量化精度混用这两个问题经常让同一个人在不同时间跑出两个互相矛盾的结果。下一步可以做的扩展方向是把你自己的评测配置整理成一份标准配置文件像管理代码一样管理评测配置每次评测强制加载同一份配置。如果能做到“分数可复现、配置可追溯”那你手里的榜单排名才会真正有参考价值。建议收藏备用。后续如果你也在做模型评测遇到“榜单复现不了”“排名不稳”的问题可以按这篇文章的思路重新把配置梳理一遍。
