用OpenRouter构建AI模型评测流水线：两小时搞定十款新模型

当Descript这种量级的音视频创作团队愿意把“评测新模型”的流程从一周压缩到两小时这件事本身就值得好好拆一拆。我一直在做AI应用的工程化常年跟模型评测打拉锯战看到这个标题的时候第一反应是他们终于找到正确的路了。用OpenRouter做统一接入把评测流程彻底流水线化这听起来不复杂但真正落地过的人知道坑全藏在细节里。这篇文章我尽量把整个方案还原得完整可复现从为什么选OpenRouter、评测维度怎么设计到脚本怎么写、并发怎么控、结果怎么判最后再把你一定会遇到的几个坑提前拿出来晾一晾。1. 为什么Descript需要把模型评测跑成“流水线”1.1 背景Descript是做什么的为什么它要频繁评测新模型Descript是干什么的简单说就是做音视频编辑工具的但它的核心卖点是“像编辑文档一样编辑视频”。你剪掉一段语音里的某个词画面和字幕会自动跟着对齐你输入一段文字它能生成主播声音。这些功能背后全是AI模型而且是语音理解、音频生成、文本推理、字幕对齐、内容改写等多条模型的混合链路。这类产品的特殊性在于任何一个环节换一个模型最终用户体验都会变。有些模型在标准测试集上跑分很漂亮但一放到真实录音素材上就开始胡说有些模型响应快但格式乱有些模型便宜到白送但指令理解差一截。所以Descript整个团队对“新模型出现”这件事极其敏感GPT、Claude、Llama、Mistral每隔一两周就有新版本冒出来他们需要快速判断“这个新模型能不能进我的某个管线”。以前的做法很有代表性也很有问题每周花一天时间把当周新出的模型手工接入各个评测脚本逐个跑测试集再把结果粘贴到表格里等团队会议时人工讨论。跑到中途如果某个模型API参数不兼容还要现查文档改代码。整个过程下来一个模型从拿到API Key到得出可决策的结论往往要两三天如果模型多一周就没了。而且这种流程里人参与得越多结果越容易出错有人忘了加temperature参数有人把系统提示词写错版本评测结论的可信度反而低。1.2 旧流程一周慢在哪新流程目标是什么旧流程慢的原因其实不是“跑测试”本身慢而是分散在大量隐性环节里。我拆开来看每个模型厂商的API格式都不同接入一个新模型要重新阅读文档、写适配代码、调参数。很多小厂商的新模型不提供稳定的测试环境需要团队内部人工申请Key、配额度、等审核。评测用例散落在各个开发者的本地脚本里没有一个统一的基准集跑出来的结果没法横向对比。判断结果靠人工看一个模型输出几十个case逐条读下来再总结优劣势时间全耗在这上面。每次评测环境都不一样依赖库版本、API超时时间、重试策略不统一导致这周测的结果下周无法复现。新流程的目标很简单任何新模型出现后只做一次API Key配置然后按一个按钮或者跑一条命令自动化完成“拉起评测集→并发调用→自动判分→输出对比报告”的全链路。从接入到拿到可决策报告整体控制在两小时以内。这个目标意味着整个流程里没有一个环节依赖人工逐条阅读输出所有判分工作都要交给代码和裁判模型来做。1.3 OpenRouter在方案中的位置——统一网关的价值OpenRouter这个平台在方案里的角色可以粗暴理解成“模型API的聚合路由器”。你只需要一个OpenRouter的Key就可以通过同一个OpenAI兼容的接口格式访问市面上已经接入的几乎所有主流模型。每个模型都有一个统一的模型编号比如openai/gpt-4o、anthropic/claude-3.5-sonnet、meta-llama/llama-3.3-70b-instruct你只需要把请求里的model字段换成对应编号就行。这意味着Descript的评测脚本里不再需要为每一个模型厂商写一套适配代码也不需要一个接一个去申请各家API Key。各家模型的能力对比、历史报价、可靠性OpenRouter都帮你汇总好了。更关键的是OpenRouter的接口完美兼容OpenAI的SDK你现有代码里把base_url改成OpenRouter的地址填上它的Key就能立刻开始调用一大堆新模型。评测脚本的开发成本被压到极低团队可以把精力全部集中在“测什么”和“怎么判”这两件真正重要的事情上。2. 整体设计与评测框架选型思路2.1 为什么选OpenRouter而不是自己接各家API我知道肯定有人会问为什么不直接接各家模型的官方API这个问题我实测下来有非常明确的答案单独接官方API在模型数量少的时候确实没问题但一旦要批量横向评测十个以上新模型维护成本会指数级上升。不同厂商的API结构不同有的用messages格式有的是自己独有的接口重试逻辑、错误码、速率限制策略都不一样光是写兼容层就要花掉好几天。OpenRouter把“多样性”这一层彻底抹平了所有模型都统一成OpenAI的Chat Completions格式你代码里写一个请求函数就能测遍所有模型。另外还有一个我特别看中的能力OpenRouter支持在同一个请求里配置多个模型做自动fallback。就是你指定一个主模型和备用模型主模型挂了或超时会自动切换备用模型继续跑。对于批量评测这种需要长时间稳定运行的场景这个特性太实用了一条命令跑完上百个请求不用半夜爬起来处理个别模型偶发性的超时问题。还有一个容易被忽略的好处OpenRouter的后台会记录每一次请求的输入输出token数、延迟和费用。评测跑完后你不用额外写日志统计直接从后台导出数据就能算出每个模型的成本对比和响应速度。这三个数据对最终决策非常重要有时候模型质量差一点点但便宜十倍结论就会不一样。2.2 评测维度设计质量、延迟、成本、格式遵从整个评测体系我建议从四个维度来设计这也是我在实际项目里反复验证过的组合。质量是核心维度用来衡量模型输出的内容好不好。Descript的场景里质量包含几个子项比如“语义正确性”输出是否理解了用户需求、“内容完整性”是否漏掉了必要信息、“逻辑合理性”前后是否矛盾。这个维度光靠代码没法自动判需要用LLM-as-a-Judge的方案拿一个公认的强模型比如Claude或者GPT-4充当裁判让裁判模型根据提前定义好的评分标准给被测模型打分。延迟直接决定产品能不能用。一个功能如果模型的响应需要十秒就算质量再高用户也早跑了。评测脚本里要记录从发起请求到完整收到响应的总耗时并且要在相同网络条件下对比不然结果没有意义。建议每个模型至少跑三轮取平均值避开偶发网络波动。成本是很多团队容易漏掉的维度。新模型可能质量不错但如果每千次请求的成本是现有方案的十倍那这个模型只能躺在评测报告里吃灰。OpenRouter后台能直接看到每个请求的费用评测后按“单次请求平均成本”做对比一下子就筛掉性价比过低的模型。格式遵从是工程化落地的隐藏门槛。很多模型能力很强但让它严格输出JSON它就喜欢在前后加注释或者把字段名改了。Descript的链路里下游解析模块依赖固定的输出格式模型输出不遵守格式规范就需要额外写一堆兼容逻辑。评测集里要专门放一批“格式指令测试”要求模型必须按指定结构返回用程序直接校验通过率这一步是纯代码判断不需要裁判模型参与。2.3 基准集搭建回归集实时抽检场景覆盖评测集的设计决定了评测结果的可信度而评测集本身也需要持续维护。我建议Descript式的工作流里评测集分成两个固定部分再加上一个灵活部分。固定部分叫“回归集”长期保持不变。这批用例覆盖产品里所有核心链路比如音频转写后的语义修正、字幕时间轴对齐描述生成、用户指令的意图分类、长篇内容的要点提取每个场景配5到10条用例总共维持在大约50条。为什么固定因为只有保持评测集不变你才能把新模型和旧模型放在同一个基准线上对比数据才有可比性。如果今天加两条用例明天删两条评测分数的波动你根本分不清是模型变了还是评测集变了。灵活部分叫“实时抽检集”每个月或每个季度更新一次。这批用例选自最近用户真实反馈中出问题的case、新上线的产品功能对应的场景、以及业内公认的模型弱项。抽检集的作用是防止评测体系固化让模型训练或者选型的关注点能跟上实际需求的变化。在场景覆盖上有一个原则真实素材优先于标准题目。用Descript自己的脱敏用户数据或者团队内部录制的素材比用网上公开的通用测试题更有参考价值因为同一个模型在不同领域的效果差异很大跑分高的模型不一定适合你的业务。3. 核心实现两小时跑完一批新模型的完整流程3.1 批量调用OpenRouter的标准请求封装这一节直接上实操代码。下面是整个方案里最底层的请求封装基于OpenAI的Python SDK只是把base_url指向OpenRouter然后把Key填进去。这段代码是整个评测流水线的地基所有模型调用都走这一个函数。from openai import OpenAI import time import json client OpenAI( base_urlhttps://openrouter.ai/api/v1, api_key你的OpenRouter_API_Key, ) def call_model(model_id, messages, temperature0.3, max_tokens1024, timeout60): start time.time() try: response client.chat.completions.create( modelmodel_id, messagesmessages, temperaturetemperature, max_tokensmax_tokens, timeouttimeout, ) latency time.time() - start content response.choices[0].message.content usage response.usage return { model: model_id, content: content, latency: latency, prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, error: None, } except Exception as e: return { model: model_id, content: None, latency: time.time() - start, prompt_tokens: 0, completion_tokens: 0, total_tokens: 0, error: str(e), }这套封装有几个细节要说明。temperature我统一设成0.3而不是0因为很多模型在temperature等于0时反而会出现输出不稳定或者重复的现象0.3既能保证输出的一致性又不会过于随机评测结果复现性更好。max_tokens需要根据你的用例类型来定简单分类任务1024足够长文摘要可能要2048以上。timeout设成60秒如果某个模型超过一分钟还没回应说明它当前状态不适合被评测直接标记失败就好。调用示例也很简单遍历你的模型列表再遍历测试用例人工双重循环就行了。但这样串行跑太慢一个模型50条用例10个模型就是500次请求串行下来可能要跑三四个小时。所以下一步要上并发。3.2 评测判分与结果汇总LLM-as-a-Judge的实际落地模型跑完只是拿到原始输出接下来要做的是判分。判分分两条线适合代码硬校验的格式遵从、URL可访问性、关键词是否包含直接写规则适合语义评估的内容质量、逻辑性、相关性用裁判模型打分。裁判模型的选型很关键我的建议是选一个能力足够强且推理稳定的模型当裁判。比如anthropic/claude-3.5-sonnet或者openai/gpt-4o你让它们当裁判去评判其它模型不会因为自身能力不够而产生偏低的分数。评测提示词要写得非常具体给出评估维度、打分区间、输出格式要求否则裁判模型会给出模糊的结果。我实测下来最有用的提示词结构是这样你是一位严格的AI模型评测专家。请根据以下标准对模型的回答进行打分。 【任务描述】 {这里填用户原始指令} 【候选模型回答】 {这里填被测模型的输出} 【评测维度】 1. 正确性0-5分回答是否准确、无事实错误 2. 完整性0-5分是否覆盖了任务要求的所有关键点 3. 可读性0-5分表达是否清晰、结构是否合理 4. 指令遵循0-5分是否严格遵守了格式和约束要求 【输出要求】 只输出一个JSON对象格式如下 {正确性: 4, 完整性: 5, 可读性: 3, 指令遵循: 4, 总评: ...}判分代码的核心逻辑就是把这个请求发给裁判模型解析返回的JSON然后汇总到全局结果里。def judge_output(task_description, model_output, judge_modelopenai/gpt-4o): judge_prompt f 你是一位严格的AI模型评测专家。请根据以下标准对模型的回答进行打分。 ... result call_model( judge_model, [ {role: system, content: 你是一位严谨的评测专家只输出JSON。}, {role: user, content: judge_prompt}, ], temperature0, max_tokens256, ) if result[error]: return {error: result[error]} try: return json.loads(result[content].strip().strip()) except Exception: return {error: JSON解析失败, raw: result[content]}注意这里裁判模型的temperature设成0确保每次打分尽量一致。解析JSON时我做了容错处理先把内容里的反引号和多余空白去掉再解析因为有些模型会输出json包裹的格式。如果解析失败就记录原始内容后续统一处理。结果汇总阶段我会把所有单个用例的得分按模型ID分组计算每个维度的平均值同时统计延迟、成本、格式通过率最后生成一张Markdown表格形式的对比报告。这样评测结束后团队直接看报告就能开会做决策了。3.3 从一周到两小时差距到底在哪坦白说单纯把测试跑完从串行改并发时间就能从几小时缩到几十分钟。真正让Descript达到“两小时”水平的是整个流程中几个看起来不起眼但作用巨大的优化。第一配置一次终身复用。OpenRouter的统一接口让所有模型都走同一套代码新模型接入只需要把模型编号加进配置列表不需要改任何业务逻辑。第二并发拉满。50条用例一个模型跑串行差不多要10到20分钟但配合并发控制在20到30个请求同时跑一个模型基本三五分钟跑完。10个新模型并发执行整体跑测试环节控制在40分钟左右。第三人工介入被压缩到极限。评测前只需确认模型列表评测后只需看汇总报告中间所有判分、统计、报表生成全部自动化。这样算下来两小时绰绰有余还包括了评测过程中偶尔出现的意外重试时间。我实际跑下来的数据是10个新模型每个模型50条测试用例加上5条格式测试总共550个请求并发度25从开始跑评测到拿到完整报告最快一次是1小时37分钟。这里面还包括了OpenRouter的限流等待和两台模型的超时重试。所以“两小时内”不是吹的是可复现的真实水平。3.4 并发控制与限流避让的实操细节并发控制是整个评测流水线从“能跑”到“跑得快且稳”的关键。如果你同一时间发出上百个请求OpenRouter或者底层的模型供应商几乎一定会触发限流返回429错误。所以我用Python的ThreadPoolExecutor加上信号量来做一层限流控制。from concurrent.futures import ThreadPoolExecutor, as_completed MAX_CONCURRENCY 20 # 同时最多20个请求 def run_benchmark(models, cases): all_results [] with ThreadPoolExecutor(max_workersMAX_CONCURRENCY) as executor: futures [] for model in models: for case in cases: future executor.submit( call_model, model_idmodel, messagescase[messages], ) futures.append((model, case, future)) for model, case, future in as_completed(futures): result future.result() all_results.append({ model: model, case_id: case[id], case_category: case[category], **result, }) return all_results这个实现里MAX_CONCURRENCY 20是我压测后的平衡点。并发数太小跑得慢并发数太大会频繁触发429限流重试时间反而把并发优势抵消了。20这个数值在不同模型间表现比较稳定如果你用的是开源宿主的模型限流阈值可能更低建议保守一点设成10到15。还有一个特别容易踩的坑OpenRouter对不同模型的限流策略不一样有的模型同一个Key同时只能有2个请求有的可以到50个。如果你某一个模型频繁429针对那个模型单独降低并发数就好。我在代码里会为每个模型维护一个独立的信号量这样性能好的模型能跑满并发容易被限流的模型自动降速整体效率最高。另外重试策略一定要加指数退避。网络抖动是常态一个请求偶尔超时不必大动干戈但如果连续重试三次都失败就应该把这个请求标记为失败并继续下一个不然个别模型的故障会卡住整个评测流程。4. 常见问题与排查技巧实录4.1 模型输出格式不稳定JSON解析频繁失败这是我在评测过程中遇到最多的问题尤其是新出的小参数模型明明提示词里说“只输出JSON”它还是会在JSON前后加一堆解释说明或者把字段名从下划线风格改成驼峰风格。对于评测框架来说解析失败就意味着这个用例没分可打会导致结果数据缺失影响横向对比。我的解决办法是三层容错。第一层先把模型的输出做清洗去掉所有不在最外层花括号之间的内容提取{...}部分再尝试解析。第二层如果仍然解析失败就把这段输出发给裁判模型让它把内容转换成标准JSON再返回这样至少还能拿到数据。第三层如果裁判模型也救不回来就把这个case标记为“解析失败”并把这个模型的“格式遵从”维度直接判零分。你不要小看这个设计在实际评测中格式遵从率往往能拉开模型之间的差距打磨过的商用模型基本能达到100%而一些开源小模型可能只有60%。4.2 并发一高就大量429/超时评测直接崩掉这个问题我刚开始跑的时候经常遇到现象是前两分钟跑得很顺然后突然一大批请求全部返回429限流错误日志里全是红色。原因就是我把并发开到50试图“加速”结果触发了OpenRouter和底层模型服务商的双重限流。排查步骤很简单先看限流是哪个层面触发的。如果429里带的错误信息提到了rate_limit那就是并发过高如果提到了overloaded可能是底层模型服务商能力不足。应对策略是动态调整并发度我现在的方案是把基准并发设为20如果连续三个请求都返回429就把并发数临时降一半持续一段时间后再慢慢恢复。遇到特定模型频繁限流的单独给它挂一个更严格的信号量从根上降低它的请求速率。要注意一点不要为了追求速度把所有模型都一视同仁地并发跑。不同模型的限流档位差异很大开源小模型通常便宜且吞吐高闭源大模型比如Claude、GPT-4的限流会比较严格。把资源集中在吞吐高的模型上反而能更快跑完整体评测。4.3 评测结果前后不一致同一个模型分数波动大同一份测试集早上跑和下午跑同一个模型的平均分能差出十几分这种问题我遇到过不少次。常见原因有三个排查顺序也是从易到难。先查裁判模型是不是被负载影响了。有些裁判模型在高峰期的输出质量会波动尤其是带随机性的参数设置下打分会不稳定。对策是裁判模型temperature设0同时固定同一个裁判模型不要换。再查测试用例的提示词是否有隐藏的随机性比如时间戳、用户ID这些变量如果混进提示词里模型输出就会不一致。最后查被测模型的版本OpenRouter上某些模型编号背后会做路由今天跑到的版本和下周跑到的可能是不同的小版本长期评测要锁定具体版本号。如果这些都没问题那就是评测集本身的稳定度不足。有些用例描述写得模棱两可模型怎么答都可能这种情况需要人工审查评测集把歧义描述改清楚。评测集的稳定度直接决定评测数据的可信度所以我宁可少放十条例题也要保证每一题都无歧义。4.4 成本控制与资源利用的实用建议很多人评测模型的初衷是想省钱结果评测本身却烧了一大笔钱这事挺讽刺的。跑一次10个模型的评测光API调用费可能就要几十到上百美元如果还用GPT-4级别的模型当裁判给每个case都打一次分成本会更高。这里有几个我实测有效的省钱技巧。第一在保证评测质量的前提下适当减少裁判模型的调用次数。同一模型的同类用例结果可以打包成一个批次发给裁判模型让它在一次请求里同时给多个输出打分这样请求数减少费用也减少。第二先用延迟和格式通过率做粗筛再用裁判模型做精评。很多模型跑完格式测试和延迟测试就已经出局了质量评测根本不用做。粗筛阶段是纯规则判断零成本能帮你省掉一大笔裁判费用。第三关注模型供应商的价格波动。OpenRouter上同一个模型经常有好几个供应商在托管价格和速度都不同选择价格更低的供应商跑测试能省不少钱测试结果的差异通常可以忽略。5. 从评测到落地的扩展思路5.1 把评测报告变成产品选型的决策依据评测跑完不是终点报告才是真正有价值的东西。我建议最终输出给团队的评测报告不只是一个分数表而是包含明确的决策建议。比如某个模型质量分虽然高但成本是原方案的三倍对用户无感知的场景不提效那就不值得替换某个模型整体平均分不如老模型但在特定的字幕生成场景里得分明显高出一截那就可以作为这个场景的定向候选。在日常使用中我发现一个很有效的工作方式是评测脚本跑完后自动把报告推送进团队的项目管理工具然后打上“待评估”的标签。评估会议上产品、工程、算法三方直接对着报告讨论每个人的判断都有同一个数据基准不容易各说各话。这比让开发者说“我觉得这个模型还行”靠谱得多也比产品经理拍脑袋下结论有依据得多。5.2 评测集持续维护与Prompt版本管理评测体系建立起来之后最大的风险不是测不准而是“测的和实际用的对不上”。产品功能在迭代提示词在改版如果评测集跟不上变化再高的分数也没有参考价值。所以维护评测集这件事需要和产品迭代节奏绑在一起每次提示词改动影响到核心链路时触发一次质量回归把新模型和老模型都重新跑一遍对比变化。同时要做好评测集和提示词的版本管理。我建议评测集文件本身纳入代码仓库管理每次新增用例或者修改原有用例都记录一个版本号。跑评测时把评测集版本号记入结果文件这样即使过了几个月再翻出来看当时的评测结果也能清楚知道那份报告是基于哪一版评测集产出。没有版本管理的评测集跑完就丢几个月后你想复现当时的数据就只能对着空气叹气。5.3 模型评测与CI/CD流水线的集成既然整个评测流程已经控制在两小时内那这件事完全可以和CI/CD结合做成发布流水线中的一个自动化环节。我在团队内部尝试过这种模式当一个新的模型版本出现在OpenRouter的模型列表里自动化脚本检测到后触发一次评测然后把报告推送到开发群。评测结果达到预定阈值的模型自动进入候选池未达阈值的模型直接被标记为“不推荐”。更进一步可以在提示词改动的时候自动执行评测回归防止改提示词导致模型效果回退。这个机制的商业价值很大因为你不需要等用户投诉才发现线上质量下降了。模型评测自动化不只是帮助Descript这类AI公司节省人力它本质上是在给产品体验加保险让每一次技术决策都有数据兜底。我自己的习惯是每当评测跑完一批新模型都会顺手把竞品模型和现有线上模型也放进同一次评测里形成“新旧对比 竞品对比”的完整视图。这个习惯帮我避免过不少坑因为一个模型单独看可能很不错但放到同类竞品里一比高下立判。做模型选型最怕的就是没有参照物所有分数都是相对的对照系越完整决策越安全。