GPT-Live 实时语音系统架构解析

对于语音 AI 来说，把握插话时机是公认的难题。人类对话中，双方可以在零点几秒内完成话轮交接，但过去的语音 AI 却跟不上这种节奏。它们的架构基于轮次，依赖一个名为 turn detector 的小型模型来判断何时结束用户话语并开始生成回复。猜得过早，会打断用户；猜得过晚，响应又显得迟钝。直到检测器做出决定，真正的大语言模型才开始运转。

GPT-Live 是 OpenAI 的第三代语音系统，它直接将 turn detector 从音频链路中移除。其语音模型支持全双工，可以同时听和说，无需单独的检测器，对话因此更加即时自然。当需要更深层的推理或工具调用时，GPT-Live 可以调用 GPT-5.5 等前沿模型，且不会打断对话流。这两项能力结合，赋予了 GPT-Live 前所未有的对话响应速度与智能水平。

要大规模提供这种体验，需要为低延迟优化一套全新系统架构。与典型的请求-响应式推理不同，该系统将传入的音频流式送入语音模型，同时把输出的语音传回给用户，而委托任务则通过独立的异步路径处理。过去六个月，OpenAI 重构了模型推理、上下文管理和媒体传输，以保证端到端语音流畅。

该架构还划清了核心语音路径与应用逻辑的边界，方便定制应用行为而不影响响应速度。这一基础支撑了 ChatGPT Voice 中越来越多的能力，包括新推出的桌面端电脑操控与智能体协调功能。

接下来，OpenAI 将解释为何旧有的轮次式系统无法满足需求，以及如何从每一层工程上实现响应速度。具体包括有状态推理、动态上下文管理、异步委托和协议级优化。

从轮次对话到流式传输

早期的语音架构继承了文本 LLM 的轮次特性，每一轮都是一个离散的音频块。在级联系统中，语音转文本、LLM 和文本转语音依次运行，不仅增加了延迟，还忽略了语气和语速等线索。

语音到语音模型直接处理音频，改进了这一方法，保留转录丢失的细节并更快响应。但系统仍依赖 turn detector 决定何时开始推理。GPT-Live 则让语音模型主导对话：音频流入流出模型，更深层的推理和工具调用在异步进行。系统的核心任务是维持不间断的媒体循环，其他工作（如调用前沿模型、持久化会话）都不在实时路径上。

实现持续推理

保持媒体循环不中断并不容易。传输、处理或推理中的任何延迟都可能变成可听见的停顿或杂音。OpenAI 此前已经重建了语音基础设施，以更低且可预测的延迟流式传输音频和视频。GPT-Live 将该设计进一步推进，通过新的有状态推理系统将媒体一路流式送入模型。

流式推理只是解决方案的一部分。生产环境中还需确保从客户端到推理栈的可靠音频传输，并应对有状态推理的挑战。OpenAI 的一个早期决定是将媒体流与应用逻辑分离：音频在客户端和语音模型之间的专用快速路径上移动，而委托、工具调用等工作在异步 RPC 边界之后进行。慢速工具调用可以延迟自己的结果，但不能阻断媒体流。这种分离也提供了干净的自定义边界，应用可以改变工具、策略和后端行为，而不影响负责保持音频流动的媒体前端。实时路径始终保持小、可预测、专注。

媒体前端和推理逻辑用 Go 编写，替代了之前 Python asyncio 实现，帧传输的流畅度显著提升，新系统的 p95 延迟与旧系统的 p50 持平。WebRTC 提供传输基础，可应对丢包、时钟漂移和连接变化，必要时会微调音频以填补空隙，再加速播放回到实时。通过最小化缓冲和阻塞，系统实现亚秒级响应。

维持有状态对话

有状态推理有自己的取舍。语音会话可能持续很长时间，上下文不断增长，模型实例根据需求弹性伸缩。OpenAI 构建了跨模型实例的无缝切换机制：当需要转换时，可以预先启动一个替代实例，用当前会话上下文预填充，并行运行两个实例，新实例就绪后切换到它。同一机制支持动态上下文压缩。当上下文超过限制时，压缩需要时间，并使 KV 缓存失效，需要重新预填充。OpenAI 将压缩也作为一次受管转换：原实例继续聊天，系统压缩上下文并准备新实例，就绪后切换而不中断媒体。这样就能支持长时间通话。

不阻塞对话的委托

GPT-Live 能调用现有前沿模型，将“说话”与“深度思考”解耦。但要让两模型架构像一系统，需解决两个关联问题：结果必须足够快返回，以及将持续会话表示为离散消息。

为深度工作委托

GPT-Live 提供快速自然响应，GPT-5.5 在后台处理搜索。

音频示例

当委托被派发时，优化到前沿模型产生有用结果的时间。语音模型可以短暂维持交流，但无法隐藏任意慢的响应。因此，OpenAI 将委托完整循环（路由、提示处理、推理、工具调用）纳入响应预算。

第一个优化是在委托请求前就设置好前沿模型及其工具。语音会话开始时，应用服务器为前沿模型创建推理会话，并用初始对话上下文预填充，确保在第一次委托请求前提示词已完全处理。随后在语音会话期间保持该推理会话可用，并使用稳定会话亲和性。结合提示缓存，在故障可恢复的同时降低延迟。推理力度、输出限制、工具模式和模型工具往返也会影响结果到达时间，OpenAI 调整这些杠杆以获得更快响应。

从连续语音中提取离散轮次

虽然语音模型处理连续流，但周围许多系统仍基于用户和助手轮次，包括 ChatGPT 对话界面、分析和安全基础设施。应用服务器需要将重叠且有时模糊的对话拆分为离散消息。音频到达时，服务器使用部分转写和时序信号推断说话人并构建消息队列。最新消息保持临时性，文本、时序和说话人归属都可能变化。当说话人保持话语足够久时，服务器最终确定对应消息。说话重叠使这更复杂：用户说话时助手简短认同（如“嗯哼”）不应成为独立消息，但实质性的插话需要。系统维护两个视图：推测视图用于 UI，权威记录用于分析流水线。

用更快的协议启动会话

响应速度从点击按钮开始。GPT-Live 必须建立媒体路径并开始向模型喂入音频。WebRTC 提供实时基础，但启动标准 WebRTC 会话需要多次握手和网络往返。WebRTC 早于 QUIC 等以最小化往返为中心的协议，底层协议有时会重复工作，比如每个协议都有自己的抗 DoS 机制。OpenAI 设计了 WARP 作为开放规范，与 WebRTC 社区合作，推进 IETF TSVWG 工作组的提案，并已在 libwebrtc 和 Pion 中支持。

优化媒体握手后，一个剩余延迟是交换 SDP 信令。为了从关键路径中移除该交换，OpenAI 开发了 Instant Connect，可提前协商参数而不预留服务器容量，也无需修改现有 WebRTC 实现。Instant Connect 与标准信令流程并行。如果预协商参数有效，服务器可在第一个媒体包到达时实例化会话；如果失效，信令流程已在进行，客户端可无额外延迟回退。两者结合大大缩短从用户意图到媒体流动的时间。客户端只需发送一个 UDP 数据包即可启动会话，服务器立即响应。

用真实数据安全测试

系统可能纸面上很快，但在真实流量下卡顿。OpenAI 在 GPT-Live 上线前进行了静默测试：将生产 ChatGPT Voice 会话的小部分流量逐渐增加到 Advanced Voice Mode 和 GPT-Live 影子路径，影子路径以只读模式运行推理，不改变用户体验。第一个教训是容量不能仅看 GPU 吞吐量。语音会话持续发送帧，CPU 端流处理器、队列和网络路径必须与推理一起扩展。真实负载下，一个支持组件比负载测试预测更早饱和，导致推理请求累积和延迟叠加。容量问题变成“系统能维持多少并发会话同时保证每帧按时？”地理因素也至关重要。将推理移到离用户更近的地方有帮助，但端到端响应取决于路径上的所有服务。长时间会话暴露内存和持久化压力，重连测试压缩和状态恢复，普通断开暴露关闭握手竞争。生产测试还迫使改进可观测性和发布控制：增加更细粒度的遥测、验证已知良好配置、分阶段灰度、快速隔离故障路径。静默测试成为一次早期发布预演。

从客户端到模型的响应式体验

将 GPT-Live 带到 ChatGPT 规模需要一个围绕基本原则构建的全新系统：语音必须流动。流式推理保证全双工模型音频供给，专用媒体路径确保帧可靠传输，异步委托让深度思考并行，优化传输让体验始终保持响应。GPT-Live 的架构正在成为实时交互的更广泛平台，驱动 ChatGPT Voice 从对话扩展到智能体协调，并支撑即将推出的 GPT-Live API。未来，它还将让语音体验跨越更多设备、应用和模态，而不牺牲语音对话的即时性。