Ming-3.0-asr-tiny 对比 Granite Speech 5.0 470M TurboCTC：参数多 19 倍，吞吐量却毫无优势

把 Ming-3.0-asr-tiny和Granite Speech 5.0 470M TurboCTC放在同一页上，最先跳出来的数字是参数量之比：88.7 亿对 4.7 亿，约为十九比一。第二点是，小模型才是为速度而生的那个，而且优势极大；第三点是，这并不矛盾。Granite Speech 5.0 470M TurboCTC 没有需要运行的解码器——它是一个输出字符后就停止的编码器。Ming-3.0-asr-tiny 有一个 24 层的混合专家解码器，每次写一个 token，并且可以事先被告知即将说出哪些名字。一个是面向英语音频的吞吐机器。另一个是面向中文音频的上下文机器。IBM 于 2026 年 8 月 25 日发布了 Granite Speech 5.0 470M TurboCTC，配有博客文章、技术报告和 Open ASR 排行榜条目；inclusionAI 于 2026 年 10 月 14 日将 Ming-3.0-asr-tiny 的权重放上 Hugging Face，完全没有任何公告。此处使用的每个 Granite 数字都来自 Granite Speech 5.0 470M TurboCTC 模型卡，其中包含 Open ASR 表格、噪声扫描和单语言声明。像这次发布背后的、有记录的 AI 故障和智能体事件，都收集在 OrcaRouter AI Incident Archive中，每一条记录都有自己的来源、严重程度、置信度等级和争议标记。

这两个模型都不在 OrcaRouter 目录中，也都没有出现在对方的评估中，因此没有可引用的厂商直接对比。以下内容均来自各模型自己发布的配置和图表，并已按此标注。

架构分岔，说得直白些

Granite Speech 5.0 470M TurboCTC 是一个纯编码器模型，IBM 表示这是有意背离自身过往。此前的 Granite Speech 模型由一个声学编码器、一个投影器和一个带 LoRA 适配器的 Granite 语言模型组成——也就是说，它们是戴着麦克风的语言模型。5.0 一代完全舍弃语言模型，并在 16,384 单元的 BPE 头上优化 CTC 目标。16 个 conformer 块、1,024 维隐藏维度、8 个注意力头、128 帧上的块注意力、第 8 个块处的自条件化，以及宽度为 7 的卷积核。

下采样是带来速度提升的部分。音频以每秒 100 帧、320 维的 log-mel 加差分形式输入。三级 2× 缩减——先是通过重塑将连续帧堆叠起来，然后在头两个 conformer 块内部使用步长卷积——将其降至每秒 12.5 个输出 token。IBM 的博客明确指出，这是相较其早期编码器的变化；早期编码器每秒输出 50 个字符：每秒音频的输出步数减少为四分之一，并且没有自回归循环来决定每一个输出。

Ming-3.0-asr-tiny 在这里真正重要的每一个维度上都反其道而行之。它的解码器是 24 层混合专家结构，包含 128 个专家，每个 token 路由 8 个，另有一个共享专家和一个稠密的第一层，并以三个 K​imi Delta Attention 层与一个 Gated MLA 层交替排列。它以自回归方式生成 token。它还带有一个 32 层、1,280 维的 Whisper 形状编码器——也就是 Whisper large-v3 的形状，仓库中还随附了 modeling_whisper_encoder.py 以及 O​penAI 的 MIT 声明，放在单独文件中。Ming 保留了语言模型，并让它成为开销最大的部分。

这些数字实际上从何而来

这一节决定两个模型的说法各应得到多大重视，而这两个发布版本在性质上不可相提并论。

• Granite Speech 5.0 470M TurboCTC — 截至 2026 年 8 月 25 日，在 Open ASR 排行榜的公开英语短语音数据集上，总体 WER 为 5.00%，其中 LibriSpeech test-clean 上为 1.93%，test-other 上为 3.59%。其非商业版本得分为 4.85%。在单块 H200 上使用批处理推理时，吞吐量超过 12,600 RTFx。arXiv 上有一份技术报告，Hugging Face 上有一篇博客文章，相关结果已提交至一个列出这些结果的公开排行榜。

• Ming-3.0-asr-tiny — 在中文公开集上平均 CER 为 3.55，在英文公开集上平均 WER 为 3.99，在十五个方言集上为 8.42，在五个内部领域上为 1.67，在上下文 ASR 汇总集上为 4.36。所有这些都以 PNG 图片形式存在于模型卡上。没有技术报告，没有排行榜提交，仓库中也没有评测脚本。

那篇博客文章值得打开，原因和模型卡值得打开的原因一样：它是 Ming 所没有的线索。IBM 发布了一篇注明日期的文章、一份技术报告和一条排行榜条目，而文章中的吞吐量声明可以对照它所描述的批处理配置进行核查。

这种不对称并不是在贬低 Ming 的数据；它说明的是你能核查什么。任何人都可以用公开数据在一个下午重跑 Granite 的 Open ASR 指标。要重跑 Ming 的指标，则必须重建其测试集，其中包括五个内部领域，而这些领域的构成并未公开。

还有一处不对称，而且方向相反：这两个模型没有共用任何一个评估集。Granite 的图表仅限英语，涵盖 LibriSpeech、AMI、Earnings-22、GigaSpeech、SPGISpeech、TED-LIUM 和 VoxPopuli。Ming 的英语平均值则使用 LibriSpeech、Multilingual LibriSpeech、FLEURS English、Common Voice 15 English 和 VoxPopuli——五项中仅有两项重叠，且聚合方式不同。想要知道“哪个在英语上更准确”的读者，从任何一家厂商那里都得不到答案，因为两家都没有问这个问题。

速度在这里意味着两种不同的东西

IBM 的 12,600 RTFx 是一个批处理吞吐量数字：音频被成批送入 GPU 处理，每消耗一秒算力就能处理超过三个半小时的语音。对于转录存档资料来说，这是个恰当的数字；但对于实时麦克风输入，它几乎毫无意义。IBM 确实提供了流式处理——浏览器中的 WebGPU 演示、分块注意力（chunkwise attention），以及面向 Apple Silicon 的 MLX 路径——但那个头条数字描述的是批处理场景。

Ming 完全没有公布 RTFx。它公布的是一个体量：17.7 GB 的 BF16 权重，以及一个带有 128 个专家的自回归解码器。逐 token 循环就是成本模型。每多一秒音频，就意味着更多解码器步数，而每个解码器步都会触及一次跨 128 个专家的路由决策。这正是规模小 19 倍的仅编码器模型反而能宣称吞吐量的结构性原因，而这一点无需基准测试来证明也成立。

实际后果是，它们并不是在争夺同一个部署场景。Granite Speech 5.0 470M TurboCTC 的设计目标是能放在笔记本电脑、手机或单块 H200 上，持续处理播客存档。Ming-3.0-asr-tiny 则需要一块 CUDA GPU、PyTorch 2.11.0、torchaudio 2.11.0、Transformers 5.12.1、fla-core 0.5.2 和 trust_remote_code=True，以及如果你想把它作为服务提供，还需要一个固定到特定提交的独立 SGLang 适配器。其中一套的依赖清单是可以直接放进产品里的。

Granite 为达到这一目标而放弃的能力

仅编码器设计换来了速度和体积优势，而 IBM 对相应代价也直言不讳。其博客称，5.0 模型放弃了配备 LM 的版本曾具备的一些能力，并点名了语音翻译和关键词偏置。第二点很有意思，因为关键词偏置正是 Ming 所称的 Context ASR，并被其视为主打功能。

Ming 接受将热词列表或上一轮对话作为转写提示的一部分，厂商自己的示例很有启发性：在一段音频片段中，电影标题“同囚”在普通路径下输出为“同球”，而在提供主题和热词列表后则正确输出。该卡片谨慎地说明，热词是提示而非保证，这是一种诚实的表述——偏置会改变概率，但并不会强制输出。

Granite Speech 5.0 470M TurboCTC 没有对应的机制。它没有提示词、没有上下文字段，也没有可提供的名称列表，因为它根本没有可供施加条件的语言模型。如果你的音频中充斥着产品名称、药品名称或来自客户数据库的姓氏，那么模型只有一个工具：它在训练中学到的东西。IBM 对这类问题的答案是提供一个 notebook，用于在自有数据上微调，而这是另一种工作流程，成本也截然不同。

语言覆盖范围也是如此。Granite 是英语，并明确表示为唯一支持的语言，在八块 H100 上用十天时间基于约 60,000 小时英语音频训练而成。Ming 支持中文和英文，包含十五个中文区域方言测试集，涵盖粤语、闽南语和上海话，方言平均分为 8.42，其自家图表显示该成绩领先于其列出的每一个开源基线。

在两者之间选择

如果你的音频是英语，而你的问题在于数据量——通话录音、存档资料、会议转写，以及任何每小时成本比最后那一点准确率更重要的场景——那么 Granite Speech 5.0 470M TurboCTC 是更合理的起点；而且它能以量化形式通过原生 C++ 运行时运行，无需 Python，这是一项部署优势，再多的中文方言覆盖度也无法抵消。

如果你的音频是普通话或某种地区方言，或者准确率问题是你能够提前列出的专有名词，那么 Ming-3.0-asr-tiny 是两者中唯一能解决这一问题的，而且它依靠的是为此构建的架构，而不是临时加上的微调。它发布也才五天，下载量只有 35 次，这意味着你会是最早发现它如何失败的人之一。

还有第三种情况值得点名：你两者都想要，并且想知道在你自己的流量上哪一个更胜一筹。这正是 OrcaRouter 专为解决的路由问题。这两个模型都没有托管在那里——Ming-3.0-asr-tiny 和 Granite Speech 5.0 470M TurboCTC 都是自托管的开放权重——但同一个作为你托管模型前端的端点，也可以作为候选 ASR 路径的前端，并具备自动故障转移，使失败的请求回退到现有模型而不是暴露给用户；同时一个密钥即可通用于 200 多个模型，因此这种比较不需要第二份合同。

两家供应商都未曾向你展示过的东西

两个模型都没有经过任何独立方的评分。Granite 的数据至少还出现在一个其他团队也会提交的公开排行榜上，这意味着这些数据是可以被质疑和讨论的；Ming 的数据则放在四张 PNG 图片里，而这些图片在发布当天下午仍在被编辑。两张模型卡都没有记录词级时间戳或说话人分离，因此任何需要时间信息的流水线对两者都不在适用范围内——Granite 的模型卡描述的是纯转写输出，而 Ming 的使用说明明确指出，输出是不带词级时间戳或说话人分离的转写文本。

真正能为这件事下定论的比较，两家厂商都做不了。它需要同一个语料库、同一个语言对、同一个评分脚本，以及让两个模型跑在同一块 GPU 上。在有人公布这样的结果之前，唯一站得住脚的说法，就是这些架构本身已经表明的那一点：一个大十九倍的自回归混合专家模型，在吞吐量上无法与仅编码器的 CTC 模型竞争；而仅编码器的 CTC 模型无法被预先告知要预期哪些词。