实时语音应用的选型，最终会拆成两条并不相同的链路：一条是人和模型来回说话的会话链路，一条是把语音变成文字的转写链路。前者关心首包延迟、打断响应、会话状态由谁维持；后者关心吞吐、标点与时间戳、长音频怎么切。Google 官方博客在 2026-09-15 公布了一组音频模型名称——Gemini 3.8 Live、3.8 Live Extended Thinking 和 3.5 Transcribe，官方给它们的定位是「最新的音频模型」，内容方向是「开发者如何用它们构建实时语音应用」。
目前可确认的官方事实
- 三个模型名称：Gemini 3.8 Live、Gemini 3.8 Live Extended Thinking、Gemini 3.5 Transcribe；
- 官方把它们称为最新的音频模型；
- 官方表述的落点是开发者如何构建实时语音应用；
- 官方发布时间为 2026-09-15。
官方资料没有提供模型规格、API 名称、参数、代码示例、性能数字、定价或可用范围，因此下面这些内容不能在本文中当成事实使用：上下文长度与最大音频时长、延迟与吞吐数字、流式协议（是 WebSocket、WebRTC 还是别的）、SDK 语言支持、计费单位、是否支持工具调用与系统指令、是否支持打断（barge-in）与端点检测、GA 或 Preview 状态、地区可用性与配额、是否提供时间戳与说话人分离。
把这份「未公布清单」明确列出来并不是凑字数，它直接决定排期：哪些部分现在就能动手设计，哪些必须等文档确认后才能定接口。
命名能读出的只是方向
从工程角度看，命名给出的信息量有限，但方向是可读的。Live 与 Live Extended Thinking 共享同一个前缀，差别落在 Extended Thinking 上——这暗示同一套会话能力下存在两档推理投入，一档换取更短的首包时间，一档换取更深的前置推理。这是命名层面的推断，不是官方承诺。
真正值得先确认的是三个问题：扩展思考是否可在会话中途切换、切换是否要重建会话、推理耗时是否直接体现在端到端响应上。这三点决定了它在实时对话里能不能用。如果思考过程不可控或不可打断，它在语音场景中的位置就更接近会前准备或会后处理，而不是对话中段。相比之下，Transcribe 与 Live 的命名分叉更直接：一个是转写，一个是实时会话。把两者当成同一类模型的参数档位，是选型时最容易犯的错误。
两条链路各自的关注点
会话链路上，通用工程关注点集中在几处：音频采集与端点检测放在端上还是服务端；上行编码与丢包重传怎么处理；会话状态由服务端保持还是客户端维护，断线重连后能否恢复；用户打断时下行音频如何截断、已产生的会话历史如何记账。首包延迟建议拆成采集、上行、模型首个输出、下行合成四段分别测量——只测端到端平均值，通常定位不到瓶颈在哪一段。工具调用是个容易低估的点：它能把响应时间从百毫秒级推到秒级，交互上需要有兜底话术，否则用户会以为连接断了。
转写链路上，先要回答的是结果形态：需要流式部分结果还是一次性结果；长音频按什么粒度切分，切点会不会切断词；标点、大小写、时间戳、说话人是否需要后处理补齐；领域词和热词怎么注入。下游用途反向决定精度要求——用于实时字幕和用于合规存档，对时间戳对齐的要求完全不是一回事。
接入前建议核对的清单
- 官方 API 参考页中三个模型各自的模型 ID 字符串；
- 流式协议类型与音频编码、采样率要求；
- 首包延迟与单次会话的最大时长限制；
- 会话状态由服务端保持还是客户端维护；
- 是否支持工具调用、系统指令、中途打断；
- 计费单位是按秒、按音频时长还是按 token；
- 配额与限流策略；
- GA 状态、地区限制，以及语音数据的处理与留存政策——语音数据的合规敏感度通常高于文本。
不能从当前资料推出的结论
不能因为命名就说 Gemini 3.8 Live 的延迟一定低于 3.8 Live Extended Thinking；不能把 3.5 Transcribe 理解为 Live 的降级版本，版本号不同不代表属于同一条产品线；不能给出任何填了具体数字的对比表；也不能给出相对上一代的提升幅度。这些都需要等官方规格页或 API 文档出现后才能判断。
对近期就要排期的团队，一个可行的做法是：先用最小会话链路（采集 + 端点检测 + 一次往返）跑通，再把扩展思考、工具调用这类会拉长响应时间的能力逐个叠加，每加一项重新测一次端到端首包延迟。语音交互的体验瓶颈往往来自延迟逐层叠加，而不是单点模型能力。等三款模型的规格明确后，再决定哪些能力留在会话链路、哪些下移到转写链路做后处理。