Grok Voice Transcribe 2.0 对比 Granite Speech 5.0 470M TurboCTC：12,600 倍实时遇上半秒

Granite Speech 5.0 470M TurboCTC 在单块 H200 上每秒可转录约 3.5 小时的音频，而 Grok Voice Transcribe 2.0 会在你停止说话 0.49 秒后返回第一份部分转录文本。在各类对比文章中，这两个数字常被并排放在一起，仿佛它们属于同一种测量，可实际上它们根本不是同一类测量——一个是批量数据中心的吞吐量指标，并不附带任何延迟信息；另一个是某个模型的延迟指标，而该模型的吞吐量从来没有人公布过。IBM 于 2026 年 8 月 25 日以 Apache 2.0 许可发布 Granite Speech 5.0 470M TurboCTC，彻底去掉了语言模型解码器，改用单次非自回归 CTC 计算完成解码。SpaceXAI 于 2026 年 9 月 18 日推出 Grok Voice Transcribe 2.0，以托管 API 形式提供，批量处理为每音频小时 0.10 美元，流式处理为每小时 0.20 美元。两者都是出色的转录模型，分别解决同一问题中相反的两半；一旦你不再直接比较这些数字，在两者之间做选择就会容易得多。

12,600× 实时，以及修饰它的词语

Granite 的这个数字是 12,600 RTFx，在单块 NVIDIA H200 上以批量推理测得——这是 IBM 在发布时报告的数字，此后未再被独立复现。RTFx 是音频时长与处理时间的比值，因此 12,600 意味着每秒钟实际时间大约可处理 3.5 小时音频。IBM 自己的说法是，这比早期 Granite Speech 版本的吞吐量高出 20 倍以上，而这才是这里真正重要的主张：提速来自减少了工作量，而不是增加了硬件。

它不是一个延迟数字。一个每秒能完成 3.5 小时音频的批处理作业，返回任何单个文件的第一个 token 仍可能耗时很久，具体取决于批次如何组装，以及它在开始前被喂入了多少音频。IBM 完全没有为 TurboCTC 公布任何延迟数据。在远场排行榜上，这两个检查点是最快的两个条目，但那里的吞吐量是在单块 NVIDIA L4 上测得的，那是一款接近数据中心的加速器，而不是手机。

这件事之所以重要，是因为该模型被明确地定位为面向笔记本电脑、手机和边缘设备——这是 IBM 自己的说法——而没有人公布过其中任何一种设备上的单流性能。在有人这么做之前，请把“12,600×”理解为关于你能以多低的成本在租来的 GPU 上处理完一次回填的陈述，这是一个真正有价值且有充分证据支持的说法，而不是关于单个用户多快能得到一句话回复的陈述。

IBM移除了什么，以及这会让你付出什么代价

TurboCTC 是一种仅编码器设计：一个 16 层的 Conformer 声学编码器，使用 CTC 训练，在一次非自回归前向传播中贪婪解码，并带有一个 16,384 单元的子词输出层。整个流程中不含语言模型。速度正是源于这一点，而能力上的削减也同样源于此，并且这些削减并不小。与早期的 Granite Speech 模型相比，TurboCTC 去掉了语音翻译，去掉了关键词偏置，并且不再提供时间戳或标点工具。

将这一点与管理型模型在其标价中包含的内容进行对比，这笔交易的结构就变得具体了：

• 关键词偏置 — Granite Speech 5.0 470M TurboCTC 不支持，而 Grok Voice Transcribe 2.0 每次请求最多支持 100 个关键词

• 词级时间戳——未随 TurboCTC 提供，而随置信度分数一同提供

• 语音翻译——在早期 Granite Speech 模型中提供，在此处已移除，而不是两者都未提供

• 语言覆盖范围 — 仅英语 vs 在广泛的多语言输入集中自动检测，并支持 25 种语言的格式设置

• 说话人分离 — 是需自行解决的独立问题，还是包含在请求价格中

• 声道 — 每次处理一个流，而一次请求最多支持八个音频声道

• 文本规范化——无 vs 逆文本规范化，将口语中的日期、货币和电话号码转换为书面形式

• 部署 — 你下载并运行的权重 vs us-east-1 中的托管端点

把那份清单看作对两种不同产品的描述，而不是一张评分卡。去掉说话人分离、偏置和归一化，换来的正是吞吐量。把 40,000 条通话录音批量回填到搜索索引，并不需要时间戳或说话人轮次——它需要的是便宜，并且需要能跑完——而对这项任务来说，那些缺失的功能并不是缺失，而是被卸掉的负重。

对于任何实时场景，情况则恰恰相反。如果你在构建语音智能体，关键术语列表正是让“Kubernetes”和“Granola”以及客户姓名拼写正确的方式，而一个没有偏置机制的转录器每次都会把它们弄错，除了微调之外别无他法可以修正，而微调是一个预算不同的另一个项目。仅仅这一个缺失的功能，就让 TurboCTC 在某些工作负载中被排除在外，而在另一些工作负载中则无关紧要，这就是为什么模型比较不如工作负载比较有用。

无法清晰进行的准确性比较

IBM 在 Open ASR Leaderboard 上报告，Apache 2.0 检查点在公开英语短音频数据集上的总体词错误率为 5.00%，非商业姊妹版本为 4.85%。这些是榜单上的批处理数字，而该榜单的评估包含 AMI、Earnings22 以及长音频对话数据集；它们由厂商自行报告——通过榜单工具跑了流程，但尚未纳入官方表格，官方表格还包含私有测试集。模型卡上公布的各数据集细分结果值得一读，因为平均值掩盖了很多信息：LS Clean 1.42%、LS Other 2.66%、SPGISpeech 3.18%、Voxpopuli-Cleaned-AA 4.88%、Earnings22-Cleaned-AA-chunked 6.69%、AMI-Cleaned 7.52% 和 Gigaspeech-Cleaned 8.67%，平均正好为 5.00%。同一张模型卡还给出在单台 H200 上测得的平均 RTFx 为 13,042.98——高于 IBM 发布博文中使用的 12,600，而这两个数字都出自该公司，来自同一周、同一硬件。

Grok Voice Transcribe 2.0 的 2.7% 最终转写稿数字并不是一个可比的测量值。它来自 Artificial Analysis 的 AA-WER Streaming 榜单，这是一个加权综合指标：AA-AgentTalk 占 50%、VoxPopuli 占 25%、Earnings22 占 25%——大约是八小时按智能体场景加权的英语对话音频，并通过流式接口进行测量。数据集不同，加权方式不同，运行模式也不同。把 2.7% 与 5.00% 并列，并由此断定托管模型的准确率大约是其两倍，是这种比较中最容易犯、也最常见的错误。

能如实说的其实更窄，但仍有用。两个模型各自在其被测音频上都很强。Grok Voice Transcribe 2.0 在一个独立运行的流式测试榜上领先，其他模型也在该榜上被测，因此它的排名是可核查的，即便其具体数值无法直接套用。Granite Speech 5.0 470M TurboCTC 在标准开放 ASR 集上有一个总体 WER，另外还有一个远场结果：非商业检查点准确率排第五，Apache 版排第九——这是在噪声和混响语音上测得的，而这是该集中最难的条件，也可以说是两个模型数字中最诚实的一项。

如果你的音频是干净的英语朗读语音，那么这两者之间的准确率差距很可能比排行榜名次所显示的要小。如果音频有噪声、带口音、属于电话语音或非英语，那么这两个排行榜都无法告诉你太多信息，只有你自己的测试集才是唯一能说明问题的工具。

自由重量与每小时1.67美元相比

成本对比是这两款模型真正容易区分的地方，而人们通常引用的那个数字在两个方向上都错了。

• 批量转录 — Grok Voice Transcribe 2.0 为每音频小时 $0.10，即每 1,000 分钟约 $1.67；相比之下，Granite Speech 5.0 470M TurboCTC 无授权费用，但需另计 GPU 时间

{{1}}• 流式处理——每音频小时 $0.20，每 1,000 分钟约 $3.33，而 IBM 未发布托管的流式处理方案{{/1}}

• 许可证——商业 API 不提供权重，而主检查点采用 Apache 2.0，更准确的非商业版本则采用 CC-BY-NC-SA-4.0

“Free”在第一行里承担了太多分量。一个 470M 的纯编码器模型小到足以在普通硬件上运行——这正是该设计的要点，也是 IBM 用八块 H100 训练十天、以 `transformers>=5.16.0` 为依赖发布并附上 WebGPU 演示的原因——但 GPU、服务栈、自动扩缩容、重试和值班轮换总得有人买单。在小规模下，托管价格通常比工程时间更便宜。在稳定的大规模用量下，租用硬件这条路更划算，而交叉点取决于你的利用率，而非你的音频量：一块持续忙碌的 GPU 每小时成本很低，而一块为了峰值流量保持热备的 GPU 则不然。

有一个许可细节值得在任何人围绕它做架构设计之前先指出来。两个检查点中更准确的那个，也就是 WER 为 4.85% 的那个，是采用 CC-BY-NC-SA-4.0 的非商业检查点。Apache 2.0 检查点是 5.00% 的那个，而它才是你可以随产品发布的那个。这是用 0.15 个百分点的准确率差异，换取究竟能否使用该模型的权利；这也意味着，任何为“Granite Speech 5.0”引用 4.85% 然后讨论商业部署的比较，引用的都是错误的检查点。

决策规则

要区分这两款模型，三个问题比任何基准测试表都快。

转录是在说话人还在说话时就被实时使用吗？如果是，TurboCTC 就不是候选——不是因为它慢，而是因为它没有流式接口，也没有部分输出，而部分转录与快速批量解码是两种不同的架构承诺。如果否，那么吞吐量优势就成了全部关键，而按处理每小时音频的成本计算，IBM 的模型非常难以击败。

这项工作需要领域词汇吗？如果需要，带偏置功能的模型默认胜出，而 TurboCTC 缺少关键词偏置就是取消资格的理由，而不只是不便。如果不需要，那你就是在为托管侧一个根本不会用到的功能付费。

音频是在不错的硬件上录制的英语朗读语音吗？如果是，两者都很强，选择就取决于运维。如果不是，两块板子都没有参考价值，只有你自己的评估才重要。

无论最终选择哪条路，真正让这个决策变得低成本的，是运营层。OrcaRouter 把 200 多个模型放在一个兼容 OpenAI 的密钥之后，并支持跨提供商的自动故障转移，因此某个单区域托管语音端点偶尔“状态不佳”，不再会成为你的服务中断；同时提供商标价以 0% 加价直接透传——这意味着供应商的价格调整或新检查点，当天就能在我们这边上线。对于正确答案确实尚不明确的工作负载，这消除了选错的代价：在一个端点后面用你自己的音频对两者做基准测试，留下胜出的那个，等下一个模型发布时再改一下模型字符串即可。

简而言之：对于“廉价地、在我们自己掌控的硬件上转录我们曾经记录下的一切”这个问题，Granite Speech 5.0 470M TurboCTC 是更好的答案；而对于“实时、准确地转录，且无需我们运行服务栈”这个问题，Grok Voice Transcribe 2.0 是更好的答案。12,600× 这个头条数字和 0.49 秒这个头条数字都是真的，但两者都不能作为关于对方的证据。