Gemini 3.5 Transcribe 上线后怎么选中转 API：录音转写、实时字幕与账单核验清单

要做会议纪要、客服质检、播客转写或实时字幕时，很多人的第一反应是：找一个“支持 Gemini”的 API 就行。

Gemini 3.5 Transcribe 上线后，这个判断已经不够了。录音文件转写和实时字幕对应不同模型、不同接口和不同传输方式；一个渠道即使能调用普通 Gemini 聊天模型，也不等于它已经同步了转写模型，更不代表它能正确转发文件上传、Interactions API 或长连接 WebSocket。

截至 2026 年 8 月 28 日，Google 已将 Gemini 3.5 Transcribe 与 Gemini 3.5 Transcribe Live 作为公开预览能力提供给开发者。前者面向已录制音频，后者面向双向流式的实时语音转写。对通过第三方 API 平台接入的开发者来说，下一步不该直接迁移生产流量，而是先完成一轮协议、功能与计费核验。

先选对任务：录音转写和实时字幕不是同一个接入

你的任务	应核验的模型	官方接入路径	最容易踩的坑
会议录音、访谈、通话记录、播客等已完成音频	`gemini-3.5-transcribe`	先通过 Files API 上传，再使用 Interactions API 转写	渠道只有聊天补全兼容接口，没有文件上传或 Interactions API
边说边出字的字幕、语音 Agent、通话辅助	`gemini-3.5-transcribe-live`	通过 Live API 建立双向 WebSocket 流	渠道宣称支持模型，却不支持 WebSocket、音频流或该协议版本

Google 的转写文档明确将文件转写和实时转写拆开：已录制音频使用 gemini-3.5-transcribe，实时低延迟流式识别则使用 gemini-3.5-transcribe-live。这意味着，只有 /v1/chat/completions 一类 HTTP 兼容入口的渠道，在工程上不能仅凭“Gemini 可用”就推断这两项能力也可用；必须针对实际协议做验证。

这次新增了什么，哪些能力会影响你的接口设计

Gemini 3.5 Transcribe 支持自动语言识别、说话人区分、词级时间戳、自定义词表和 Smart transcription。Smart 模式会清理口头语、重复和停顿，并做格式化；如果你的产品需要“可读会议纪要”，它可能更方便。

但“更干净的文本”和“可审计的逐字记录”不是同一个目标：

Smart transcription 适合草稿、会议摘要前处理、面向用户的可读字幕。
Verbatim + 词级时间戳 / 说话人区分 更适合质检、字幕对齐、取证或需要回放定位的场景。
两者不能混用：官方文档说明 Smart 模式不能与词级时间戳或说话人区分同时开启。
标准单次请求最多可处理 1 小时音频；启用说话人区分或词级时间戳时，音频处理上限为 30 分钟。说话人区分最多支持 8 人，但 3 人及以上的归属仍是实验能力。

因此，接入前先写清楚你的输出合同：你要的是“整理过的文本”，还是“带说话人和时间轴的逐字稿”。不要让渠道在两个模式之间静默降级，否则下游存储、检索、字幕和质检流程都可能出错。

官方价格可以当基线，但不是你的最终账单

按 Google Gemini API 价格页在 2026 年 8 月 28 日 可见的标准付费价估算：

模型	音频输入	文本输出	官方给出的有效混合成本估算
`gemini-3.5-transcribe`	$0.003 / 分钟	$0.002 / 分钟	约 $0.005 / 分钟
`gemini-3.5-transcribe-live`	$0.005 / 分钟	$0.004 / 分钟	约 $0.009 / 分钟

这是官方 Gemini API 的估算基线，不是任何第三方平台的承诺价。中转渠道还可能叠加模型倍率、支付币种换算、最小充值额、请求失败的计费规则或自有计量口径。特别是 Live 模型，音频持续时间、断线重连、静音段是否仍在推流、以及文本输出长度都会影响实际账单。

建议先用一段固定长度、固定语言、固定码率的测试音频做一次对账，再放大流量：

记录上传文件时长、模型 ID、请求 ID 和转写模式；
保存渠道响应中的用量字段、账单明细与返回状态；
用官方每分钟估算价格计算一个参考区间；
对比渠道的模型倍率和最终扣费；
对实时链路额外记录断线次数、重连后是否重复发送音频，以及重复段是否重复计费。

这样得到的是可解释的单次样本，不是长期稳定性结论；要判断可用性，仍应在不同时间段、网络条件和音频类型下重复测试。

选中转渠道前，先跑完这 7 个核验项

1. 核验准确模型 ID，而不是只看“Gemini 3.5”

要求渠道明确列出 gemini-3.5-transcribe 和/或 gemini-3.5-transcribe-live。不要把 gemini-3.5-flash、通用音频理解模型或自定义别名自动等同于专用转写模型。

2. 对录音场景同时测 Files API 和 Interactions API

官方文件转写流程不是单个聊天请求：要先上传文件，再把文件 URI 作为模型输入交给 Interactions API。渠道若只提供文本聊天、图片或普通生成接口，通常无法完整复现这条流程。

3. 对实时场景单独测 WebSocket

实时模型依赖 Live API 的双向流。要检查能否稳定建立 WebSocket、是否支持连续音频帧、断线后怎样恢复，以及服务端是否会把实时能力“兼容”为延迟很高的轮询接口。后者即使能返回文字，也不等于适合字幕或语音 Agent。

4. 检查转写模式和返回结构有没有被裁剪

至少测试一次 Smart 模式，以及一次 Verbatim 模式下的词级时间戳或说话人区分。除纯文本外，下游如果需要说话人标签、时间偏移或 annotations，必须确认渠道没有在协议转换时丢弃这些字段。

5. 用业务词做自定义词表回归

模型允许提供自定义词表。品牌名、产品名、代码名、药品名、地名和缩写往往才是转写项目最贵的错误。选取 20～50 个真正高频词，制作一段固定样本，每次切换渠道或模型版本都回归一次。

6. 先核验时长边界

长录音不要只用 20 秒样本验证。分别测试接近 30 分钟和接近 1 小时的文件，并观察启用时间戳、说话人区分后的行为。产品层也应在上传前提示限制，而不是等转写任务运行一半才失败。

7. 分开记录“模型可用”和“渠道可用”

Google 在 2026 年 8 月 26 日宣布这两款模型进入公开预览；这只能说明官方能力已发布，并不能证明某个中转渠道已经接入、开放给你的分组，或能长期保持相同协议和价格。可以把每个候选渠道的核验结果记录为：模型名、接口类型、测试时间、音频样本、成功/失败、返回字段和实际扣费。

一套最小上线策略

如果你正在替换原有语音识别服务，可以按下面的顺序降低迁移风险：

离线录音先行：先用 gemini-3.5-transcribe 跑固定的会议或客服录音集，比较可读性、专有名词、时间戳和说话人标签。
将 Smart 与 Verbatim 分成两条输出：用户阅读版可使用 Smart；合规、字幕或质检链路保留 Verbatim 的原始结构。
实时业务独立灰度：只在确实需要边说边出字时接入 gemini-3.5-transcribe-live，并单独测网络波动、重连和端到端延迟。
成本按分钟和会话双记账：Live 场景尤其要把音频分钟数、连接时长、重连次数与账单关联起来。
渠道替换要保留退出条件：模型不可用、WebSocket 不稳定、字段缺失或账单解释不清时，能够快速切回已验证路径。

有开发者平台已经明确把 gemini-3.5-transcribe 作为独立的转写模型接入，而不是把它伪装成通用聊天模型；这也从侧面说明，转写能力是否可用取决于具体模型与协议实现，不能只依据一个宽泛的“支持 Gemini”标签判断。

如果你准备通过第三方 API 平台使用 Gemini 音频模型，可先在 RouterHub 平台目录筛出提供 Gemini 的候选站点，再按本文的模型、协议、返回字段与账单清单逐项询问和测试。目录信息可以帮助你发现候选渠道，但最终是否支持专用转写模型、实时链路与对应价格，应以测试当日的渠道说明和实际响应为准。

参考来源

资料核验时间：2026 年 8 月 28 日（UTC）。价格、模型可用范围和第三方渠道支持情况会变化；本文未对任何中转渠道的模型来源、长期稳定性或价格做保证。