OpenAI 近日发布 GPT-Live 工程文章，详细披露了新版 ChatGPT 语音系统背后的架构改造。其中最引人注目的数据是：新系统的 p95 音频帧延迟已降至旧系统 p50 的水平，意味着新系统中最慢的 95% 的音频帧，现在都能跑得和旧系统中最快的 50% 音频帧一样顺滑。虽然 OpenAI 未公布具体毫秒数，但这一结果说明改造主要压缩了那些偶发但明显的慢帧。

GPT-Live 的核心变化在于不再等待用户说完一句话再开始工作，而是让声音持续进入模型，模型生成的语音也持续返回用户。搜索、工具调用和复杂推理则被移到另一条异步路径。这一设计借鉴了人类神经系统的多级延迟通道，构建了多路实时传输网络：快速通道负责“不假思索”的反馈，处理音频流的截断、情绪随动；深度通道由 GPT-5.5 等主力模型处理复杂的语义理解和长程推理；异步任务则包括搜索、工具调用和数据保存等，被彻底移出主路径。

在工程实现上，OpenAI 将媒体前端和部分推理逻辑从 Python asyncio 改写为 Go，因为 Python 在高并发下的线程调度、内存分配和垃圾回收过程中的不可控停顿是制造 p95 延迟的元凶。同时，OpenAI 优化了 Linux 内核层，使用 SO_REUSEPORT 让多个工作单元共享同一个 UDP 端口，由内核实现负载均衡；负责读取 UDP 的 Go 协程固定在操作系统线程上，减少线程迁移和 CPU 缓存失效；预分配接包缓冲区，减少内存复制。这些后端改进最终反映在 p95 上：新系统不是只降低平均延迟，而是让绝大多数音频帧都能稳定按时到达。

在网络层面，OpenAI 开发了名为 WARP 的自定义协议，将 DTLS 握手、SCTP 建立和数据通道协商合并，将通道启动从 6 次网络往返缩短到 1 次。具体做法是把路由提示写进 WebRTC 的 ICE ufrag，使 Relay 在收到第一个包时无需查询远程 Redis 就能知道该把数据送往哪个实例，在内存中直接建立映射，消灭了一次跨网络查询。虽然从 6 次往返缩短到 1 次并不意味着整体启动速度提高 6 倍，但它移除了多次必须等待网络返回的步骤，对于跨地区连接，减少完整网络往返通常比压缩服务端代码更有效。

音频传输稳定后，GPT-Live 还需解决模型在持续对话中管理发言权和会话状态的问题。过去的语音系统依赖独立的回合检测器，根据静音时间判断用户是否说完；GPT-Live 则把这项判断放进语音模型本身，音频持续进入模型，模型一边理解内容，一边决定继续听、开始回答、暂停输出或接受打断。这要求主模型在整场会话中持续运行，但 OpenAI 尚未公布这种方式增加的计算成本，也未给出误抢话和错误打断的数据。

打断是其中最难处理的一环。用户可能在第 4 秒插话，但模型已生成到第 10 秒，部分音频甚至已发到客户端。系统不能只停止继续生成，还要分别记录模型生成到哪里、服务器发送到哪里、用户实际听到哪里，下一轮对话只能以用户真正听见的部分为准。OpenAI 未公开播放确认和音频撤销的具体协议，但文章提到最新消息的文字、时间范围和说话者归属都可以继续修改，意味着模型输出不会立即成为最终记录。

持续语音还要求模型实例能够在不中断会话的情况下迁移。一场长会话会保存对话上下文和 KV Cache，直接切换到空白实例会导致新实例重新处理全部历史，语音可能出现停顿。OpenAI 的做法是让旧实例继续运行，同时启动新实例并完成 Prefill，新实例补齐准备期间新增的音频、追上当前进度后，系统才切换媒体流。上下文压缩也沿用这套机制，旧实例继续对话，后台压缩历史并准备新实例，等新实例完成状态追赶后再接管，但会暂时占用双份推理资源。至于多次压缩后长期要求、未完成任务和工具状态能保留多少，官方尚未公布数据。

双模型架构真正难处理的不是把任务交给后台，而是保证结果回来时仍接得上当前对话。GPT-5.5 开始搜索或调用工具后，GPT-Live 不会停下来等待，而是继续接收声音、回应用户。期间用户可能补充条件、改变问题甚至取消原任务，后台模型返回的答案即使正确也可能已不适用。因此每个后台任务都需绑定发起时的上下文位置，结果返回后要先判断当前对话是否仍延续原意图，可理解为一次带状态校验的“断点续传”。OpenAI 未公开任务版本、取消信号和过期结果的具体处理机制，但这些能力决定了系统能否避免读出已失效的答案。

此外，模型处理的是连续声音，而 ChatGPT 的搜索、日志、安全和聊天记录需要一条条明确的消息。应用服务器会先维护一份允许修改的临时记录，再根据时间、转录和发言权确认最终消息。界面使用更新更快的推测状态，日志、分析和部分安全系统则依赖顺序更稳定的权威记录。正式上线前，OpenAI 通过影子测试将真实语音会话同时送入新旧系统，发现一个辅助组件比预期更早饱和并拖慢推理队列，说明双模型协作能否稳定接续不只取决于模型速度，还取决于网络、队列和状态服务能否共同跟上。

从公开内容看，GPT-Live 的技术重点不是某个单独模型变快了，而是重新划分了实时语音系统中的责任：音频被放进独立快速路径，WebRTC 入口被拆成 Relay 和 Transceiver，路由信息被放进连接协议本身，模型实例可带着上下文迁移，复杂任务则交给预热好的后台模型。这些设计也带来额外成本，如持续推理增加主模型占用、实例切换和上下文压缩短时间使用双份算力、Relay 增加一次内部转发、双模型系统需处理任务过期和状态不同步。目前 OpenAI 公布了 p95 达到旧系统 p50 的音频帧数据，以及 WebRTC 网络往返从 6 次降到 1 次，但持续推理的单位成本、实际打断准确率、长会话多次压缩后的信息损失以及后台结果过期的比例仍未披露。

GPT-Live 的这次工程拆解给全行业提了个醒：实时性不是模型的恩赐，而是系统调度的红利。系统的瓶颈往往不在 GPU 推理，而是某个辅助组件（如日志或状态存储）的先饱和。OpenAI 改写 GPT-Live 的核心思路在于不再只关注 GPU 每秒处理多少 Token，而关注系统能同时维持多少场“帧稳定”的语音会话。虽然持续推理的单位成本、长会话压缩后的信息损失等数据仍有待进一步验证，GPT-Live 目前已经证明持续语音已从单纯的模型“实验室能力”变成了一套可以在 ChatGPT 规模下运行的完整工程系统。对于国产 Agent 开发者来说，或许不必再死等 GPT-5 变快，真正拉开差距的战场在 WebRTC 的握手包里、在 Go 的内存管理里、在那个能随时回滚的状态机里。