从标题说起，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. 方案选型：为什么偏偏是 OpenRouter
2.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_url="https://openrouter.ai/api/v1", api_key="<YOUR_OPENROUTER_API_KEY>", ) def chat_completion(model: str, prompt: str, temperature: float = 0.2): response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=temperature, ) 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-a | 100 | 100% | 2.3s | 8.2% | 91.8 |
| model-b | 100 | 98% | 1.8s | 9.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 帮我们把切换成本打到了最低，所以管线评测才变得可行。
如果你也想搭一套类似的评测体系，我建议从最简单的一个模型、一个数据集开始，不用一开始就追求完美。先把“从看到新模型到拿到评测报告”的流程跑通，再慢慢加数据集、加并发、加报告维度。这套能力建起来之后，你面对模型迭代的速度压力时，会从容很多。
