8 月 26 日,Google 发布了 Gemini 3.5 Transcribe。这不是 Gemini 通用模型的又一次版本迭代,而是专门为"语音转文字"这一个任务造的专用模型,正式接替 Google 之前的转写模型 Chirp 3。
先看数字
按 Google 官方博客的说法,在 FLEURS 多语言基准的一组主要语言和地区上,Gemini 3.5 Transcribe 流式模式词错误率(WER)为 5.50%,非流式 5.04%,均优于 Chirp 3。另一组来自 Artificial Analysis 的平均口径数字是:流式 4.0%、非流式 2.6%。延迟方面,同样由 Artificial Analysis 测量,最终转写的出稿时间比 Chirp 3 快 70%——对实时场景来说,这个数字比 WER 更有杀伤力。
一个模型,两个端点
工程上它拆成两个 API:gemini-3.5-transcribe 走 Interactions API 处理预录文件,gemini-3.5-transcribe-live 走 Live API 做双向流式。能力清单包括多说话人归属、词级时间戳、85 种以上语言与方言的自动检测和语码转换、自定义词汇偏置,以及能清理口语中"嗯、啊"等不流利成分的 Smart transcription。限制同样明确:Smart 模式不能和词级时间戳、说话人归属同时开启;live 会话上限 10 分钟,单文件上限 1 小时,开启说话人归属后缩短到 30 分钟。价格约为批处理每分钟 0.005 美元、实时每分钟 0.009 美元,没有开放权重。
通用模型时代,为什么还要专用 ASR
我的看法:转写正在从"听清"变成"理解"。过去 ASR 拼的是把声音切成字;现在 voice agent 要的是知道谁在说、说到哪个词、什么时候说完。Google 把这些能力——说话人归属、时间戳、自定义词表、实时语言切换——打包进一个专用分支,而不是让开发者拿通用 Gemini 硬凑,本质是在给 voice agent 生态修地基:Live API 已经预接线 LiveKit、Pipecat、Agora、Vercel 等框架,消费端则计划铺向 Search Live、Docs、Gmail 乃至 Chrome 的全网页语音输入。
对照物是 Whisper 的开源路线:Google 选择闭源 API 加低价,把生态绑在自家管线上。对开发者,真正的信号是:转写模型的竞争焦点已经从准确率转向延迟、上下文理解和工具链集成的乘积。如果你的语音应用还停在"ASR 加 LLM 两段式"架构,这条新闻是一个提醒:输入端正在被重新发明(详见 Google 官方公告)。