OpenAI 如何在六个月内构建实时语音 AI 系统

对于语音 AI 来说，「什么时候该说话」比听起来难得多。人类说话者在不到一秒的时间里就能自然地把话头交给对方，但以往的语音 AI 系统跟不上这个节奏。它们基于轮次的架构依赖一种被称为轮次检测器（turn detector）的小模型，而这个小模型面临一个左右为难的判断：猜得太早，用户会被打断；猜得太晚，响应又显得迟钝。只有检测器做出决定后，更大的 LLM 才能开始工作。

GPT-Live 是我们的第三代语音系统，它把轮次检测器从音频路径中移除了。它的语音模型是全双工（full-duplex）的，也就是说可以同时听和说。这消除了对独立检测器的依赖，让对话感觉更即时、更自然。当需要更深度的推理或工具调用时，GPT-Live 还能在不中断对话流畅性的情况下调用 GPT-5.5 等前沿模型。这些能力组合在一起，赋予 GPT-Live 前所未有的对话响应速度与智能水平。

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

这套架构还在核心语音路径与应用逻辑之间划出了清晰的边界。这样一来，定制应用行为时不会影响响应速度。这个基础支撑了 ChatGPT Voice 日益丰富的能力，包括最近上线的、在 ChatGPT 桌面应用中控制电脑和协调多个 Agent 的功能。

在这篇文章中，我们会解释为什么早期的轮次系统无法满足需求，以及我们如何从每一层工程上把新系统打磨得足够灵敏。我们会涉及有状态推理（stateful inference）、动态上下文管理、异步委派（asynchronous delegation）以及协议层优化，这些环节共同让 GPT-Live 真正有「实时」的感觉。

从轮次对话走向流式传输

早期的语音架构继承了文本 LLM 的轮次特性，只是把每一轮从文本换成了一个离散的音频片段。在级联式（cascaded）系统里，语音转文字、LLM 和文字转语音需要依次运行。这种串行处理既增加了延迟，又忽略了语调、节奏这类线索。

端到端语音模型（speech-to-speech）通过直接处理音频改进了这一点。让模型原生地理解和生成语音，可以保留转录过程中丢失的细节，并更快地做出响应。但系统仍然依赖轮次检测器来决定何时开始推理。模型承担了更多交互工作，可交互本身依然是轮次的。

GPT-Live 把语音模型置于对话的主导位置：音频在模型里进出，而更深度的推理和工具调用则在异步发生。系统的主要职责是维持一个不间断的媒体循环。其他工作，比如调用前沿模型和持久化对话，都在实时路径之外完成。

让推理持续不断

要让这个媒体循环保持不间断，并不总是那么容易。传输、处理或推理中的任何延迟，都可能变成一段可被听见的停顿或杂音。以往的轮次系统对音频片段何时到达有一定的容忍度，而实时媒体系统则必须按时送达每一帧音频。

我们在 ChatGPT Voice 和 Realtime API 上的早期工作打下了重要基础。此前我们已经重建了语音基础设施，以更低且更稳定的延迟把音频和视频直接流入流出系统。GPT-Live 进一步推进了这一设计，通过一套全新的、为持续对话打造的有状态推理系统，把媒体一路流式送进模型。

不过流式推理只是解决方案的一部分。要让它真正在生产环境中跑起来，我们还必须保证从客户端到推理栈的音频传输稳定可靠，并解决有状态性带来的种种挑战。

让媒体快速流动

我们很早就做出的一个决定，是把媒体流与应用和业务逻辑明确分开。音频在客户端和语音模型之间走一条专用的快路径；委派、工具调用和其他应用工作则放在一条异步 RPC 边界之后。一个慢的工具调用或后端服务最多拖慢它自己的结果，却无法阻塞媒体流。

这种分离也为系统定制提供了清晰的边界。应用可以改变自己的工具、策略和后端行为，而不影响负责推动音频流转的媒体前端。实时路径因此保持小巧、可预测，并且只专注于那些必须在实时中完成的工作。

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

WebRTC 提供了传输基础。它本就是为低延迟媒体设计的，能够在丢包、时钟漂移和客户端连接切换中继续工作。如果数据包迟到了，WebRTC 可以轻微拉伸音频来避免出现间隙，然后再短暂加速播放以追回实时节奏。

通过尽量减少整个系统中的缓冲和阻塞，我们得以交付人类对话所期待的亚秒级响应。

让（有状态的）对话持续下去

有状态推理本身也有运维上的权衡。一次语音会话可能长时间保持活跃，但它的上下文会持续增长，而模型实例则按需求动态启动和关闭。

针对这些问题，我们构建了一种跨模型实例的无缝切换机制。当需要切换时，我们可以在现有实例旁边预热一个替换模型实例，把当前会话上下文预先填充进去，对两者并行运行推理，等新实例完全就绪后再切换过去。

同一套基本机制也支撑了动态上下文压缩（dynamic context compaction）。随着对话推进，累积的上下文最终可能超出模型的上下文限制。压缩可以把上下文缩小到限制以内，但这个操作需要时间。而且由于它会改变过去的上下文，也会让模型的键值（KV）缓存失效，而 KV 缓存存放着先前处理过的 token 的注意力键和值。重建这部分状态需要一次新的预填充（prefill），会带来额外的延迟。

取而代之的是，我们把压缩当作又一次受控的迁移。当原始模型实例继续对话时，系统在后台压缩上下文，并用新的上下文准备好一个替换模型实例。一旦该实例就绪，我们就可以切换过去，而不会造成任何媒体中断。这让系统能够支持长时间的通话，并在必要时随时进行压缩。

繁重的处理都放在实时路径之外，所以即便在切换过程中，对话也从未中断。

不阻塞对话的委派

GPT-Live 能够调用现有的前沿模型，这赋予它强大的能力，实际上是把「说话」和更深层的「思考」解耦了。但要让人感觉这两套模型架构像同一个系统，需要解决两个相关的工程问题。

第一，结果必须足够快地返回，才能在持续进行的对话中派上用场，所以我们必须在整个委派路径上压低延迟，从路由、提示词处理，一直到推理和工具调用。与此同时，产品中其他地方的系统仍然需要离散的消息，所以我们还必须把持续进行的对话表示成它们能够理解的形式。

让委派快到感觉自然

当一次委派被派发出去时，我们优化的目标是：前沿模型为对话产出有用内容所需的时间。语音模型可以在前沿模型推理或调用工具时短暂地维持对话进行，但它无法掩饰一个任意缓慢的响应。因此，我们把完整的委派回路（路由、提示词处理、推理和工具调用）都纳入响应预算的一部分。

第一个优化是，在委派被请求之前，就把前沿模型和它所需的工具准备好。当一次语音会话开始时，应用服务器就为前沿模型创建一个推理会话，并用初始对话上下文进行预填充，确保在第一次委派请求到来之前，提示词已经被完整处理。

随后，我们在整个语音对话期间保持该推理会话可用，并对连续的请求使用稳定的会话亲和性（session affinity）。配合提示词缓存，这些技术降低了延迟，同时一旦某个 worker 出错也很容易恢复。

推理强度（reasoning effort）、输出长度限制、工具 schema 以及模型与工具之间的往返轮次，同样会影响对话何时收到有用的结果，我们也调整了这些杠杆以获得更快的响应。通过把委派路径上所需的工作量降到最低，我们让语音模型能够快速整合来自前沿模型的结果。

从连续语音中提取离散回合

尽管语音模型在连续的语音流上运行，但围绕它的许多系统仍然在「用户轮次」和「助手轮次」上运作，包括 ChatGPT 的对话 UI，以及我们分析和安全基础设施的一部分。所以应用服务器要把这段相互重叠、偶尔含糊不清的对话拆解成一条条离散的消息。

随着音频不断到达，服务器利用部分转录文本和时序信号来推断当前是哪位说话者在主导，并构建一个消息队列。最新的一条消息始终保持临时状态，它的文本、时间和说话者归属都可能随着更多语音到来而改变。一旦某位说话者持续占据主导足够长的时间，归属判断变得可靠，服务器就会把对应的消息最终确定下来。

说话者的重叠让这件事变得更复杂。当用户正在说话时，助手一句简短的回应（比如「嗯哼」或「好的」）不一定要单独成为一条消息；但助手一次有实质内容的插话往往就应该成为一条。类似地，即便用户在中间插话，我们也会优先保证所显示的助手回复连贯一致。

任何分段策略都要在「新鲜度」和「确定性」之间做取舍。提交太早，会让历史记录碎片化、顺序不稳定；等得太久，又会拖延转录文本以及依赖它们的特性。因此，系统维护着两种相关但不同的对话视图：一个是当前状态的推测性视图，另一个是「说过什么」的权威记录。应用 UI 中的对话视图能够处理更新，所以使用的是推测性视图；但写入分析流水线则需要一份最终转录。

这样一来，ChatGPT 的其余部分就能拥有对这段交流的稳定视图，而又不必把轮次机制强加到实时语音路径上。

用更快的协议启动会话

响应速度从用户点击按钮的那一刻就开始了。在 GPT-Live 中，系统必须先建立媒体路径并开始把音频送入模型，对话才能真正开始。这意味着启动序列里的每一个环节都处在关键路径上。

如前所述，WebRTC 提供了强大的实时基础，但启动一个标准的 WebRTC 会话需要数量惊人的协议握手和网络往返。WebRTC 早于那种「尽量减少往返」的设计理念，而正是这种理念塑造了 QUIC 等后来的协议。结果是，当它的底层协议被组合在一起使用时，有时会重复做功。例如，每个协议都内置了自己的反 DoS 机制，即便在整个 WebRTC 协议栈的上下文中并不需要。

我们分析了整个协议栈，并开发了 WebRTC Abridged Roundtrip Protocol（WARP），把媒体和数据的启动从六次网络往返减少到一次。WARP 通过一组向后兼容的协议改进做到了这一点：把 DTLS 握手搭载在 ICE 之上（SPED），使用更快的 DTLS 1.3 握手，预先协商 SCTP 握手（SNAP），以及预先协商数据通道而不是使用 DCEP。

我们与 WebRTC 社区的合作者一起，把 WARP 设计成一组开放规范，让更广泛的生态都能从中受益。我们正在通过 IETF 的 TSVWG 工作组推进这些提案，WARP 的支持也已经加入到 libwebrtc 和 Pion 中，其他 WebRTC 实现也在跟进。

在优化了媒体握手之后，还有一个延迟环节格外显眼：信令交换。它用于在 WebRTC 建立连接之前共享 SDP 参数。为了把这段交换从关键路径上移走，我们开发了一套名为 Instant Connect 的方案。它能提前协商好这些参数，既不占用服务器容量，也不需要对现有的 WebRTC 实现做任何改动。

Instant Connect 与标准的信令流程并行运行。如果预先协商的参数有效，服务器就可以在第一个媒体数据包到达时就把会话实例化。如果参数已经过期或失效，信令流程此刻也已经在进行中，客户端可以无额外延迟地回退到标准流程。

Instant Connect 与 WARP 一起，大幅缩短了从「用户意图」到「实时媒体流通」的时间。SDP 交换离开了关键路径，WARP 又压缩了传输握手，客户端现在只需一个 UDP 数据包就能启动一次会话。服务器可以立即响应，让系统的其余部分开始做用户真正关心的事：聆听和回应。

用真实数据在生产环境安全地测试 GPT-Live

一套系统在纸面上可能很快，但在真实的语音流量下却可能卡顿。在让 GPT-Live 与用户正式对话之前，我们进行了一次静默测试（silent test），把一小部分（并逐步增加）的生产 ChatGPT Voice 会话路由到现有的 Advanced Voice Mode 体验和新系统。Advanced Voice Mode 照常为用户提供服务，而影子路径则以只读模式运行推理。这把系统暴露在真实的客户端、网络、会话时长和地理分布下，却不会改变用户听到的内容。

最早的教训之一是，容量不能简单地等同于 GPU 吞吐量。语音会话会一直保持开启并持续发送数据帧，所以 CPU 侧的流处理器、队列和网络路径都必须和推理一起扩展。在真实负载下，一个配套组件比负载测试预估更早达到饱和，导致推理请求堆积、延迟层层叠加。我们把容量问题从「一块 GPU 能处理多少请求？」改成了「系统在保证每一帧按时送达的同时，能维持多少并发会话？」

这次测试也让地理位置成为了一等（first-order）考量。把一次会话路由到远处的算力，会在启动和流式传输的多个节点引入延迟。我们开始把模型发布、区域容量和流量调度配置放在一起验证，并按来源地区拆解延迟。把推理挪到离用户更近的地方确实有帮助，但同时也印证了那个更广泛的教训：端到端的响应速度取决于路径上的每一个服务，而不只是模型服务器。

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

最后，生产测试倒逼我们改进了可观测性和发布控制。我们发现一些指标把不同来源的延迟混在一起，一些仪表盘上的聚合数据掩盖了单个不健康的引擎，测试系统和线上系统之间还存在配置漂移。作为应对，我们增加了更细粒度的遥测、针对已知良好配置的校验、分阶段的放量，以及快速隔离或禁用单条路径的能力。这次静默测试成了一场提前进行的上线演练，不仅检验系统能承受多少流量，更检验我们能多快地发现、遏制故障并从中恢复。

从客户端到模型，全程响应

把 GPT-Live 带到 ChatGPT 的规模，需要围绕一个根本原则构建一套全新系统：语音必须流动起来。流式推理让全双工模型始终有音频可处理；专用的媒体路径保证帧可靠送达；异步委派让更深度的思考并行运行；优化的传输则让体验一路灵敏地传递到用户。

GPT-Live 背后的架构正在成为更广泛的实时交互平台。它驱动着 ChatGPT Voice 从对话扩展到 Agent 协调，也将支撑即将推出的 GPT-Live API。随着时间推移，它将让语音体验跨越更多设备、应用和模态，同时不牺牲那种让语音对话感觉「实时」的即时性。

如果这正是你想解决的工程问题，欢迎加入我们。