OpenAI：我们如何在六个月内构建响应式语音AI的实时系统

# 我们如何在六个月内构建出响应式语音 AI 的实时系统 来源：https://openai.com/index/continuous-voice-interaction-with-gpt-live/ 对于语音 AI 来说，知道何时开口比听起来要难得多。人类说话者能在不到一秒的时间内轻松完成话轮交接，但此前的语音 AI 系统无法跟上这种节奏。它们基于轮流说话（turn-based）的架构依赖于被称为“话轮检测器”（turn detector）的小型模型，而这些模型面临着一个棘手任务：猜得太早，用户会被打断；猜得太晚，响应又会显得迟钝。只有检测器做出决定后，更大的 LLM 才能开始工作。 GPT‐Live（https://openai.com/index/introducing-gpt-live/），我们第三代语音系统，将话轮检测器从音频路径中移除。它的语音模型是全双工的，这意味着它可以同时听懂和说话。这消除了对独立检测器的需求，使对话更加直接和自然。当需要更深入的推理或工具使用时，GPT‐Live 还可以咨询我们的前沿模型，如 GPT‐5.5，而不会打断对话的流畅性。这些能力共同为 GPT‐Live 带来了前所未有的对话响应速度与智能组合。 要大规模提供这种体验，需要一种专为低延迟优化的新系统架构。与典型的请求-响应推理不同，我们的系统将传入的音频流式输入语音模型，并将输出语音流式返回给用户，同时在独立的异步路径上处理委派。在过去的六个月里，我们重新设计了模型推理、上下文管理和媒体传输，以确保语音从端到端流畅流动。 该架构还在核心语音路径和应用逻辑之间建立了清晰的边界。这样可以轻松定制应用程序行为，而不影响响应性。这一基础为 ChatGPT Voice 中不断增长的功能提供了支持，包括新推出的在 ChatGPT 桌面应用中控制计算机和协调 agent 的能力。 在这篇文章中，我们将解释为什么早期的轮流说话系统无法满足我们的需求，以及我们如何在每一层架构上精心设计这个新系统以实现高响应性。我们将涵盖有状态推理、动态上下文管理、异步委派和协议级优化，所有这些协同工作，让 GPT‐Live 真正“活”起来。 ## 从轮流说话转向流式处理 早期的语音架构继承了文本 LLM 的轮流说话特性，但每一轮表示为离散的音频块而非文本。在级联系统中，语音转文本、LLM 和文本转语音各自串行运行。这种顺序化增加了延迟，并忽略了语气和节奏等线索。 语音到语音模型通过直接处理音频改进了这种方法。训练模型原生地理解和生成语音，使其能够保留转写中丢失的细节，并更快地做出响应。但系统仍然依赖话轮检测器来决定何时可以开始推理。模型处理了更多的交互，但交互本身仍然是基于轮流说话的。 GPT‐Live 让语音模型掌控对话：音频流入和流出模型，而更深入的推理和工具使用则异步进行。系统的主要任务是维持一个不间断的媒体循环。其他工作，例如调用前沿模型和持久化对话，则在实时路径之外进行。 ## 实现持续推理 保持这一媒体循环不中断并非总是易事。传输、处理或推理中的任何延迟都可能变成可听见的停顿或失真。之前的轮流说话系统可以容忍音频块到达时间的一些波动。然而，实况媒体系统需要按时交付每一个音频帧。 此前在 ChatGPT Voice 和 Realtime API 上的工作为我们提供了重要基础。我们已经重建了语音基础设施（https://openai.com/index/delivering-low-latency-voice-ai-at-scale/），以更低且更可预测的延迟将音频和视频直接流式传入和传出我们的系统。GPT‐Live 进一步推进了这一设计，通过一个新的有状态推理系统将媒体一直流式传输到模型中，该系统专为持续对话而构建。 不过，流式推理只是解决方案的一部分。要让它在生产环境中良好运行，我们还必须确保从客户端到推理栈的可靠音频传输，并应对有状态（statefulness）带来的挑战。 我们早期做出的一个决定是明确地将媒体流与应用和业务逻辑分开。音频在专用快速路径上在客户端和语音模型之间移动。委派、工具使用和其他应用工作则在异步 RPC 边界之后进行。一个缓慢的工具调用或后端服务可以延迟自身的结果，但不会阻塞媒体的流动。 这种分离还为系统提供了清晰的自定义边界。应用程序可以更改其工具、策略和后端行为，而不会影响负责保持音频流动的媒体前端。实时路径保持小巧、可预测，并专注于必须在实时完成的工作。 我们用 Go 编写了媒体前端和推理逻辑，取代了此前 Python 的 `asyncio` 实现。这显著提高了帧交付的流畅性，新系统的 p95 达到了旧系统的 p50 水平。 WebRTC 提供了传输基础。它专为低延迟媒体而设计，并且能够在丢包、时钟漂移和客户端连接变化的情况下继续运行。如果数据包到达较晚，WebRTC 可以巧妙地拉伸音频以避免间隙，然后短暂加速播放以重回实时状态。 通过最小化整个系统中的缓冲和阻塞，我们能够提供人类在对话中期望的亚秒级响应。 ### 保持（有状态的）对话继续进行 有状态推理有其自身的运维权衡。一个语音会话可能保持活跃很长时间，但其上下文不断增长，模型实例会根据需求上下线。 为了解决这些问题，我们构建了一个跨模型实例的无缝切换机制。当需要转换时，我们可以在现有实例旁边预热一个替换模型实例，用当前会话上下文对其进行预填充（prefill），并行地对两者运行推理，并在新实例完全就绪时进行切换。 相同的基本机制还支持动态上下文压缩。随着对话的进行，累积的上下文最终可能超出模型的上下文限制。压缩可以将上下文大小缩小到限制之内，但该操作需要时间。而且由于它改变了过去的上下文，它还会使模型的键值（KV）缓存失效，该缓存存储了之前处理过的 token 的注意力键和值。重建这些状态需要新的预填充，从而引入额外的延迟。 相反，我们将压缩视为另一次受控转换。在原始模型实例继续对话的同时，系统压缩上下文并准备一个带有新上下文的替换模型实例。一旦该实例就绪，我们就可以在不中断媒体的情况下进行切换。这使得系统能够支持长时间运行的呼叫，并在必要时进行压缩。 繁重的工作保持在实时路径之外，因此即使在切换期间，对话也不会错过一个节拍。 ## 在对话不阻塞的情况下进行委派 GPT‐Live 调用现有前沿模型的能力赋予了它强大的力量，有效地将“说话”与更深的“思考”解耦。但是，让这种双模型架构感觉像一个系统，需要解决两个相关的工程问题。 ### 为更深层工作委派 GPT‐Live 提供快速、自然的响应，而 GPT‐5.5 在后台处理搜索 转录 与 GPT‐Live-1 的示例对话，使用 GPT‐5.5 Instant 首先，结果必须足够快地返回，以便在持续交流中有用，因此我们必须最小化整个委派路径的延迟，从路由和提示处理到推理和工具调用。同时，产品中的其他系统仍然需要离散消息，因此我们必须以它们能够理解的形式来表示持续对话。 ## 让委派快得足够自然 当委派被调度时，我们优化的是前沿模型为对话产生有用结果之前的时间。语音模型可以在前沿模型推理或使用工具时短暂地维持交流的推进，但它无法隐藏任意缓慢的响应。因此，我们将整个委派循环——路由、提示处理、推理和工具调用——视为响应时间预算的一部分。 第一个优化是在请求委派之前设置好前沿模型及其所需的任何工具。当语音会话启动时，应用服务器为前沿模型创建一个推理会话，并用初始对话上下文进行预填充，确保提示在第一次委派请求之前已被完全处理。 然后，我们在整个语音对话期间保持该推理会话可用，并对连续请求使用稳定的会话亲和性。结合提示缓存，这些技术在工作人员故障仍然易于恢复的情况下改善了延迟。 推理努力程度、输出限制、工具schema以及模型与工具之间的往返也会影响对话何时收到有用的结果，我们调整了这些杠杆以获得更快的响应。通过最小化委派路径上所需的工作，我们使语音模型能够快速纳入来自前沿模型的结果。 ### 从连续语音中提取离散话轮 即使语音模型在连续的语音流上运行，它周围的许多系统仍然基于用户和助手话轮进行操作，包括 ChatGPT 的对话界面以及部分分析和安全基础设施。因此，应用服务器将重叠的、偶尔有歧义的对话解析为离散消息。 随着音频到达，服务器使用部分转录和时序信号来推断当前是哪位说话者在掌控（floor），并构建消息队列。最新消息保持为暂定状态；其文本、时间和说话者分配都可能随着更多语音的到来而变化。一旦某位说话者持续掌控足够长的时间，使归属可靠，服务器就会最终确定相应的消息。 说话者重叠使这变得更加复杂。助手在用户说话时的短暂确认（例如“嗯哼”或“好的”）不应一定要成为一条独立消息。然而，助手实质性的插话通常是应该的。同样，即使在中途用户说话的情况下，我们也优先考虑所显示助手响应的一致性。 每种分段策略都在新鲜度和确定性之间进行权衡。过早提交会产生碎片化的历史和混乱的排序；等待太久则延迟转录和依赖转录的功能。因此，系统维护两个相关的对话视图：当前状态的推测性视图和关于所说内容的权威记录。应用界面中的对话视图可以处理更新，因此它使用推测性视图。但是记录到分析管道则需要最终转录。 这为 ChatGPT 的其余部分提供了稳定的交流视图，而不会对实时语音路径强加轮流说话机制。 ## 用更快的协议启动会话 响应性从用户点击按钮的那一刻就开始了。使用 GPT‐Live 时，系统必须在对话开始之前建立媒体路径并开始通过模型馈送音频。这使得启动序列的每个部分都处于关键路径上。 如上所述，WebRTC 提供了强大的实时基础，但启动一个标准的 WebRTC 会话需要数量惊人的协议握手和网络往返。WebRTC 早于后来塑造 QUIC 等协议的“最小化往返次数”这一关注点。因此，当一起使用其底层协议时，有时会产生重复工作。例如，每个协议都包含自己的防 DoS 机制，即使在整个 WebRTC 栈的上下文中并不需要。 我们将 WARP 设计为一组开放规范，并与 WebRTC 社区的协作者合作，以便更广泛的生态系统能够从这项工作中受益。我们正在通过 IETF 的 TSVWG 工作组推进这些提案，并且 WARP 支持已经添加到 libwebrtc 和 Pion 中，其他 WebRTC 实现的集成工作也在进行中。 优化媒体握手后，仍有一个延迟突出：用于在 WebRTC 连接之前共享 SDP 参数的信号交换。为了将该交换从关键路径中移除，我们开发了所谓的 Instant Connect。它会提前协商这些参数，而无需预留服务器容量，也无需更改现有的 WebRTC 实现。 Instant Connect 与标准信号流程并行运行。如果预先协商的参数有效，服务器可以在第一个媒体数据包到达时实例化会话。如果参数已过时或无效，信号流程已经在进行中，因此客户端可以在没有额外延迟的情况下回退。 Instant Connect 和 WARP 共同大幅缩短了从用户意图到实时媒体流动的时间。通过将 SDP 交换移出关键路径，并用 WARP 压缩传输握手，客户端现在可以用一个 UDP 数据包启动会话。服务器可以立即响应，让系统的其余部分开始执行用户真正关心的工作：聆听和响应。 ## 使用真实数据在生产环境中安全测试 GPT‐Live 一个系统在纸面上可能看起来很快，但在真实语音流量下仍可能停滞。在让 GPT‐Live 与用户聊天之前，我们运行了一项静默测试，将生产 ChatGPT Voice 会话中一小部分且逐渐增加的比例同时路由到现有的高级语音模式（Advanced Voice Mode）体验和我们的新系统。高级语音模式继续像往常一样服务用户，而影子路径以只读模式运行推理。这使系统暴露在真实的客户端、网络、会话时长和地理分布之下，而不会改变用户听到的内容。 其中一个早期教训是，容量不能简化为 GPU 吞吐量。语音会话保持打开并持续发送帧，因此 CPU 侧的流处理器、队列和网络路径必须与推理一起扩展。在真实负载下，一个辅助组件比我们负载测试估计所预测的更快达到饱和，导致推理请求积压和延迟累积。我们将容量问题从“*一个 GPU 能处理多少个请求？*”转变为“*系统在保持每个帧按时交付的同时，能维持多少个并发会话？*” 测试还使地理因素成为首要关注点。将会话路由到较远的容量可能会在启动和流式传输的多个环节增加延迟。我们开始将模型发布与区域容量和流量引导配置一起验证，然后按来源地理位置分解延迟。将推理移到离用户更近的地方有所帮助，但也强化了更广泛的教训：端到端响应性取决于路径中的每个服务，而不仅仅是模型服务器。 其他失败只出现在现实会话生命周期中。长时间运行的会话暴露了内存和持久化压力。重连则检验了压缩和状态恢复。普通的客户端断连揭示了关闭握手过程中的竞态条件。这些问题很少在短期负载测试中出现，因为它们依赖于时间、累积状态以及跨服务边界的行为。 最后，生产环境测试迫使我们改进可观测性