Gemini 3.5 Live Translate:实时语音翻译从演示走进 API

Google DeepMind 发布流式语音到语音翻译,70+ 语言、保留语调语速音高,关键不在演示而在它进了 Gemini Live API。

Gemini 3.5 Live Translate:实时语音翻译从演示走进 API
图 / Unsplash

概述

Google DeepMind 发布的 Gemini 3.5 Live Translate,最省事的读法是”翻译又变快变好听了”。这个读法不算错,但它会让你错过这次发布真正的分水岭:实时语音翻译第一次以一种开发者可以直接拿去拼装产品的形态出现,而不只是又一个剪得很漂亮的发布会片段。

把这件事讲清楚需要先分开两个层面。一个是模型本身:它能自动识别 70 多种语言,生成听起来自然的译后语音,并且保留说话人的语调、语速和音高。另一个是分发:它同时铺在三个口子上,开发者经 Gemini Live API 和 Google AI Studio 拿到公开预览,企业经 Google Meet 拿到私有预览(本月起),所有人经安卓和 iOS 上的 Google 翻译 App 用上。这两层里,对建设者真正要紧的是后者,而且要紧的恰恰是那个不起眼的细节:它进了 Live API。

所以本文的判断很直接:实时语音翻译过去是个被各家攥在自家产品里炫耀的能力,现在它变成了一块可以被任何人接进自己应用的积木。能力强不强只是门票,能不能集成才决定它会不会真的改变产品形态。下面逐层拆。

发生了什么

Gemini 3.5 Live Translate 是一个面向实时语音到语音翻译的音频模型。按官方描述,它自动识别 70 多种语言,不需要手动配置,输入端可以是多语言混杂;它对噪声有一定鲁棒性,意在应付吵闹、不可预测的真实环境。

技术上最值得记住的一句话是:它不是逐句等待的系统。传统的逐轮翻译要等说话人把一句话讲完才开口,Gemini 3.5 Live Translate 则是边听边持续生成语音,在”多等一点上下文换更高质量”和”立刻翻出来跟上说话人”之间做平衡。官方给的体感指标是:全程比说话人慢几秒,不会出现尴尬的停顿。这一句话其实就是整个产品的工程核心,后面会单独讲。

铺货路径分三档。开发者档:经 Gemini Live API 和 Google AI Studio 公开预览,官方还点名了一批已经接进来的实时媒体平台,包括 Agora、Fishjam、LiveKit、Pipecat、Vision Agents,由它们去扛实时流媒体的复杂基础设施,开发者只管做体验。企业档:经 Google Meet 私有预览,本月起面向部分 Workspace 商业客户,Meet 里的语音翻译会从原先只支持 5 种语言扩到 70 多种,从只能跟英语互译扩到一场会议里 2000 多种语言组合。消费者档:Google 翻译 App 全球上线,安卓还新增一个”听筒模式”,把手机贴耳朵就能像接电话一样听到译音。所有生成的音频都打了 SynthID 水印。

合作方给的反馈是定性的好评,没有公开数字,唯一一个具体量级来自 Grab:它的司机和乘客每月通过 Grab 打超过 1000 万次语音电话,Grab 正在用这个模型测试接送时的近实时多语沟通。这个数字说明的是潜在场景的体量,不是模型性能。

为何重要

重要性不在”翻译更好了”,而在交互形态的切换:从逐句翻译切到流式翻译。

逐句翻译的体验问题是结构性的,不是调参能解决的。它必须等一句话说完,于是对话被切成一段段独白,双方都得记住”现在轮到谁等”,越往后越累。流式翻译换了一套节奏:系统边听边出声,始终落后说话人几秒,对话因此能保持来回的弹性,而不是变成两个人轮流对着翻译机说话。这个差别在两三句寒暄里感觉不出来,但在一通十分钟的真实对话里就是”能用”和”勉强能用”的分界。

而流式翻译之所以难,难在它把翻译变成了一个实时控制问题。模型每一刻都要赌:现在抢着翻出来,可能赌错后面的语义,得返工;多等半秒上下文,又会拉大延迟、让对话脱节。这不是一次性算好的最优解,是贯穿整段对话、每一刻都在重做的取舍。能稳定地把这个取舍做到”慢几秒、不卡顿”,比单纯刷低延迟数字难得多,也更说明工程成色。

第二点重要性在”信达雅”里的”雅”被当成了一等目标,也就是保留语调、语速、音高。机器翻译过去默认只搬运语义,把怎么说全丢了。但人在对话里靠语调判断对方是认真还是玩笑、是迟疑还是笃定,语速和音高则承载着情绪和强调。把这些一起翻过去,等于承认翻译不止是搬运信息,还要搬运”人味”。这件事做不做得好,目前只有合作方的定性好评背书,没有可核验的指标,得留个问号。但它被列为明确目标本身,已经是方向上的进步。

对建设者的影响

对建设者,最硬的信号是它进了 Gemini Live API,而不是只停在 Google 自家产品里。

这两件事差别巨大。一个能力只活在 Google 翻译和 Google Meet 里,它就只是 Google 的产品功能,你顶多旁观。一旦它进了 Live API,它就成了一块原料:你可以把它接进多语言客服、跨国会议、在线课堂、直播配音、跨境出行,官方自己点的这几类场景都是应用层而非 Google 自家场景。判断一个 AI 能力会不会改变行业,不要只看它强不强,要看它有没有越过那道从”自家功能”到”可集成原料”的线。这次越过了。

第二个对建设者友好的细节是那批集成伙伴。Agora、Fishjam、LiveKit、Pipecat、Vision Agents 处理的是实时流媒体里最脏最难的部分:回声、抖动、丢包、多端同步。Google 把模型放进 Live API、又让这些平台先接好,意味着你不必从零搭实时音频管道,可以直接在它们之上拼业务逻辑。这降低的不是模型调用成本,是”把一个语音翻译 demo 变成真能上线的产品”之间那段最容易翻车的工程距离。

但有两个现实约束必须先想清楚,否则会做出过度乐观的产品决策。其一,它现在是预览,不是正式可用,开发者公开预览、企业私有预览。预览意味着配额、稳定性、定价都还可能变,别在它之上压上确定性要求很高的业务。其二,那个”慢几秒”是体验的硬地板。几秒延迟对会议、课堂、客服完全够用,但对需要严丝合缝同步的场景(比如实时口译要卡着画面、或抢答类互动)就未必,产品定位时要先认这条线,而不是指望它会消失。还有一条容易被忽略:所有译音都带 SynthID 水印,如果你的产品要做合规留痕或内容溯源,这是个现成的抓手。

该忽略什么

该忽略合作方那些定性赞美。“质量惊人""准确度高""延迟低""SOTA”这类话来自正在合作的伙伴,是市场口径,不是评测数据。它们能说明合作方愿意背书,不能用来做技术选型。真要选型,等可核验的延迟、准确率和语言对覆盖数据,自己在目标场景里测。

该忽略”70+ 语言”被当成一个可以横向比较的硬指标。语言数是营销友好的大数字,但对你的产品,真正决定成败的是你那几对语言翻得怎么样、口音和噪声下扛不扛得住,而不是它一共支持多少种。一个能把你需要的三对语言做到稳的模型,胜过支持 70 种但你那几对很糟的模型。

该忽略消费者侧那些好用的小功能本身,安卓”听筒模式”、Google 翻译 App 全球上线。它们很贴心,但那是 Google 的产品决策,复制不到你的应用里,也不构成对你的能力。对建设者有意义的永远是 API 那一档。消费者档只是用来证明 Google 自己相信这个模型已经到了能大规模铺的成熟度,把它当成信心信号,别当成可借用的能力。

技术要点

来源

  1. Fluid, natural voice translation with Gemini 3.5 Live Translate / official
  2. Gemini 3.5 Live Translate / hn