多数语音翻译产品还困在一个怪圈里：把你说的话变成文字，翻译文字，再把翻译好的文字念出来。每一步都在丢信息——语气丢了，停顿没了，一句带着笑意的反问到对方耳朵里可能变成冷冰冰的陈述。Google 这次直接把中间两步砍掉了。刚刚放出的 Gemini 3.5 Live Translate，做的是音频进、音频出，近实时延迟，并且在 70 多种语言之间保留说话者的语调、节奏和音高。这不仅仅是翻译模型的迭代，而是把实时跨语言通话从 demo 真正推到了可用的工程水位。
从音频到音频，中间不落文字
跳过 STT 和 TTS 的代价是什么？
传统语音翻译管线是串行的：自动语音识别把音频转成文本，神经机器翻译处理文本，最后文本转语音念出来。每一步都有延迟，每一步都在积累错误。整个链路下来，端到端延迟做到 2 秒以内已经算优秀，而且你永远听不到对方原本的笑声或叹息。Gemini 3.5 Live Translate 换了一种思路——直接处理原始音频流，模型内部学习跨语言的声学映射和语义对齐，输出端合成的语音自然带上了源说话者的副语言特征。Google 没有披露具体的模型架构细节，但从其之前的 AudioLM 和 Gemini 多模态积淀来看，这应该是一个统一处理语义和声学特征的端到端模型，抛弃了离散的文本中间表示。
保留语调为何比准确率还关键？
很多人会第一时间盯翻译准确率。但在实时对话场景里，语调所承载的意图往往比字面意思更重要。一句“你确定？”用上扬的疑问语气和下沉的威胁语气，含义截然不同。如果翻译后只剩平铺直叙的文字朗读，对话的社交信号就丢失殆尽了。Grab 之所以对这个能力感兴趣，正因为它所服务的司机和乘客来自东南亚多种语言背景，打车场景中的沟通高度依赖即时的情感判断——“师傅我快迟到了，能快一点吗？”这句话里的焦虑，不能只靠文字传达。Gemini 3.5 对节奏和音高的保留，意味着跨语言对话中的情绪线索首次没有被技术吃掉。
70 种语言的栈里藏着什么？
覆盖 70 多种语言听起来像是一个常规的大模型卖点，但实时语音翻译对低资源语言的门槛远比文本翻译高。训练数据不仅要包含双语平行语音，还要有足够的对话交互、噪声环境和口音变体。Google 敢把这套系统推向东南亚市场——一个语言碎片化程度极高的区域——说明其在端到端语音对齐上已经跑通了规模化的数据工程。再结合第三方开发者的快速接入，这个语言栈很可能不是简单的大模型一次性推理，而是嵌入了某种适配层的混合系统，允许针对特定语言对做延迟和质量的微调。
1000 万次通话的试验场
Grab 的司机与乘客场景
最实在的检验永远来自真实业务。东南亚超级应用 Grab 每月有超过 1000 万次司机与乘客之间的语音通话，他们正在探索用 Gemini 3.5 Live Translate 替代原有的文字翻译弹窗。这比任何基准测试都有说服力：车内环境嘈杂，司机和乘客的母语从泰语、越南语到印尼语不一而足，对话内容涉及确认上车地点、修改目的地、甚至一些突发状况的协商。任何翻译延迟或语调丢失导致的误解，都会直接拉低乘客满意度和司机接单效率。Grab 选中这个模型，说明其在实际道路噪音和口语化表达下的稳定性至少过了内部评估关。
延迟究竟有多低？
Google 使用了“近实时”这一谨慎措辞，但根据其同步放出的开发者文档和演示视频，翻译后的语音开始推流的时间差被压缩到了 几百毫秒级别，基本等同于普通蓝牙耳机的音频延迟。这背后不仅仅是模型推理速度的问题，还需要一整套实时音频流处理管道——从音频捕获、窗口切分、模型推理、到一个干净的低延迟输出流，中间不能有任何缓存堆积。与 LiveKit、Fishjam 这类 WebRTC 基础设施的深度整合，正是为了解决流媒体层面的瓶颈。这一点后面细说。
实时性与隐私的双重考验
语音翻译进入实时通话场景后，隐私问题比文本翻译尖锐得多。原始音频直送云端翻译，意味着每一通电话的内容都对服务提供方透明。Grab 作为平台方，需要对司机和乘客双方做数据合规声明，并确保音频流不会被存储或用于二次训练。Google 这边给出的方案是 Gemini Live API 的按需处理，宣称翻译完成后不留存音频数据，但具体的合规细节仍取决于各地法规。这也是为什么这类功能往往先在东南亚等监管相对灵活的地区落地，而不是欧洲。
开发者如何接手这套实时管线？
API 层：LiveKit、Fishjam 与 MoQ 协议
Google 没有只把这个能力锁在自己的 App 里，而是直接开放了 Gemini Live API，让开发者可以接入实时音频流。这是正确的做法，因为实时翻译的落地形态远比一个翻译软件复杂。LiveKit 第一时间展示了虚拟会议室中的多语言即时理解——不同语言的参会者各自说母语，其他人听到的是翻译后保留原语的语音。Software Mansion 则把目光放在传输协议上，结合 MoQ（Media over QUIC）突破了高并发下的流媒体瓶颈，意味着在弱网条件下的翻译连续性有了本质改善。Fishjam 和 Pipecat 这些前端框架的加入，也让低代码搭建实时翻译客户端成为可能。
VisionAgents 的动态语言切换
另一个有意思的整合来自 VisionAgents AI。他们展示了在一次对话中动态切换多种语言的能力，不是用户手动切换语言通道，而是系统自动识别说话者当前使用的语言并切换到正确的翻译目标语。这在东南亚等多语言频繁切换的地区几乎是刚需——一个马来司机可能上一句说马来语，下一句切到英语。这种多语态识别和语音翻译的无缝衔接，让 Gemini 3.5 的能力从“翻译器”升级成了“多语言理解层”。
一键试用的 Cookbook
Google 没有只扔出一串文档就完事。开发者现在可以在 Google AI Studio 里直接试用 Gemini 3.5 Live Translate，并且有配套的 Cookbook 提供可运行的代码示例。从音频流接入、语言选择到与 LiveKit 等组件对接，Cookbook 给出了一整套最小可行实现。这意味着一个有一定音频开发基础的团队，最快几天内就能把实时语音翻译嵌入自己的产品原型。门槛被降到了相当低的程度。
这不止是翻译工具的升级
出海产品的下一个基建
过去两年，中国出海产品在文本翻译上已经吃尽了 LLM 的红利——客服聊天、产品文案、评论回复纷纷用大模型替代。但语音层面的实时翻译一直卡在工程化。Gemini 3.5 Live Translate 的发布，等于给所有涉及跨语言实时通话的出海场景——从社交直播到网约车、从在线教育到远程医疗——提供了一个可商用的基础设施选项。不必自己训练端到端语音翻译模型，直接调用 API 就能搭建多语言语音房、AI 导游、实时口译耳机等应用。对中小团队来说，这是把精力放回产品体验而不是底层模型的契机。
别急着欢呼，还有些锈没除
当然，一切还没有那么美好。端到端语音翻译虽然在延迟和语调保留上有优势，但其翻译的忠实度和稳定性在长尾语言对上未必能超过传统的级联方案。另外，实时翻译中的“口误修正”和“文化适配”依然是难题——一个带有调侃意味的本地俚语，模型是否该直译，还是应该替换成目标语言中功能对等的表达？这背后需要的不仅是声学对齐，还有深层语用推理。目前 Gemini 3.5 更偏向保留原始情感，这意味着它可能把一个粗鲁的表达原汁原味地传过去，这在某些商务场景下反而是灾难。
语音原生的新入口正在裂开
跳出翻译本身，Gemini 3.5 Live Translate 透露出的信号更值得关注：Google 正在把 语音原生 作为 AI 交互的默认形态来构建基础设施。当实时翻译成为一种随时可调用的低保真功能，应用之间的竞争就不再是“能不能翻”，而是“翻完之后还能做什么”。能在翻译之上叠加情感分析、意图理解、对话摘要的玩家，会获得更厚的价值层。这也是为什么类似 VisionAgents 的动态多语言切换这种小创新，反而比翻译核心指标更值得追踪——它们是未来产品形态的原型碎片。一条新的语音原生管线已经拆箱，现在轮到开发者们去组装自己的产品了。
