Granite Speech 5.0 2B 与 Granite Speech 5.0 470M TurboCTC：吞吐量提升 35 倍，WER 仅相差 0.45 个百分点

IBM 在相隔不到一天的时间里先后发布了两个 Granite Speech 5.0 检查点，而它们有意思的地方并不在于其中一个更大。真正有意思的是，Granite Speech 5.0 2B在 Open ASR Leaderboard 上以 570 RTFx 取得 5.06% 的平均英语 WER，而Granite Speech 5.0 470M TurboCTC以 19,870 RTFx 取得 5.51%——用远不到半个百分点的准确率代价，换来了约三十五倍的吞吐量。如果你以为参数数量能带来成比例的收益，那并没有。它带来的是翻译、关键词偏置、语言 ID 控制，以及一个能够遵循提示的语言模型。速度不在这个列表上。像本次发布这类发布背后有记录可查的 AI 故障和智能体事件，均收录在OrcaRouter AI Incident Archive中，其中每条记录都附有自己的来源、严重程度、置信度等级和争议标记。

这两个数字都来自 IBM 自家，在同一个排行榜上测得，发布日期相差不到一周，因此这算是现有较为干净的同一家族内部比较之一——但同时也仍应假定它是厂商自己跑的评测，而非经过审计的评测。这两个模型都没有独立复现；截至撰稿时，我能找到的任何推理服务提供商都没有提供它们，包括我们自己的目录。

同一周，两则不同的发布故事

这两个模型并不是尺寸不同的双胞胎。它们的发布方式不同，构建方式也不同，而发布历史解释了为什么它们的模型卡读起来如此不同。

• Granite Speech 5.0 2B — 仓库创建于2026年10月7日，权重于当晚提交，模型卡公开编辑了两周，发布日期标注为10月20日，公告博客于10月21日发布。新模型，低调开场，高调收尾。

• Granite Speech 5.0 470M TurboCTC — 于 2026 年 8 月 25 日首次发布，是一个仅支持英语的模型，宣称达到 12,600 RTFx。10 月 21 日发布的是一次更新，而非新模型：架构相同，新增一个 16,384 词元的多语言 BPE 头、六种新增语言，以及原生标点符号和大小写处理。

当你细看这些数字时，这一差异就很重要。2B 的 5.06% 是对一个新检查点的最新评估。470M 的 5.51% 相比 8 月公布的 5.78% 有所提升，而 IBM 的博客将其表述为“尽管新增了六种语言，英语 WER 反而更好”，这才是正确的解读方式——多语言更新并没有牺牲英语准确率，反而有所提升。

两种架构，同一个后果

Granite Speech 5.0 2B 是一个语音-语言模型。16 块 Conformer CTC 编码器馈入两层窗口查询 Transformer 投影器，该投影器以 10× 下采样为 10 Hz 声学嵌入，这些嵌入进入 granite-4.0-1b-base 的中间检查点，该检查点使用 YaRN 扩展到 16k 位置。监督微调是在投影器和语言模型上联合应用 LoRA。生成是自回归的：语言模型逐 token 写出转录文本。

Granite Speech 5.0 470M TurboCTC 是一个编码器。十六个 Conformer 块、CTC 目标函数、一个 16,384 单元的多语言 BPE 分类头、以 8 为因子的时间下采样（将 100 Hz 的帧降至 12.5 Hz）、贪心非自回归解码。没有投影器，没有语言模型，没有生成循环。输出之所以带有标点和大小写，是因为模型被训练为在 token 流中输出标点，而不是因为事后由第二个模型添加。

后果本身构成了整个比较的实质。一个生成 token 的 2B 模型存在每 token 的延迟下限，无论批处理规模多大都无法完全消除；而非自回归编码器在一次前向传播中就能输出全部结果，因此吞吐量几乎只随批大小扩展，其他因素影响甚微。正因如此，一个参数量只有四分之一大小的模型，最终速度是三十五倍，而不是四倍。

这也是 470M 放弃 2B 所具备的一些能力的原因。没有需要遵循的提示，因此没有语言 ID 指令，也没有关键词列表，也没有翻译——CTC 头将声学特征映射为 token，无法要求它将德语语音呈现为英文文本。

记分牌，以及每个数字的来源

• 参数 — Granite Speech 5.0 2B 为 2B；Granite Speech 5.0 470M TurboCTC 为 470M。

• 英语 WER，Open ASR 9 组平均 — 5.06% 对比 5.51%。两次均为 IBM 评估运行，2026 年 10 月 15–20 日。

• 吞吐量，RTFx — 570 对 19,870。相同的排行榜测试框架，相同的日期范围。

• 噪声和混响条件下的 WER，FFASR — 14.80%（在 42 个中排名第 4）对比 17.57%（排名第 12）。2B 的鲁棒性约高出 2.8 个百分点。

• 许可证 — 两者均为 Apache 2.0。TurboCTC 还有一个 -NC 版本，采用 CC-BY-NC-SA-4.0 许可；发布前请核对仓库名称。

• 语言 — 六种转录语言（En、Fr、De、Es、Pt、Ja）外加翻译，对比七种（增加意大利语）但不提供翻译。

• 控制功能——2B 上支持语言标识提示、可偏置至 2,000 个关键词的关键词偏置以及语音翻译；470M 上则不具备这些功能。

• 训练——2B 模型在 8 块 H100 上历时 40 天，共 390,000 小时；470M 模型在 8 块 H100 上历时 24 天，共 153,000 小时。

稳健性差距才是人们会跳过的那一行。35 倍速度很吸睛，但在远场嘈杂音频上 17.57% 的 WER 对 14.80%，意味着 19% 的相对错误率差异，而大多数真实部署面对的就是嘈杂音频。如果你的音频来自厨房里的一台笔记本电脑，那么小模型的速度优势就被花在了你随后还得手动纠正的转写文本上。

470M 在准确率上真正胜出的唯一地方

日语。TurboCTC 卡片声称，在 CSJ eval1、CommonVoice-17 和 FLEURS 这三个测试集上，其在字符错误率方面优于 2B 模型，并在卡片文本中明确说明了这一点，而不是把它埋在图表里。具体数字只出现在一张图中，因此无法引用优势幅度，但这一方向是 IBM 对自家两个模型作出的声明，这使其比跨厂商比较更可信。

有一种合理的机制。2B 通过在字符头上增加 92 个字符的语音片假名集合，并在训练中加入 16,500 小时的日语关键词偏置 ASR 以及 9,600 小时的 Fineweb-2 TTS 来处理日语，但它仍会将结果送入一个主要用欧洲文本训练的语言模型。470M 使用单一的 16,384 单元多语言 BPE 词表，从一开始就包含日语，并在 ReazonSpeech 上投入 8,130 小时、在合成日语上投入 1,860 小时。如果你的产品是大规模日语转写，这就是小模型既更快又更好的那一个对比场景，值得在因为规模而默认选择 2B 之前直接测试一下。

成本，靠计算而非报价

IBM 没有公布这两款模型的价格。两者都是 Apache 2.0 权重，因此运行它们的成本就是硬件成本，而 RTFx 数值是你估算这一成本的唯一杠杆。

以每天 1,000 小时的音频工作负载为例——一个中等规模的呼叫中心存档。在 570 RTFx 下，2B 模型需要约 6,300 秒的 GPU 时间，略高于 1.7 GPU 小时。在 19,870 RTFx 下，470M 需要约 181 秒，即 0.05 GPU 小时。在每小时约 2–3 美元的 H100 上，这相当于每天几美元对几美分。两者都是很小的数字，而关键正在于此：在这个规模下，两个模型都不昂贵，决策应基于准确性和能力，而不是算力。

另一端的计算情况则截然不同。如果你要在笔记本电脑上实时转写单路音频流，或运行设备端应用，2B 需要 GPU 才能跟上实时进度，而 470M 则仍有充足余量——这正是 IBM 将 TurboCTC 定位用于笔记本电脑、手机和边缘设备，并在文档中说明 mlx-audio 面向 Apple Silicon 的原因。2B 也能在 llama.cpp 和 mlx-audio 上运行，但需使用 Q8_0，并附带警告：更低比特量化在音频超过约一分钟后会损失准确性。

按照决策实际发生的顺序进行选择

不要从基准开始。从任务所要求的内容开始，因为其中三项差异是硬性要求，而不是权衡取舍。

输出是否需要与输入使用不同的语言？那么就是 2B，无需进行比较。470M 无法翻译。仅这一项要求就使它在字幕流水线、多语言会议记录以及任何由非英语音频构建的英语存档中被排除在外。

转写内容需要包含特定术语吗？产品名称、药品名称、工单 ID、客户的 SKU 清单——2B 可将最多 2,000 个术语作为关键词列表接受，并且正是为此在 23,600 小时的关键词偏置音频上进行了训练。470M 没有提示词接口。在小模型上无法进行术语表驱动的部署。

音频干净吗？如果是，0.45 个百分点的英语差距很小，35 倍的速度优势几乎是白得的。如果不是——会议、呼叫中心、远场麦克风——FFASR 上 2.8 个百分点的差距说明，小模型出错的代价会超过它靠速度省下的成本。

是日语吗？先测试 470M。IBM 说它在三个日语测试集上都胜出。

它是在设备上运行的吗？470M 就是为此而设计的。2B 可以在一台设备上运行，但并非为此而设计。

坦率的总结是：这并不是同一款产品的两种规格。一个是带有控制界面的转写与翻译系统；另一个是没有控制选项的极快、极便宜的转写引擎。大多数认为自己需要“更好的那个”的团队，实际上需要先回答翻译和术语表的问题，而这两个答案就能定论。

同时运行两者，但不押注任何一方

对于一个要测试这一模型家族的团队来说，合理的生产形态是两者都部署，因为它们具有相反的失效模式。470M 能以几乎可以忽略不计的成本处理大批量干净转录；2B 则处理困难音频、非英语音频以及任何需要术语表的内容。一个对每个传入文件进行分类的路由器——语种检测、信噪比估计、检查是否附带术语表——并把文件发送到正确的检查点，大概只需五十行代码，就能降低长尾上的错误率，同时不必为大批量数据支付 2B 的价格。

那个分类阶段只是一次小模型调用，而它正是值得通过单一端点来运行、而不是嵌入第二个厂商 SDK 的部分：OrcaRouter 将 200+ 个模型暴露在单个 OpenAI 兼容 API 之后，按提供商标价提供且不额外加价，并且其 路由 DSL 可以将语言与质量的分派表达为规则，而不是应用代码。自动故障转移在类似此次发布后的一周内最为重要：当时检查点才发布两天，没有任何独立验证，而尝试它最安全的方式就是保持第二条路径处于可用状态。这些目前都还无法帮助你运行 Granite Speech 本身——今天我们并未提供这两个检查点中的任何一个，因此语音模型仍保持自托管，路由层则从下游一步处开始。

如果你只部署一个，就部署 2B。它能完成 470M 能做的一切，速度仍比实时快三十五倍，并且在 IBM 公布的除日语之外的每一项基准测试中准确率都更高。470M 是当成本或延迟表现值得时才额外加入的专用模型——而不是你一开始就默认选择的模型。