VibeVoice-ASR-Streaming-1.5B 对比 Gemini 3.5 Transcribe：微软低调的流式语音识别对决谷歌的新 API

两个最新的流式语音转文字系统之间，相隔七天时间与一道理念鸿沟。2026年8月26日，Google 将 Gemini 3.5 Transcribe 投入公开预览：这是一个托管的闭源语音转文字 API，按音频 token 计费，并提供独立的 Live 端点用于实时会话。2026年9月2日，微软研究院在 Hugging Face 的 microsoft 命名空间下上传了 VibeVoice-ASR-Streaming-1.5B——采用 MIT 许可的权重，没有新闻稿，没有发布公告，而且在撰写本文时，任何地方都没有第三方报道。两者都能在语音仍在传输的过程中进行转录。而关于它们的一切其他方面——谁被允许运行它们、费用是多少、存在哪些证据证明它们有效——则截然不同。

此页面按两者当前的实际状态进行比较，这意味着双方证据并不对等。Gemini 3.5 Transcribe 是谷歌的正式产品，已公布代币价格，并有来自 Artificial Analysis 的第三方准确率数据；下文中标注为 AA 的数字即来自该机构。VibeVoice-ASR-Streaming-1.5B 则是一个检查点，其模型卡完全没有以文本形式发布词错误率和延迟数据——该卡片的评测是一张图片，而流式家族迄今为止唯一的公告只是 Microsoft 的 VibeVoice GitHub 仓库中一条日期为 9 月 3 日的新闻。下文中微软一侧的所有内容均来自该仓库可知的信息：配置文件、模型卡，以及微软自己的流式文档。目前尚没有任何针对它的独立基准测试。

两款模型概览

• 它是什么 — VibeVoice-ASR-Streaming-1.5B：开放检查点、MIT 许可、可自托管；对比 Gemini 3.5 Transcribe：托管 API、封闭权重。

• 发布 — 2026年9月2日发布权重，9月3日发布仓库新闻；相对于2026年8月26日附完整发布材料的公开预览。

• 流式形态——以约2.9秒的文本块输出，带约0.5秒前瞻；会话状态通过前缀缓存承载，而 WebSocket Live 会话则按音频 token 计费，每次会话音频上限为10分钟。

• 书面准确度——没有以文本形式发布的WER或时延数据；相较之下，AA在预录端点上测得的WER为2.6%，在实时端点上为4.0%。

• 说话人输出 — 声称支持流式“谁说了什么”归属（未经验证），而 Live 端点无说话人分离，也无词级时间戳。

• 热词 — 通过与批量 VibeVoice-ASR 相同的上下文提示受支持；而 Live 端点未将其列为功能。

• 费用 — 权重免费（$0），自托管约需 5.6 GB 存储；据 Google 公布的 token 价格，预录音频端点的混合费率约为每音频小时 $0.30，Live 端点约为 $0.54。

一个托管的API和一次安静的上传，相隔七天

Gemini 3.5 Transcribe 是 Google 的替代级转录模型，以两种产品形式提供。通过 Interactions API 提供的预录制端点，接收完整音频文件，并返回带有预期附加信息的转录文本。实时端点 gemini-3.5-transcribe-live 通过双向 WebSocket 运行，在工作形态上与 VibeVoice-ASR-Streaming-1.5B 竞争：即对正在进行的会话进行实时转录。Google 以常规流程发布了它——8月26日公开预览上线，模型页面给出定价，第三方排行榜数日内即将其收录。

微软的流式发布却没有这些。9月2日，微软的Hugging Face账号在同一分钟内创建了两个检查点：VibeVoice-ASR-Streaming-7B和VibeVoice-ASR-Streaming-1.5B。GitHub仓库的模型表现在将VibeVoice-ASR-Streaming列为家族成员之一，其新闻栏目也发布了9月3日的公告，宣称“一个统一的流式ASR模型，能在语音到达时持续转录谁说了什么，并支持自定义热词和10种语言”——但该公告只点名了7B，1.5B则是随其一起发布、却未被单独提及的较小兄弟版本。我们在上传一天后查看时，两个检查点的下载量仍然为零。

"流式传输"在每一侧的含义

“流式”这个词掩盖了一个真正的设计差异。Microsoft 的预处理器配置使 VibeVoice 的节奏具体化：音频以 24 kHz 的采样率到达，并被压缩 3,200 倍，成为大约 7.5 Hz 的语音 token 流（每个 token 约 133 毫秒）。该配置随后声明一个 22 帧的块（chunk）和 4 帧的前瞻（lookahead）——每块约 2.9 秒的音频，其中约半秒的未来音频用于稳固当前片段。模型在每个已解析的块上输出一次文本，Microsoft 的文档指出，来自更早块的上下文通过 KV 缓存保留，因此长会话不会从头重新计算。这些数值体现在配置中；实际结果是，转录文本以大约三秒为增量增长，而不是逐词产生部分结果。

Google 的 Live 端点是一种不同的流式形态：一个双向 WebSocket 会话，音频以每秒 25 个音频令牌计费，专为交互式使用而设计，但每个会话的音频时长上限为 10 分钟，而且——具体到 Live 端点——不提供说话人分离或词级时间戳。若要将两者作为实时转录引擎进行比较，关键的差异在于：会话上限（Google Live 一侧为 10 分钟，Microsoft 一侧仅受您自己的 GPU 和内存限制）、输出节奏（约 3 秒的块对比 WebSocket 会话所返回的任意结果）、以及额外输出功能（Microsoft 产品卡上声称的说话人归属和热词，在 Google 的 Live 功能列表中均不存在）。

准确度：一边有数字，另一边有图片

这是本次对决中最大的差距，而且是证据上的差距，未必是质量上的差距。Artificial Analysis 测得 Gemini 3.5 Transcribe 在预录端点上的词错误率为 2.6%，在 Live 端点上的词错误率为 4.0%——你为实时交付所付出的溢价体现在错误率上，这是流式系统常见而诚实的权衡。这些是发布数天后出现在中立排行榜上的第三方数据。

VibeVoice-ASR-Streaming-1.5B 在任何地方都找不到可与之相比的指标数据。模型卡以图片形式附带了一张评估结果图，但正文中没有给出数值化的 WER、RTF 或延迟——没有可引用的数据，也没有可独立核查的内容。微软也没有为 7B 或 1.5B 模型以文本形式提供流式准确率数据。整个系列中唯一的数值锚点是批处理版 VibeVoice-ASR 模型卡，它报告了供应商侧运行得到的平均 7.77% WER（跨八个英语测试集）以及 LibriSpeech clean 上的 2.20%——但这描述的是非流式模型，而流式模型通常以牺牲少量准确率来换取延迟上的优势。在有人通过公开测试基准运行流式检查点之前，诚实的结论是：Google 的模型是经过实测的，而微软的并未经过实测。

成本：每音频小时对比每GPU小时

Google 按 token 销售 Gemini 3.5 Transcribe，定价在两个端点之间清晰区分。预录制端点列出每 100 万音频输入 token 2 美元、每 100 万文本输出 token 12 美元，综合下来约为每音频小时 0.30 美元。Live 端点则列出每 100 万音频 token 3.50 美元、每 100 万文本 token 21 美元——综合约为每音频小时 0.54 美元，比预录制高出约 80%，这正是实时交付的代价。Google 按每秒 25 个 token 对音频计费，因此只有当你的客户端不传输静音时，静音才免费；重连、重复音频和日志记录都可能增加实际费用。存在免费套餐，但需注意，免费套餐内容可能被用于改进 Google 产品。

微软的模型则按GPU小时数计价。1.5B检查点大约是5.6 GB的bf16权重（一个1.5B级Qwen语言主干，外加音频分词器和扩散头——safetensors元数据合计约3B参数），而运行它的文档化方式是自托管：使用microsoft/VibeVoice仓库中的Python演示，或使用微软描述的vLLM插件来提供OpenAI兼容和WebSocket端点。目前还没有托管定价，因为没有推理服务商上架该模型。成本问题完全取决于你自己使用GPU的时间是否比谷歌的每小时费率更便宜——对于任何持续性的转写量来说，答案几乎肯定是更便宜的——而许可问题与成本问题相互独立，因为MIT许可的权重归你所有，这一点是任何API订阅都无法比拟的。

这两者在生产技术栈中并不互斥。对于今天就需要实时转写的团队来说，务实的做法是将ASR层收敛在单一端点之后，使选择保持可逆：一个以提供商列表价格对接200多个模型的路由API——不加价，因此供应商调价当天即生效——并具备自动故障转移。正是这样的层，让你可以将Google的计量API作为默认运行，同时当有提供商托管VibeVoice-ASR-Streaming-1.5B时，让一小部分真实流量立即对其进行测试。这就是OrcaRouter的模式，也是采用这个准确性尚无人验证的检查点的低风险方式。

谁应该选择哪个

如果您想要一个今天就能使用的转录 API，并且它拥有已公布的准确性、可预测的按小时定价，还无需您费心照看 GPU，那就选择 Gemini 3.5 Transcribe——尤其是当您的音频不在微软列出的十种语言之内，或者您需要预录制端点的说话人分离和词级时间戳来进行文件转录时。10 分钟的 Live 会话上限是一个真实的限制，在您决定将其用于实时会话之前，需要针对您的用例进行测试。

如果您是自托管，如果您想要MIT提供的权重和数据控制，如果您需要无限制的会话长度，或者如果{{1}}谁说了什么{{/1}}的流式输出和热词是您特别想要评估的功能，请选择VibeVoice-ASR-Streaming-1.5B。请为从源代码安装做好预算，在NVIDIA GPU上约需{{2}}5.6 GB{{/2}}的权重，并设置您自己的评估门槛——因为没有现成的基准可供参考，所以准确性问题需要您用自己的音频来回答。

一周后的结论是：谷歌交付的是经过验证的产品，微软交付的是有趣的赌注。Gemini 3.5 Transcribe 是更稳妥的默认选择，背后有第三方数据支撑；VibeVoice-ASR-Streaming-1.5B 则是开放、可自行托管、完全未经验证的替代方案。这个选择之所以成本低，是因为它不必是永久性的——保持 ASR 端点可替换，那么一个发布时不附带任何基准测试的检查点，也能凭你自己转录文本的证据来赢得或失去你的流量。