10 月 29 号晚上，我准备把 14 场会议录音扔进脚本重跑。整理资料时却发现一个挺烦人的问题：现有素材只有模型能力和部分价格，没有原始录音、人工标注稿、逐请求日志，也找不到 gpt-transcribe 可核验的单价。
TL;DR：截至 2026 年 10 月 30 日，公开资料不足以证明 elevenlabs/scribe_v2 和 openai/gpt-transcribe 谁的字错率更低，也算不出可信的"每小时成功成本"。目前只能确认，前者偏结构化转写，后者更容易接入现有 OpenAI 工作流。文章如果拿不出原始录音、标注稿和失败日志，却直接给出 CER、P95 延迟和完成率，这些数字大概率没法复算。
这篇不硬编什么"准确率提升 27%"。能确认的结果、缺失的数据，以及一套可以直接复测的流程，我都放在下面。
评测口径：别拿厂商宣传图直接对打
中文会议转写应该看 CER（字错误率），不能只盯着英文语音识别常用的 WER。
计算式如下：
text
CER = (替换字数 + 删除字数 + 插入字数) ÷ 标注稿总字数专有名词正确率要单独计算：
text
术语正确率 = 正确识别的术语次数 ÷ 术语出现总次数时间戳也不能凭肉眼判断"挺准"。可以抽取人工标记的词级锚点，再统计绝对偏差：
text
时间戳偏差 = |模型时间戳 - 人工时间戳|结果至少要公布中位数和 P95。只给平均值，很容易被几段特别干净的录音拉高。
你的场景应该选哪个
| 使用场景 | 当前更合适的选择 | 原因 |
|---|---|---|
| 需要说话人区分、词级时间戳 | elevenlabs/scribe_v2 |
官方文档明确提供结构化转写能力 |
| 需要音频事件标注 | elevenlabs/scribe_v2 |
能标记笑声等非语音事件 |
| 已有 OpenAI 摘要、翻译流程 | openai/gpt-transcribe |
接口链路更容易接入现有工作流 |
| 预算必须提前锁死 | 暂不下结论 | 素材未提供两个目标模型可直接横比的当前价格 |
| 中文口音和噪声录音 | 必须用自己的录音复测 | 现有公开资料不足以判定谁绝对领先 |
| 超过 25 MB 的单文件 | 先切片，再做 A/B 测试 | OpenAI Speech-to-Text 指南公开限制为 25 MB |
这里使用的是实时目录中的完整模型 ID：openai/gpt-transcribe。别擅自换成博客里见过的相似名字。模型 ID 差一个字符，接口都可能直接拒绝。
评测结果天梯图
这张表只放有证据支撑的结论。"无法确认"不是和稀泥，是真没有数据。
| 排名维度 | elevenlabs/scribe_v2 |
openai/gpt-transcribe |
当前结论 |
|---|---|---|---|
| 字错误率 CER | 未提供同源实测值 | 未提供同源实测值 | 无法排名 |
| 专有名词正确率 | 支持关键词提示 | 支持文本 prompt | 无法排名 |
| 时间戳能力 | 官方明确支持词级时间戳 | 素材未给出同口径数据 | elevenlabs/scribe_v2 信息更完整 |
| 长音频完成率 | 约 3 GB、10 小时，待当前文档复核 | 单次上传限制 25 MB | 不能直接按容量判胜负 |
| 处理延迟 | 无逐请求日志 | 无逐请求日志 | 无法排名 |
| 每小时成功成本 | 素材未提供目标模型单价 | 素材未提供目标模型单价 | 无法排名 |
| 工作流衔接 | 偏结构化转写 | 偏 OpenAI 技术栈 | 按工程环境选择 |
说实话，一开始我是拒绝写这么多次"无法排名"的，太不爽文了。但没有原始输出还敢做 CER 排行，那不是评测，是赛博算命。
第一梯队：结构化转写看 scribe_v2
elevenlabs/scribe_v2 的优势不在一句含糊的"识别更准"，而在于它的输出结构更适合会议系统。
按 ElevenLabs 官方文档，它支持 90 多种语言，提供这些能力：
- 说话人区分；
- 词级时间戳；
- 音频事件标注；
- 关键词提示。
这些功能放在会议纪要里都很实用。比如产品会上同时出现"回滚""灰度""Cline"和一串内部项目代号，关键词提示可能比单纯换模型更有效。
不过要分清楚：支持关键词提示，不代表专有名词正确率一定更高。如果一边提前把答案塞进关键词列表，另一边却裸跑，这场测试从一开始就不公平。
开源社区确实有人提出接入需求。LibreChat 的 ElevenLabs STT 增强请求获得 5 个赞，Whispering 的相关发布请求获得 3 个赞，OpenWhispr 的 API 接入请求获得 1 个赞。这些数据只能说明有人想用，不能证明准确率。点赞不是 Benchmark。
第二梯队：现有工作流看 gpt-transcribe
openai/gpt-transcribe 更适合已经围绕 OpenAI API 搭好后处理链路的项目。转写完成后，可以接着做摘要、行动项抽取和翻译，不用再维护一套完全不同的调用逻辑。
测试专有名词时要固定 prompt。两个模型可以拿同一份术语表，也可以都不提供术语表，但不能一边开辅助、一边裸考。
长录音还要处理 25 MB 的文件限制。60 分钟会议直接上传，压缩参数稍微保守一点就可能超限。折腾半天后，我现在更倾向于先切成 10 至 15 分钟的小段，保留 500 至 1000 毫秒的重叠区间。这个重叠长度是不是最佳实践，我也不确定，实际还得看语速和句子长度。
我遇到过一次上传请求在客户端超时，终端完整报错是：
text
curl: (28) Operation timed out after 60001 milliseconds with 0 bytes received这种失败不能直接记成"模型慢"。问题可能出在上传链路或网关超时，也可能是服务端还在处理。评测时必须同时记录 HTTP 状态码、首字节时间和总耗时，否则算出来的 P95 会一塌糊涂。
每小时成功成本应该怎么算
公开素材给出了 openai/GPT-5.5-transcribe 的参考价：约 $0.003/分钟，也就是 $0.18/小时。它可以当低成本对照组，但不能把这个价格直接套给 openai/gpt-transcribe。
两个目标模型没有同时提供可核验、同口径的价格，所以这里不编最终金额。
更有参考价值的是"成功成本"，公式为：
text
每成功小时成本 = 总账单 ÷ 成功完成的音频小时数假设一小时录音因为超时完整重试一次，名义单价虽然没变，成功成本却接近翻倍。切片重叠产生的重复音频也得算进去：
text
计费时长 = 原始时长 + 重叠区间总时长 + 重试时长所以只抄官网的"每分钟价格"没什么用。完成率 98% 的方案即使标价稍高，也可能比频繁重试的方案更好控制。一个月跑几千小时，差出来的可不是几杯咖啡钱。
接入渠道也要纳入评测
模型之外，网关会影响超时率、账单审计和失败重试。可以把 OpenRouter、Together AI、ofox.io 放进同一套请求脚本，但必须分别记录路由，不能把网关差异误判成模型差异。
按 2026 年 10 月 30 日公开资料核对，OpenRouter 收取 5.5% 手续费；另一接入渠道公开口径为 0% 加价，并提供按模型、用户和 API Key 查看 Token、延迟、成功失败及费用的后台。这里讨论的是可观测性，不代表它的转写准确率会更高------准确率最终仍由目标模型和输入音频决定。
| 接入对象 | 评测时要记录什么 | 不能据此推导什么 |
|---|---|---|
| 官方 API | 请求 ID、HTTP 状态码、总耗时 | 不能只测一次就代表长期 SLA |
| OpenRouter | 手续费、实际路由、重试次数 | 不能把路由波动归因于模型 |
| Together AI | 可用模型、响应状态、账单口径 | 不能跨日期混算延迟 |
| ofox.io | 模型、API Key、成功失败、费用 | 不能由网关数据推导 CER |
同一批录音应该怎么切
我的测试集会按难度拆成五组，不把所有录音搅在一起算一个平均值：
| 测试组 | 录音特征 | 主要指标 |
|---|---|---|
| 普通会议 | 单人或轮流发言、环境安静 | CER、延迟 |
| 口音组 | 不同地区口音、语速变化 | CER |
| 噪声组 | 键盘声、空调声、远场收音 | CER、完成率 |
| 重叠发言组 | 两人同时说话 | 说话人识别、漏字率 |
| 技术术语组 | API、库名、代码变量和项目代号 | 专有名词正确率 |
每段音频都要保留原始文件哈希，确保两个模型读取的是完全相同的文件。人工标注稿至少复核两遍，标点符号、数字和英文大小写的处理规则也要提前定好。
延迟统一从"请求开始发送"计时。不能一边统计上传时间，另一边只算服务端处理时间。OpenAI 的服务器那天到底在忙什么我不知道，但测试口径不能跟着心情变。
不同需求怎么选
如果要做带说话人和时间轴的会议纪要，我会先测 elevenlabs/scribe_v2。它的能力边界更清楚，后续处理也能少一些。
如果项目已经接好了 OpenAI 的摘要和信息抽取链路，我会优先验证 openai/gpt-transcribe。不是因为它已经被证明更准，只是工程迁移成本更低。
批量处理长录音时，先别急着站队。拿 10 小时以上的自有音频跑一轮，报告里至少要有这些数据：
- 各测试组 CER；
- 术语命中次数与总次数；
- 时间戳偏差中位数和 P95；
- 成功文件数与总文件数；
- 总账单与成功音频小时数；
- 失败原因分布。
样本只有三五段，我也不确定这个排名有没有统计意义。目前没找到比公开原始输入、标注稿和评分脚本更可靠的办法。
小结
目前能确认的只有两点：elevenlabs/scribe_v2 偏结构化转写，openai/gpt-transcribe 偏现有 OpenAI 工作流集成。中文 CER、口音表现、P95 延迟和每小时成功成本，现有素材都不足以判断谁赢。
别被漂亮的柱状图带跑。没有同一批录音、同一套提示、同一评分脚本和完整失败日志，所谓转写实测就没法复算。