谷歌把语音转文字并入 Gemini API，Transcribe 进入公开预览

谷歌于 2026 年 8 月 26 日推出 Gemini 3.5 Transcribe，把转写能力从独立的 Cloud Speech 产品线搬进了核心的 Gemini API。真正的变化不在头条准确率分数上 —— 该模型目前在独立评测中排名第五，落后于 ElevenLabs 和阿里云 —— 而在于什么被整合进了一次 API 调用：说话人分离、词级时间戳和函数调用，全都在基础模型里，并通过与 Gemini 其余部分相同的 token 体系计费。

此次发布用一个开发者以 Gemini 模型 ID 调用的模型，取代了谷歌此前的转写产品 Chirp 3。对于那些要用多个服务 —— 一个转写器、一个分离器、再加一道格式化 —— 拼出会议纪要或语音智能体流水线的团队来说，新的架构才是更有分量的进展，尽管去除口头语的演示更上镜。

两个端点，能力和限制各不相同

Gemini 3.5 Transcribe 以两条独立的 API 路径发布。批处理路径 gemini-3.5-transcribe 走的是 Interactions API，处理预先录制的音频：会议、呼叫中心记录、访谈录音。它支持最多三名说话人的归属识别，生成词级时间戳，每次会话最多接受一小时音频 —— 不过一旦启用说话人分离或时间戳，这个上限会降到 30 分钟。

流式路径 gemini-3.5-transcribe-live，以双向 WebSocket 连接跑在 Live API 上，面向交互式用途：实时字幕、语音界面、客服通话。谷歌称其延迟在一秒以内。这个端点把会话上限设为十分钟，且不支持说话人归属或词级时间戳。两条路径是两个独立的计费项，定价也各自独立：批处理约每分钟 0.005 美元，流式约每分钟 0.009 美元，这是按谷歌官方每秒 25 token 的音频计费率折算出来的 —— 分别约合每小时音频 0.30 美元和 0.54 美元。两者都有免费额度，而定价页明确注明免费额度可能会用数据来改进谷歌的产品；付费额度则不会。

「智能转写」在实践中改变了什么

谷歌的智能转写模式会在推理阶段施加模型层面的编辑：自我更正被消解（「我们周二见 —— 不，周三」变成周三的会面），犹豫词被去掉，标点和格式被补上。该模型还接受自定义词表，把识别向领域专用术语偏置 —— 产品名、医学术语、字母数字编码。函数调用让模型可以把任务路由给其他 Gemini 模型，从而把转写变成更大的智能体流水线中的一个环节，而不是终点；这项能力目前在 Gemini 的 macOS 应用中可用，批处理 API 即将支持。

编辑层面的含义是实质性的。智能模式会替说话人做出他们并未明确做出的决定，这对会议纪要和口述很有用，但在需要逐字忠实的场合就不合适。法律证词笔录、医疗问诊录音和新闻采访都需要逐字模式 —— 谷歌把它写进了文档，并保留为默认。还有一条硬性约束：智能模式无法与说话人归属或词级时间戳同时使用。团队必须在可读性与完整可追溯性之间二选一。

Gemini 3.5 Transcribe 实际排在什么位置

按 Artificial Analysis 的测量 —— 其非流式排行榜覆盖 57 个语音转文字模型 —— Gemini 3.5 Transcribe 以 2.6% 的词错率排名第五。阿里云的 Fun-Realtime-ASR-preview 以 1.7% 词错率领先，其后是 ElevenLabs Scribe v2 的 2.2%、MAI-Transcribe-1.5 的 2.4%，以及同为 2.4% 的 Smallest AI Pulse Pro。OpenAI 已被广泛部署的 Whisper Large v3 在同一评测上约为 4.2%；Mistral 的开放权重模型 Voxtral Small 达到 2.8%，且拥有完全自托管的部署控制权。

谷歌还宣称，相较 Chirp 3，其「出最终转写结果的时间」改善了 70%，引用的是 Artificial Analysis 的数据 —— 而这家分析机构指出，该数字是谷歌自选的测量结果，测的是一个在报告时才上线约一天的模型，并非独立的对抗性比较。截至本文写作时，尚不存在针对开放权重替代方案的第三方正面复现测试。评估 Gemini 3.5 Transcribe 的生产团队，应当用取自自身分布的音频来测试 —— 口音构成、背景噪声水平、领域词汇密度，以及是否存在两名以上说话人，都会以单一公布的词错率数字所无法体现的方式影响真实准确度。

API 整合的理由

论原始的非流式准确率，ElevenLabs Scribe v2 和阿里云的预览模型领先。论语音智能体所需的流式延迟，Deepgram Flux 和 ElevenLabs 更强。论成本和控制权，Voxtral Small 和 NVIDIA Parakeet 提供不依赖 API 的自托管方案。

Gemini 3.5 Transcribe 独有的东西，是在谷歌技术栈内部的接口整合。在这次发布之前，要在谷歌基础设施上搭一条带说话人分离、带时间戳、经领域适配的转写流水线，需要 Cloud Speech-to-Text、一个独立的分离服务，再加一层格式化 —— 三条计费线，三个集成点。如今一次对 gemini-3.5-transcribe 的调用，就能返回带说话人归属、带时间戳、已格式化、且已应用自定义词表的输出。对那些还要跑下游 Gemini 模型做摘要、抽取或行动项识别的团队来说，消除这些服务边界同时降低了延迟和复杂度。

这份整合是否值得承受相对 ElevenLabs 的词错率劣势，取决于具体的工作负载。对于随后还要交给 Gemini 处理的多语种会议纪要，理由很充分。对于以准确率为约束瓶颈的法律或医疗转写，理由就弱一些 —— 而且该模型处于公开预览状态，意味着定价、限制和 API 行为在正式发布之前仍可能变动。

对生产规划有影响的那些约束

有几条硬性限制，值得任何评估 Gemini 3.5 Transcribe 用于生产的团队重复记一遍：实时会话上限十分钟；批处理会话上限一小时，若启用说话人识别或时间戳则为 30 分钟；三人以上的说话人分离被标注为实验性；而词级时间戳在文档中被写明可能降低整体转写准确度。该模型处于公开预览，意味着上述所有参数在正式发布前都可能改变。

在消费端，Gemini 3.5 Transcribe 已经在为 Android 上 Gboard 的 Rambler 和 Gemini macOS 应用的 Speak to Window 功能提供支持，Chrome 的语音输入、Docs Live、Keep 和 Gmail 的集成也在计划中。这条轨迹指向的是：转写正在成为 Gemini 技术栈的通用输入层 —— 每一个进入谷歌各个界面的口头词句，都先经过这个模型，再路由给处理后续任务的那个 Gemini 智能体。它与排行榜前两名之间的准确率差距，以及这个差距会不会在正式发布前收窄，将决定 Gemini 3.5 Transcribe 究竟会成为谷歌生态开发者的默认选择，还是仅仅是最方便的那一个。