事件:IBM 把 ASR 推回到 encoder-only

2026 年 8 月 25 日,IBM 在 Hugging Face 社区博客上同步放出 Granite Speech 5.0 TurboCTC 的两块模型:granite-speech-5.0-470m-turboctc(Apache 2.0)和 granite-speech-5.0-470m-turboctc-nc(CC-BY-NC-SA-4.0)。两块都是 470M 参数,只在训练数据和许可证上有差异,核心架构完全一致(来源:IBM Granite HF 博客)。

这件事最反直觉的点在于:IBM 这次主动把 Granite Speech 家族里的语言模型和 LoRA 适配器砍掉了。前几代 Granite Speech 模型采用"声学 encoder + projector + Granite LM + LoRA 适配器"的三段式,新模型直接退回到纯 encoder + CTC。IBM 在博客里把这块拆得很清楚:"The encoder-only design provides strong transcription performance, a small memory footprint of only 470M parameters, and over 20x faster throughput than previous Granite Speech models."

砍掉 LM 的代价是显式的:模型放弃了语音翻译、keyword biasing 这些需要 LM 参与的能力。但 IBM 把收益的另一面摆在 OpenASR Leaderboard 上:在公开 short-form 测试集上,非商业版 WER 4.85%、Apache 2.0 版 WER 5.00%,聚合 RTFx 超过 12,600。这两个数字不是孤立的——前者保证了"够准",后者保证了"够快"。

速度是怎么做到的:从 50 字符/秒降到 12.5 token/秒

Granite 5.0 跟前代共享四个底层组件:16 个 Conformer block、第 8 层后接 self-conditioning、chunkwise attention 避免注意力随序列长度二次增长、CTC 损失函数。变化集中在输出端的 token rate。

前代 encoder 每秒吐 50 个字符;新模型压到了 12.5 token/秒,tokenizer 也换成了基于语音转录文本训练的 SentencePiece(NC 版)或 BPE(Apache 版)。从 100 帧/秒的 log Mel spectrogram 压到 12.5 token/秒,靠三段 2× 降采样:第一段是相邻 log Mel 特征向量的简单 reshape(这一段前代就在用),第二、第三段被嵌进堆栈最前面的两个 Conformer block,用 stride=2 的卷积做时间维下采样,同时把残差连接里的相邻位置做平均以匹配降采样后的时间步长。

换句话说,不是更聪明的算法,是更稀疏的输出。token rate 砍到 1/4,叠加纯 encoder 不再被 LM decode 拖慢,最终在 H200 上拿到 12,600+ RTFx——按 IBM 的说法,这意味着批推理 1 秒能跑完 3.5 小时以上的语音。同等准确度下,FFASR 远场榜单上 NC 版排名第五、Apache 版第九,两块同时还是榜单上速度最快的两个。

为什么这件事对边缘设备更值得看

Granite Speech 5.0 的副标题不是"击败 Whisper",而是"ideal for speech-to-text tasks on edge devices"。把 LM 砍掉之后,模型只剩 encoder,显存/内存占用直接落到 470M 这一档;CTC 解码是贪心的,不需要 beam search 和大语言模型侧的 KV 缓存;Hugging Face 还配套上线了一个 Chrome/Edge 才能跑的 WebGPU 流式 demo,意味着在浏览器里也能跑这套 470M 参数的 STT。

IBM 在博客里还做了一件不太张扬但很实用的事:把训练数据配方完整列出来。两块模型共用 7 个公开数据集(MLS 44,600 小时、YODAS 8,900、CommonVoice-17 2,500、Librispeech 960、VoxPopuli 500、AMI 150、Earnings-22 100),NC 版额外接入 GigaSpeech 10,000 小时和 SPGI Speech 4,900 小时。除此之外还合成了 3 套:MLS/YODAS/CommonVoice/VoxPopuli/AMI 的多说话人拼接 2,000 小时、Earnings-22 拼接 500 小时,以及用 gpt-oss-120b / gpt-oss-20b 生成文本、StyleTTS2 合成的 240 小时数字/货币/网址/电话/小数点专项语料——这一段直接展示了 IBM 怎么用大模型去造小模型的训练数据。

给读者的判断:为什么这不只是一个 ASR 发布

把这件事放到 2026 年下半年的趋势里看,信号其实很清楚:通用大模型不适合所有任务,小而专的 encoder 在窄任务上正在反超。Whisper、Canary、SenseVoice 这类端到端 STT 一直在堆参数、加 LM 加能力;IBM 反着走,把 LM 拆掉,只留 encoder,代价是丢掉翻译等"看起来很酷"的能力,换来的是 1/20 的延迟和 1/数十分之一的内存。

对想在终端、浏览器、嵌入式设备上做实时转写的人来说,Apache 2.0 那块模型几乎是一个现成的生产级底盘:470M 跑得动 CPU,CTC decode 没有外部依赖,token rate 砍到 12.5 让流式输出更跟得上说话节奏。这也是为什么 IBM 把 WebGPU 流式 demo 放在 Hugging Face Spaces 上而不是论文图里——他们要让你打开浏览器就能体验"砍掉 LM 之后到底有多快"。

所以如果你正在做边缘语音、车载语音、会议纪要、电话客服这类对延迟敏感、对翻译能力没要求的场景,Granite Speech 5.0 TurboCTC 是一个可以立刻拿去试的、许可证干净的 470M 选择;反过来,如果你需要语音翻译或 keyword biasing,前代 Granite Speech 仍然是 IBM 官方推荐的路线——这两件事在 IBM 的产品矩阵里是并行的,不是替代。

参考链接:Granite Speech 5.0 TurboCTC 模型卡(Apache 2.0)、WebGPU 流式 demo。