Nemotron 3.5 Transcribe 对比 Granite Speech 5.0 470M TurboCTC：参数量多 64 倍，速度慢 43 倍

这个对比中最有用的对象是一个 279 兆字节的文件。那就是 Q4_K_M 量化版的 Granite Speech 5.0 470M TurboCTC，IBM 的仅编码器语音识别器；它能在笔记本电脑 CPU 上转写英语，无需 GPU、无需像样的 Python 环境，也无需服务合同。Nemotron 3.5 Transcribe，NVIDIA 于 2026 年 10 月 28 日以开放权重形式发布，是一个 300 亿参数的语音增强型语言模型，需要数据中心级加速器以及大约 60 GB 的 BF16 权重。NVIDIA 的模型大 64 倍，并且按各厂商公布的吞吐量数据，每 GPU 秒大约慢 43 倍。它也是两者中唯一能告诉你谁在说话的那个。

这两个事实都不足以一锤定音。它们描述的是两台不同的机器，只不过碰巧被放在同一个排行榜上衡量；而整件事的关键在于，你的工作负载需要的是实实在在的空间，还是仅仅需要那些字面上的说法。

一种非自回归 CTC 模型与生成式语音大语言模型的对比

Granite Speech 5.0 470M TurboCTC 由 16 个 Conformer 块构成，输出层包含 16,384 个 BPE 单元，以 CTC 目标函数训练，并采用贪心解码。它没有语言模型，没有投影器，也没有生成循环：音频输入后，直接输出帧同步的标签序列，并从 100 Hz 下采样至 12.5 Hz。正是这一设计让它速度快、体积小，也让它无法完成标签集之外未覆盖的任何事情。它没有提示词的概念，没有输出风格，没有翻译目标，也没有说话人字段。

Nemotron 3.5 Transcribe 采用相反的架构，而这种差异并非代际差距。语音编码器将输入馈入一个冻结的 Nemotron 3 Diarization 模型，该模型的说话人活动信号通过 Parallel Expert Encoder 注入编码器；一个混合 Mamba–Transformer 的专家混合解码器以文本形式生成转写，其 300 亿参数中每个 token 约有 40 亿参数处于活跃状态。由于输出是生成而非分类得到的，因此它可以接受指令：逐字或书面形式、预期实体列表、翻译目标、带说话人归属的输出，或针对音频所提问题的语音回答。

• 参数——总计约 30B，每个 token 约 4B 激活，而仅编码器模型为 470M。

• 解码——基于30B MoE的自回归生成 vs 贪婪式非自回归CTC。

• 许可证 — OpenMDW-1.1 与 Apache-2.0（两者中限制更少的一个；IBM 另行发布的 -nc 同类许可证为 CC-BY-NC-SA-4.0）。

• 占用空间 — BF16 约 60GB，另有 NVFP4 和 GGUF 版本可选，而社区 GGUF 移植版的 Q4_K_M 仅 279MB。

• 语言——转录 40 种，翻译 31 种，而 2026 年 10 月 21 日多语言更新后为 7 种（英语、法语、德语、西班牙语、葡萄牙语、意大利语、日语）。

• 说话人 — 最多 8 位，可归属，支持 13 种语言，对比之下为无；说话人分离需单独模型。

• 时间戳——通过解码后 CTC 适配器实现词级时间戳，对比不使用适配器；CTC 峰值位置并非词边界。

• 流式传输 — 无，仅录制音频 vs 无。

准确率差距小于规模差距，并且平均值并不匹配。

IBM 报告称，多语言 TurboCTC 版本在九个公开英语测试集上的平均词错误率为 5.51%，较 8 月发布时的 5.78% 有所改善。NVIDIA 报告称，在 Hugging Face Open ASR Leaderboard 上的英语 WER 平均为 5.33%，并在其自身研究页面的九个公开测试集上为 4.71%。这两个数字均来自厂商报告，而且这两个平均值并非同一构成：IBM 的九个测试集与 NVIDIA 在排行榜上的八测试集条目在构成和归一化方式上不同，而研究页面单独给出的九测试集数字又与其自身排行榜条目不同。不要将它们相减并把差值称为质量差距。站得住脚的说法更狭窄——在公开英语短音频排行榜上，这两个结果相差不过零点几个百分点，对于一个规模小 64 倍的模型来说这是非凡的结果，也提醒人们排行榜平均值中有多少是 LibriSpeech 式的干净朗读语音。

词错误率同样掩盖了真正将它们区分开来的东西。Granite 是一个分类器：它输出最可能的标签序列，而在声学上存在歧义的地方，它会输出某种看似合理的内容。Nemotron 背后有一个语言模型来生成文本，这正是其上下文提示能力——在提示中提供实体列表时，在 ContextASR-Bench 上命名实体错误减少六倍——得以实现的原因。在一份满是产品代码的销售通话转写稿上，小模型没有任何机制来引入这种偏置，而大模型则有。

吞吐量：19,870 RTFx，对比 462

Nemotron 3.5 Transcribe 在 Hugging Face 排行榜条目中的 RTFx 为 462.09——这意味着在该排行榜的测试框架上，模型每秒计算大约可处理 462 秒音频。IBM 在十月更新中报告，TurboCTC 在单块 H200 上的 RTFx 为 19,870；在采用单块图复用优化后，这一数值较发布时的约 12,600 有所提升。这是 43 倍的差异；与 WER 数值不同，这一差异至少是在两种有竞争力的加速器上测得的，而不是在两种不同的测试混合集上测得的。

NVIDIA 自己给出的标题则是另一种数字：在单块 RTX PRO 6000 Blackwell 上，使用 NVFP4 检查点和 DFlash2 草稿模型，每秒可处理高达 2,238 秒的音频。这比排行榜上的 462 更高，因为它是不同的测量方式——正如 NVIDIA 自己的 Hugging Face 帖子所述，在高并发下使用 30 秒音频片段，启用了投机解码，并且所用的量化方式当时仍被描述为即将推出。把两者放在一起看，诚实的结论是：Nemotron 的吞吐量会因配置不同而相差一个数量级，而 TurboCTC 的吞吐量则是由其架构决定的特性。一个没有自回归循环的模型，不可能像 30B MoE 那样慢。

4.7亿参数能带给你什么，而300亿参数却不能

第一个答案是部署形态。一个 279MB 的 GGUF 可运行在 CPU 上、在贴近手机的边缘设备上、在桌面应用内，如果你有耐心，还能在 Raspberry Pi 级别的板卡上运行。现在已有社区提供的 GGUF 移植版，以及一个将该模型视为一等引擎的 C++ 运行时系列。Nemotron 3.5 Transcribe 可在 vLLM 搭配 NeMo Speech 插件或 SGLang-Omni 下运行，使用 80GB 加速卡并以 BF16 运行，或在 Blackwell 卡上以 NVFP4 运行。这些并不是同一谱系上的两个点；它们属于不同的采购类别。

第二点是延迟下限。CTC 模型通过一次前向传播即可返回转写文本。生成式模型一次只返回一个 token，其在短文件上的实际延迟主要取决于解码循环，而不是音频本身。对于批量归档处理，这无关紧要。但对于任何交互式场景——听写框、通话质量监控器，以及必须跟上拖动进度的字幕工具——小模型是两者中唯一能在用户察觉之前完成处理的模型。

第三点是许可清晰度。Apache-2.0 是法务部门已经批准的许可证；OpenMDW-1.1 则足够新，以至于其中一些法务部门会希望进行审查。如果你的阻碍是采购表格而不是基准测试，那么 IBM 的模型能更快地通过这一关。

300亿参数能带来什么，而4.7亿参数做不到

说话人，首先且具有决定性。TurboCTC 完全没有任何说话人表示。要获得带说话人归属的转写文本，需要在它前面加一个说话人分离模型，再加一个合并步骤，并为合并步骤留出误差预算——这就是标准的级联方案。Nemotron 3.5 Transcribe 将一个冻结的说话人分离模型并入编码器，直接输出说话人标签，最多八个，支持 13 种语言，并通过解码后的 CTC 适配器提供带说话人归属的词级时间戳。NVIDIA 报告称，在 David AI 基准上跨 21 种语言的说话人分离错误率为 18.26%，在 14 个系统中最佳，最接近的竞争者是其自家的 Nemotron 3 Diarization 模型，为 18.38%。这些是厂商在其自家测试框架上给出的数字，尚未被独立复现。它们所暗示的级联对比——一个模型对三个模型——根本不是基准主张，而是对部署方式的描述。

语言和翻译次之。TurboCTC 在 10 月更新后覆盖七种语言；Nemotron 支持四十种语言转录，并支持三十一种语言与英语互译。如果你的队列只涉及欧洲语言且为单语，七种就够了。如果不是，比较就到此为止。

第三，微调。NVIDIA 报告称，在单块 GPU 上，每个任务的适配耗时为 0.5 到 2.3 GPU 小时；并给出一个医疗语音示例：在 3,619 个片段上微调后，词错误率从 30.8% 降至 11.8%，留出说话人的错误率从 22.44% 改善至 12.17%。IBM 的 TurboCTC 也可微调——它是 Apache-2.0——但你将是在一个小得多的模型上微调 CTC 头，而且额外上下文能带来的上限更低，因为没有语言模型可供“说服”。

决定成败的成本模型

TurboCTC 的经济性几乎平淡得乏味。一台 H200 以 19,870 RTFx 提供服务，就能让一个非常大的队列饱和；而在普通 CPU 上运行一个量化后的 279MB 构建，每音频小时的成本几乎可以忽略不计，电费才是真正的支出项。整个技术栈中没有任何按分钟计费的计量器。

Nemotron 的经济性形态相同，只是规模不同：不按分钟计费，但加速器大得多，吞吐上限也低得多。一张 Blackwell 卡每秒可处理 2,238 秒音频，在高并发下不到三分钟就能处理 100 小时，而在存在重叠发言的一小时会议场景中，处理量会少得多。

• 每月 20 小时的队列——在 CPU 上运行 TurboCTC 实际上几乎不花什么钱；Nemotron 则需要租用或自备加速器，而该加速器在一个月的大部分时间里都会闲置。

• 对于每月 2,000 小时、无说话人识别要求的归档任务而言——在单块 GPU 上运行 TurboCTC，或使用一小批 CPU，都是成本更低、速度更快的配置，且优势十分明显。

• 每月 2,000 小时的六人会议存档——TurboCTC 加说话人分离器再加合并层，在单卡上与 Nemotron 对比测量。这是唯一能让大模型价格站得住脚的配置，而且即便如此，级联方案在硬件上仍更便宜。

• 任何受保密限制且禁止上传音频的情况——两者均可自托管，因此无论采用哪种方式都能满足该限制，决定便取决于说话人和语言。

流水线的后处理环节，正是路由层无论你选用哪种识别器都能体现其价值的地方。OrcaRouter 用一个密钥即可接入 200 多种文本与多模态模型，供应商标价按 0% 加价率透传，自动故障转移，以及路由 DSL，可将一类转写文本发送给廉价的摘要器，将另一类发送给更强的模型，而无需第二套集成。该目录既不提供 Nemotron 3.5 Transcribe，也不提供 Granite Speech 5.0 470M TurboCTC——我们不托管语音转文本服务——因此语音选择仍是一份单独的合同，只有其上层变得可移植。

根据工作的形态来选择，而不是看排行榜。

如果任务是“把大量干净、以英语为主的音频尽可能便宜、尽可能快地转成文本”，那么 Granite Speech 5.0 470M TurboCTC 会胜出，而且差距悬殊——它是一个 279MB、采用 Apache 许可的模型，速度超过一个 30B 系统四十倍以上，而在公开英语平均成绩上几乎没有什么损失。你为说话人构建的级联，就是这种效率的代价；如果你从不需要说话人，就永远不必付出这个代价。

如果任务是“从四十种语言中的某一种的困难录音里，产出一份带说话人归属、带时间戳的结构化转录稿”，那么 Nemotron 3.5 Transcribe 是两者中唯一尝试这项任务的那一个，而供应商给出的说话人分离数据——尚未被独立复现——表明它在这件事上比它所取代的级联方案做得更好。吞吐量的代价是实打实的，硬件成本也是实打实的，而对于会议密集型的负载来说，这两者都算不上难以承受。

要避免的错误，是把它当成一场代际竞赛。470M CTC 模型并不是 30B speech LLM 的过时版本；它是另一种工具，只是恰好在一个主要由干净朗读语音构建的基准上取得了相近的分数。下一次发布并不会让它过时。你自己最差的那段录音会告诉你，你需要的究竟是哪一个。