Google 发布 Gemini 3.5 Transcribe：专做语音转文字的模型到底强在哪

Google 这次把语音转文字这件事单独拎出来，做了一个专门的模型——Gemini 3.5 Transcribe。不再让用户在通用大模型里手动调提示词拼凑转录结果，而是直接给一个为 ASR（自动语音识别）场景打磨的工具。

从通用大模型里拆出一条 ASR 专用线

过去几年，开发者想做语音转写，往往要在 Whisper、通用大模型、各家云厂商的语音 API 之间反复横跳。Google 的方向很明确：把转录从"通用模型的副业"变成"独立产品线"。这意味着定价、调用方式和准确率优化都会围绕 ASR 场景展开，而不是被对话或生成任务牵着走。

四个真正影响开发者的能力

说话人分离是这次最显眼的升级。原生的 speaker diarization 可以直接输出"谁在第几秒说了什么"，不用再写后处理脚本把多个说话人拼回去。对会议记录、访谈整理、播客剪辑这类场景，省下的不只是开发时间，还有调试成本。

词级毫秒时间戳是另一项关键能力。每个单词都带精确时间标签，意味着可以直接驱动字幕生成、视频剪辑对齐，甚至用来训练更细粒度的语音模型。

85+ 种语言的自动识别加上代码切换（code-switching），对中文用户尤其有用。一段中英混说的会议录音，过去经常出现中文被识别成英文或者专有名词乱码的情况。新模型把这件事当成一等公民来对待。

自定义词表（custom_vocabulary）允许传入最多 1,000 个领域术语，产品名、人名、医学或法律术语都可以预先注入，显著降低专有名词拼写错误率。同时提供 Smart Transcription 和 Verbatim 两种模式，前者清理填充词，后者保留全部语气词，覆盖会议纪要和取证两类典型场景。

对个人开发者而言，一个 API 就能拿到时间戳、说话人标签和多语言结果，不用维护音频分段、说话人聚类、文本对齐三套独立流水线。对企业用户来说，更值得关注的是总成本曲线：如果这些能力不需要额外付费模块，下游做字幕、检索、合规存档的方案都能显著简化。

中文用户需要注意的几件事

首先，85+ 语言里中文的识别质量如何，目前只有官方描述，没有第三方盲测数据。建议先用真实录音做样本测试。

其次，Smart Transcription 对中文口语习惯的清理程度尚不明确。中文填充词（"嗯""那个""就是说"）在商务会议里大量存在，过度清理可能丢掉重要语义。

最后，1,000 个自定义词表上限对中小团队足够，但跨国公司的产品名矩阵可能很快触及天花板，需要提前规划词表优先级。

后续观察点

一是 Google 会不会把"专用模型"思路扩展到图像、表格等其他模态，让通用和专用形成两条产品线。

二是定价与延迟数据。官方强调"快速、低成本"，但中文场景的实测延迟和按分钟计费价格，目前还没有公开 benchmark。

三是和 Gemini 多模态生态的联动。带时间戳的转录文本可以直接喂给 Gemini 做摘要、问答或结构化提取，这条链路在企业场景里比单纯的 ASR 价值更高。

总的来看，Gemini 3.5 Transcribe 不是一次颠覆性发布，而是 Google 在 ASR 赛道一次清晰的产品定位——把转录做成可独立调用的基础设施。对中文用户来说，关键不在于"又多了一个选择"，而在于它能不能在中文长尾场景里稳定输出。