GPT-Live 语音栈重构：OpenAI 拆掉转弯检测器，AI 学会边听边说

它能在说话时继续听你说话

8 月 3 日，OpenAI 在官方博客中公开了 GPT-Live 的完整工程架构。核心改动一句话：拆掉了语音对话中的「转弯检测器」，让模型在全双工模式下同时听与说。

此前 ChatGPT 语音依赖一个小型检测模型判断用户是否说完话——猜早了抢话，猜晚了迟钝。GPT-Live 是 OpenAI 第三代语音系统，音频连续流进流出模型，深度推理和工具调用被分流到独立异步通道，不再打断对话节奏。

负责该项目的 OpenAI 技术成员 Justin Uberti 与 Zahan Malkani 在博文中写道，整个系统在过去六个月内从客户端到模型全部重建。

Speak 联合创始人兼 CTO Andrew Hsu 在 X 上称这篇博文「值得全文精读」，并逐一拆解了系统设计要点。

他特别指出 WARP 协议，将一个「改善启动延迟」的工单变成一套新的 WebRTC 握手协议，称其为「跨代际的需求蔓延」。

Hsu 还判断，全双工语音已是确定的未来方向，但每一路全双工会话每秒处理约 100 个音频帧，对 CPU 流处理器和网络路径的压力远超普通应用。他警告这是实时语音规模化时不可忽视的成本驱动因素。

AI 领域大 V Rohan Paul（15 万粉丝）发布了技术摘要，将 Go 重写、WARP 协议、上下文热切换等改进逐条列出。

用户反馈则褒贬不一。部分用户反馈新版本「嗯」「啊」等填充语气词过多，显得不够自然；但也有用户称这是「迄今为止最好的 AI 语音」，能与 6 岁和 8 岁孩子自然对话而不让房间里的任何人感到沮丧。

OpenAI 在博文中系统回顾了语音架构的三代演进。第一代级联系统将语音识别、语言模型推理和语音生成串联执行，每一步都引入延迟且丢失语调、节奏等信息。第二代语音到语音模型直接处理音频，响应更快，但依然依赖转弯检测器决定何时开始推理，交互本质上仍是「你一句、我一句」的轮流制。

GPT-Live 将语音模型置于对话控制端：音频持续流进流出，模型自主决定是听、是说、是停顿还是允许被打断。OpenAI 将此称为将「说话」与「思考」解耦。

这一架构转折并非孤立事件。就在 OpenAI 博文发布的次日，NVIDIA 通过 ModelScope 开源了 NemotronLabs-VoiceChat-11B。

这是一个端到端全双工语音模型，在 VoiceBench 和 Full-Duplex-Bench 1.0 上排名开源模型第二，且支持实时工具调用。

OpenAI 将 GPT-Live 架构原则概括为一句：让语音流动。以下是支撑这一原则的三个核心工程决策。

Go 重写媒体前端，p95 追上旧版中位数。用 Go 替代 Python asyncio 实现媒体前端和推理逻辑后，新系统的 p95 帧交付延迟与旧系统的 p50 持平，最差那 5% 的体验追上了旧系统的平均水平。

WARP 协议：六次握手砍成一次。标准 WebRTC 需六次网络往返才能建立会话。OpenAI 开发的 WARP（WebRTC Abridged Roundtrip Protocol）通过 DTLS over ICE 搭载、DTLS 1.3 等优化将握手压缩为一次往返。

配合 Instant Connect 机制（预先协商 SDP 参数），语音会话可从单一 UDP 数据包开始。WARP 作为开放规范已进入 IETF 标准化流程，libwebrtc 和 Pion 均已实现支持。

实例热切换，对话不中断。模型实例需轮换时，系统在旧实例旁预热替换实例并预填会话上下文，双方并行推理，就绪后无声切流。上下文压缩沿用同一机制，后台完成压缩和 KV-cache 重建后再切换。

此外，系统通过快慢通道分离将音频传输与工具调用解耦：慢速工具调用只能延迟自己的结果，无法冻结对话流。

上线前，OpenAI 以只读模式将部分生产流量路由至 GPT-Live 进行 shadow testing，实测发现容量瓶颈不在 GPU 吞吐，而在 CPU 流处理器和长会话行为。

应用服务器同时维护推测视图和权威记录两份对话状态，将连续语音流转译为离散消息，供 UI 和分析管线使用。

WARP 协议的意义超出了 OpenAI 自身。Pion 是 WebRTC 开源生态中的关键组件，WARP 在 Pion 中的落地意味着更快的语音会话建立速度不会停留在 ChatGPT 内部。

OpenAI 明确表示正在与 WebRTC 社区合作推动标准，WARP 已被 libwebrtc 和 Pion 两个主流实现采纳。

Andrew Hsu 的判断指向了一个更深层的格局变化：全双工语音将语音 Agent 的竞争焦点从模型能力拉向基础设施。

他写道，每一路全双工会话的 CPU 压力远超普通应用，是推高基础设施成本「非常不可忽视的驱动因素」。

GPT-Live 的工程披露表明，响应速度、会话连续性、连接建立延迟等系统工程因素，对用户体验的影响不亚于模型能力本身。

OpenAI 在博文末尾确认，GPT-Live 的架构将支撑即将推出的 GPT-Live API，并允许语音体验跨越更多设备、应用和模态。

让 AI 像人一样对话，模型能力只是入场券。传输协议、状态管理、异步调度——这些系统工程的深水区，才是拉开差距的地方。当一家公司把六个月的工程积累写成公开博文，同时将核心协议推向 IETF 标准化时，语音 AI 的下一阶段竞争已经开局。