👁 250 次阅读
2026年8月26日，Google 发布了 Gemini 3.5 Transcribe，这是 Gemini Audio 团队口径下的”迄今最精准的语音转文本模型”。它不是一个孤立的产品更新，而是语音识别赛道的一次形态切换：传统的 ASR 模型只负责”把语音逐字搬成文字”，而这个模型把口语清理、自我纠正合并、自动排版和自定义术语识别全部塞进了同一次 API 调用里。
本文基于 Google 官方博客、Gemini API 开发者文档、Google AI Studio 定价页，以及 Artificial Analysis 的第三方测量数据整理，逐条拆解准确率、定价、硬限制和竞品格局。需要提前说明的是：本文不对模型做独立复现测试，所有数字均标注来源与测量口径，便于你在自己的场景里做二次验证。第八节专门说明了本次评测的方法与局限。
一、发布概况：一个产品，两个 API 端点
Gemini 3.5 Transcribe 目前处于公开预览（public preview）阶段，从 Gemini API / Google AI Studio 即可申请访问，企业侧走 Gemini Enterprise Agent Platform。Google 把它拆成两个独立端点，这是理解整个产品的第一把钥匙：
gemini-3.5-transcribe（非流式）：走 Interactions API，处理已录好的音频——会议录音、通话日志、访谈素材。特点是支持说话人分离和词级时间戳，因为这两项能力都需要完整上下文的二次分析。gemini-3.5-transcribe-live（流式）：走 Live API，基于 WebSocket 做连续双向流，官方口径为亚秒级延迟，面向语音助手、实时字幕这类交互式场景。
这个拆分不是市场话术，而是真实的工程权衡。流式管线为了压低延迟，无法承受”回头做全局分析”的成本，所以流式版放弃了说话人分离和词级时间戳。几乎每一家主流流式 ASR 产品都有同样的取舍，Google 只是把它写进了产品定义里。
从架构上看，Google DeepMind 的模型卡显示 Gemini 3.5 Audio（Transcribe 所属系列）基于 Gemini 3 Pro，属于多模态基座模型把音频当作又一种输入类型处理的路径，而不是像老一代 Cloud Speech-to-Text 那样用专用 ASR 架构。Google 公开文档并未披露独立的模型结构细节，也没有开放权重。
二、准确率到底怎样：三组数字，别混着用
这是本次发布最容易被误读的地方。市面上流传着”2.6%”、”4.0%”、”5.50%”三个不同的错误率数字，它们全部属实，但来自不同的评测集，不能互相替换：
| 指标 | 流式（Live） | 非流式（文件） | 测量方 / 来源 |
|---|---|---|---|
| 平均词错误率（WER） | 4.0% | 2.6% | Artificial Analysis |
| FLEURS 多语言基准 WER | 5.50% | 5.04% | Google 官方博客 |
| 相对 Chirp 3 的终稿时延 | 提升约 70% | Artificial Analysis | |
几点必须注意的细节：
- WER 越低越好。在头部模型的这个量级上，低于 1 个百分点的改善通常就被视为有意义——所以非流式版走到 2.6% 的幅度是实打实的。
- 4.0% 与 2.6% 的差距主要来自模式差异，而不是模型本身有两条能力线。流式为了赶时间不做二次校对，非流式可以做全局回溯。
- FLEURS 的 5.04% 比 2.6% 高，不是退步。FLEURS 是覆盖多语言多口音的评测集，任务本身更难；2.6% 来自 Artificial Analysis 的自有平均集。两者口径不同，硬放在一起比较会得出错误结论。
- WER 是厂商联合第三方公布的数字，样本构成并未完全公开，做采购决策时应视为”方向性很强”而非”可认证的排名”。
除了错误率，Google 特别强调了在噪声环境和字母数字串上的表现——邮编、订单号这类混合字符正是传统 ASR 的失分点。这是转写准确率在业务里真正值钱的地方：一个客户电话录音里的订单号被识别错，后面整条对账链路都要返工。
三、真正的分水岭：Smart Transcription
WER 数字吸引眼球，但决定工程团队是否迁移的其实是功能形态。Gemini 3.5 Transcribe 提供两种输出模式：
verbatim（逐字）——API 默认值。保留全部原始措辞，包括”嗯””啊”、重复和说到一半改口的部分。适合需要可审计、可回溯原文的场景。smart（智能）——合并自我纠正、清除填充词、自动排版。Google 官方给出的例子是”我们周二见——不对，周三”，最终输出只保留”周三”。
更具体一点，官方文档里的示例输入是：”Um, so for the meeting, I think we should, uh, invite Alice and, wait no, Bob and Carol.” Smart 模式输出为”For the meeting, I think we should invite Bob and Carol.”——注意它不仅删了 um、uh，还把 invite Alice and, wait no 这整段自我推翻的表述消解掉了。
这里有一个必须在开工前确认的硬约束：smart 模式不能与词级时间戳或说话人分离同时启用。这意味着”一份可直接阅读的会议纪要”和”一份可逐字核实的审计转录”现在是两次独立的 API 调用。会议纪要、通话质检这类既要可读性又要可追溯的场景，调用量与成本都要按两份算。
另外两项能力值得单独说明：
- 自定义词表：可偏置最多 1000 个领域术语与人名，医学名、内部代号、客户姓氏这类传统 ASR 的硬伤由此缓解。
- 说话人分离：最多标注 8 位说话人，但 Google 明确标注3 位及以上说话人的归属属于实验性功能——多人评审会、圆桌访谈这种场景不要把它当成熟能力用。
- 词级时间戳：每个词返回起止偏移，足够直接生成字幕文件。但官方同时提示，启用它可能带来一定的准确率损失。
四、定价：按 token 计费，折算下来一小时约三毛钱
Gemini API 转写不是按分钟计费的，而是按 token 结算，这也是各家定价难以直接横比的根本原因：
| 项目 | gemini-3.5-transcribe（非流式） | gemini-3.5-transcribe-live（流式） |
|---|---|---|
| 音频输入 | $2.00 / 百万 token | $3.50 / 百万 token |
| 文本输出 | $12.00 / 百万 token | $21.00 / 百万 token |
| 官方折算有效单价 | 约 $0.005 / 分钟 | 约 $0.009 / 分钟 |
官方定价页给出的折算假设是每秒约 25 个音频 token 输入、每分钟约 175 个文本 token 输出。据此，一小时录音大约 30 美分。需要提醒的是，这是基于假设速率的估算值，不是简单的按分钟费率——如果你的语音密度高、或者用了会扩大输出的排版功能，实际账单会有浮动。
两个容易被忽略的点：
- 有免费额度，具体上限显示在你的 Google AI Studio 账户里。做 PoC 验证时可以先在免费层内跑完。
- 数据使用政策分档：未付费的 Gemini 服务提交的输入内容可能被用于改进 Google 的产品；付费层级的 prompts 与 responses 不会用于此用途（依据 Gemini API 服务条款）。Google Cloud 企业条款另行规定客户数据不会在未经许可的情况下用于训练或微调。合规敏感的团队应在接入前确认自己走的是哪一档。
五、硬限制清单：这些坑要在开工前知道
这些限制都写在官方模型文档里，全部是”能不能用”级别的问题：
| 限制项 | 非流式 | 流式 |
|---|---|---|
| 单次音频时长上限 | 1 小时 | 会话最多 10 分钟 |
| 开启说话人分离 / 词级时间戳后 | 降至 30 分钟 | 不支持这两项功能 |
| 说话人数量 | 最多 8 位（3 位以上为实验性） | — |
| 自定义词表 | 最多 1000 条 | — |
| 语言覆盖 | 85+ 种语言，自动检测，支持句内语言切换 | |
最容易被忽略的是30 分钟这个隐藏上限。默认单次请求可吃 1 小时音频，但只要勾选了说话人分离或词级时间戳，上限就砍半。做会议转录的产品如果直接接 90 分钟的评审会录音，会在这里撞墙——必须在应用层做音频切分，并自行处理切点处的说话人归属衔接。
还有一个口径差异需要如实指出：官方模型属性表把 Function calling 标注为”不支持”，而官方博客在功能介绍中提到模型可以通过函数调用把复杂任务委派给其他 Gemini 模型，并说明该能力当前仅在 Gemini macOS 应用内可用。两处口径存在差异，开发者直接接 API 时应以模型文档的”不支持”为准。
另外，Caching、Code execution、File search 三项在模型文档中同样标注为不支持。
六、竞品格局：为什么现在还不能下”最好”的结论
转写赛道的竞争者不少，但 Google 这次的定位非常清楚——直接对标前代 Chirp 3，以及 OpenAI 在上一个窗口期推出的 GPT-Transcribe。
对 Chirp 3：提升体现在准确率、时延（终稿时延提升约 70%）和输出形态三处。但要说明的是，说话人分离和 1000 条自定义词表并不是新增能力，Chirp 3 已经具备。真正的新东西是 smart 模式的口语清理。
对 OpenAI GPT-4o Transcribe，可对比的数据是：
- OpenAI 官方公开定价为输入音频 $2.50 / 百万 token、输出 $10 / 百万 token。第三方按同样方式折算后，GPT-4o Transcribe 约 $0.0045 / 分钟，与 Gemini 的 $0.005 / 分钟几乎持平。
- 流式场景差距明显：OpenAI 的 gpt-live-transcribe 约 $0.017 / 分钟，Gemini live 版约 $0.009 / 分钟，约为前者的一半。
- 能力打包方式不同：Gemini 在一个模型里同时返回词级时间戳和说话人标签；OpenAI 侧仍需在 whisper-1 与 gpt-4o-transcribe-diarize 之间拆分工作。
- 免费额度：Gemini 有，OpenAI 托管转写没有。这决定了 PoC 阶段的成本差异。
更大的格局是：截至本文发稿，没有任何公开的、在同一组音频上对 Gemini 3.5 Transcribe 与 Whisper、Deepgram Nova、AssemblyAI、Azure AI Speech 做的同台对比基准。OpenAI Whisper 仍然是部署最广的开源 ASR，本地运行不产生任何费用；Deepgram 与 AssemblyAI 在企业客服与媒体平台有较深积累；ElevenLabs 从语音合成延伸出转写产品；Azure 把转写打包进云语音服务套件。
所以任何”Google 已经吊打 Whisper”的表述都缺少证据支撑。可以确认的是：在公开可查的数据集上，Gemini 3.5 Transcribe 的准确率与单位成本都处在第一梯队，且把功能打包得更完整。但这不是最终排名。
七、场景选型建议
按需求分五类，给出可直接落地的判断：
1. 会议纪要、通话复盘、访谈整理
走非流式端点加说话人分离。必须提前处理两件事：一是超过 30 分钟的录音要做切分；二是smart 模式与分离、时间戳互斥，想要”可读纪要”和”可审计原文”两份产出就得调两次。建议先跑一次逐字模式拿到带时间戳的可审计底稿，再用 smart 模式生成给读者看的版本。
2. 实时字幕、语音助手、在线会议辅助
走 live 端点。亚秒级延迟是这个模式的核心价值，代价是放弃说话人分离和词级时间戳。单次会话 10 分钟的上限需要应用层做好续接。
3. 客服呼叫中心、大批量归档
先按 token 口径把账单算清楚，再评估是否走 Gemini Enterprise Agent Platform 拿预置吞吐、合规控制和批量折扣。公开资料显示该通道仍处公开预览，生产承诺要留余量。另外，未付费档的内容使用政策不适用于这种规模，务必确认走付费层级。
4. 隐私敏感或需要完全离线
转写类服务天然要把音频送出机器，如果这条底线不可突破，应直接选 Whisper 本地部署等方案，不要在云端转写上做妥协。
5. 已有语音管线、想快速接入
Live API 已被 LiveKit、Pipecat、Agora、Fishjam、Vercel AI Gateway 等主流语音框架接入，消费端已经在 Android Gboard 的 Rambler 功能和 macOS Gemini 应用听写里落地，Chrome 端官方列为即将支持。已有管线的团队迁移成本相对较低。
八、本次评测的方法与局限
为避免读者误读，把本文的证据边界写清楚：
- 本文未做独立复现测试。所有 WER、时延、定价数字均来自 Google 官方博客、Gemini API 开发者文档、Google AI Studio 定价页，以及 Artificial Analysis 的测量结果（部分经由第三方技术媒体报道转述）。
- WER 数字的样本构成未完全公开。2.6% 与 4.0% 由 Artificial Analysis 测量，是相对可信的第三方数据；FLEURS 上的 5.50% 与 5.04% 出自 Google 官方博客。两组口径不同，不可互换。
- 定价折算是估算值，基于官方给出的假设 token 速率。实际账单取决于你的语音密度与输出长度。
- 竞品对比缺乏同台基准，OpenAI 侧的折算单价来自第三方按同样方法推算，双方公布的计费单位本身不可直接换算。
- 模型处于公开预览阶段，功能与限流政策可能变化，接入生产前应以最新官方文档为准。
九、总结：语音输入正在从”逐字转录”转向”直接可用”
Gemini 3.5 Transcribe 真正的意义不在 2.6% 这个数字上，而在于它把”转写之后的清洗工作”收进了模型本身。过去的产品链条是”ASR 出逐字稿，LLM 清理口语，人工排版”，现在第一步和第二步合并了。对会议纪要、客服质检、语音代理这三类产品，成本结构里的一个环节直接消失。
但需要保持清醒的有三点：
- 模式互斥是真实的设计代价——smart 与时间戳、分离不能同开，”可读版本”和”可审计版本”目前是两次调用。
- 30 分钟与 10 分钟的上限要在架构层解决，不能指望应用层兜不住。
- 缺少同台基准意味着不要盲信排名。建议在自己的真实音频集（尤其是口音、噪声、领域术语这三类）上做一次小规模对照测试，这比任何第三方榜单都更能指导采购决策。
对内容创作者、知识工作者来说，Rambler 和 macOS 听写里的这项能力已经可以日常使用；对开发者，非流式端点适合先接会议纪要类需求，流式端点适合已有语音交互管线的项目。价格层面，非流式约 $0.005 / 分钟、流式约 $0.009 / 分钟的量级，在这个能力密度下属于可接受区间——但前提是先把上面的限制清单读完。
参考来源：Google 官方博客 Introducing Gemini 3.5 Transcribe（2026-08-26）、Gemini API 开发者文档 gemini-3.5-transcribe 模型页、Google AI Studio 定价页、Google DeepMind Gemini 3.5 Audio 模型卡、Artificial Analysis 测量数据、MLQ News 与 Spokenly 的技术报道、Ars Technica 与 9to5Google 报道。