GPT-Live-1 与 Gemini 3.5 Live Translate：已发布的通用型选手对阵预览版专精选手

这两个模型之所以常被放在一起比较，是因为它们都把实时语音能力塞进了 API，而只要你翻开模型卡片，这种比较就立刻站不住脚。GPT-Live-1 是一个通用的全双工语音模型，OpenAI 于 2026 年 9 月 10 日将其开放给开发者 API，此时距它 7 月 8 日在 ChatGPT 内上线已过去三个月。Gemini 3.5 Live Translate 则是一个单一用途的音频到音频翻译模型，由 Google DeepMind 于 2026 年 6 月 9 日发布，其模型 ID 至今仍挂着 preview 字样。其中一个，你可以今天就按公开标价摆到付费客户面前；另一个，Google 却可能在毫无弃用通知的情况下从你脚下把它换掉。真正该决定取舍的，是这种不对称，而不是那张基准测试成绩表。

两台不同的机器却贴着相同的标签

值得直说：两者的重叠少得可怜。Gemini 3.5 Live Translate 做的是翻译。它接收一种语言的流式音频，再以另一种语言输出流式音频，同时保留说话者的音色与语气，覆盖 70 多种语言、2,000 多个语言对，并具备自动语言检测和双向运行能力。它不会进行对话、调用函数或回答问题。它是一台同声传译引擎。

GPT-Live-1 则恰恰是相反的形态。它是一个对话式模型：边听边说，每秒多次判断是继续聆听、暂停、打断，还是调用工具，并把繁重的工作——网页搜索、更深层的推理、智能体任务——通过 Responses API 交给另一个推理模型处理，而对话仍在继续。Ope​nAI 自己发布的 WebRTC 示例就把这种委派接到了 GPT-5.6 Terra 上。翻译是它能做的事情之一；而反过来说，Goo​gle 的模型并没有任何与之对等的能力。

所以，实际问题比标题对决所暗示的要更窄：如果你要构建的是口译功能，Google 的模型是专门为此打造的，而 OpenAI 的是通用型。如果你要构建的是偶尔会进行翻译的语音代理，那么在两者之中，GPT-Live-1 是唯一一个甚至属于正确产品类别的产品。

每个每分钟音频的成本是多少

这正是专家发挥价值的地方，而对 OpenAI 来说，这笔账确实很难算。

• GPT-Live-1 — 语音每分钟 $0.05，按秒计费，而不是向上取整到下一整分钟。由所委派后端进行的推理和工具调用，按该模型的正常费率单独计费。

• Gem​ini 3.5 Live Translate — 每百万音频输入 token 3.50 美元，每百万音频输出 token 21.00 美元，计费按每秒音频 25 个 token 计算。合计下来，约为每分钟翻译音频 0.037 美元。

按纯翻译分钟计算，Goo​gle 大约便宜四分之一。在大规模下，这不是四舍五入的差异：每月 10,000 分钟口译在 GPT-Live-1 的语音层上花费约 500 美元，而在 Gem​ini 3.5 Live Translate 上约为 368 美元。而且这一差距是真实存在的，并非计量方式变更造成的假象，因为这两个模型按真正不同的单位计费。

反方向也有一个陷阱。GPT-Live-1 宣传的 $0.05 只是语音层的价格。如果你的智能体在翻译的同时还要查资料，或者把一句难句升级交给推理模型处理，那么你还要为这种委派额外付费——而被委派的模型会像任何其他前沿模型一样按 token 计费。纯翻译工作负载永远不会触发这一点。翻译加任何其他任务的工作负载则会触发，而每分钟成本对比中的赢家就不再那么显而易见了。

预览标签是无人计入价格的风险

Gemini 3.5 Live Translate 的模型 ID 是 gemini-3.5-live-translate-preview。它作为公开预览版登陆 Gemini Live API 和 Google AI Studio，同时登陆 Android 和 iOS 上的 Google Translate 应用，并在 Google Meet 中面向部分 Workspace 客户提供私密预览。“预览”在 Google 一直以来的含义就是：没有稳定性保证，没有公布的弃用窗口期，也不承诺你当前支付的费率能撑过下一次发布。

对于消费级应用来说这没什么问题。但对于这款模型真正瞄准的工作负载——呼叫中心的实时传译、会议产品、旅行产品——它是整个技术栈中最大的集成风险。你正在为一个 Google 明确未承诺支持的模型构建生产依赖。

GPT-Live-1 面临的是相反的问题，而且问题更小，但并非为零。它已正式可用，按已公布的价格提供，有文档记录的端点，并且不会消失。但它的 API 覆盖面很窄，这会让那些以为它能直接接入现有 OpenAI 集成的团队感到意外：只有一个模型 ID、一个端点，并且无法通过 Chat Completions、Responses、Realtime、Batch、Assistants 或微调来接入。唯一的接入方式是 WebRTC 上位于 v1/live/sessions 的 Live Sessions 端点，并在数据通道上进行事件处理。这是一种全新的集成，而不是改一个参数。

语言，以及通才确实较弱的地方

Goo​gle 的数字是 70 多种语言，并保留语音和语气。Ope​nAI 自己的文档对其自身覆盖范围明显不那么自信：发布材料指出，对于某些语言，模型可能带有非母语口音，或在流利度上存在不足，而且它没有公布能与 Goo​gle 相竞争的语言数量。

那不是供应商在故作含糊——那是通用型对话模型与针对该问题训练的专用模型相比时所呈现出的样子。如果你的产品价值主张是“我们能很好地译解 40 种语言”，那么专用模型才是诚实的选择，而通用模型会在长尾场景中让你难堪。如果你的产品是一个面向英语市场的语音代理，只是硬加上了一个翻译功能，那么通用模型的语言短板就永远不会暴露出来。

两款模型都使用 SynthID 为生成的音频添加水印，如果你所在的司法管辖区或客户合同要求合成语音具备来源溯源，这一点就很重要。这一项算是打平。

委派架构在何处改变构建

这两者的结构差异在于，GPT-Live-1 实际上是两个模型，中间有一道接缝。语音层让对话保持进行；一个独立的推理模型负责思考。那道接缝正是你的工程投入所在，也是成本模型变得复杂的地方。

值得了解的是，被委派的那一半是一个普通的文本模型，你可以像路由任何其他模型一样对它进行路由。Ope​nAI 自家示例中所用的后端 GPT-5.6 Terra，通过 OrcaRouter 提供服务，收费为每百万输入 token 2.00 美元、每百万输出 token 12.00 美元，并具备 1M token 的上下文窗口，同时开放 /v1/chat/completions 和 /v1/responses 两个端点。如果你想更换语音代理背后的推理大脑——在简单通话中换用更便宜的模型，或在问题升级时换用更强的模型——那么技术栈的这一半是有可选方案的，因为它只是一次普通的 API 调用，与同一把密钥下的另外约 190 个模型。

语音那一半则不能。GPT-Live-1 不在 OrcaRouter 上，Gemini 3.5 Live Translate 也不在；这两者都只能从各自的厂商处获取。在这样一套架构中，路由器真正能占有一席之地的地方，是音频下游的一切：负责检索、摘要、CRM 回写和升级的文本模型——这才是账单中你可以真正整合到一把密钥和一张发票上的那一半。

到底该怎么选

• 如果翻译本身就是产品、每分钟价格比合同稳定性更重要，而且你能承受预览版模型在你脚下发生变化，就选择 Gemini 3.5 Live Translate。预算大约每分钟 $0.037，并在调用之上保留一层抽象，以便 GA 模型无需重写就能替换它。

• 如果你需要的是一款恰好具备翻译能力的对话式智能体，如果你需要在语音回路中实现函数调用和工具使用，或者如果采购团队会追问模型退役后会发生什么、而你需要一个比“大概什么都不会发生”更好的答案，那就选择 GPT-Live-1。

• 不要因为其中某一个在基准测试中胜出就选择它。双方的基准测试并不可比——OpenAI 的全双工数据是它自家数据，没有任何第三方复现过；而 Google 的语言能力宣称，也尚未在同一音频数据集上与通用模型进行对比测试。

一个前瞻性的提示：这两个领域正在趋同，而不是相互碰撞。Google 的翻译模型已经存在于 Gemini Live 之中，而 GPT-Live-1 的语音层被明确设计为可以让新的前沿模型直接接入其后。合理的预期是，在几个发布周期内，通用型选手的翻译会有所提升，而专业型选手的集成方案也会变得不那么像一场赌博。如果你今天正在构建，并且这个决策很接近，那就支持选择更便宜、更可替换的方案，并且无论如何都要把音频路径隔离在一个接口之后。