AIREITER很多人搜索时会写成“3-5”，但 Google 的模型 ID 实际是 gemini-3.5-transcribe 和 gemini-3.5-transcribe-live。这套 API 确实存在，价格也不高，但真正决定它是否适合你的，不是“能不能转写”，而是你要的是通顺稿件、可追溯的原话，还是实时字幕。
Gemini 3.5 Transcribe API 评测结论，一张表看懂
如果你要处理录音文件、语音口述，或做短时实时字幕，Gemini 3.5 Transcribe 值得拿来做原型。不过，它不适合作为精确逐字稿或长时间实时记录的默认方案：Smart 转写会主动编辑语音内容；实时会话没有说话人标签和词级时间戳；整个服务目前仍处于公开预览阶段。
| 你的需求 | 建议使用 | 评测结论 |
|---|---|---|
| 把会议、通话或播客录音转成文字 | gemini-3.5-transcribe | 可以用；在措辞重要时选择逐字模式 |
| 整理口述内容或生成易读的会议笔记 | 录音模型的 Smart 模式 | 如果可以接受编辑，可以用，但要复核 |
| 在说话过程中生成字幕 | gemini-3.5-transcribe-live | 适合短时互动场景，先做原型 |
| 说话人标签和词级时间戳 | 带逐字标注的录音模型 | 有限度地使用；30 分钟和 3 人以上说话人属于实验性能力 |
| 法律、医疗、合规或存档用途的最终记录 | 逐字转写流程加人工复核 | 不要作为唯一来源 |
这是一篇基于证据的 API 评测，不是受控环境下的 WER 基准测试。Gemini 3.5 Transcribe API 配置与价格指南介绍了请求流程；本文关注的是第一次成功调用之后，那些文档里的能力取舍会如何影响实际使用。
别把它当成一个 API：Gemini 3.5 Transcribe 实际上是两套契约
gemini-3.5-transcribe 通过 Interactions API 处理上传或预先录制的音频；gemini-3.5-transcribe-live 则通过 Live API 处理流式音频。
录音转写：gemini-3.5-transcribe
如果目标是生成可长期保存和使用的文字稿，录音转写路线能力更完整。Google 在音频转写文档中列出了 85 多种语言的自动检测、自定义词汇、Smart 或逐字输出、说话人分离，以及词级时间戳。
普通音频时长上限为 1 小时。启用说话人分离或词级时间戳后，上限会降至 30 分钟；Google 还特别标注，3 位及以上说话人的归属判断属于实验性能力，尽管模型参考文档列出的说话人数量上限为 8 位。
这条路线适合口述、采访和较短的通话。若是需要说话人归属和时间对齐的长会议，就得由应用负责拆分音频，再把结果拼接起来。
实时转写：gemini-3.5-transcribe-live
实时路线的设计目标是逐步生成字幕，而不是通过 WebSocket 复刻录音转写路线。Google 的实时转写文档说明了中间转写和最终转写事件、自动语言检测、自定义词汇，以及自动、混合或手动语音活动检测。
单个连续实时会话只能持续 10 分钟；实时流式转写不支持说话人分离和词级时间戳。音频还必须是原始 16-bit PCM、16 kHz、单声道、小端格式。这些限制足以应付字幕预览，但如果要录制长通话，应用就必须处理重连、片段拼接和临时文本。
真正决定体验的，是这些能力之间的取舍
Gemini 3.5 Transcribe 的差异化卖点是“智能”清理，但这也改变了“准确”的含义。润色后的文字可能更适合口述整理，却未必适合作为原始记录。
Smart 模式是在编辑，不是在留档
Google 的 Smart 模式会删除语气词、口吃和说到一半的停顿，处理口头改口，并自动整理标点、数字、列表和段落。比如“我们周二见，不，周三见”，最后可能只会变成“我们周三见”，而不是保留前面的改口过程。
对于草拟邮件、语音备忘录或易读的会议笔记，这种处理很方便。但如果犹豫、原始错误，或者完整的措辞顺序本身具有意义，它就会带来风险。
官方转写指南明确了这条边界：Smart 模式不能与说话人分离或词级时间戳同时使用。换句话说，API 要求你在整洁文本和可追溯标注之间做选择。
更稳妥的做法是把逐字稿保留为事实来源，再为读者生成 Smart 版本或经过下游处理的干净稿件。不要指望靠提示词绕过这个冲突，因为它属于输出契约层面的限制。
时间戳和说话人标签增强了可追溯性，但也会压缩可用范围
在逐字模式下配置后，录音转写可以返回 word_info 标注，其中包含词语文本、偏移量和说话人标识。这些信息可用于字幕、点击跳转播放、计算每位说话人的发言时长，以及核查原始证据。
| 需求 | 录音路线 | 实时路线 |
|---|---|---|
| 说话人分离 | 支持；文档列出最多 8 人，3 人以上属于实验性 | 不支持 |
| 词级时间戳 | 支持 | 不支持 |
| 带标注的 Smart 输出 | 不支持 | 不支持词级标注 |
| 时长限制 | 普通情况 1 小时；启用说话人分离或词级时间戳后为 30 分钟 | 每个连续会话 10 分钟 |
| 准确率注意事项 | Google 警告词级时间戳可能降低准确率 | 中间文本在最终确定前可能发生变化 |
因此，“支持时间戳”并不是完整的采购结论。功能本身确实存在，但它会降低单个文件的时长上限，还可能牺牲识别准确率。不要把文档中的最大说话人数当成大型会议中的可靠性承诺，应该直接测试说话人归属效果。
自定义词汇与语言检测
两条路线都支持自动语言检测和自定义词汇。Google 文档显示支持 85 多种语言和语言切换；如果应用已经知道语言，Google 建议提供类似 en-US 的提示。
自定义词汇最多可包含 1,000 个词条，但 Google 的实际建议是，通常控制在 100 个以内效果最佳。词表应该用于产品名、缩写、专有名词和技术术语，而不是普通词语。
“支持”不代表在不同口音、方言、嘈杂环境和句中语言切换下都能达到同样的质量。早期 Reddit 上有人专门询问实时路线能否处理混合语言，这可以作为一个值得测试的场景，但不能据此证明产品存在或不存在某种问题。
“我更希望它把视频稍微延迟一点，让字幕能和说出来的话同步。”——u/WaterObjective5107，Reddit
这条评论点出了 WER 无法衡量的实时产品问题：字幕即使语言上完全正确，如果和视频或说话内容不同步，用户仍然会觉得体验不对。
这些准确率数字，究竟能说明什么
Google 发布的数据看起来很有吸引力，但它们对应的是多个不同的评测环境，并不是 Gemini 3.5 Transcribe 的一个通用得分。这些数字足以支持认真做一次试点，却不能替代对你自己的麦克风、口音、术语和说话人模式进行测试。
| 评测环境 | 报告 WER | 它能说明什么 |
|---|---|---|
| Artificial Analysis，流式 | 4.0% | 引用的流式平均值，不代表延迟或说话人分离表现 |
| Artificial Analysis，非流式 | 2.6% | 在其测试条件下得到的录音转写平均值 |
| FLEURS，流式 | 5.50% | 覆盖部分语言环境的多语言流式结果 |
| FLEURS，非流式 | 5.04% | 另一组多语言录音转写结果 |
这些数据来自 Google 的发布公告。公告还声称，相比 Chirp 3，最终转写完成时间提升了 70%。但这仍是 Google 的说法，并不是针对你的工作流进行的独立测试。
2.6% 和 5.50% 之间的差异并不矛盾。两者的路线、数据集、语言构成和流式条件都不同。与其只看总体 WER，不如重点统计那些真正会造成成本的错误，比如人名、订单号、日期、金额、产品术语和说话人切换。
早期社区反馈把语言切换、说话人归属、时间戳行为以及长录音能否完整返回列为重点测试场景；一位 X 平台测试者称，20 分钟音频最后只返回了 5 分钟内容。这些只是方向性的个案，不是受控条件下的产品事实。（X 报告）
配置指南之外，真正影响上线的摩擦点
上传成功或 WebSocket 连接成功，只能证明传输链路可用，并不代表系统已经适合生产环境。真正的风险通常出现在演示之后：实时文本会变化、不同路线有不同限制、凭据需要保护、服务仍在预览期，以及团队是否明确了如何保存一份可信的文字稿。
实时字幕首先是一个状态管理问题
实时响应有两种用途。interim_input_transcription 是用于字幕预览、随时可能变化的猜测文本；input_transcription 才是已经确定的片段，可以追加到持久化的文字稿状态中。
可以采用下面这套状态模型：
- 每次收到中间更新时，替换界面上显示的字幕。
- 只把最终确定的文本追加到已提交的文字稿中。
- 在 10 分钟会话边界到来前续期或重连。
- 拼接多个会话时加入明确的边界标记，并实现去重逻辑。
- 不要让不可逆操作依赖中间文本。
在浏览器和移动端客户端中使用临时令牌，避免把长期 API 密钥暴露在前端代码里。你需要一个后端来签发并限制这些令牌；如果应用架构适合，音频随后可以从客户端直接流向 Live API。还要监控连接错误、最终确定延迟和重复片段。
录音工作流必须先定义“事实来源”
先确定输出契约，再选择模式。需要通顺文字时使用 Smart 模式；需要原话、说话人或偏移量时使用逐字模式。
保存逐字结果及其标注，再为搜索、摘要或面向客户的笔记生成单独的清理稿。这样会多出一个处理步骤，但比起 Smart 模式改写源内容后再试图找回被删掉的语气词或被覆盖的改口，这种方式安全得多。
预览状态会改变部署决策
Google 于 2026 年 8 月 26 日以公开预览形式发布 Gemini 3.5 Transcribe 模型家族。Google 模型参考文档列出了能力和限制，但由于仍处于预览阶段，在迁移之前，价格、配额、行为和可用性都需要重新确认。
先用一小组不含敏感信息的评测集和已保存的参考转写稿开始测试。分别统计关键实体准确率、说话人归属、最终确定延迟、重连行为和人工修正率；在测试前写下明确的通过阈值，只有各项指标都达标后再扩大使用范围。
别只看单价：真正该算的是“可接受文字稿成本”
按当前展示的估算，Gemini 3.5 Transcribe 价格不高，但它采用的是按 token 计费，并不是一个有保证的固定每分钟资费。Google 官方价格表列出，录音音频输入大约为每分钟 $0.003，文本输出为每分钟 $0.002，合计约为每分钟 $0.005；Live 的混合估算约为每分钟 $0.009。
| 路线 | 音频输入估算 | 文本输出估算 | 混合规划估算 | 100 小时 |
|---|---|---|---|---|
录音 gemini-3.5-transcribe | $0.003/分钟 | $0.002/分钟 | $0.005/分钟 | 约 $30 |
实时 gemini-3.5-transcribe-live | 约 $0.005/分钟 | 约 $0.004/分钟 | $0.009/分钟 | 约 $54 |
第一版预算可以按 100 小时录音约 $30、实时约 $54 来估算，但这还没算重试、存储、音频转换、人工修正和下游摘要。输出长度及额外上下文都可能改变最终账单，因此要保留用量日志。
截图来自 Google 公开价格页面；在承诺大规模用量前，请确认当前价格表。参见官方 Gemini API 价格文档。
可接受文字稿的成本，应该按 API 用量加上复核时间、审核人员时薪、重试、存储、格式转换和下游处理来计算。如果 Smart 模式的修正或额外的标注流程能减少人工返工，那么即使 API 单价更高，整体成本也可能更低。
Gemini 3.5 Transcribe API 评测 FAQ
Smart 转写能保留原话吗？
不能。Smart 模式会编辑口语中的不流畅表达和自我修正，因此只要原话重要，就应该把逐字模式保留为事实来源。
Live API 提供说话人标签或词级时间戳吗？
不提供。如果需要说话人分离或词级时间戳，请使用录音路线。
Gemini 3.5 Transcribe 能处理长会议吗？
普通录音转写上限为 1 小时；启用说话人分离或词级时间戳后为 30 分钟；Live 每个连续会话最多 10 分钟。
它适合法律、医疗或合规转写吗？
只能将它作为辅助层使用，并配合逐字输出、关键字段检查和人工复核；不要把 Smart 输出作为高风险记录的唯一版本。
最终结论：可以拿来做原型，但别让它稀里糊涂变成正式记录
如果你的目标是低成本、多语言、能结合上下文的转写，而不是完美保留每一个字，Gemini 3.5 Transcribe 值得认真考虑。建议先从录音路线开始，用你自己的音频对比 Smart 和逐字输出；只有在 30 分钟时长边界可以接受时，再加入说话人或词级标注。
如果要做字幕或语音 UI，等客户端能够安全地以要求的 PCM 格式传输音频，并且能明确区分中间文本与最终文本后，再切换到 Live。对于敏感记录，要保留原始路线的结果，并把人工复核写进验收标准，而不是等 Smart 模式改写了源内容后再临时补救。