GPT-Live 如何在六个月内构建响应式语音 AI 实时系统

OpenAI 推出 GPT-Live，实现与 AI 的连续语音交互。该系统采用无轮次语音模型和低延迟架构，使对话更快、更自然。GPT-Live 的构建耗时六个月，核心在于减少交互延迟并支持不间断对话。

作者：Justin Uberti 和 Zahan Malkani
原文：https://openai.com/index/continuous-voice-interaction-with-gpt-live/
翻译：实时互动网

对于语音 AI 来说，知道何时开口比听起来要难得多。人类说话者能在几分之一秒内自然地交接话语权，但此前的语音 AI 系统跟不上这个节奏。它们的轮次架构依赖于被称为”轮次检测器”的小型模型，面临着两难的任务：猜得太早，用户会被打断；猜得太晚，回应又显得迟钝。只有等检测器做出判断后，大得多的 LLM 才能开始工作。

GPT-Live 是我们的第三代语音系统，它将轮次检测器从音频通路中移除。其语音模型是全双工的，意味着它可以同时听和说。这消除了对独立检测器的需求，使对话感觉更即时、更自然。当需要更深层推理或工具调用时，GPT-Live 还可以咨询我们的前沿模型（如 GPT-5.5），而不会中断对话流。这些能力共同赋予了 GPT-Live 前所未有的对话响应速度与智能水平的结合。

在大规模场景下交付这种体验需要一套全新的、专为低延迟优化的系统架构。与典型的请求-响应式推理不同，我们的系统将传入音频流式输入语音模型，并将输出语音流式传回用户，同时在单独的异步路径上处理委托任务。在过去六个月里，我们重构了模型推理、上下文管理和媒体传输，确保语音从端到端顺畅流动。

该架构还在核心语音路径和应用逻辑之间建立了清晰的边界。这使得定制应用行为变得容易，同时不影响响应速度。这一基础支撑着 ChatGPT 语音功能日益丰富的能力，包括新近推出的控制电脑和在 ChatGPT 桌面应用中协调智能体的功能。

在这篇文章中，我们将解释为什么早期的轮次系统无法满足需求，以及我们如何在每一层为新系统进行响应速度优化。内容涵盖有状态推理、动态上下文管理、异步委托和协议级优化，它们协同工作，让 GPT-Live 真正做到”实时”。

从轮次交替到流式处理

早期的语音架构继承了文本 LLM 的轮次特性，但每个轮次表现为一段离散的音频块而非文本。在级联式系统中，语音转文本、LLM 和文本转语音依次串行执行。这种串行处理增加了延迟，也忽略了语调和节奏等线索。

语音到语音模型改进了这一方式，直接处理音频。通过训练模型原生理解和生成语音，它能保留转写中丢失的细节并更快做出响应。但系统仍然依赖轮次检测器来决定何时开始推理。模型处理了更多交互环节，但交互本身仍是轮次制的。

GPT-Live 让语音模型掌控对话：音频流入和流出模型，而深层推理和工具调用异步进行。该系统的主要任务是维持不间断的媒体循环。其他工作，例如调用前沿模型和持久化对话，则在实时路径之外进行。

实现连续推理

保持这个媒体循环不中断并不总是那么简单。传输、处理或推理中的任何延迟都可能变成可听到的停顿或瑕疵。之前的轮次系统可以容忍音频块到达时间的某些波动。然而，实时媒体系统需要按时交付每一帧音频。

此前在 ChatGPT 语音和 Realtime API 上的工作为我们提供了重要基础。我们已经重建了语音基础设施，以更低、更可预测的延迟直接在系统间流式传输音频和视频。GPT-Live 进一步推进了这一设计，通过一套全新的、为持续对话构建的有状态推理系统，将媒体流一直传输到模型。

不过，流式推理只是解决方案的一部分。要在生产环境中良好运行，我们还必须确保从客户端到推理栈的可靠音频传输，并解决有状态性带来的挑战。

加快媒体流传播速度

我们早期做出的一个关键决策是将媒体流与应用和业务逻辑分离。音频在客户端和语音模型之间的专用快速路径上传输。委托、工具调用和其他应用工作发生在异步 RPC 边界之后。一个慢速的工具调用或后端服务可以延迟其自身的结果，但不能阻塞媒体流。

这种分离还为系统提供了清晰的定制边界。应用可以更改其工具、策略和后端行为，而不影响负责保持音频流动的媒体前端。直播路径保持小巧、可预测，并专注于必须实时完成的工作。

我们用 Go 语言编写了媒体前端和推理逻辑，替换了此前基于 Python asyncio 的实现。这显著改善了帧交付的平滑度，新系统的 p95 延迟与旧系统的 p50 相当。

WebRTC 提供了传输基础。它专为低延迟媒体设计，能够在丢包、时钟漂移和客户端连接变化的情况下继续运行。如果数据包延迟到达，WebRTC 可以微妙地拉伸音频以防止间隙，然后短暂加速播放以重新跟上实时进度。

通过最小化整个系统中的缓冲和阻塞，我们能够实现人类在对话中所期望的毫秒级响应速度。

保持（有状态的）对话持续进行

有状态推理有其自身的运维权衡。一个语音会话可能长时间保持活跃，但其上下文持续增长，且模型实例根据需求不断创建和销毁。

为了解决这些问题，我们构建了跨模型实例的无缝切换机制。当需要过渡时，我们可以在现有实例旁边预热一个替代模型实例，用当前会话上下文预填充它，在两个实例上并行运行推理，然后在新实例完全就绪后切换过去。

同一套基本机制也支持动态上下文压缩。随着对话进行，累积的上下文最终可能超出模型的上下文限制。压缩可以减小上下文以适应限制，但该操作需要时间。而且由于它改变了过去的上下文，还会使模型的 KV 缓存失效——该缓存存储了先前处理过的 token 的注意力键值。重建该状态需要新的预填充，引入额外延迟。

相反，我们将压缩视为另一种受管理的过渡。在原始模型实例继续对话的同时，系统压缩上下文并准备一个使用新上下文的替代模型实例。一旦该实例就绪，我们就可以切换过去，而不会造成任何媒体中断。这使得系统能够支持长时间通话，并在需要时进行压缩。

繁重的计算工作不会影响实时通信，因此即使在交接过程中，对话也不会中断。

授权而不阻碍对话

GPT-Live 能够调用现有的前沿模型，这赋予了它强大的功能，有效地将“说话”与更深层次的“思考”分离。但要让这种双模型架构感觉像一个系统，就需要解决两个相关的工程问题。

首先，结果必须足够快地返回，才能在正在进行的交流中发挥作用，因此我们必须最大限度地减少整个委托路径上的延迟，包括路由和提示处理、推理和工具调用。同时，产品中的其他系统仍然需要离散的消息，因此我们必须以它们能够理解的形式来表示正在进行的对话。

快速有效地进行授权，使其感觉自然而然

当委托任务发出时，我们会优化前沿模型生成对对话有用的信息所需的时间。语音模型可以在前沿模型进行推理或使用工具期间短暂地维持对话的进行，但它无法掩盖响应速度过慢的问题。因此，我们将完整的委托循环（路由、提示处理、推理和工具调用）都纳入了响应速度预算的考量范围。

第一个优化步骤是在请求委托之前设置好前沿模型及其所需的任何工具。当语音会话开始时，应用服务器会为前沿模型创建一个推理会话，并预先填充初始对话上下文，以确保在首次委托请求之前，提示信息已被完全处理。

然后，我们在语音通话期间保持该推理会话可用，并对后续请求使用稳定的会话亲和性。结合即时缓存，这些技术可以降低延迟，同时还能轻松恢复工作进程故障。

推理工作量、输出限制、工具模式以及模型与工具之间的往返次数都会影响对话何时获得有效结果，我们调整了这些因素以获得更快的响应。通过最大限度地减少委托路径上所需的工作量，我们使语音模型能够快速整合来自前沿模型的结果。

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

尽管语音模型在连续的语音流上运行，但它周围的许多系统仍然基于用户和助手的轮次运行，包括 ChatGPT 的对话 UI 以及部分分析和安全基础设施。因此，应用服务器将重叠的、偶尔含糊不清的对话拆解为离散消息。

随着音频到来，服务器使用部分转写和时间信号来推断哪位说话者拥有话语权，并构建消息队列。最新的消息保持临时状态，其文本、时间和说话者归属都可能随着更多语音到来而改变。一旦某位说话者持续拥有话语权的时间足以使归属可靠，服务器就会最终确定相应的消息。

说话者重叠使情况更加复杂。当用户在说话时助手的简短回应（如”嗯嗯”或”好的”）不一定要成为独立消息。然而，助手实质性的插话通常应该成为独立消息。同样，即使用户在中间说话，我们也优先保证显示的助手回复的连贯性。

每种分段策略都在新鲜度和确定性之间做权衡。过早提交会产生碎片化的历史和不稳定的排序；等待太久则延迟转写及依赖它的功能。因此，系统维护着对话的两个相关视图：当前状态的推测视图和所说内容的权威记录。应用 UI 中的对话视图可以处理更新，因此使用推测视图。但写入分析流水线需要最终转写。

这让 ChatGPT 的其余部分对交流有一个稳定的视图，而不会将轮次交替强加于实时语音路径。

用更快的协议启动会话

响应速度从用户点击按钮的那一刻就开始了。在 GPT-Live 中，系统必须在对话开始之前建立媒体路径并开始向模型输送音频。这使得启动序列的每个环节都处于关键路径上。

如前所述，WebRTC 提供了强大的实时基础，但启动一个标准 WebRTC 会话需要数量惊人的协议握手和网络往返。WebRTC 早于后来塑造 QUIC 等协议的最小化往返设计理念。因此，当其底层协议一起使用时，有时会重复工作。例如，每个协议都包含自己的反 DoS 机制，即使在完整 WebRTC 协议栈上下文中并不需要。

我们分析了整个协议栈，并开发了 WebRTC 精简往返协议（WARP），将媒体和数据的启动从六次网络往返减少到仅一次。WARP 通过一组向后兼容的协议改进实现这一目标：将 DTLS 握手搭载在 ICE 之上（SPED）、使用更快的 DTLS 1.3 握手、预协商 SCTP 握手（SNAP），以及预协商数据通道而非使用 DCEP。

我们将 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 语音会话同时路由到现有的高级语音模式体验和我们的新系统。高级语音模式继续照常为用户服务，而影子路径以只读模式运行推理。这让系统暴露于真实的客户端、网络、会话时长和地理分布，而不会改变用户听到的内容。

最早的教训之一是容量不能简单归结为 GPU 吞吐量。语音会话保持开启并持续发送帧，因此 CPU 侧的流处理器、队列和网络路径必须与推理一起扩展。在实际负载下，一个支撑组件比我们的负载测试预估更早达到饱和，导致推理请求累积和延迟叠加。我们将容量问题从”一块 GPU 能处理多少请求？”转变为”系统能维持多少并发会话，同时确保每一帧按时交付？”

测试还使地理分布成为一阶问题。将一个会话路由到远处的计算资源会在启动和流式传输的多个环节增加延迟。我们开始将模型发布与区域容量和流量调度配置一起验证，然后按来源地域分解延迟。将推理移近用户有帮助，但它也强化了更广泛的教训：端到端响应速度取决于路径上的每个服务，而不仅仅是模型服务器。

其他故障只在真实的会话生命周期中才会出现。长时间运行的会话暴露了内存和持久化压力。重连测试了压缩和状态恢复。普通的客户端断开连接揭示了关闭握手中的竞态条件。这些问题很少在短时负载测试中出现，因为它们依赖于时间、累积状态和跨服务边界的行为。

最后，生产测试迫使我们改进可观测性和发布控制。我们发现某些指标混淆了不同来源的延迟，某些仪表盘的聚合数据隐藏了个别不健康的引擎，以及测试系统与部署系统之间的配置漂移。作为应对，我们添加了更细粒度的遥测、对已知良好配置的验证、分阶段放量，以及快速隔离或禁用单个路径的能力。静默测试成为了一次早期发布预演——不仅测试系统能接受多少流量，更测试我们能多快地检测、遏制和恢复故障。