Gemini 3.5 Live Translate：翻译从轮流说变成跟着说

开口说话和听到译文之间，如果总要等一个完整句子结束，会议就会变成一串尴尬停顿。Gemini 3.5 Live Translate 要解决的就是这个缝隙：它不再把语音翻译当成「听完一句、翻一句」的轮流流程，而是把输入音频当作连续流，边听边生成另一种语言的语音。Google DeepMind 在 2026 年 6 月 9 日发布这项模型，称它支持 70 多种语言，译音会尽量保留说话人的语调、节奏和音高，并让输出在会话中只落后说话人数秒。1

实时翻译最难的地方不是把一句话翻对，而是在「等更多上下文」和「尽快出声」之间取舍。等得久，主谓宾和代词关系更清楚，翻译质量更稳；出声早，用户才会觉得对话在同一个节奏里。DeepMind 对 3.5 Live Translate 的描述正落在这个折中点上：模型会持续生成译音，同时平衡上下文完整度和同步性。1

这意味着它更像一个实时口译管线，而不是一个会聊天的语音 Agent。Google 的开发者文档也把二者明确区分开：Live Agent 可以使用工具、接受指令、处理多模态输入；Live Translation 只做低延迟翻译，输入被限制为音频，不支持工具和系统指令。2 这点很关键，因为它说明 Google 在这里牺牲了部分通用性，换取更稳定的延迟边界。

从发布路径看，Google 并没有只把它放进 Translate App。3.5 Live Translate 同时进入三个入口：开发者可通过 Gemini Live API 和 Google AI Studio 使用公开预览版；企业用户会先在 Google Meet 私有预览中试用；普通用户则能在 Android 和 iOS 版 Google Translate 里使用。1

API 文档暴露出的工程边界也很具体。输入音频格式是 16kHz、单声道、16-bit PCM；输出是 24kHz、单声道、16-bit PCM；推荐以 100ms 音频块发送。2 对产品团队来说，这不是「调一个翻译接口」这么简单，前端采集、回声消除、网络抖动处理、音频播放缓冲都会影响最终体验。

模型卡写明，Gemini 3.5 Live Translate 基于 Gemini 3 Pro，音频输入上下文窗口最高 128K token，输出支持音频和文本，最高 64K token。3 这个配置说明它不是一个轻量级端侧模型，而是面向长会话和在线服务的 Gemini 系列音频能力。

评测部分更值得注意。Google 把质量拆成三类：翻译质量、延迟和语音自然度。翻译质量用 AutoMQM 这类错误分类指标评估；延迟分成初始延迟和词级延迟；语音自然度则看卡顿、声音漂移和非预期音频伪影。3 但模型卡没有给出公开分数，只说使用内部 benchmark 和 Gemini Live API 输出评估。换句话说，官方已经给了评测维度，却还没有给外部开发者足够的横向数字来判断它比传统级联方案强多少。

3.5 Live Translate 现在最适合的是「低风险、高频跨语言沟通」：跨国团队例会、在线课程、导览、客服预沟通、直播辅助字幕和语音转译。DeepMind 提到 Grab 正在测试它用于司机和旅客接送时的近实时多语言沟通，而 Grab 用户每月通过平台产生超过 1000 万次语音通话。1 这类场景的共同点是：翻译错一句会影响体验，但通常不会立刻造成法律、医疗或金融后果。

真正要谨慎的是多说话人、强口音、相近语言快速切换和背景声很重的场景。模型卡和开发者文档都列出类似限制：声音可能在长停顿后漂移，快速多人对话里可能卡在某个声音上；语言检测在非母语口音、相近语言或快速切换时会吃力；背景噪声和音乐也不一定完全被过滤。3 如果要把它用于客服、医疗问诊、法律咨询或大型会议同传，最好保留人工复核、文字转录回看和关键句确认机制。

语音翻译过去已经能做到「可用」，但可用不等于自然。用户真正在意的是三件事：能不能跟上说话节奏，声音是否足够自然，出错时能不能发现并纠正。Google 给 3.5 Live Translate 加上 SynthID 音频水印，用于帮助识别 AI 生成音频，说明它也把误用风险放进了发布叙事里。1

下一步应看两个外部信号。第一，开发者在 Live API 上跑真实网络、嘈杂环境和多人会话后，词级延迟和断句错误是否可控。第二，Google Meet 的企业预览能否证明 70 多种语言和 2000 多种组合在会议里不是功能清单，而是能长期使用的协作体验。没有这些实测之前，3.5 Live Translate 更像一条清晰的产品路线：把翻译从离散句子处理，推向连续语音流处理。