要做多模型对比，最烦的不是选模型，是每接一家就要配一套 key、改一遍请求格式、再重写一次解析逻辑。OpenRouter 能把这一步压成一套接口，但它也带来新问题：同一条题发过去，各家返回的字段、参数支持、计费口径不完全一样，跑出来的差异到底算模型的还是算接入的？这篇按「先跑通再谈优化」的顺序走一遍，给能直接照做的排查顺序和对照清单。
要做多模型对比，最烦的其实不是选模型，是每接一家就要配一套 key、改一遍请求格式、再重写一次解析逻辑。模型一多，接入差异就开始混进评测结论里，最后你分不清跑出来的分数差到底是模型能力差，还是你哪家的参数填错了。
OpenRouter 能把这一步压成一套接口，但别指望它帮你把差异全抹平。同一条题发过去，各家返回的字段、参数支持、计费口径不完全一样。所以顺序应该是先跑通一条链路，再谈横评优化。下面按这个顺序走，给能直接照做的排查顺序和对照清单。
为什么横评先解决接入，而不是先挑模型
很多人的做法是先去榜单挑几个看起来强的模型，然后一个个接官方 API。接完两家就发现，光是维护 base_url 和错误码就够呛。更麻烦的是，接入层的不一致会悄悄污染结论：A 模型你用了默认温度，B 模型你手填了参数，跑出来 B 显得更稳，其实是参数不一样。
OpenRouter 的价值就在这儿——请求格式统一成一套，横评时变量只剩模型本身。但这层统一不是免费的，它不保证每家参数都生效、返回字段都齐全。所以你得单独验一遍，别把平台的行为当成模型的水平。
- 每接一家官方 API 就要维护一套 key、base_url 和错误码，模型越多，接入差异越容易混进评测结论里
- 把请求格式统一成一套后，横评时改的只剩模型标识这一行，结论才站得住
- 参数是否生效、返回字段是否齐全、限流与计费口径各家不同，这三件事要单独验，不能默认一致
第一次跑通，按这个顺序点一遍
第一次别上来就批量。先只发一条最短的纯文本请求，确认 key 有效、能拿到返回。这一步失败，后面全是白搭。常见的坑是 key 填在了环境变量里但没被读到，或者模型标识写成了官方名而不是平台认的写法，报错信息还挺含糊。
- 发一条最小请求纯文本、短输入、单模型。能拿到正常返回再往下走，拿不到就先查 key 和模型标识，别急着改代码逻辑。
- 把模型标识挪进配置别写死在请求代码里。横评时只改配置这一行，避免改漏、改错，也方便把用过的模型记进结果文件。
- 显式声明超时和重试别用默认值。某一家慢的时候，默认超时会把整批拖住，重试次数不写清，失败率就没法归因。
- 小样本跑一轮并打印结构把返回原样打印出来看一眼：字段名、错误信息、有没有被截断。结构跟你想的不一样，解析逻辑就得先改，别等到批量跑完才发现。
这四步跑完，你手里应该有一条能稳定返回的链路。这时候再往评测集里加题，变量才是可控的。
让每家拿到的题真的一样
横评最容易翻车的地方，是以为题一样、其实参数不一样。温度、最大输出长度这类参数，能显式传就显式传。默认值不一致，它就是个隐变量，你还找不出来。
还有一类更隐蔽：你传了某个参数，平台收下了，但那家模型不支持，于是被静默忽略。不报错，结果却变了。判断办法很土但有效——同一道题，改一次参数再跑一次，看结果有没有跟着变。没变化，说明这参数在这家身上没起作用。
| 要核对的项 | 怎么验 | 不通过怎么办 |
|---|---|---|
| 参数是否真正生效 | 同一题改一次参数重跑，看输出有无变化 | 没变化的参数在结果里标成「未生效」，别算进对比 |
| 返回字段是否齐全 | 打印原始返回，逐字段对一遍 | 缺字段就在解析层兜底，别让它变成空值参与评分 |
| 长文本与图片输入 | 拿一条样例单独试目标模型 | 接不了就在评测集里标掉，别算进平均分 |
| 错误信息格式 | 故意发一条错请求看返回 | 错误结构不同的，单独写解析分支，别混进质量分 |
每轮实际用的模型标识和参数，连同结果一起存下来。后面复盘时你才知道差异从哪来，不然只剩一句「感觉这个模型不太行」。
跑批之前先把钱和限流管住
横评比的是相对差异，不需要把每家的额度都打满。按 token 估个总量，先小样本跑一轮，记下实际用量再放大。凭感觉批量发，账单和限流会一起找上门。
给整批设一个预算上限，超了就停。这不是抠，是让评测能重复跑——一次跑太狠，第二次你就不敢跑了。遇到限流就用退避重试，并且把这类错误单独记一个失败桶。限流失败不是模型答不出来，混在一起看，失败率就没意义了。
- 先小样本记实际用量，再按比例放大，别直接按估算值批量发
- 整批设预算上限，触发就停，保留重跑余地
- 限流走退避重试，失败单独归类，不算进模型质量
- 单价和可用模型会变，投入之前去 /openrouter 和 /price-watch 核对当时的数字与变动记录
结果怎么读才不算白跑
拿到结果先别看质量分。先看失败率和平均延迟。这两项不稳，后面的分数全是噪声。某个模型失败率明显高，先回头查是不是超时设太短、是不是那家限流更严，别直接判它能力差。
同一模型隔一段时间再跑一次，波动大的就别拿来下结论。模型会更新，平台的路由和限流策略也会变，单次结果说明不了太多。
平台侧的影响要单独列：返回被截断、字段缺失、超时。这些不算模型能力差。想找个外部参照，可以去 /benchmarks 这类公开榜单交叉看一眼。差得远，先查自己的评测集和参数，别急着否定模型。
下一步把你要对比的模型和单价先摸一遍，再决定评测集的规模。站内的模型资料库和价格追踪页能省掉不少来回核对的时间。→常见问题
用 OpenRouter 做横评，结论能直接当官方模型的水平吗？
只能当参考。它统一了请求层，但路由、限流、上下文处理这些环节仍可能影响输出。想下强结论，挑出两三个候选后回到官方接口复跑同一套题，两边的结果差异在可接受范围内再采信。
同一条提示词发过去，各家返回格式不一样怎么办？
先固定只取最核心的那几个字段，把其余内容丢掉，别为了兼容某家特例去写分支。格式差异大的模型单独记一笔，看是平台层的问题还是模型本身输出习惯的问题，再决定要不要留在评测集里。
跑多少条样本才够判断一个模型行不行？
没有固定数。先用少量样本看失败率和结果方差，方差大就加量，方差小就保持。关键是每组样本都要人工抽看几条，确认自动打分没有把明显错的判成对，样本多但判错等于白跑。
