🎙️ 语音系统 · 工程拆解

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

OpenAI 发布 GPT-Live 工程文章，首次披露新版 ChatGPT 语音系统的底层架构。新的媒体系统中，p95 音频帧延迟已降至旧系统 p50 的水平——最慢的 5% 音频帧，现在和旧系统一半的帧一样快。

综合公开信息整理• 2026 年 7 月• 全文约 4 分钟读完
#OpenAI #GPT-Live #实时语音 #系统架构
p95 → p50 音频帧延迟，95% 的帧稳定按时到达
6 → 1 WebRTC 网络往返次数，WARP 协议合并握手
6 个月 语音系统架构重写耗时

⚡ 30 秒速览

  • 延迟缩水：p95 音频帧延迟降至旧系统 p50 水平，偶发慢帧被系统性压缩。
  • 网络减负：自定义 WARP 协议将 WebRTC 握手从 6 次网络往返缩到 1 次。
  • 语言栈换血：Python asyncio 改写为 Go，内核层 SO_REUSEPORT + 协程固定消除不可控停顿。
  • 持续语音：模型不再等待用户说完，搜索、工具调用移入异步路径。
  • 双模型协作：GPT-5.5 后台推理，结果需校验上下文位置才能安全接回。

01旧系统的瓶颈 音频帧不能排队

在实时语音交互中，延迟是唯一的"死线"。文字回答慢几百毫秒，用户顶多觉得体验不佳；但音频只要卡顿一次，那种"非人"的割裂感就会瞬间摧毁信任。

音频帧不能长时间排队。

旧系统：单体异步服务

音频处理、模型调用、工具请求、聊天记录保存在同一套异步服务中。一个环节变慢，后面的任务全部排队。

新系统：多路实时传输网络

快速通道、深度通道、异步任务各走各路。音频永不等待，后台任务可以推迟结果，但不能卡住声音。

每一帧声音都有对应的播放位置。它迟到以后，即使最终处理完成，也已经没有意义。旧音频一旦持续积压，整场对话就会逐渐落后于用户当前所处的时间。

这是一场"必须实时到达"的接力赛——不是跑得快就行，而是每一棒都不能掉。

02网络层：从 6 次到 1 次 WARP 协议

标准 WebRTC 建立连接需要 6 次网络往返（RTT）。对于跨地区连接，光速的限制就足以造成明显的首字延迟。

OpenAI 用自定义协议 WARP 解决了这个问题。

DTLS 握手→ SCTP 建立→ 数据通道协商→ 6 次往返

WARP 将这三步合并，把通道启动从 6 次缩短到 1 次。更关键的是，路由提示被写进 WebRTC 本来就携带的 ICEufrag 字段。Relay 层收到第一个包时，不需要查询远程 Redis 就能知道该把数据送往哪个实例——在内存中直接建立映射，消灭了一次跨网络查询。

把 6 次缩短到 1 次，并不意味着整体启动快 6 倍——服务器调度、客户端处理和模型准备仍然需要时间。但它移除了多次必须等待网络返回的步骤，对跨地区连接尤其有效。

03持续语音：打断与迁移 最难的三件事

音频传输稳定之后，更难的问题来了：模型如何在持续对话中管理发言权和会话状态？

过去的语音系统依靠独立的回合检测器，根据静音时间判断用户是否说完。GPT-Live 把这项判断放进语音模型本身——模型一边理解内容，一边决定继续听、开始回答还是接受打断。

🔀 打断处理 状态三线同步

  • 用户可能在第 4 秒插话，但模型已生成到第 10 秒，部分音频已发到客户端。
  • 系统需要分别记录模型生成位置、服务器发送位置、用户实际听到位置。
  • 下一轮对话只能以用户真正听见的部分为准，否则模型会误以为某些内容已经讲过。
最新消息的文字、时间范围和说话者归属都可以继续修改——模型输出不会立即成为最终记录。

🔄 实例迁移 双实例并行

  • 一场长会话会保存上下文和 KV Cache，直接切换会丢失全部历史。
  • 旧实例继续运行，新实例完成 Prefill 并补齐新增音频，追上进度后才切换媒体流。
  • 上下文压缩也沿用这套机制，但会暂时占用双份推理资源。
多次压缩后，长期要求、未完成任务和工具状态能保留多少，官方尚未公布。

🧠 发言权判断 模型自主决策

  • 不再依赖静音检测，而是结合语义、语气和上下文判断何时回应。
  • 音频持续进入模型，模型持续输出，没有明确的"回合"边界。
  • 代价是主模型需要在整场会话中持续运行，计算成本显著上升。
官方尚未公布误抢话和错误打断的数据——这是持续语音真正成熟与否的试金石。

04双模型协作 后台结果要"接得上"

双模型架构真正难处理的，不是把任务交给后台，而是保证结果回来时仍然接得上当前对话。

GPT-5.5 开始搜索或调用工具后，GPT-Live 不会停下来等待，而是继续接收声音、回应用户。期间，用户可能补充条件、改变问题，甚至取消原任务。后台模型返回的答案即使本身正确，也可能已经不再适用于此时的会话。

  • 后台任务绑定上下文位置。结果返回后先判断当前对话是否仍延续原意图，不能直接播放。
  • 应用服务器维护临时记录。用户和助手可能同时说话，简短回应未必单独成句，先维护可修改的临时记录，再确认最终消息。
  • 影子测试暴露瓶颈。真实语音会话同时送入新旧系统，发现一个辅助组件比预期更早饱和，拖慢了整个推理队列。

双模型协作能否稳定接续，不只取决于模型速度，还取决于网络、队列和状态服务能否共同跟上实时对话。

系统的瓶颈往往不在 GPU 推理，而是某个辅助组件（如日志或状态存储）的先饱和。

05编辑判断

编辑核心判断

实时性不是模型的恩赐，而是系统调度的红利。
当 p95 取代平均延迟成为新的度量标准，决定语音体验的已经不只是模型参数，而是调度器在每一个 WebRTC 握手包、每一次内存分配、每一轮状态同步里省下的往返。

▶现在就能用

GPT-Live 已集成于新版 ChatGPT 语音模式，逐步向移动端与桌面端开放。打开 ChatGPT 即可体验持续语音对话。