GPT-Live 底层拆解：OpenAI 如何让 95% 的音频帧不再延迟

OpenAI发布GPT-Live技术细节：p95音频帧延迟降至旧系统p50水平

OpenAI今日发布一篇关于GPT-Live语音系统的工程文章，详细披露了新版ChatGPT语音系统背后的架构改造。其中关键数据是，新系统的p95音频帧延迟已降至旧系统p50的水平，这意味着新系统中95%的音频帧延迟表现与旧系统中50%的音频帧相当。

GPT-Live不再等待用户说完一句话再开始工作，而是让声音持续进入模型，模型生成的语音也持续返回用户。搜索、工具调用和复杂推理被移到异步路径。

文章重点介绍了GPT-Live在架构分层、网络协议和模型状态管理等方面的多项优化。

架构分层与音频传输优化

GPT-Live将音频处理、模型调用和工具请求等功能解耦，构建了多级延迟通道：

• 快速通道：
  负责处理音频流的截断、情绪随动等低延迟反馈，由极小模型或硬编码逻辑在边缘侧或前端处理。

• 深度通道：
  由GPT-5.5等主力模型处理复杂的语义理解和长程推理。

• 异步任务：
  包括搜索、工具调用和数据保存等，被彻底移出主路径。

OpenAI还将媒体前端和部分推理逻辑从Python asyncio重写为Go。在Linux内核层面，通过使用SO_REUSEPORT让多个工作单元共享UDP端口，由内核实现负载均衡，同时减少线程迁移和CPU缓存失效，并预分配接包缓冲区以减少内存复制。

WARP协议：网络往返从6次降至1次

OpenAI开发了名为WARP的自定义协议，将DTLS握手、SCTP建立和数据通道协商合并，使WebRTC通道启动从6次网络往返（RTT）缩短到1次。

OpenAI将路由提示写进WebRTC的ICE ufrag，使得Relay（转发层）在收到第一个包时，无需查询远程Redis，直接在内存中建立映射，从而消除了一次跨网络查询。

边说边听：模型状态管理

GPT-Live的持续对话机制要求模型管理发言权和会话状态。系统将判断用户是否说完的任务纳入语音模型本身，模型根据语义、语气和上下文判断停顿，并决定继续听、开始回答、暂停输出或接受打断。

打断处理是难点之一。当用户在第4秒插话时，模型可能已生成到第10秒。系统需分别记录模型生成、服务器发送和用户实际听到的进度，后续对话只能以用户实际听见的部分为准。

OpenAI还实现了模型实例在不中断会话情况下的迁移。旧实例继续运行，同时启动新实例并完成Prefill，新实例补齐准备期间新增的音频后，系统才会切换媒体流。

双模型协作与任务状态管理

GPT-5.5开始搜索或调用工具后，GPT-Live不会等待，而是继续接收声音并回应用户。每个后台任务需绑定发起时的上下文位置，结果返回后，系统需判断当前对话是否仍延续原来的意图。

应用服务器会维护一份可修改的临时记录，再根据时间、转录和发言权确认最终消息。界面使用更新更快的推测状态，后台任务则依赖顺序更稳定的权威记录。

上线前，OpenAI通过影子测试将真实语音会话同时送入新旧系统。测试发现，一个辅助组件比预期更早饱和，并进一步拖慢推理队列。

待确认事项

OpenAI公布了新系统p95音频帧延迟达到旧系统p50水平，以及WebRTC网络往返从6次降至1次。但持续推理的单位成本、实际打断准确率、长会话多次压缩后的信息损失，以及后台结果过期的比例，目前尚未披露。

参考链接：

https://x.com/OpenAI/status/2084378418989379822

https://openai.com/index/continuous-voice-interaction-with-gpt-live/