Muse Voice Transcribe：Meta 的流式语音转文本模型，详解

Muse Voice Transcribe 是 Meta 的流式语音转文本模型。它运行在 Meta Model API 上，价格为 每音频小时 0.18 美元，模型 ID 为 muse-voice-transcribe-1.0，无论是流式处理实时音频，还是提交一段已录制完成的录音，价格都相同。它之所以值得单独写一篇参考页，而不是只做一句价格查询，关键在于这些工作在哪里完成：二十多个说话人的说话人归属识别以及语音结束检测都在识别模型内部运行，而不是在音频流末尾外挂一个批处理环节。它只做语音转文本——Meta 的开发者文档明确写道：它不合成语音，也不提供语音到语音的对话 API。

这是读者在搜索该模型自身名称后所落到的页面，因此它被设计成对两个问题给出稳定答案——这个模型是什么，以及一小时音频要多少钱——而不是一篇公告。有一个日期必须先于其他一切记录在案，因为它是关于该模型的事实，而不是这个页面存在的原因：Meta Superintelligence Labs 于 2026-09-01在注明日期的公告帖 Introducing Muse Voice Transcribe中推出了 Muse Voice Transcribe——读者如今仍可通过 Meta 的博客索引找到那篇帖子，尽管它已不在自己的网址上作答。以下所有内容均于 2026-09-29 在 Meta 自己的页面上读取，主要是模型页面以及 API 的语音转文字与概览文档。凡是 Meta 没有公布的数据，本页面会径直说明，而不会去找一个替代指标来充数。

用 Meta 的术语来说，它是什么

Meta 自己的文档在开头就直白地写道：“Muse Voice Transcribe 是 Meta 在 Meta Model API 上的语音转文本模型。可以转录实时音频或已有录音，并具备话轮检测、说话人标签和词汇偏置功能。”概述页面把同样的内容浓缩成一句话——流式说话人分离、原生端点检测和语音活动检测、上下文与关键词偏置，以及 25 种经过评估且支持语码转换的语言。因此，输出是一条单一的转录流，同时携带三种标注：文字内容、说话人是谁，以及这句话是否已经说完。这正是目前大多数生产环境技术栈要靠一个识别器，外加一个独立的语音活动检测器，再加一个独立的说话人分离模型才能拼凑出来的组合，而每个组件都有自己的延迟预算。

Meta 的模型页面将其表述为“具有竞争力的延迟、流式转录准确率，并支持 20 多位说话人的实时归属”，而开发者文档则将输出字段描述为“带有轮次级时间信息和可选说话人标签的转录文本”。由此可以得出两点，而这两点都比这套表述本身更重要：

• 这是一个音频输入、文本输出的模型。它既不是文本输入型，也不是文本输出型，而且 Meta 明确表示它不是语音生成器。

• 它首先是一个流式模型。实时路径并不是对文件路径的封装；它是一个 WebSocket 会话，拥有自己的事件、模式和限制，如下所述。

一小时音频的费用是多少

Meta 的 Muse Voice Transcribe 模型页面将价格表述为“使用单一模型构建，每小时 $0.18”，其规格表中则将 muse-voice-transcribe-1.0 列为 每小时 $0.18音频，以及 每 1,000 分钟 $3.00。这是同一费率的两种单位表述，二者均印在 Meta 自己的页面上（查阅日期为 2026-09-29）。开发者文档以第三种方式陈述了同一费率：“定价为 每小时 $0.18的已处理音频。”本页面上的任何数字都不是从 Meta 定价页面沿用而来的，因为并不存在可读取的 Meta 定价页面：文档将该费率链接到一个“定价与速率限制”页面，而该页面在 2026-09-29 查阅时显示 此页面不可用，因此模型页面是该费率的权威记录来源，也是此处唯一采用的来源。

计费详情就在开发者文档中，在确定工作负载规模之前值得了解：

• 流式与非流式成本相同。实时端点没有额外费用。

• 根据文档，零数据保留处理与标准层级定价持平——它并非一项附加费用。

计费向下取整至整秒，因此一个两秒的轮次计费为两秒，而不是三秒。

• 在转录内容生成之前发生的失败不计费，429 速率限制响应同样不计费。

• 免费额度存在于平台层面，而非模型层面。Meta 的语音转文字文档在定价段落结尾写道：“平台免费套餐额度适用。”这是该模型页面上唯一涉及免费内容的措辞，而且刻意含糊其辞：它指向的是平台层面的额度方案，而非承诺转录的免费额度，也没有给出任何具体数字、期限或资格规则。应将其理解为可能减少账单的额度，而不是该模型的免费套餐。Meta 面向消费者的声明称其个人智能体“对人们所需的大部分内容免费”，这是关于 Muse 应用的独立表述，并不适用于 Model API。

举个实际例子，因为按小时计价很难有直观感受：一段两小时的录音访谈，转录费用是 0.36 美元。一千小时的通话音频——大致相当于一个中型联络中心的月处理量——是 180 美元。在这种规模下，费率就是全部论点的关键，而费率也是唯一可能在你脚下悄悄变动的东西：Meta 的页面是这方面的权威，如果那里的数字变了，这里的数字也会变。

流式接口，逐端点

This is the part a reference page owes a reader that a launch write-up cannot carry, so here it is in the order you meet it. Base URL for Model API is https://api.meta.ai/v1 with a Bearer token, and Muse Voice Transcribe adds two endpoints on top of it.

• 实时音频 — wss://api.meta.ai/v1/asr/realtime。传输协议为 WebSocket，而认证细节则是个陷阱：你是在握手帧中完成认证的，并且 Authorization 头会被忽略。握手必须是第一个 JSON 文本帧，且必须在 10 秒内到达。一个会话最长持续 60 分钟，每新建一个 WebSocket 就会创建一个新会话，而且没有恢复令牌。

• 录音 — POST https://api.meta.ai/v1/asr/transcribe。使用分段（multipart）上传，并且这个接口确实使用 Authorization 请求头进行身份验证。输入格式很窄：仅支持 16 或 24 kHz 的单声道 16 位 PCM WAV。上限为每个请求体 32 MB，每次请求音频时长 10 分钟。

在实时会话中，三种模式会改变你收到的内容。 PUSH_TO_TALK 是默认模式，执行单轮转写。 ENDPOINTING 提供由模型检测的轮次边界，每个检测到的语音片段为一个轮次，并发出 speechStart、重复的 transcript、speechEnd 和 speechComplete 事件——但要注意，speechEnd 并不是转写文本。 DIARIZATION 增加了自动说话人检测与归属，发出 speaker 事件，其标签类似于 A 和 B。部分转写结果要么是累积式的，即每个部分结果都会替换前一个，要么是增量形式的。

同一份文档中的两个操作细节很容易被忽略，而一旦在生产环境中才发现，代价往往很高：

• 说话人分离（Diarization）标记的是可能的新说话人，而不是干净的语音端点，并且 Meta 表示它并未针对低延迟的语音命令使用场景进行调优。请将这些标签视为会话范围内的标识符——A 在一个会话中，与A 在下一个会话中并不是同一个人。

• 回合可能会重叠，因此每个回合的状态应以回合标识符为键，而不是以到达顺序为键。

• 已公布的每租户上限为128个并发流和每小时16,000个流。

模型内部运行着什么，以及它取代了什么

Meta 的模型页面做出了一个关于架构而非评分的具体声明：“对 20 个以上说话人的说话人归属和语音结束检测在识别模型内部完成”——并且它明确将其与音频流末尾的批处理进行了对比。实际区别在于，无需等待第二个阶段。说话人标签和话轮边界与文字在同一流中到达，因此下游的语音代理或实时字幕界面无需后处理环节就能获得一个完整的话轮和身份。

Meta 记录为存在于该模型中的其他能力：

• 原生端点检测和语音活动检测，因此你无需在 API 前面运行自己的 VAD。用文档中的说法，你无需运行自己的语音活动检测，就能为每段话语获得一份完整的转写，并且检测到语音结束并不会结束会话。

• 上下文与关键词偏置，无需微调。Meta 的模型页面称其准确率是"通过上下文与关键词偏置、无需微调"而得以保持的，正是这一特性让流式 ASR 能够适用于领域词汇——药品名称、股票代码、产品 SKU——而非停留在通用语言的平均水平上。文档对相关限制的说明十分明确：关键词能够引导识别偏置，但并不能保证拼写完全准确，而且关键词偏置与语言偏置都会在会话开始时固定下来。

• 25 种经过评估且支持语码转换的语言。文档列出了它们：阿拉伯语、孟加拉语、荷兰语、英语、法语、德语、希伯来语、印地语、印度尼西亚语、意大利语、日语、卡纳达语、韩语、普通话中文、马拉地语、波兰语、葡萄牙语、西班牙语、他加禄语、泰米尔语、泰卢固语、泰语、土耳其语和越南语。语码转换——在句子中间和话语中间，且无需提前告知接下来会是哪种语言——是单语识别器在结构上无法提供的能力。有一点值得注意：语言偏置是一个语言列表，而不是自由上下文，并且它不会强制模型使用这些语言。

那篇标注日期的公告说得更远：它声称该模型在70多种语言上训练，其中25种“经过广泛验证”——这属于厂商自报数据，而这份25种已验证清单才是Meta愿意背书的子集。这才是规划时应依据的覆盖范围，而不是那70种。

记录的{{1}}限制{{/1}}

参考页面的价值取决于它所列出的约束条件，而 Meta 列出了好几条。

• 是轮次级时间戳，而非词级时间戳。模型页面和文档都直白地写道：“它返回轮次级时间戳，但不返回词级时间戳。”轮次带有以毫秒为单位的开始时间和结束时间。如果你的产品需要按词点击跳转——卡拉 OK 式高亮、逐词置信度路由、强制对齐——那这就是错误的模型，再多的提示词工程也改变不了这一点。

• 没有置信度分数，没有声音事件检测，没有情绪检测，也没有转写文本的重新格式化。Meta 将这四项统统列为不可用。你能得到的只有词、话轮、时间信息和说话人标签，至于模型有多大把握，则一无所知。

• 没有语音合成，也没有语音到语音的对话 API。它只是单向的。

• 文件路径支持的音频格式范围很窄。单声道 16 位 PCM WAV，16 或 24 kHz。其他任何格式都必须先转换，然后才能上传。

开放权重，以及 Muse Glimmer 的困惑

Muse Voice Transcribe 是专有产品，通过 API 提供服务——它并非开放权重发布，Meta 的文档也从未如此声称。这一点很重要，因为读者会把 Muse 系列的开放权重路径归到错误的名字上。 Muse Glimmer才是那条路径：Meta 的文档将其描述为从 Muse Spark 蒸馏而来的开放权重多模态模型，以宽松的 Apache 2.0 许可证分发，你可以通过 vLLM、SGLang、llama.cpp 或 ExecuTorch 等运行时在自己的硬件上下载并运行。在同一页面上，Muse Voice Transcribe 与 Muse Spark、Muse Image 和 SAM 一起被归类为调用而非下载的模型。

所以：Muse Voice Transcribe 没有权重，没有自托管选项，也没有审计或微调它的途径。如果某个页面告诉你并非如此，那它就是把 Muse Voice Transcribe 和 Muse Glimmer 混为一谈了。当模型的权重未公开时，服务平台就是全部关键——而这正是下一节要讲的内容。

客户如何到达它

Meta 的 Model API 的设计初衷就是能直接接入你现有的客户端。厂商在 API 概览页上给出的说法是，Model API“可直接兼容 OpenAI 兼容和 Anthropic 兼容的客户端库，以及 OpenAI 兼容的 agent CLI。设置好客户端的 base URL、填入你的密钥，其余代码保持不变。”就 Model API 整体而言，它提供三种请求形态——Responses API、Chat Completions API 和 Messages API——因此现有的集成通常无需重写就能找到相匹配的接口。有一点范围上的提醒：那句兼容性表述以及这三种形态是整个 Model API 的能力，而不是印在 Muse Voice Transcribe 自身模型页面上的文字。该模型页面自己的快速入门范围更窄——它只说你“将现有的 OpenAI 兼容客户端指向 Meta Model API”，并且你会在五分钟内发出第一个可用的请求。

参考页面上有一个值得指出的真实缺口：Meta 针对此模型的文档没有为 Muse Voice Transcribe 指定任何官方客户端库，而且它的“客户端库”页面位于 SAM 部分下，而不是 Voice 部分。语音转文本指南反而提供了一份具体的依赖清单——Python 3.9 或更高版本，以及 websockets和sounddevice 软件包——外加一本语音 API 基础手册。因此，所谓可直接替换的说法描述的是 Model API 请求面的总体情况；实时 ASR 端点本身是一个 WebSocket，有自己的握手规则，也没有文档化的封装器。

Meta 尚未发布的内容

基准测试的缺失是关于文档本身的一个事实，因此这里就将其作为事实陈述出来。Meta 为 Muse Voice Transcribe 提供的模型页面没有印制准确率表格：其准确率证据以三项图像资源的形式呈现——一个流式词错误率排行榜、一项说话人分离错误率对比，以及一个流式准确率指数——可提取文本中没有任何数字。该模型页面本身既未给出词错误率，也未给出说话人分离错误率，也没有按语言逐一细分的数据。

发布公告文章确实包含厂商报告的数字，包括流式词错误率和平均说话人分离错误率，而这些正是该模型发布时我们撰写报道所采用的数字；它们是 Meta 自己的测量结果，至今仍未被第三方复现。本页不会重新运行那项比较，因为在参考页面上重新运行发布当日的厂商基准，会把一个未经复现的数字粉饰成一个已有定论的数字。可以直说的话范围更窄：对于这个模型，Meta 没有发布在同等投入和同等评测框架下与具名竞争对手的正面对比评估，因此你在任何地方读到的任何比较，都是对不同条件下收集到的厂商数字进行的比较。

还有一个日期也是刻意不予确定的。模型页面完全没有标注发布日期——其唯一的版本标记就是 -1.0，出现在模型 id 中。本文中的 2026-09-01 这个日期来自那篇标注了日期的公告帖，此处用它来为模型确定时间，而非报道某一事件。

谁应该选择它，谁又不应该

Muse Voice Transcribe 的定位明确而有力：在实时音频中，你需要在同一条流上同时获得文字、说话人身份和话轮结束点，而价格足够低，使其可以持续运行而非按需调用。语音智能体、实时字幕、会议与通话智能、听写以及高吞吐量转写，正是 Meta 所列举的工作负载，也正是这套接口真正为之设计的工作负载——一条 60 分钟的 WebSocket，配有端点检测模式和会话级说话人标签。

反对它的理由同样具体。如果你需要词级时间戳、逐词置信度、声音事件或情绪检测，或者转录文本重格式化，这个模型并不具备这些功能，而这属于有文档说明的缺失，而非缺陷。如果你的音频采用非单声道 16 位 WAV（16 或 24 kHz）的格式，并且你使用的是文件端点，那么你就要承担一个在其他地方无需承担的转换步骤。而如果你的需求是对归档录音进行批量转录，且准确性是唯一衡量标准，那么流式方案的卖点对你毫无价值——两条路径价格相同，所以你是在为自己不会用到的实时能力付费。

在你确定生产路径之前，唯一需要核实的一点，正是本页存在的意义所在——那就是这个数字；而它也是唯一一个能在模型毫无变化的情况下发生变动的数字：每音频小时 $0.18，正如今天 Meta 自家模型页面上所印的那样。Meta 的页面在这件事上就是权威。一旦它变动，所有以它为基准的估算——每月一千小时、单次访谈成本、自建与采购的算术——都会随之变动。