在实时语音交互中，延迟是唯一的“死线”。
文字回答慢上几百毫秒，用户顶多觉得体验打折；但音频只要卡顿一次，那种“非人”的割裂感会瞬间摧毁信任。为了解决这个工程顽疾，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 的内存管理里，在那个能随时回滚的状态机里。更多实时交互系统深度技术解析，尽在云栈社区。
参考链接：
发表于 6 小时前
|
查看: 5|
回复: 0
