Grok Voice Transcribe 2.0 对比 VibeVoice ASR Streaming 7B：微软未公布的那个数字

VibeVoice ASR Streaming 7B 是微软推出的统一流式语音识别器，于 2026 年 9 月 2 日上传至 Hugging Face，次日以 MIT 许可证在 microsoft/VibeVoice 仓库中发布。它做到了 Grok Voice Transcribe 2.0 及其大多数竞争对手都没做到的一件事：在音频到达的同时输出带说话人归属的文本，无需单独的说话人分离阶段。微软的技术报告称，该 7B 检查点在五个评估集上取得了最低的平均 WER 和 CER，并在 13 项评估设置中有 12 项取得最佳或并列最佳的说话人归属。但模型卡没有做的事是：用文字公布哪怕一个数字——没有 WER，没有 RTF，没有延迟数据；这些结果仅以报告中的图片形式存在。Grok Voice Transcribe 2.0 于十六天后的 2026 年 9 月 18 日发布，批量处理每小时音频收费 0.10 美元，流式处理每小时 0.20 美元，它公布了一切：在 Artificial Analysis 的流式排行榜上，最终转写 WER 为 2.7%，首个部分结果 WER 为 3.4%，两者延迟均为 0.49 秒。因此，这场对比诚实的起点是：两个模型中有一个是可衡量的、文档记录更完善的，而这种不对称本身就是这场较量中最具决策相关性的事实。

Microsoft 发布了什么，以及读者可以用它做什么

VibeVoice 报告是真实的研究，其中的主张即便在价值上未必如此，在形式上也很具体。它评估了四个会议基准——AliMeeting、AISHELL-4、AMI-SDM 和 AMI-IHM——外加 MLC-Challenge，涵盖九种语言，并报告了两项主要结果：7B 模型在这五个集合上的平均 WER/CER 最低，并且在 13 个评估设置中的 12 个里取得了最佳或并列最佳的说话人归属。两者都是相对性主张，而这是一种有意义的主张类型：“在这五个集合中最低”是一个关于排序的陈述，而排序正是买家所需要的。

缺失的是每一个绝对数字。没有任何可供比较的 WER 百分比，没有吞吐量数字，没有延迟测量，也没有按数据集分列的文本细分。把 VibeVoice 与 Grok Voice Transcribe 2.0 并列并给微软模型分配一个数字的比较表，是在凭空捏造那个数字。可以说的是，VibeVoice 在自己五数据集的评估中胜出，而微软之外的任何人都没有重新运行过它——没有独立基准测试，没有第三方评估，而且在撰写本文时，没有任何托管推理服务商列出该模型。因此，这一比较是在一个有记录的数字与一个无记录的排名之间进行的，而无记录的排名并不会仅仅因为缺少小数点就成为两者中较弱的一方。

Grok Voice Transcribe 2.0 的文档则存在相反的问题。它的 2.7% 和 3.4% 来自 Artificial Analysis 的 AA-WER Streaming 榜单，这是一个加权综合指标：AA-AgentTalk 占 50%，VoxPopuli 和 Earnings22 各占 25%——约八小时的智能体形态英语对话音频，由独立机构运行，其来源可信度确实高于厂商自家的评估。但它只是英语中一个狭窄的切片，而且该榜单页面本身只标绘了 33 个模型中的 27 个，而 SpaceXAI 在宣称于 32 个模型中排名第一时，统计的却是 33 个模型。狭窄测试上的精确数字与更宽泛测试上的不精确说法并不能直接相提并论，本文也不会假装它们可以。

两秒半对半秒

延迟对比是唯一一处可以将这两个模型直接并列比较、而无需就数据集附加任何说明的地方，因为两者都公开了各自的流式配置——而这种差异源于架构本身，而非调参取舍。

VibeVoice ASR Streaming 7B 以块为单位工作。其已发布的检查点每个块使用 22 个潜在帧，而在模型每秒 7.5 个潜在帧的速度下，这大约相当于每个块 2.9 秒的音频，并带有四个潜在帧的前瞻——大约 0.5 秒的未来音频——以及约 2.00 秒的预期说话人归属延迟。它每个块输出一次文本。这是一个真正的流式系统，但节奏以秒而非毫秒衡量。

Grok Voice Transcribe 2.0 在说话者停止后 0.49 秒返回首个部分转写，并在语音结束后 0.49 秒定稿。它用速度换来了准确性——首部分错误率从 1.0 版的 18.3% 降至 2.0 版的 3.4%，代价是在同一指标上从 0.25 秒增至 0.49 秒。

并排放置：

• 流式节奏 — Grok Voice Transcribe 2.0 连续发出部分结果，首个部分结果延迟为 0.49 秒，而 VibeVoice ASR Streaming 7B 大约每 2.9 秒发出一个文本块

• 说话人归属延迟——包含在同一条 0.49 秒路径内，而按设计约为 2.00 秒

• 前瞻——未公布，对比四个潜在帧，约 0.5 秒的未来音频

• 实际效果——语音代理可以对正在形成中的句子采取行动，而一个系统则是每三秒接收一段带说话人标签的段落

这两种做法都没错。对于会议转录来说，2.9 秒的片段是完全合理的设计，因为它的产出是一份文档，而其价值在于文档在会议进行期间而非会议结束后送达。但对于对话式智能体来说，这就是错误的设计，因为三秒的沉默不是停顿，而是故障。这两种节奏之间的差距大约有六倍，而它几乎恰好对应着转录一场对话与参与一场对话之间的差别。

说话人归属作为输出，而非流水线阶段

这正是 Microsoft 模型真正领先的地方，而这种设计值得了解，因为它正是分块粒度较粗的原因。

VibeVoice 使用两个预训练分词器——一个声学编码器和一个语义编码器——以 24 kHz 运行，并进行 3,200× 下采样，从而每秒产生 7.5 个潜在帧，即每 133 毫秒一帧。这些帧被投影到 Qwen2.5 语言模型主干中，传入的语音和生成的文本作为单一序列交错排列，先前观察到的语音和文本则保留在模型的上下文中。其结果就是，说话人身份从来都不是一个单独的问题：模型并不是先转写、再判断谁说了话，而是在以仍然包含这些声音的音频历史为条件来生成文本。这就是为什么不存在需要对齐的说话人分离阶段，也是为什么 Microsoft 关于在 13 种设置中有 12 种实现说话人归属的说法在架构上是可信的，而不是一个外挂式的结果。

这种设计的代价是历史保留量会随录音长度线性增长，因此已发布的检查点面向的是最长八分钟的录音。这是一个真实的上限，而且这一点被明确说明。它使该模型无法用于长时长任务——两小时的财报电话会议、一整天的联络中心音频——除非你自己构建分段和重新初始化，而这恰恰重新引入了该架构原本旨在消除的复杂性。

Grok Voice Transcribe 2.0 以不同方式解决同一个问题，并且有着一组不同的限制。它无需额外费用即可包含说话人分离功能，并在单次请求中最多支持八个独立音频通道。对于联络中心电话场景，每位参与者通常各自通过自己的通道接入，通道分离比说话人分离更可靠，而且不附带错误率。对于混合音频，则取决于说话人分离的质量；与 Meta's Muse Voice Transcribe 不同——后者公布了 17.5% 的平均说话人分离错误率——SpaceXAI 根本没有公布任何说话人分离数据。因此，两个模型都在说话人分离证据上留下了空白：一个公布了排名却没有数值，另一个公布了功能列表却没有测量结果。

十八吉字节，十种语言，MIT

部署情况差异如此之大，几乎算不上是可比对象。VibeVoice ASR Streaming 7B 的 bf16 权重约为 18 GB——Hugging Face 模型卡为这个名为 7B 的检查点列出了 90 亿总参数，而一个 1.5B 的同系列模型约为 5.6 GB——采用 MIT 许可，并提供 Python 演示和一个用于服务的 vLLM 插件。十种语言：中文、英语、法语、德语、意大利语、日语、韩语、葡萄牙语、俄语和西班牙语。微软将其定位为用于研究与开发。

Grok Voice Transcribe 2.0 是一个托管端点，无需下载权重，支持 12 种输入格式（从 8 kHz 电话音频到 48 kHz）、最多八个声道、每个请求 100 个关键术语、带录制中途切换的自动语言检测、覆盖 25 种语言的逆文本归一化、最大 500 MB 的文件，以及每个团队每秒 10 次请求和 100 个并发流式会话的服务限制。它仅在 us-east-1 运行。

• 权重 — MIT 许可，18 GB，归你所有、随处可运行 vs 无，仅限供应商托管

• 语言 — 10 种命名语言 vs 自动检测，支持跨 25 种语言的格式设置

• 关键词偏置——通过热词支持，每次请求最多 100 个关键词

• 录制时长 — 每个检查点约八分钟，之后历史记录保留会成为限制，而对方未公布上限，文件最大 500 MB

• 区域控制——你部署所在的区域与 us-east-1 的对比

• 成本 — 无许可费，另需 18 GB GPU 内存和一套服务栈；相比之下，批处理每小时 0.10 美元，流式处理每小时 0.20 美元

一个 18 GB 的模型不是能随便在笔记本电脑上跑的东西，而 vLLM 插件意味着需要一块拥有真实显存的 GPU。但反过来说，如此规模的模型采用 MIT 许可证并不常见，也很有价值：两者之中，只有它能在你自己的网络内部运行、完全无需与任何供应商建立关系——对于受监管的音频而言，这不是偏好问题，而是硬性要求。托管方案按小时计费很便宜，却无法在本地部署。

路由决策应该放在哪里

成本是这两个模型最终能以得出具体数字的方式进行比较的地方。Grok Voice Transcribe 2.0 的批处理路径成本为每音频小时 $0.10，约合每 1,000 分钟 $1.67；其流式路径为 $0.20，约合 $3.33。VibeVoice ASR Streaming 7B 完全没有许可成本；它取而代之的是大约 18 GB 的常驻 GPU 内存，以及一套由你运维的 vLLM 服务栈。这种规模的 7B 级模型，在租用硬件上按音频小时计费不会便宜，而且利用率曲线毫不宽容——一块为峰值流量保持热备的 GPU，无论是在转写还是空闲，成本都一样。

这就是"自建还是外购"之争的典型形态，而其结论会因用量规模、以及音频是否被允许离开你的网络而不同。过去一个月里发生变化的是答案更替的速度：流式识别的准确率头名在三周内两度易主，一个9月初发布的模型到9月中旬就已被取代。任何让模型选择难以逆转的架构，如今在这个品类里都是错误的架构。

OrcaRouter 正是让这种反转变得成本低廉的地方。一把兼容 OpenAI 的密钥即可覆盖 200 多个模型，并支持跨提供商自动故障转移，因此单一区域的托管端点故障只是一次路由事件，而非服务中断；同时，提供商目录价以 0% 加价直通——这意味着供应商调价或发布新检查点，当天就能在我们这边生效。对于想要用自己的音频把 VibeVoice 与 Grok Voice Transcribe 2.0 做对比测试的团队，或是想让自托管备用方案与托管主方案共用同一接口的团队而言，调用端不再是那个必须做出改变的地方。

坦率的结论是：VibeVoice ASR Streaming 7B 是更有趣的模型，Grok Voice Transcribe 2.0 是更好用的产品，而这两种说法之间的差距，完全可以由一家厂商发布图表、另一家发布数字来解释。如果你的需求是本地部署、带说话人归属、时长不到八分钟的会议转录，那么微软的模型检查点是两者中唯一符合条件的一个。如果你的需求是能在对话停顿内回答的语音智能体，那么 2.9 秒的分块节奏在讨论准确率之前就已经把它排除了。如果你还在等那场能一锤定音的对比——同一段音频分别跑两个模型，由不在两家公司任职的人评分——这样的测量还不存在，下次有表格在 VibeVoice 的名字旁边放上一个数字时，这一点值得记住。