从标题说起Descript 这家公司做的是音视频编辑工具核心卖点是用 AI 把音频和视频变成“可编辑的文本”所以他们对新模型的嗅觉非常敏锐。但凡市面上冒出一个新的语音识别模型、一个新的 LLM他们都要快速判断“这玩意儿能不能用到我们产品里、效果到底如何”。早先他们评测一个新模型从申请 API、看文档、写适配代码到跑完评测集、汇总分析差不多要一周。后来他们接入了 OpenRouter把整个流程压到了两小时。这个优化幅度不是简单省了几天时间而是把“评测”这个动作从一项需要排期的专项工作变成了随时可以做的例行操作。这篇文章我就以一线工程师的视角把这个项目的背景、选型思路、具体做法和踩过的坑完整拆开讲清楚。不管你是做 AI 应用开发、模型选型还是在团队里负责技术调研这套方法论都可以直接抄作业。1. 项目背景Descript 为什么把模型评测当成日常任务1.1 Descript 的模型依赖程度有多高Descript 的产品逻辑是“编辑视频就像编辑文档”也就是先用语音识别把音视频转成文字用户直接改文字再通过语音合成把改动后的文字变回自然的语音。整个链路里至少有两条强依赖模型的环节一条是语音转写ASR一条是语音合成TTS。另外他们还有一个叫 Underlord 的 AI 助手负责帮你写脚本、给剪辑建议、总结视频内容这就用到了大语言模型。这意味着什么模型的质量直接决定产品体验。ASR 转写错了用户改起来就烦躁TTS 合成出来语音生硬用户就会觉得不自然Underlord 回答不到点子上用户就不再用了。所以 Descript 对模型的重视程度非常高每一个新版本、每一款新模型发布他们都要去评估“集成进来会不会比现在好”。问题在于模型迭代的速度越来越快。以前一年可能就 GPT 一家在更新现在几乎是每周都有新的开源模型或者新版本冒出来。Meta 放出 Llama 的新版本、Mistral 更新、Qwen 出新尺寸、Anthropic 或 OpenAI 发布新旗舰这些消息一出来团队就得评估一遍。如果评估一次要一周那基本永远追不上节奏等测完下个新模型又出了。所以“评测从一周缩短到两小时”对这个团队不是锦上添花而是活下去的基本要求。1.2 传统评测一周都花在哪里了很多人以为评测模型就是“发个请求、看下结果”这么简单但实际做过的才知道一周时间其实是合理估算。我拆一下时间花在哪里第一天申请各家的 API 权限。如果评测的是 Claude 或 Gemini 这种商业模型需要去对应平台注册、绑卡、申请 key运气好当天能下来运气不好要等审核。如果是自托管的开源模型那就更麻烦了要先找机器、配环境、下权重、起服务。光是“能跑起来”这一步半天到一天是常态。第二天到第三天写适配代码。每个平台的 API 格式都不一样OpenAI 是一套、Anthropic 是一套、Google 又是一套。有些平台有 SDK有些只有 HTTP 接口有些支持流式有些不支持。你要评测 5 个模型就至少得写 5 套调用代码再加上统一的数据结构转换、异常处理、重试机制一天打底。第四天到第五天跑评测集。评测集不是几个 sample 就完事至少要覆盖正常场景、口音变化、背景噪音、长文本、短文本等等。串行跑的话几十到上百条样本跑一个模型就要几小时多个模型排队跑一天就没了。第六天到第七天人工汇总结果。每个模型产出一堆 JSON 日志你要把准确率、延迟、失败率这些指标分别算出来再手工整理成对比表格写分析结论。这还是理想情况如果中途发现某个模型的 API 有 bug或者评测集里数据有问题整个流程会继续顺延。所以一周真的一点都不夸张。1.3 评测想要达到的目标状态这套流程优化前团队内部其实有一个很直接的期望能不能做到“今天看到新模型发布的消息今天就能知道它表现如何”。这需要满足三个条件第一新模型要立刻可访问不用等审批、不用自己部署。第二评测代码要零改动切换模型不能每次适配一套 API。第三评测结果要自动汇总跑完直接出对比报告不用人工算指标。这三个条件分开看不难合在一起就指向同一个答案用 OpenRouter 这种聚合平台再配套一套长得像“模板”的评测脚手架。接下来我会详细讲为什么选 OpenRouter以及它到底解决了什么最核心的问题。2. 方案选型为什么偏偏是 OpenRouter2.1 评测场景对模型访问的核心诉求先说评测场景跟生产环境的差别。生产环境里你对某一家云厂商的 API 有稳定性要求可能要做私有化部署或者要做很深的定制这时候倾向直接用官方平台。但评测场景不一样它的核心诉求是“快速、灵活、低成本覆盖足够多的模型”。具体来说有三点很关键。第一是覆盖速度新模型发布后评测平台能不能在当天或次日上线这个模型。如果评测一个模型要等平台商务对接那一点意义都没有。第二是切换成本评测多个模型时代码层面最好只改一个模型名字而不是改整套调用逻辑。第三是并行能力同时跑多个模型的评测需要并发支持否则串行跑还是慢。这三点用传统“逐个对接官方 API”的方式很难同时满足。覆盖速度跟不上就不说了光是每个平台一种鉴权方式、一种请求结构就能把工程成本拉满。2.2 OpenRouter 的核心机制与评测优势OpenRouter 本质上是一个大模型 API 网关它把几十家厂商的几百个模型统一到一个入口后面。你只需要用一个 API key用一套 OpenAI 兼容的接口格式就能调用平台上所有模型。对于评测场景这个设计有几个隐藏优势。第一个优势是它内部做了模型的重试和降级。OpenRouter 允许你在请求里指定多个模型如果第一个模型对应的上游服务不可用它会自动切换。这个对评测特别实用因为评测任务经常是深夜批跑上游供应商偶尔抽风是常态有了自动降级就不用半夜起来重启任务。第二个优势是它有流量负载均衡。同一个模型在上游可能有多个供应商提供OpenRouter 会根据延迟和可用率把请求分发到合适的供应商。你在评测时测到的是“这个模型通过 OpenRouter 暴露出来之后的综合表现”虽然不是直接连某一家厂商但对选择“哪个模型适合集成到产品”来说参考性更强因为你实际集成时大概率也是走网关。第三个优势是它对新模型的上线速度。OpenRouter 社区生态很活跃新的开源模型出来后基本几个小时到一天内就会上线。评测团队最看重的“抢鲜能力”在这里天然满足不用自己部署、不用刷审批。2.3 和自部署模型/直连官方 API 的对比这里我列个对比表方便理解三种方式的取舍对比维度OpenRouter 网关直连各家官方 API自部署开源模型新模型获取速度快通常当天取决于平台审核取决于硬件与权重下载代码适配成本一套接口全打通每平台一套每模型一次部署多模型并行支持并发需自己管理配额需要多卡机器成本按量付费有免费模型各平台单独计费硬件成本高适合场景快速评测、多模型对比生产环境深度集成数据敏感或长期固定调用从表里能看出来评测选 OpenRouter 是性价比最高的。它在“获取速度”和“代码适配成本”这两个评测最在意的维度上都是最优解。当然如果你评测完要正式集成到生产环境那还是得回到官方 API 或者私有化部署上评测阶段的结论只能作为选型的参考依据不能替代生产级的验证这一点后面会提。3. 实操流程怎么把评测从一周压到两小时3.1 搭建一套“评测脚手架”而不是写一次性脚本很多人做评测都是临时写个 Python 脚本跑完就扔下次换个模型再写一遍。这样永远快不了。Descript 的做法是把评测做成一个脚手架工程核心思路是“模型可配置、数据可复用、结果可对比”。我建议你按这个结构来组织eval_runner/ ├── configs/ │ └── model_list.yaml ├── datasets/ │ ├── asr_zh_test.jsonl │ ├── asr_en_noise.jsonl │ └── llm_summarize.jsonl ├── core/ │ ├── client.py │ ├── metrics.py │ └── runner.py ├── results/ │ └── 2025-01-15_run.jsonl └── main.py配置层和代码层一定要分开。举个例子你要评测六个模型在model_list.yaml里写清楚每个模型的名称、评测数据集、参数配置然后跑python main.py --config configs/model_list.yaml。评测脚本本身完全不感知“换了哪个模型”它只负责读取配置、发起请求、收集结果、计算指标。这样一来下一次新模型发布你要做的只是往 YAML 里加一行模型名而不是改代码。这里有个关键设计评测数据集必须是固定的。你一定不希望为了对比 A 模型和 B 模型两次用的测试样本不一样那样指标根本没有可比性。所以数据集文件要锁定版本任何修改都要走版本管理。3.2 用 OpenRouter 统一接口屏蔽模型差异OpenRouter 使用 OpenAI 兼容的 API 格式这意味着你只需要封装一个客户端。下面是一个最小可用的调用封装我用 OpenAI 的 Python SDK 来演示。from openai import OpenAI client OpenAI( base_urlhttps://openrouter.ai/api/v1, api_keyYOUR_OPENROUTER_API_KEY, ) def chat_completion(model: str, prompt: str, temperature: float 0.2): response client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperaturetemperature, ) return response.choices[0].message.content这段代码写完之后评测任何 LLM 就只是传一个不同的model字符串的问题。OpenRouter 的模型 ID 格式是vendor/model:version比如openai/gpt-4o、anthropic/claude-3.5-sonnet、meta-llama/llama-3.3-70b-instruct。你可以在配置里直接写这些 ID代码一行都不用改。我建议把超时时间、重试次数、并发数都通过环境变量配置。评测时如果某个模型响应特别慢单请求超时时间建议设置在 60 到 120 秒重试两到三次就够了不要把重试拉到很高否则评测时间会失控。3.3 评测集设计两小时跑完的关键在并行刚才提到传统评测一周里很大一部分时间是耗在串行跑数据和人工汇总上。用 OpenRouter 之后这两步都可以优化。关键改动是“并发 自动重试”。先告知一个坑OpenRouter 默认的限流策略是基于你的账号等级和剩余余额的新手账号并发数并不高。所以在写评测脚本时不要一开始就开 50 个并发先看平台返回的X-RateLimit-Limit之类响应头再决定要不要慢慢加。稳妥的做法是先限制并发在 5 到 10 个请求跑通之后再逐渐上调。我实测下来一个包含 100 条样本的 LLM 评测集串行跑大概要 50 到 80 分钟也就是一条样本要几十秒。开了 10 个并发之后几分钟就能跑完。ASR 任务类似只要上游接口支持并发速度提升非常明显。评测脚本里还要加一个断点续跑的机制。每跑完一条样本就把结果追加写进一个 JSONL 文件。万一中途网络断掉或者 API 报错重启脚本的时候先检查一下哪些样本已经跑过了直接跳过而不是从头再来。这个环节看着不起眼但在评测模型数量多的时候能省下大量时间。3.4 评测结果自动汇总与对比分析跑完数据只是第一步真正的价值在对比分析。千万不要跑完就手动复制粘贴结果那样又回到了老路。我习惯把结果整理成结构化数据再用脚本自动生成对比报告。每个评测任务的输出应该包含这几个字段模型名、样本 ID、输入内容、模型输出、耗时、是否成功。拿到这些之后指标计算就可以全部自动化。LLM 类任务常用 ROUGE、BERTScore或者更简单的关键词命中率ASR 类任务就是字错误率CER或词错误率WER。写一个指标计算脚本输入一个结果 JSONL输出一份 Markdown 表格模型样本数成功率平均耗时CER/WER得分model-a100100%2.3s8.2%91.8model-b10098%1.8s9.5%90.5有了这个表格你还要做一步失败案例分析。每次评测总会有一两个模型在特定样本上表现特别差你要把这类样本单独挑出来比如“所有模型在带背景噪音的英文样本上都表现不好”这个结论才是评测报告里对产品选型最有价值的部分。只看平均分容易把关键问题糊弄过去。4. 实操中的踩坑记录与排查技巧4.1 并发提不上去接口频繁返回 429 怎么办这是最常碰到的第一个问题。你觉得自己开 10 个并发不多但 OpenRouter 对非付费账号的限流很严格。我碰到的实际报错是这样的RateLimitError: Error code: 429 - You have made too many requests to the API.解决思路分三步。第一步是查看响应头里的限流信息一般会包含X-RateLimit-Limit和X-RateLimit-Remaining通过日志打印出来能直观看到自己的额度。第二步是退让式重试也就是遇到 429 就等待一段时间再重发等待时间建议采用指数退避加抖动避免所有请求同时重试造成“惊群”。第三步是提升账号等级OpenRouter 支持在充值后获得更高的并发限制如果评测是团队的常态化需求这一步值得投入。这里还有个细节OpenRouter 的免费模型和付费模型共用同一个限流池如果你同时跑免费和付费模型免费模型的并发会被限得更狠。我后来把免费模型单独跑付费模型分开跑问题就缓解了很多。4.2 同一个模型 ID为什么不同时间测出来的结果波动很大这个坑比较隐蔽。OpenRouter 上的同一个模型 ID它的上游供应商可能不止一家。就好比同样叫“某个开源模型”A 供应商部署在 A 类显卡上B 供应商部署在 B 类显卡上推理结果在有随机性的任务上会有细微差异。另外OpenRouter 还有route策略比如route:fallback会在首选供应商失败时切换到另一个所以结果出现波动是正常的。要解决这个问题我的建议是记录每一次请求的x-openrouter-route-id响应头。这个头会告诉你请求实际走了哪个供应商。如果发现模型结果异常先看是不是路由被降级到了备用供应商。如果你要特别严格的对比比如评测一个刚出的开源模型建议先用 OpenRouter 找到直连官方或指定供应商的方式减少路由波动对评测结果的影响。4.3 评测成本控制免费额度与限额怎么设置OpenRouter 按 token 计费不同模型价格差距非常大。评测如果不设上限一个不小心可能烧掉不少钱。我踩过一次坑评测一个长文本任务忘了设max_tokens某个模型生成了超长回复几十条样本下来直接把当天的额度跑穿。控制方法很简单但要注意细节。所有请求统一设置max_tokens不要依赖模型默认值。另外OpenRouter 后台可以设置用量限额credit limit我习惯把评测账号的限额设成团队预算的一半跑偏的时候至少不会烧太多。最后在评测脚本里也要做一个总成本估算启动任务前先打印出预估成本确认后再跑。还有一个实用技巧OpenRouter 上很多开源模型有小参数版本成本只有大模型的十分之一。在初筛阶段先用小模型跑一遍把明显不行的模型过滤掉再用大模型精评整体成本能降低不少。4.4 模型输出不稳定如何判断是模型问题还是接口问题有时候评测结果差未必是模型本身不行而是调用方式有问题。比如 temperature 设置过高、prompt 格式不符合模型微调习惯、上下文太长被截断等。我建议的排查顺序是先用官方推荐参数复测一遍再逐步修改 prompt最后才下结论说模型不行。具体到 DeepSeek 这类对 prompt 格式敏感的模型我遇到过因为 system prompt 没写清楚导致回答完全走偏的情况。排查时先固定 prompt 模板如果多个模型跑出来的结果都异常问题大概率出在 prompt 上而不是模型上。如果只有单一模型异常那再考虑是不是这个模型本身不适合这个任务。4.5 评测自动化与 CI/CD 结合的进阶玩法两小时评测是人工触发的但你完全可以更进一步把它接到发布流程里。我们的做法是每周定时跑一次全量模型对比把结果推到内部页面上展示。当有新的模型发布时也会自动触发一次冒烟评测只跑一个 10 条样本的快速集判断这个模型“值不值得进入下一轮详细评测”。这个设计的好处是可以把评测结果沉淀成团队的历史数据。几个月之后你翻看历史记录就能回答一个问题某个模型在那一天开始表现变差是不是因为上游换了供应商。这种数据资产的价值远远超过“评测一次出个结论”本身。自动化并不复杂核心就是把评测脚本封装成命令行工具用一个 crontab 或 GitHub Actions 定时触发最后把结果推送到内部的监控看板。5. 这套流程的适用边界与进一步扩展5.1 什么场景不适合用 OpenRouter 做评测前面说了不少 OpenRouter 的好处但它不是万能的。如果你评测的内容涉及用户隐私数据或者受合规要求不能出域那 OpenRouter 这种云端网关就不合适你应该考虑私有化部署。另外如果你要评测的是一个尚未在 OpenRouter 上线的私有模型或者只有通过特定渠道才能访问的模型那也得走自己部署或者直连官方 API 的路线。模型切流量的实时性也需要敲打一下。OpenRouter 上的模型版本更新可能比官方晚几小时甚至几天如果你需要在一款模型发布后的第一时间拿到首测结果建议同时对官方平台和 OpenRouter 各跑一遍这样才能确认首测和上线之间存在的时间差。5.2 从“评测模型”升级到“评测能力”最后我想说一个理念上的转变。一开始我们做评测关注的是单个模型在各个任务上的分数比如 ASR 准确率、摘要 ROUGE 值。但跑了一两个月之后我们开始意识到真正应该评测的不是模型而是“能力组合”。比如在 Descript 的产品里用户上传一段嘈杂的会议录音链路是先做语音增强再做 ASR再做摘要。每一环选什么模型对最终结果的影响是叠加的。所以我把评测脚手架延展成了“管线评测”。不是只调一个模型看输出而是把多个模型的输出串联起来看看整条链路的效果。这个改动让评测结果和真实用户体验之间的相关性高了很多。而这个能力强依赖一个前提你能很方便地切换每一个环节的模型。OpenRouter 帮我们把切换成本打到了最低所以管线评测才变得可行。如果你也想搭一套类似的评测体系我建议从最简单的一个模型、一个数据集开始不用一开始就追求完美。先把“从看到新模型到拿到评测报告”的流程跑通再慢慢加数据集、加并发、加报告维度。这套能力建起来之后你面对模型迭代的速度压力时会从容很多。