每日 AI 简报，9月19日：Grok Voice Transcribe 2.0 正式上线，Meta 向开发者开放 Muse

Grok Voice Transcribe 2.0 已于 2026 年 9 月 18 日在 Grok Voice API 中上线，录制转写为每音频小时 0.10 美元，流式转写为每小时 0.20 美元——与 SpaceXAI 对 1.0 版收取的费率相同。同一周，Meta 向外部开发者开放了 Muse 连接器平台，允许任何服务公开其现有 API，并让 Meta 的 Muse 智能体代表用户调用它。这些看起来像是来自两家不同公司、关于两种不同产品的互不相关的新闻标题，而在过去两年的大部分时间里，它们确实会是不相关的。放在一起读，它们是同一个故事：转写正在变成一种输入，而争夺的焦点已经转移到谁拥有消费它的那次调用。

先看价格，因为这是读者今天就能据此行动的部分。然后是准确性，这一点确实重要，但比发布时的表述所暗示的范围要窄。最后是Meta那部分，这才是六个月后真正要紧的。

统一价格，以及如果您已经在为转录付费，这意味着什么

Grok Voice Transcribe 2.0 与 1.0 价格相同。不是“起步价”相同，也不是会过期的促销价——而是完全一致：批量处理为每音频小时 $0.10，流式处理为每小时 $0.20，折合每 1,000 分钟 $1.67 和 $3.33。说话人分离、带置信度分数的词级时间戳、逆文本归一化、填充词去除和关键术语偏置都包含在这个价格内，而不是作为附加项另行收费，这在该品类中并非常态。

实际效果是算术层面的，而非戏剧性的。一个每月转写 5,000 小时联络中心音频的团队，无论走哪条路，批量处理路径都要付 500 美元，而新模型能以显著更低的错误率返回同样的量。这次迁移丝毫不改变你的付费金额，而这正是迁移容易获得认可的原因：无需做成本决策，只需做质量决策，而质量提升了。

现有集成的迁移方式是，在 /v1/stt 上将 grok-voice-transcribe-2.0 作为 model 参数传入，或在打开 WebSocket 会话进行流式传输时选择它。无需更改 schema，无需新增端点，也无需重新编码你的音频管线。SpaceXAI 目前仍将 1.0 保留为默认值，因此，从不改动 model 参数的集成会一直获得旧版本，直到该公司将其切换——该公司表示这将在未来几周内发生，同时 1.0 将被弃用。这段窗口期值得有意识地加以利用：将生产环境音频的影子副本指向 2.0，并把转录文本与当前上线的结果做 diff 对比，因为一旦默认值切换，无论你是否测试过，都会运行它。

规格表的其余部分在结构上没有变化，如果你是在为部署做规模规划，而不仅仅是评估准确率，那么这些内容值得了解：12 种输入音频格式，从 8 kHz 电话音频到 48 kHz；单次请求最多八个独立音频声道；每个请求 100 个关键术语，用于领域词汇；自动语言检测，并可在录音中途切换；以及跨 25 种语言的逆文本归一化，让口述的日期、货币、电话号码和电子邮件地址返回时以人类会书写的方式呈现。服务限制为每秒 10 个请求，以及每个团队 100 个并发流式会话；而该服务在单一区域运行——us-east-1——这是规格表上唯一会让生产团队停下来三思的一行，因为单区域语音 API 就是单区域故障。

准确度实际提升在哪里

发布时的说法是“准确度提升一倍”，而背后的数字比这个说法更具体，也不那么整齐划一。在 Artificial Analysis 的 AA-WER Streaming 榜单上——这里是独立的衡量标准——两个版本的区分如下：

• 最终转录准确率——Grok Voice Transcribe 2.0 的词错误率为 2.7%，而 Grok Voice Transcribe 1.0 为 3.9%，两者均在说话者停止后测量

• 首次部分转写准确率——3.4% WER 对比 18.3%，这是两个版本之间最大的单项差距，且差距悬殊

• 达到最终转录时间——0.49秒对0.37秒，因此2.0在此指标上更慢而非更快

• 首次部分成交时间 — 0.49秒对0.25秒，即同一笔交易的反向操作

最后那一对是表格上最有意思的东西。Grok Voice Transcribe 2.0 用大约四分之一秒的延迟换来了它的准确率，而且是双向的。对语音智能体来说，这是实打实的代价——它关乎一个停顿是自然的，还是一个会让主叫方察觉到的停顿——而对批处理流水线来说，它则完全不可见。首个部分转写结果上的改进，才是改变你能构建什么的那一项，因为部分转写正是智能体在主叫方还在说话时可以用来推理的文本。在这个数字上从 18.3% 降到 3.4%，就是从部分转写只是粗略提示，到部分转写真正可用的差别。最终转写从 3.9% 降到 2.7% 是一项不错的改进，但没有任何用户会注意到。

SpaceXAI 还发布了四项内部评估，阅读时值得带上这个标签——这些是该公司针对自家音频给出的自家数据，并非独立复现：

• 8 kHz 客户支持通话 — WER 从 1.0 的 10.6% 降至 2.0 的 7.1%

• 与Grok的对话——从8.7%下降至3.3%

• 口头凭证，即大声读出的姓名、电子邮件和账户详情——从7.2%降至3.2%

• 跨19种语言的短句——从20.6%降至6.8%

8 kHz 那一行才是值得抓住不放的。电话音频是这一类中最难处理的常见输入，也是大多数呼叫中心买家实际会遇到的输入；而这一项从 10.6% 降至 7.1%，对这些买家来说，比榜单上的头条数字意义更大。

排行榜的说法，如实解读

SpaceXAI 表示，该模型在准确率上位列 32 个流式模型之首。Artificial Analysis 的榜单确实在最终转写排名和首个部分结果排名中都将它列在第一位——但榜单页面只标绘了 33 个模型中的 27 个，所以"32"是该公司自己的统计口径，而这一排名所基于的集合，读者理应了解其构成。AA-WER Streaming 是三个英语数据集的加权综合：AA-AgentTalk 占 50%，VoxPopuli 占 25%，Earnings22 占 25%，音频总时长约八小时，且权重严重偏向代理式对话语音。它并不以任何结构化方式衡量口音、电话编解码器、领域词汇或多声道呼叫中心音频。

这一切都不能说明那个数字是错的。它只是说明这个数字是具体的。一个在以智能体通话为权重的英语榜单上领先的模型，对于智能体通话形态的英语音频来说就是正确选择，而相信 8 kHz 结果来自供应商内部评估、而非公开榜单，才是诚实的理由。音频特征不同的买家应该用自己的音频进行测试，而不是把这份排名当作普遍结论来解读——这一点在这次发布之前成立，在下一次发布之后也依然成立。

Meta 向开发者开放 Muse 连接器

本周的第二则新闻是关于 Meta 的。Muse 是 Meta 于 9 月 8 日在 iOS、Android、muse.ai 和 WhatsApp 上推出的个人智能体，如今它开始接受第三方连接器：服务方公开其 API，而 Muse 提供智能体、浏览器和用户上下文，把该 API 变成用户只需开口请求就能调用的东西。Meta 对此的表述是一种分工——你带来 API，我们带来意图和用户。首批被点名的是 Notion 和会议记录工具 Granola，此外还有 Meta 自己推出的那些连接器。

值得明确的是，这是什么，以及不是什么。它不是一套开放的跨智能体协议。构建一个连接器，只能在 Muse 自己的用户群内获得分发，除此之外别无他处；而基于开放协议构建，则能触达所有兼容的智能体，但不归属于任何特定用户群。Meta 也尚未公布开发者规划时需要依据的若干内容——连接器审核流程、技术集成面、Muse 如何在两个功能重叠的连接器之间做选择，或者开发者如何衡量一个连接器是否真正拉动了任何使用量。

毋庸置疑的是方向。Muse 将每个用户的代理运行在各自独立的虚拟机中，为其配备独立浏览器，并在对外操作前设置单独的审核层；它持有的是替身令牌，而非真实的 API 密钥。只有当计划是让代理调用大量服务时，这种架构才说得通。转录 API 正是代理会调用的服务之一，而 Meta 有自己的——Muse Voice Transcribe，这是 Meta 于 9 月初推出的实时模型，价格为每音频小时 0.18 美元。一个同时拥有代理和语音模型的平台，显然有理由将自己的流量导向自己的模型，而在连接器之上构建的开发者也应默认这就是默认做法，除非有什么因素使其不再如此。

一个本月发布语音功能的团队实际上应该做什么

两个故事指向同一个方向。语音准确率正在趋同——三周内，同一榜单上的三个模型彼此相差不超过 1.5 个百分点——而剩下的差异化因素是价格、延迟、许可证，以及谁控制路由。这使得你的转录调用发往何处，比选择由哪个模型来响应它更有影响，因为在接下来的一年里，你会想多次更换那个答案。

这就是 OrcaRouter 所在的层级。一个 API key 就能覆盖 200 多个模型，它们都位于兼容 OpenAI 的端点之后，并具备跨供应商的自动故障转移，因此某个单区域语音服务下午状态不佳，不再等于你的服务中断。我们按0% 加价直通供应商的标价，这意味着供应商降价或新模型版本发布，我们这边当天即生效，而无需等待重新定价。而且由于每个模型都在同一份合同之下，把转录工作负载从一个模型迁移到另一个，只是改一下模型字符串，而不是再来一次采购。

本周有三个具体行动。如果你正在用 Grok Voice Transcribe 1.0，现在就用自己的音频对 2.0 做影子测试——趁 1.0 仍是默认选项、而切换权还在你手里。如果你正在为某个 agent 评估流式语音，请在你自己的延迟预算内测量首个部分结果的时间（time-to-first-partial），而不是相信任何人的榜单——这个模型为换取准确率而花掉的那四分之一秒，究竟是无关紧要还是致命，取决于你的 agent 拿这些文本做什么。而如果你正在构建的东西有朝一日可能被个人 agent 调用，请密切关注 Muse connector program，因为它提出的分发论证，比它发布时附带的技术细节更有分量。