GPT-Live 底层拆解：OpenAI 将 95% 音频帧延迟降至旧系统 p50 水平

OpenAI 发布 GPT-Live 工程文章，公开新版 ChatGPT 语音系统的底层架构改造。OpenAI 耗时 6 个月重做整个语音系统，核心指标显示，新媒体系统的 p95 音频帧延迟已降至旧系统 p50 水平，即新系统中最慢的 95% 的音频帧，其延迟与旧系统中最快的 50% 大致相当。OpenAI 未公布具体毫秒数，但这一结果说明改造主要压缩了偶发慢帧。

架构分层：多级通道解耦实时交互与复杂推理

过去语音 Agent 通常视为“语音转文字 → 模型推理 → 文字转语音”的单体系统，音频处理、模型调用、工具请求和聊天记录保存在同一套异步服务中，任一环节变慢都会导致后续排队。GPT-Live 参照人类神经系统的多级延迟通道，构建多路实时传输网络：

• 快速通道：负责截断、情绪随动等“不假思索”的反馈，由极小模型或硬编码逻辑在边缘侧或前端处理。
• 深度通道：由 GPT-5.5 等主力模型处理复杂语义理解和长程推理。
• 异步任务：搜索、工具调用和数据保存彻底移出主路径，可延迟结果但不能卡住音频。

媒体前端和部分推理逻辑从 Python asyncio 改写为 Go。原因是实时音频处理的是大量时效要求极高的 UDP 数据包，Python 在高并发下的线程调度、内存分配、数据复制和垃圾回收停顿是 p95 延迟的主要元凶。

Linux 内核层面也做了优化：使用 SO_REUSEPORT 让多个工作单元共享同一 UDP 端口，由内核负载均衡；负责读取 UDP 的 Go 协程固定在操作系统线程上，减少线程迁移和 CPU 缓存失效；预分配接包缓冲区，减少内存复制。

WARP 协议：WebRTC 通道启动从 6 次网络往返降至 1 次

标准 WebRTC 建立需要 6 次网络往返。OpenAI 开发了自定义协议 WARP，将 DTLS 握手、SCTP 建立和数据通道协商合并，把通道启动从 6 次 RTT 缩短到 1 次。具体做法是把路由提示写进 WebRTC 的 ICE ufrag，Relay 收到第一个包时即可在内存中直接建立映射，无需查询远程 Redis，消除了跨网络查询。

需要说明，减少到 1 次 RTT 不等于启动速度提升 6 倍，因为服务器调度、丢包、客户端处理和模型准备仍耗时；但跨地区连接中，减少完整网络往返比压缩服务端代码更有效。

边说边听：模型持续运行与打断恢复

GPT-Live 不再等用户说完再响应，而是让声音持续进入模型，模型边理解边决定继续听、开始回答、暂停或接受打断。回合判断从独立静音检测器改为语音模型自身完成，可结合语义、语气和上下文，同时也意味着主模型需要整场持续运行。

打断处理最为复杂：用户可能在模型已生成到第 10 秒时插话，部分音频甚至已发到客户端。系统需分别记录模型生成位置、服务器发送位置和用户实际听到位置，下一轮对话只能以用户真正听见的部分为准。OpenAI 未公开播放确认和音频撤销协议，但提到最新消息的文字、时间范围和说话者归属可以修改，说明模型输出不会立即成为最终记录。

长会话中的模型实例迁移也采用“双跑”策略：旧实例继续运行，新实例完成 Prefill 并补齐期间新增音频，追上进度后才切换媒体流。上下文压缩沿用同样机制，后台压缩历史并准备新实例，期间暂时占用双份推理资源。

双模型协作：后台任务需绑定上下文位置

GPT-5.5 执行搜索或工具调用时，GPT-Live 不等待，而是继续对话；用户可能补充条件、改变问题甚至取消任务，导致后台返回的答案可能已失效。因此后台任务需绑定发起时的上下文位置，返回后系统需判断当前对话是否仍延续原意图，类似带状态校验的“断点续传”。

应用服务器还会维护一份允许修改的临时记录，再根据时间、转录和发言权确认最终消息。界面使用更新更快的推测状态，日志、分析和部分安全系统依赖顺序更稳定的权威记录。上线前影子测试发现，一个辅助组件比预期更早饱和，并拖慢了推理队列，说明双模型协作能否稳定接续取决于网络、队列和状态服务共同跟上实时对话。

未公开数据与行业影响

OpenAI 公布了 p95 达到旧系统 p50 的水平、WebRTC 往返从 6 次降到 1 次，但以下数据未披露：持续推理的单位成本、实际打断准确率、长会话多次压缩后的信息损失、后台结果过期比例。

文章认为，实时性不是模型能力的直接体现，而是系统调度的红利；瓶颈可能不在 GPU 推理，而在日志、状态存储等辅助组件先饱和。GPT-Live 说明持续语音已从实验室能力变成能在 ChatGPT 规模运行的工程系统。对 Agent 开发者而言，差距可能体现在 WebRTC 握手包、Go 内存管理和可回滚的状态机等工程细节上。