Granite Speech 5.0 2B 对比 Whisper large-v3-turbo：IBM 在基准测试中胜出，Whisper 则胜在 99 种语言

就大多数人最先查看的两个数字而言，Granite Speech 5.0 2B击败了Whisper large-v3-turbo，而且差距并不小。IBM 的模型在 Open ASR Leaderboard 的九个英语短音频测试集上平均词错误率为 5.06%，速度为 570 RTFx；OpenAI 的 turbo 检查点在同一个榜单上以 200 RTFx 的速度平均为 7.83%。在同一基准测试上，它更快也更准确，而两者的发布日期相差约两年。如果你的音频是英语，而且音质干净，那么这就是全部的比较，你可以不用再往下读了。像这次发布背后的那些有记录的 AI 故障和智能体事件，都收录在OrcaRouter AI Incident Archive中，其中每条记录都带有自己的来源、严重程度、置信度等级和争议标记。

这个页面仍然有必要存在，原因就在于第三个数字：99。Whisper large-v3-turbo 覆盖九十九种语言；Granite Speech 5.0 2B 支持六种语言转写，并可翻译成另外两种语言。如果音频是越南语，那么英语上 2.8 个百分点的 WER 优势就毫无价值。所以真正的问题不是哪个模型更好——而是你的语言组合是否能装进一个六种语言的盒子里，以及如果能，迁移成本是多少。

Whisper large-v3-turbo 实际上是什么

这里值得说得精确一些，因为这个名字常被套用到并非它的事物上。Whisper large-v3-turbo 是 OpenAI 对 large-v3 的剪枝版本：编码器保持不变，但解码器只有 4 层，而不是 32 层。仅这一项改动就把模型从 15.5 亿参数降到 8.09 亿参数，并将吞吐量大约提升到三倍，而准确率损失相对较小——这正是为什么它在 2024 年 10 月发布后的几个月内，成为整个生态系统中默认的快速 ASR 检查点。

从该设计可以得出三个特性，它们对这项比较都很重要：

• 它是一个恰好被剪枝的翻译模型，因此继承了 99 种语言的转写和语种识别能力——但 turbo 变体并未针对翻译进行训练。与 large-v3 不同，它能转写并识别语言；它不会将一种语言的语音转写为另一种语言的文本。团队经常在基于它构建之后才发现这一点。

• 解码器是自回归的。它每次写入 token 时按 4 层推进，因此其吞吐量停留在 200 RTFx，而不是数千 RTFx。Whisper 的速度来自移除层，而不是改变解码范式。

• 它采用 MIT 许可证，在实践中，它恰恰在某一方面比 Apache 2.0 更宽松，而这一点对某些法务团队来说很重要：没有需要分析的专利授权条款，也没有需要随附分发的署名文件。

Whisper 真正的优势从来都不是基准测试成绩。而是两年积累起来的工具生态——faster-whisper、whisper.cpp、各家云平台的托管端点、量化方案、词级时间戳库，以及建立在其之上的说话人分离（diarization）技术栈。这个生态构成了实实在在的迁移成本，本次对比必须诚实地将其纳入考量。

哪些差距是真实存在的，哪些只是测试框架造成的假象

5.06% 对 7.83% 的对比是在同一排行榜上进行的，这使其比大多数跨厂商数字更可信——但这并非同口径的运行，而且细节对双方都有利有弊。

• Granite 的数字来自 IBM 自己提交给排行榜的评测运行，公告博客将其描述为“非官方，截至 2026 年 10 月 15 日”。模型卡则将同样的结果称为截至 10 月 20 日的“官方”结果。你爱用哪个形容词就用哪个；IBM 之外无人复现过它。

• Whisper 数值是排行榜针对该检查点公布的结果，由排行榜自己的评估工具运行得出，这与 IBM 的流水线不同。

• 这两个数字是九个公开测试集的平均值，其中大部分是来自 LibriSpeech、Gigaspeech、SPGISpeech、Earnings-22、AMI 和 VoxPopuli 的英语朗读语音。Whisper 在这一榜单上的弱点已有充分记录，且是结构性的：它是在 68 万小时弱监督网络音频上训练的，这换来了广度，却牺牲了精确的格式化能力。

• 在远场和嘈杂音频上，排序依然成立。FFASR 榜单——将近场、高 SNR、中 SNR 和低 SNR 平均后——显示 whisper-large-v3 为 18.02%，Granite Speech 5.0 2B 为 14.80%。请注意，这是 large-v3，而不是 turbo；在困难音频上，turbo 通常比其父版本略差，因为它的解码器层数更少，难以从糟糕的声学猜测中恢复。

因此，准确率差距在方向上可能是真实存在的，而且在公平较量中可能小于 2.8 个百分点。毋庸置疑的是它来自哪里：Whisper 的解码器被要求用四层同时完成语言识别、转写、标点、大小写和时间戳对齐，而 Granite 的架构则将声学工作（带有字符头和 BPE 头的 CTC 编码器）与文本生成（一个 1B 语言模型）分开。

语言框，量化

决策正是在这里做出的，因此它值得的不只是要点列表中的一个数字。

• Granite Speech 5.0 2B 可转写英语、法语、德语、西班牙语、葡萄牙语和日语，并在这六种语言与英语之间互译，还可将英语翻译为意大利语，以及将英语翻译为普通话。

• Whisper large-v3-turbo 可转写九十九种语言，并能识别出它听到的是哪一种语言。它不进行翻译。

• Granite 的七语言同系列模型 Granite Speech 5.0 470M TurboCTC 在转录语言集中新增了意大利语——因此该系列覆盖的语言达到七种，包括欧洲语言和日语，而非六种。

99 对 7，就是支持 Whisper 的全部论据，而且这论据很有力。但实际的语言分布比数量更重要。如果你的音频是英语、法语、德语、西班牙语、葡萄牙语、日语和意大利语，Granite 就能覆盖。如果你需要印地语、阿拉伯语、韩语、土耳其语、波兰语、越南语、印尼语、荷兰语、瑞典语或其他九十来种语言，Whisper 是这两者中唯一可用的——而英语上再大的 WER 优势也改变不了这一点。

大多数团队实际所处的正是中间这种情况：一个以英语为主的产品，带有一长尾语言，而这些语言只在百分之几的情况下出现。两个模型，每个层级一个，是正常且正确的答案——而且它比听起来更便宜，因为长尾正是流量低的地方。

长音频、时间戳，以及规模化时容易出问题的地方

Whisper 的部署方案在很多方面都已成熟，而这些方面并未体现在任何基准测试中。词级时间戳、语音活动检测、说话人分离、带分块解码的流式处理——这些全都已经存在，全都经过实战检验，而且其中很大一部分都建立在 Whisper 的 30 秒窗口及其时间戳 token 的假设之上。

Granite Speech 5.0 2B 的形态有所不同。IBM 建议分段最长约两分钟，对于更长的录音则使用 VAD 进行切分，语言模型会在 16k YaRN 扩展上下文中接收 10 Hz 嵌入。基础 2B 检查点上没有词级时间戳头——4.1 代推出了单独的“-plus”变体，用于带说话人归属的 ASR 和词级时间戳，而目前尚不存在等效的 5.0 变体。

如果你正在构建字幕、带说话人标签的会议转录，或任何需要按短语定位的功能，那这就是一个实实在在的缺口。5.0 博客确实描述了时间戳方面的改进，但这些改进属于更新后的 granite-speech-4.1-2b-plus，而不是 5.0 2B。

• 需要词级时间戳——目前可用 Whisper large-v3-turbo；如果你想要 Granite 系列并能接受较旧的声学模型，则可用 Granite 4.1-2b-plus。

• 需要进行说话人归属——答案相同；5.0 2B 做不到。

• 需要在超过几分钟的长音频上保持准确性——Granite 建议的两分钟分段是一条实际限制，而 Whisper 采用 30 秒分块并以上下文为条件，这有其自身众所周知的失败模式（静音时陷入重复循环）。两者都没有明显更好；两者都需要在其前端加入 VAD。

Granite 具备而 Whisper turbo 不具备的两项功能

关键词偏置。 Granite Speech 5.0 2B 每个提示可接受最多 2,000 个术语的关键词列表，并基于欧洲和日语语言组中 23,600 小时的关键词偏置音频进行了训练。Whisper 没有等效接口——最接近的是用提示字符串来引导风格和词汇，但其背后没有训练支持。对于需要转写产品名称、药品名称、工单 ID 或客户自有术语表的部署场景，这是两个模型之间最有用的一项差异，而且它不会体现在任何 WER 平均值中。

语言 ID 提示。你可以告诉 Granite 音频使用的是什么语言，并指示它进行转写而不是翻译。Whisper 会自动检测语言，并且在 turbo 变体中只进行转写。对于你已经从元数据中知道语言的混合语言语料库，强制指定语言可以消除一整类错误——Whisper 偶尔会错误识别短音频片段，然后自信地用错误的语言进行转写。

迁移：真正可行的分步指南

如果语言问题得以解决，切换的痛苦就没有生态差距所暗示的那么大，因为大多数基于 Whisper 的流水线已经具备了你所需的接缝。

1. 保留你的 VAD。两个模型都需要分段，而不是整个文件。你用来为 Whisper 切分音频的任何方法，对 Granite 也同样适用，只是每段最长可达两分钟，而不是三十秒。

2. 替换解码调用，而不是底层管道。Granite 可通过 transformers>=4.52.1 中的 AutoModelForSpeechSeq2Seq 和 AutoProcessor 加载，也可通过 vLLM、Q8_0 量化的 llama.cpp，或在 Apple Silicon 上通过 mlx-audio 加载。如果你的服务是通过外部调用 faster-whisper 实现的，那不过是把一处本地模型调用换成了另一处。

3. 重写提示词。Granite 是由指令驱动的，提示词决定模式：原始转录、带标点转录、关键词偏置、锁定语种识别。这一步常被团队跳过，然后他们得出结论说模型更差，因为他们喂给模型的是 Whisper 的默认行为。

4. 要在你自己的音频上重新建立 WER 基线，而不是在 LibriSpeech 上。这不是走形式。Whisper 在排行榜上的弱点是格式化和长音频漂移；如果你的音频是 30 秒的干净英语片段，且你的下游环节是能修正格式的语言模型，那么你测得的差距可能接近零——或者，如果你的音频带口音且是远场，差距会大于 2.8 个百分点。

5. 保留回退路径。Granite Speech 5.0 2B 的非英语覆盖范围是一个硬性边界，在多语言产品中，模型前面的语言检测器不是可选项。任何超出这七种语言范围的内容都会路由到 Whisper。

路由层在何处体现其价值

第五步是这次迁移中真正演变为架构设计的部分。在两个语音模型前面加一层语言与质量的分发调度，再加上之后负责整理转写文本的语言模型，意味着每个文件要调用三次模型；而分别对接三家供应商，正是让一条简单的流水线变成维护难题的原因。

OrcaRouter 是一个兼容 OpenAI 的端点以供应商列表价提供 200 多个模型，不额外加价，因此后处理阶段——清理、摘要、字段提取——都可以替换或进行 A/B 测试，而无需改动语音代码；供应商发生故障时会自动切换，而不是让任务失败。路由 DSL 可以承载分发规则本身：检测语言，将七种受支持的语言发送到自托管的 Granite 检查点，其余全部发送到 Whisper，再把转写文本交给任务所需的任意清理模型。这最后一跳是我们今天真正能够提供的；Granite Speech 5.0 2B 和 Whisper large-v3-turbo 都不在我们的目录中，因此语音模型仍留在你自己的硬件上，路由从下游一步开始，而即便如此，它仍能省去大部分集成工作。

谁应该切换，谁不应该切换

如果满足以下情况，就切换：你的音频是英语加上六种 Granite 语言，你更看重准确率而非对现有生态的熟悉程度，你需要关键词偏置或强制指定语言，并且目前可以接受没有词级时间戳。5.06% 对 7.83% 是一个关键方向上的真实差距，而 570 RTFx 对 200 RTFx 意味着这次切换很可能同时降低你的 GPU 开销。

如果你需要其他九十二种语言中的任何一种、词级时间戳、说话人归属或托管端点，就不要切换——截至本文撰写时，Granite Speech 5.0 2B 尚未被任何推理服务商部署，如今自托管是获取它的唯一途径。Whisper large-v3-turbo 则随处可用，包括那些不允许你运行自有 GPU 的环境。

如果你有很长的语言长尾，就两者都运行。调度成本很低，长尾按定义就是低流量，而且这消除了 Whisper 剩下的唯一理由。