OpenAI 发布 GPT-Live：语音模型开始真正"听得懂人话"

7 月 8 日，OpenAI 上线了新的语音模型 GPT-Live-1，同步替换 ChatGPT 里那个用了快两年、被无数用户吐槽"话痨且爱抢话"的 Advanced Voice Mode。发布会上 OpenAI 研究负责人 Kundan Kumar 给出的定性很直白——这是他们"迄今最聪明的语音模型"，目标是让对话体验"像在跟另一个人说话"。

听起来又是一句发布会套话，但这次的技术路线确实不太一样。

全双工，才是这次的关键词

过去两年市面上的语音助手，不管是 ChatGPT、Gemini Live 还是 Claude 的语音模式，本质上还是"半双工"——你说完一句，它回答一句，中间靠 VAD（语音活动检测）判断你有没有说完。这套机制最大的问题就是它总在错误的时机插话：你稍微停顿一下想组织语言，它以为你说完了，抢过话头开始 balabala；你想打断它，它得等一个完整的语义单元结束才能停下来。

GPT-Live-1 做的是同时听和说。按 OpenAI 的说法，模型可以在生成音频的同时持续处理输入音频流，这带来两个直接后果：

• 打断更自然。你一开口它就能停，不用等半句话说完。
• 不该打断的时候它会闭嘴。这次官方甚至专门强调了一句——新模型"更擅长闭嘴"（better at shutting up）。用户中途停顿思考时，它会等你继续，而不是急着接话。

这个能力对实时翻译场景尤其关键。传统的语音翻译要么是"说完再译"（延迟高），要么是流式识别 + 流式生成拼起来（口型和节奏对不上）。全双工模型天然就适合同声传译——一边听源语言，一边输出目标语言，中间不需要显式的分段。TechCrunch 的报道里 OpenAI 明确提到这是 GPT-Live 的核心用例之一。

路由到 GPT-5.5，解决了语音模型"变笨"的老问题

这一点我个人觉得比全双工更值得说。

此前所有端到端语音模型都有一个共同的毛病：为了做到低延迟，语音模型本身参数不能太大，推理能力比同世代的文本旗舰弱一大截。你用语音问 ChatGPT 一个稍微复杂的问题，它经常给出比文字模式明显更差的答案。这也是为什么很多重度用户宁愿打字也不愿意说话。

GPT-Live-1 的做法是自动路由：碰到需要推理、需要联网搜索的 query，它会把请求转给 GPT-5.5 处理，然后再把结果用语音流的方式讲出来。整个过程 OpenAI 说是无缝的——模型知道自己什么时候该"边查边说"，用一些填充语（"稍等，我查一下"之类）来掩盖后台的思考延迟。

这个设计其实很务实。硬要把推理能力塞进语音模型本身，成本收益不划算；不如让语音模型专注做"感知—表达"这一层，把"思考"外包给最强的文本模型。这条路线其实和 Gemini Live 前段时间接入 Deep Think 的思路很像，但 OpenAI 这次的整合更彻底——没有模式切换，全在一个对话流里完成。

具体升级点盘点

综合官方博客和媒体简报，GPT-Live-1 相比上一代 Advanced Voice 的变化大致如下：

1. 全双工音频处理：同时听说，打断延迟据称降到人类反应时间量级（200ms 以内）。
2. 停顿感知：用户中途停顿不会触发抢话，模型会"等"。
3. 模型路由：复杂问题自动调用 GPT-5.5，联网搜索、代码解释、多步推理都能覆盖。
4. 对话增强：模型可以在语音对话中主动引入相关信息补充（比如你在问某个概念，它会顺带给出一个类比），而不是被动应答。
5. 多语言实时翻译：官方主推场景，覆盖主流语言对。
6. 声音表现：情绪、语速、语调更贴近真人，能处理笑声、叹气这类副语言信号。

上手体验，最直观的感受是"不烦了"。以前用语音模式最痛苦的是它太热情——回答动辄长篇大论，你想打断它得吼两次。这次模型明显更懂什么叫"点到为止"，反应也快了一档。

竞品对比：Gemini Live、Sesame、豆包实时通话

语音这条赛道其实这一年多打得挺凶。

• Google Gemini Live 早在去年就上了原生音频输出，全双工能力也具备，但打断的自然度一直被诟病。
• Sesame 那个 Maya/Miles 的 demo 去年爆火过一阵，主打"声音有灵魂"，但产品化速度慢。
• 字节的豆包实时通话 国内体验其实做得不错，延迟和自然度都在线，但推理深度上限明显不如接入了 GPT-5.5 的 GPT-Live。
• Kyutai Moshi 学术上把全双工端到端语音打通了，但泛用能力和商业产品差一截。

把这些放一起看，GPT-Live-1 的差异化其实很清楚：双工能力追平了第一梯队，智商用路由拉开了差距。这也是 OpenAI 在语音这块过去落后于 Gemini 之后的一次反扑。

对开发者意味着什么

OpenAI 同步开放了 GPT-Live-1 的 API，命名沿用 Realtime API 那一套，走 WebSocket 协议。老的 Realtime API 用户基本可以无痛迁移，只需要把模型名换掉。

如果你之前用 OpenAI 兼容协议接入过语音模型，调用方式大致是这样：

from openai import OpenAI

client = OpenAI(
    base_url="https://api.openai-hub.com/v1",
    api_key="your-api-key"
)

# GPT-Live 通过 Realtime API 使用 WebSocket 连接
# 以下为非流式的对话触发示例
response = client.chat.completions.create(
    model="gpt-live-1",
    modalities=["text", "audio"],
    audio={"voice": "cove", "format": "pcm16"},
    messages=[
        {"role": "user", "content": "帮我用日语和这位客户打个招呼，然后帮我实时翻译他的回答"}
    ]
)

print(response.choices[0].message.audio)

真正的实时会话建议直接用 WebSocket：

const ws = new WebSocket(
  "wss://api.openai-hub.com/v1/realtime?model=gpt-live-1"
);

ws.on("open", () => {
  ws.send(JSON.stringify({
    type: "session.update",
    session: {
      modalities: ["audio", "text"],
      voice: "cove",
      turn_detection: { type: "server_vad_duplex" },
      instructions: "你是一个实时中日翻译助手"
    }
  }));
});

// 持续推送音频帧
ws.send(JSON.stringify({
  type: "input_audio_buffer.append",
  audio: base64AudioChunk
}));

注意 turn_detection 这个字段——GPT-Live 新增了 server_vad_duplex 模式，这是启用全双工行为的关键开关。老的 server_vad 仍然兼容，但会退化到半双工体验。

OpenAI Hub 已经同步支持 GPT-Live-1，包括 Realtime WebSocket 通道，国内可以直连，用同一个 Key 就能切换 GPT、Claude、Gemini 等主流模型做对比测试，适合还在选型阶段的团队。

定价和可用性

价格方面 OpenAI 这次没有做太大调整：音频输入 40 美元 / 百万 token，音频输出 80 美元 / 百万 token，比上一代略降。文本部分和 GPT-5.5 主线保持一致。相对来说不便宜，但考虑到"一个连接搞定 STT + LLM + TTS + 翻译"，对比自己拼三段管道，实际总成本可能还更低。

可用性上：ChatGPT Plus/Pro/Team 用户当天开始灰度，企业和教育版下周跟进。API 层面全球区域同步开放，没有区分预览和 GA。

一点判断

语音这条路线过去两年反复被证伪又反复被重新押注——每次有人说"这次真的是 her 时刻"，用两天又发现还是差点意思。这次 GPT-Live 我不敢说是终点，但**"全双工 + 智能路由"这个组合确实解决了此前语音助手最刺眼的两个体验短板**：抢话和变笨。

真正值得关注的是它会不会重新点燃语音作为 AI 主要交互界面的想象力。文本对话已经是 killer app，但语音一直卡在"能用但不好用"的中间地带。如果 GPT-Live 的实际体验能追上发布会 demo 的 80%，那么客服、教育、翻译、陪伴这几个赛道大概率会有一批新产品出现——毕竟基础设施到位了。

接下来看 Anthropic 和 Google 的反应。Claude 语音已经跳票很久了，Gemini Live 的下一版据说也在测试真正的双工。这一波语音竞赛，才刚刚重新开始。

参考来源

• 全球 AI 模型发布时间线（知乎专栏） —— 持续更新的模型发布节点整理，可用于横向对照 GPT-Live 在 2026 语音赛道中的位置
• AI-Compass 每周重点（GitHub） —— 每周 AI 大事件汇总，含近期多模态与语音模型技术细节梳理