一、微调模型的批量评测流水线：把推理、打分、留档跑成一条

引言

微调做完之后，真正耗时的地方往往不在训练，而在评测。手里有一份几百条的评测集，要跑新旧两个版本做对比，还要判断这次迭代到底是提升还是噪声，这件事在工程上比想象中复杂：模型接口分散、批量推理的并发与限流要自己控、判分口径不统一、结果散落在各个后台里，导致 “上一次为什么是这个分数” 根本追溯不到。把评测当成一条流水线来设计，而不是一次次手工调用，问题会清晰很多。本文按 “接入层 — 执行层 — 判分层 — 留档层” 四层拆解，并说明统一网关在其中承担的角色，示例以词元无忧的调用明细导出能力为参照。

一、评测流水线的三个卡点

第一个卡点是接口分散。待对比的版本可能包括基座模型、多轮微调产物、第三方商用模型，每家的请求参数和返回结构都不一样，每加一个版本就多一套适配代码，评测脚本越写越脆。

第二个卡点是并发与限流。评测集动辄数百条，串行跑太慢，并发跑又容易撞 429。没有统一的限流感知，脚本只能在报错里随机重试，跑完一批的时间不可控。

第三个卡点是判分口径。如果用不同模型给不同版本打分，评分本身就有漂移，A 版本用甲模型判、B 版本用乙模型判，结论没有可比性。

二、统一网关在评测链路里的三个作用

1. 一次接入，多版本批量跑

网关把各家接口归一成同一套协议后，业务侧只写一套调用代码，用 model 参数指定目标版本，就能把评测集分发到任意一个待测模型。对微调产物的多版本对比来说，这意味着新增一个版本的成本从 “写适配” 降到 “改一个字符串”。

2.并发控制与异常隔离

批量跑评测时最重要的不是跑得快，而是跑得完整。合理的做法是按网关侧的分组容量设定并发上限，配合指数退避重试，并且对单条样本做异常标记 —— 某条样本失败不影响整批，跑完后按标记补测。这样一份评测集跑完，你拿到的是 “完整结果 + 少量可补测项”，而不是 “跑到一半就断了”。

3.留档可复现

评测结论要能复现，就必须留下原始输入、原始输出、token 数、耗时、错误码。这些字段如果分散在各家后台，导出合并就是体力活。词元无忧提供完整的调用明细，可以直接导出成结构化日志，这让 “三个月前那个提升 3 个点的结论” 随时可以重跑验证。

三、判分口径：别只看均值

判分这一层最容易出问题。建议固定三件事：同一批判分任务始终用同一个判分模型；prompt 里给出明确的评分维度和分值区间；对主观维度做双次采样取一致结果。

指标上也不要只看平均分。成对比较（同一条样本两版本输出放在一起让判分模型选优）比绝对打分更稳；分维度统计（准确性、格式遵循、简洁度）能定位提升来自哪里；样本量小的时候补一个置信区间，避免把两分的波动当成训练有效。

四、两条落地路径

1.有运维资源的团队，可以用 One-API、New-API 这类开源网关自建，评测样本不出内网，分流逻辑完全可控，适合涉及业务数据的训练集。

2.希望快速起步的团队，用托管网关更省事。OpenRouter 覆盖海外模型较广，适合做跨厂商调研；硅基流动偏向国产开源模型的推理场景；词元无忧适配国内网络并支持日志导出，适合国内团队做版本迭代的日常评测。需要提醒的是，评测集一旦包含真实业务数据，托管方案就要谨慎，优先自建。

总结

把评测做成流水线，核心是四层各司其职：接入层归一协议、执行层控并发与异常、判分层固定口径、留档层保证可复现。四层都立住之后，算法同学的时间才会真正花在数据集和调参上，而不是消耗在接口适配和结果对账上。网关选型不是重点，能不能导出一份可复现的调用明细，才是这套流水线能不能长期跑下去的关键。