GPT-Live 底层拆解：OpenAI 如何让 95% 的音频帧不再延迟
Quick Answer
OpenAI's GPT-Live significantly reduces audio frame latency, achieving p95 performance equivalent to the old system's p50.
Quick Take
By reengineering its voice system and introducing the WARP protocol, it allows real-time interaction without waiting for user input, enhancing user experience in voice applications.
Key Points
- GPT-Live reduces audio frame latency, with p95 matching the old system's p50.
- WARP protocol cuts network round trips from 6 to 1, improving connection speed.
- Real-time processing allows continuous audio input and output without delays.
- Dual model architecture manages conversation state and handles interruptions effectively.
- OpenAI's system emphasizes overall latency reduction over individual model speed.
DeepSignal Analysis
What happened
OpenAI's GPT-Live has restructured its voice system to significantly reduce audio frame latency, achieving p95 performance comparable to the previous system's p50. This was accomplished through a complete overhaul of the audio processing architecture and the introduction of the WARP protocol, which streamlines network communication.
Key evidence
- OpenAI's new media system has reduced p95 audio frame latency to the level of the old system's p50, indicating a substantial improvement in responsiveness.
- The WARP protocol developed by OpenAI reduces the number of network round trips required for WebRTC from six to one, enhancing connection speed.
- GPT-Live's architecture allows for continuous audio input and output, enabling real-time interaction without waiting for user input, which is crucial for maintaining user trust.
Why it matters
The advancements in GPT-Live highlight the importance of system architecture in achieving low-latency audio interactions. By addressing the bottlenecks in audio processing and network communication, OpenAI demonstrates that improvements in user experience can be achieved without solely relying on faster models. This could influence future developments in real-time voice applications across the industry.
📖 Reader Mode
~4 min read
作者丨郑佳美
编辑丨岑 峰
在实时语音交互中，延迟是唯一的“死线”。
文字回答慢几百毫秒，用户顶多觉得体验不佳；但音频只要卡顿一次，那种“非人”的割裂感就会瞬间摧毁信任。为了解决这个工程顽疾，OpenAI 耗时 6 个月重做了整个语音系统。
刚刚，OpenAI 发布了一篇 GPT-Live 工程文章，详细披露了新版 ChatGPT 语音系统背后的架构改造。其中最值得注意的一组数据是：新的媒体系统，其 p95 音频帧延迟已经降到了旧系统 p50 的水平。
这意味着，新系统中最慢的 95% 的音频帧，现在都能跑得和旧系统中最快的 50% 音频帧一样的顺滑。
虽然 OpenAI 没有公布具体毫秒数，但这个结果说明，改造主要压缩了那些偶发但明显的慢帧。
现在的 GPT-Live 不再等待用户说完一句话再开始工作，而是让声音持续进入模型，模型生成的语音也持续返回用户。搜索、工具调用和复杂推理则被移到另一条异步路径。
01
架构分层和优化，让 AI 的「反射弧」变快了
GPT-Live 首先改掉的是音频在服务器中的传输方式。
长期以来，开发者的通常做法是将语音 Agent 视为“语音转文字->模型推理->文字转语音”的单体推理系统，过去的语音系统音频处理、模型调用、工具请求和聊天记录保存，可能在同一套异步服务中运行。只要其中一个环节变慢，后面的任务就会排队。
这种设计在文字产品中问题不大，但音频帧不能长时间排队。每一帧声音都有对应的播放位置。它迟到以后，即使最终处理完成，也可能已经没有意义。旧音频一旦持续积压，后续声音也会越来越慢，整场对话逐渐落后于用户当前所处的时间。雷峰网(公众号：雷峰网)
OpenAI 参照人类神经系统的多级延迟通道构建了一套多路实时传输网络：
快速通道：负责“不假思索”的反馈。处理音频流的截断、情绪随动（如“嗯”、“我在听”）。这一层对延迟极度敏感，通常由极小模型或硬编码逻辑在边缘侧或前端处理；
深度通道：GPT-Live 的另一项核心设计是把实时交流和复杂推理解耦，构建逻辑中枢。由 GPT-5.5 等主力模型处理复杂的语义理解和长程推理；
异步任务：包括搜索、工具调用和数据保存等。这些任务被彻底移出主路径，后台任务可以推迟自己的结果，但不能卡住音频。
媒体前端和部分推理逻辑也从 Python asyncio 改写成了 Go。这并非简单的“谁比谁快”的争论，实时音频处理的是大量体积很小、但时效要求极高的UDP数据包，Python在高并发下的线程调度、内存分配、数据复制和垃圾回收过程中的不可控停顿，则是制造p95延迟的元凶。
OpenAI 还进一步优化了Linux内核层：它使用 Linux 的 SO_REUSEPORT，让多个工作单元共享同一个 UDP 端口，由内核实现负载均衡；
负责读取 UDP 的 Go 协程会固定在操作系统线程上，减少线程迁移和 CPU 缓存失效；预分配接包缓冲区，减少内存复制。
这些后端工程上的改进，最终反映在 p95 上：新系统不是只把平均延迟降低，而是让绝大多数音频帧都能稳定按时到达。雷峰网
02
WARP 协议：压缩物理世界的距离
在网络层面，标准 WebRTC 的建立需要 6 次网络往返（RTT）。对于跨地区连接，光速的限制就足以造成明显的首字延迟。
OpenAI 开发了名为 WARP 的自定义协议，将 DTLS 握手、SCTP 建立和数据通道协商合并。结果是将通道启动从 6 次往返缩短到了 1 次。
OpenAI 的做法是把路由提示写进 WebRTC 本来就会携带的 ICE ufrag，将路由提示直接写进连接协议。Relay（转发层）在收到第一个包时，不需要查询远程 Redis 就能知道该把数据送往哪个实例，在内存中直接建立映射，彻底消灭了一次跨网络查询。
虽然把从 6 次网络往返缩短到 1 次并不意味着整体启动速度提高了 6 倍（因为服务器调度、丢包、客户端处理和模型准备仍然需要时间），但它确实移除了多次必须等待网络返回的步骤。对于跨地区连接，减少完整网络往返通常比继续压缩几毫秒的服务端代码更有效。
03
边说边听，难点是模型状态不能乱
音频传输稳定之后，GPT-Live 还要解决另一个更难的问题：模型如何在持续对话中管理发言权和会话状态。
过去的语音系统通常依靠独立的回合检测器，根据静音时间判断用户是否说完，再启动主模型。GPT-Live 则把这项判断放进语音模型本身。
音频持续进入模型，模型一边理解内容，一边决定继续听、开始回答、暂停输出，还是接受打断。这样可以结合语义、语气和上下文判断停顿，但也意味着主模型需要在整场会话中持续运行。
OpenAI 尚未公布这种方式增加了多少计算成本，也没有给出误抢话和错误打断的数据。
打断是其中最难处理的一环。用户可能在第 4 秒插话，但模型已经生成到第 10 秒，部分音频甚至已经发到客户端。系统不能只停止继续生成，还要分别记录模型生成到哪里、服务器发送到哪里、用户实际听到哪里。下一轮对话只能以用户真正听见的部分为准，否则模型会误以为某些内容已经讲过。
OpenAI 没有公开播放确认和音频撤销的具体协议，但文章提到，最新消息的文字、时间范围和说话者归属都可以继续修改。这意味着模型输出不会立即成为最终记录，而要根据打断和实际播放情况重新确认。
持续语音还要求模型实例能够在不中断会话的情况下迁移。
一场长会话会保存对话上下文和 KV Cache。直接切换到空白实例，新实例需要重新处理全部历史，语音就可能出现停顿。
OpenAI 的做法是让旧实例继续运行，同时启动新实例并完成 Prefill。新实例还要补齐准备期间新增的音频，追上当前进度后，系统才会切换媒体流。
上下文压缩也沿用这套机制。旧实例继续对话，后台压缩历史并准备新实例，等新实例完成状态追赶后再接管。这样可以避免明显中断，但会暂时占用双份推理资源。
至于多次压缩后，长期要求、未完成任务和工具状态能保留多少，官方目前还没有公布数据。
04
双模型协作，解决「断点续传」
双模型架构真正难处理的，不是把任务交给后台，而是保证结果回来时仍然接得上当前对话。
GPT-5.5 开始搜索或调用工具后，GPT-Live 不会停下来等待，而是继续接收声音、回应用户。期间，用户可能补充条件、改变问题，甚至取消原任务。后台模型返回的答案即使本身正确，也可能已经不再适用于此时的会话。
因此，每个后台任务都需要绑定发起时的上下文位置。结果返回后，系统不能直接播放，而要先判断当前对话是否仍然延续原来的意图。
可以把它理解成一次带状态校验的“断点续传”：后台模型从某个会话节点开始工作，完成后再确认这段结果能否安全接回已经向前推进的实时对话。
OpenAI 没有公开任务版本、取消信号和过期结果的具体处理机制，但这些能力决定了系统能否避免读出已经失效的答案。
另一个问题是，模型处理的是连续声音，ChatGPT 的搜索、日志、安全和聊天记录却需要一条条明确的消息。用户和助手可能同时说话，简短回应未必需要单独成句，用户插入几个字也未必代表真正打断。应用服务器因此会先维护一份允许修改的临时记录，再根据时间、转录和发言权确认最终消息。
界面使用更新更快的推测状态，日志、分析和部分安全系统则依赖顺序更稳定的权威记录。前者保证字幕及时出现，后者保证后台任务能够找到可靠的会话断点。
正式上线前，OpenAI 还通过影子测试，把真实语音会话同时送入新旧系统。测试发现，一个辅助组件比预期更早饱和，并进一步拖慢推理队列。
这也说明，双模型协作能否稳定接续，不只取决于模型速度，还取决于网络、队列和状态服务能否共同跟上实时对话。
05
实时 Agent 迈入新的硬核工程时代
从公开内容看，GPT-Live 的技术重点并不是某一个单独模型变快了，而是 OpenAI 重新划分了实时语音系统中的责任。
音频被放进独立快速路径，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 的内存管理里，在那个能随时回滚的状态机里。
参考链接：
https://x.com/OpenAI/status/2084378418989379822
https://openai.com/index/continuous-voice-interaction-with-gpt-live/
上车，带你看遍全球 AI 顶会精华
可独家畅览：
专家演讲PPT
大会报告全文
热门论文解读
学术新星访谈
扫描上方二维码
或点击「阅读原文」关注专区。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
— Originally published at leiphone.com
Want this in your inbox every morning?
Daily brief at your local 8am — bilingual EN/中文, free.
More from 雷峰网 AI
See more →
刚刚，GPT 5.6 发布会上，OpenAI 暴露了哪些 Agent 技术路线？
OpenAI's GPT 5.6 integrates ChatGPT and Codex, introducing a for complex task execution, with models Soul, Terra, and Luna for efficient workflow management. The release emphasizes task orchestration, contextual understanding, and robust security measures for enterprise applications.
