Ming-3.0-audio-tiny 对比 VibeVoice-ASR-Streaming 1.5B：五个破折号对阵带说话人归属的流

打开 Ming-3.0-audio-tiny 的 Hugging Face 仓库中的识别图，并滚动到底部。五行——AISHELL-4、AliMeeting 和 AMI 的说话人分离与拼接最小排列错误率——在 tiny 列中显示为破折号。不是糟糕的数字，而是空白。厂商在全部五行上测量了它更大的同系列模型，却拒绝测量小的那个。现在打开 VibeVoice-ASR-Streaming 1.5B 的模型卡片，读第一条：它在语音到达时持续转写谁说了什么。那就是同样的五行，反过来了。一个模型几乎发布了一切，唯独没有说话人归属；另一个模型的存在主要就是为了发布它。 这类发布背后的已记录 AI 故障与智能体事件收集在 OrcaRouter AI Incident Archive 中，每条记录都带有自己的来源、严重程度、置信度评级和争议标记。

两者都没有经过独立评分。这一点在这里不如通常那么重要，因为这场对比取决于一项设计决策，而不是某个数字：当音频持续不断地到来时会发生什么。Ming-3.0-audio-tiny 是一个文件模型，具有大窗口和可选的语音输出。VibeVoice-ASR-Streaming 1.5B 是一个流式模型，大约每三秒输出一次文本，并为每个片段标注说话人。如果你的工作负载是一段录音，它们会相互竞争。如果你的工作负载是一个房间，那么只有其中一个在真正应对。

配置中“流式传输”的开销是什么

微软的代码仓库对其自身的延迟预算异常清晰，这使得权衡取舍可以被核查，而不是营销说辞。声学分词器和语义分词器都是因果的，并针对 24 kHz 输入以 3,200× 压缩率运行，因此 token 流大约是每秒钟音频 7.5 个 token。流式封装器每块批处理 22 个 token 帧，并带有 4 帧前瞻：22 除以 7.5 约为每次输出 2.9 秒，而 4 除以 7.5 约为模型在提交前被允许看到的未来音频半秒钟。

• 输出节奏——约 2.9 秒；前瞻部分是以延迟为代价换取准确性的环节。

• 主干 — 一个 Qwen2 系列解码器，28 层，隐藏维度 1,536，12 个注意力头（含 2 个键值头），64,000 词元窗口。

• 体积 —— 三个 safetensors 分片，总计 5.63 GB。这并非 1.5B 参数；在 bf16 下，5.63 GB 折算下来接近 28 亿参数，而名称中的 1.5B 最好理解为语言主干，而非整个技术栈。

• 语言 — 十种：中文、英语、法语、德语、意大利语、日语、韩语、葡萄牙语、俄语、西班牙语。

• 附加项 — 作为上下文传入的自定义热词，以及附加到每个输出片段的说话人标签。

• 时间 — 仓库创建于 2026 年 9 月 2 日 15:51 UTC，最后修改于次日早晨。仅通过 VibeVoice GitHub README 中的一行新闻予以公布，也就是说，几乎等于没有公布。

那个 64K 窗口是要拿来与 Ming 的 131,072 对比的数字。它听起来像是容量的一半，但并不是同一种容量。流式模型不需要保留整整一小时，因为它已经把过去五十九分钟记录下来了。这个窗口是用于当前分块的工作记忆，再加上模型向前携带的任何对话上下文。Ming 的 131K 则是相反的赌注：让所有内容都保持活跃，并对其推理。

Ming 的赌注，以及它能换来什么

这个小模型的卖点不是识别准确率——在 inclusionAI 自己的表格上，它在中文上落后于规模更大的同门模型 0.34 个百分点（字符错误率 3.79 对 3.45），在方言上落后 0.89 个百分点（10.29 对 9.40）。它的卖点在于，单个检查点能在同一次前向传递中完成识别、理解、推理和语音处理，而且窗口足够长，长到你可以问出“她在前十分钟说了什么”这样的问题。

它的音频智能分数对于这一规模来说相当可观，也是它比纯转录器更值得选择的原因：MMAU 75.90、MMAR 67.70、MMSU 73.06、BigBenchAudio 99.20，音乐方面 MuchoMusic 58.07。这些均由厂商运行，自评行带有星号，并且说明卡披露，对比模型是在 inclusionAI 自己的提示词和解码设置下复现的。应把这些数字当作设计简报来解读。

表格不会告诉你的是：到底是谁在说话。这正是那五道短横线所标记的缺口，而它是结构性的，不是偶然的。一个能回答关于某段录音问题的模型，并不需要按说话人进行分割才能回答这些问题；而一个要为会议生成转录文本的模型则需要。Ming 也许可以通过提示做出类似说话人标注的事情，而卡片上对“多说话人录音”的强调表明，它是在接近这个问题的地方训练的。但“也许”一词，正在承担五行未公开数据所起的作用。

两条流水线，如实描绘

想象一下，同一段九十分钟的录音分别经过每一个。

使用 VibeVoice-ASR-Streaming 1.5B 时，音频以约三秒一块的粒度到达，文本也以同样的节奏输出，每个片段都带有说话人。你可以实时显示它。代价是每个决策都带有局部性：模型只提前看到半秒以及它保留的上下文，因此一个停顿四秒的说话人回来后可能被标成不同的标签，而第二分钟出现的名字只能通过你提供的 hotwords 机制恢复。跨块一致性是要测试的内容，也是模型卡没有量化的内容。

使用 Ming-3.0-audio-tiny 时，文件一送达，整个内容就都在上下文里，答案该到的时候才到。跨块一致性不构成风险，因为根本没有块——只要不超过窗口。代价是模型完成之前什么都拿不到，而且内存预留是按整个窗口来算的：参考 ASR 配置在 32,768 token 的批次下占用 0.92 张卡。你可以调低 max_model_len；但没法让它流式输出，因为仓库里没有流式路径。

• 延迟形态 — VibeVoice：连续输出，约滞后 3 秒。Ming：最后一次性给出答案。

• 署名 — VibeVoice：按设计逐段标注。Ming：未发布。

• 上下文 — VibeVoice：64K 工作窗口，外加其自身的转录文本。Ming：131,072 个位置，按编码器上的计算推算，如果处理器输入的是单一连续流，大约相当于三小时音频。

• 输出 — VibeVoice：文本。Ming：文本，或通过第二块 GPU 上的可选 Talker 输出文本加合成语音。

• 硬件 — VibeVoice：一个 5.63 GB 的检查点，因此单张普通显卡即可。Ming：Thinker 为 17.74 GB，文本用一张卡，语音用两张卡。

执照和文书是一样的，这很不寻常。

两者都是 MIT 许可。两者都是低调发布。两者都在文档跟上之前就先把权重放了出来，而且都依赖一个并非以该 checkpoint 命名的 GitHub 仓库：Ming 的部署配置位于 inclusionAI/Ming-3.0-audio-flash，而 VibeVoice 的使用说明则位于 microsoft/VibeVoice，与 7B 版本放在一起。

差异在于每个仓库告诉你的内容。微软提供了一份技术报告——arXiv 2609.02812——以及模型卡中的一张结果图；该图是图片而非表格，因此数字无法提取，正文中也没有给出各语言的错误率。inclusionAI 提供了三张基准测试图片，同样是图片，外加一张模型卡；该卡仅通过留空单元格来隐含地说明自身弱点。两家厂商都没有给出一个可以直接粘贴到电子表格而无需手动转录的数字。

对于从事采购的人来说，有一处不对称值得指出：Ming 的 Hugging Face 仓库中不包含 LICENSE文件，只在卡片元数据中有一个指向另一个仓库中许可证的链接。VibeVoice 的卡片在元数据中声明 MIT，且仓库中包含该许可证文件。两项声明都属实；但只有一项位于制品之中。

路由器在这里适用于什么，不适用于什么

OrcaRouter 不提供这两个模型。Ming-3.0-audio-tiny 是一个检查点，VibeVoice-ASR-Streaming 1.5B 也是一个检查点；两者都不在我们的目录中，本文中的任何内容都不构成托管它们的要约。在这样的流水线中，路由器位于转录下游、决策上游：总结通话、提取承诺、判断该片段是否需要人工处理、翻译非工作语言的部分。这些调用都是文本，而一个端点即可访问 超过 200 个模型，0% 加价——供应商列表价直接透传，因此供应商调价当天就会体现在我们这边——从而在构建中省去与每个供应商的一份合同。自动故障转移 正是关键功能：当一项两小时的转录任务必须在凌晨两点把输出交给某个可靠的地方时，它就显得尤为重要。

路由器不会做的是：调和两个彼此不一致的说话人标签，或判断 Ming 缺失的说话人分离行是真正的弱点，还是尚未测量的弱点。这得靠你自己的音频来完成。

能在一下午内区分它们的测试

录一段二十分钟的音频，三个人参与，其中一人有两次抢话压过其他人，还有一人用的是笔记本电脑麦克风。用 VibeVoice-ASR-Streaming 1.5B 跑一遍，把热词列表填上这三个人的名字，因为这正是该模型为这种情况提供的机制。再用同一个文件跑一遍 Ming-3.0-audio-tiny，使用那个已验证的提示词——它要求先给出语言标签、一个制表符，然后是转写文本——然后在第二轮里要求它为每个句子标注说话人。

给四项打分：第一个模型正确识别了多少次说话人切换，录音中途是否有说话人标签发生翻转，第二个模型的归属在整个文件中是否稳定，以及哪个输出你手动修正起来更快。最后一项不是基准测试，但它比任何一家厂商的数据都更能预测你的实际生产体验。

在做这件事时，请记住那些短横线。一个将方言表公布到小数点后两位、却留下五个说话人分离单元格空白的供应商，已经具体地告诉你它的信心止于何处。微软则公布了一个数字而不是一张表，让你自己去解读那幅图景。两家都没有给你一个由陌生人核验过的数字。

每一个真正所属的地方

实时字幕、呼叫中心监控、需要在每行旁边标注姓名的会议助手：VibeVoice-ASR-Streaming 1.5B 正是为这类场景打造的，而且它只有 5.63 GB，能运行在你可能已经拥有的硬件上。对档案进行合规审查、“在这四十段录音里找出所有提到和解的地方”、任何问题是在音频之后而非音频过程中提出的情况：Ming-3.0-audio-tiny 的单一大型窗口及其理解得分更合适；如果没人问是谁说的，缺失的说话人分离行也就不再重要。

错误会是为了一个流式任务而选择 Ming，因为 131,072 是 64,000 的两倍；或者为了一个推理任务而选择 VibeVoice，因为 1.5B 听起来比 9.3B 更便宜。这两个数字所描述的都不是句子所假设的东西，而这正是这次比较所确立的最可靠的一点。