OpenAI 重建了 ChatGPT 的语音堆栈,使 GPT-Live 在说话时能够同时监听

专用音频通道让对话保持流畅进行,同时 GPT-5.5 在后台处理推理、搜索和工具。

By · Published

Primary source: OpenAI on X

Why it matters

GPT-Live separates real-time conversation from slower reasoning and tool use, establishing a new infrastructure baseline for developers building voice agents.

Illustration of a user talking with ChatGPT's GPT-Live voice assistant listening and responding while GPT-5.5 processes in the background.

OpenAI 工程师 Justin Uberti 和 Zahan Malkani 在 8 月 3 日 详细介绍了对 ChatGPT 语音基础设施为期六个月的重构,该重构使 GPT-Live 能在其他模型在后台处理搜索、推理和工具调用时同时听和说。

工程师在 一篇 OpenAI 工程文章X 上的一条线程 中描述了该架构,时间几乎是在 OpenAI 于 7 月 8 日 开始在全球推广 GPT-Live 四周之后。技术性的叙述展示了用户所感知为对话时机的产品行为背后究竟有多少基础设施支撑。

Uberti(WebRTC 的最初架构师之一)和 Malkani 都是 OpenAI 的技术人员。Uberti 的背景对该系统至关重要:GPT-Live 依赖 WebRTC——为低延迟音频和视频构建的通信标准——作为其传输基础。OpenAI 之前曾表示,Uberti 和 Pion 创始人 Sean DuBois 帮助指导了其在 实时 AI 与 WebRTC 基础设施 方面的工作。

A fast path for speech

早期的 ChatGPT 语音系统将对话视为一系列轮次。一个检测器尝试在模型开始响应之前判断用户是否停止说话。这样的设计造成了一个令人不舒服的权衡:过早的判断可能会打断用户,而过晚的判断又会引入可听见的停顿。

GPT-Live 将独立的轮次检测器从音频路径中移除。其全双工模型在生成输出音频的同时持续处理输入语音,使其能够每秒多次决定是倾听、说话、暂停、打断还是调用另一个系统。

OpenAI 将该连续音频环路与 ChatGPT 的其余应用逻辑分离。语音在客户端与 GPT-Live 之间通过专用的快速通道传输。搜索、工具调用、持久化和更深层的推理位于异步边界之后,因此某个慢速服务应该推迟其自身的结果,而不会阻止模型继续倾听或说话。

这种划分使 GPT-Live 能在 GPT-5.5 处理更高负载请求时保持对话流动。OpenAI 还可以在不围绕每次发布重建语音模型的情况下,随着新系统可用而替换被委托的推理模型。

该架构相当于一个以单一助手呈现的双模型系统。GPT-Live 管理时序和语音,而一个前沿模型处理需要额外计算的任务。OpenAI 的产品公告称 GPT-Live-1 Instant 和 GPT-Live-1 mini 在后台使用 GPT-5.5 Instant,而 Medium 和 High 设置则委托给具有不同推理水平的 GPT-5.5 Thinking。

OpenAI replaced Python code and compressed the handshake

OpenAI 使用 Go 重写了媒体前端和推理逻辑,替换了早期的 Python asyncio 实现。OpenAI 表示,新系统第 95 百分位的帧传递性能与先前系统的中位数相匹配,这表明重构的目标是跨会话的一致性,而不是展示一个更快的最佳情况。

长时间的对话带来了另一个问题。随着模型实例可能因容量变化而需要替换,上下文会增长。OpenAI 构建了一个交接流程,对替换实例进行预热,加载当前上下文并并行运行两个实例,然后再切换流量。相同的机制还允许 OpenAI 在不暂停对话的情况下压缩过大的上下文。

会话启动也需要在模型层之下做工作。标准的 WebRTC 设置涉及多个协议握手。OpenAI 开发了 WebRTC Abridged Roundtrip Protocol,或称 WARP,其表示将媒体和数据启动的网络往返次数从六次减少到一次。一个相关系统 Instant Connect 预先协商会话参数,当这些参数仍然有效时,允许客户端只用一个 UDP 包就开始会话。

OpenAI 正在通过一个 Internet Engineering Task Force 工作组推进 WARP 提案。工程文章称,libwebrtc 和 Pion 已经添加了对其的支持,为其他实时通信开发者提供了采用该工作部分内容的途径。

Production traffic exposed the real bottlenecks

在 7 月 8 日 发布之前,OpenAI 在不公开宣告的情况下,将逐步增加的生产语音会话比例通过新系统路由,同时其现有的 Advanced Voice Mode 继续为用户提供服务。该影子部署在不改变用户听到内容的情况下,将替代堆栈暴露给真实网络、会话长度和地理流量。

测试发现,仅以 GPU 吞吐量衡量容量是不够的。语音通话保持连接打开并持续发送帧,对 CPU 流处理器、队列和网络服务施加持续压力。OpenAI 表示,某个支撑组件比其负载测试预测的更早达到饱和,导致推理请求和延迟积累。

这一发现对于 OpenAI 所述的规模至关重要。OpenAI 表示每周超过 1.5 亿人使用 ChatGPT Voice 或 Dictation。在该规模下,自然对话依赖于区域路由、连接设置、状态管理和恢复行为,以及模型推理。

OpenAI 的 7 月 8 日发布公告,GPT-Live 目前为 ChatGPT Voice 提供动力,GPT-Live-1 指定用于 Go、Plus 和 Pro 用户,GPT-Live-1 mini 则用于 Free 用户。OpenAI 还表示该架构将支持即将推出的 GPT-Live API。

该 API 将为开发者提供访问围绕连续交互和后台委派构建的语音系统。随着用户开始期望助理在搜索和工具调用仍在运行时保持对话性,客户支持、辅导和桌面代理产品将面临更高的技术门槛。

Reader comments

Conversation for this story loads after sign-in.