2026年8月3日 · 工程 / 公司
作者：技术团队成员 Justin Uberti 和 Zahan Malkani
对语音 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 能调用现有前沿模型，因此能力十分强大，实际上将"说话"与更深入的"思考"解耦开来。但要让这种双模型架构呈现为一个统一系统，需要解决两个相关的工程问题。
委托更深入的工作
GPT-Live 提供快速、自然的响应，同时由 GPT-5.5 在后台处理搜索任务
User → GPT-Live-1 → GPT-5.5 → Search + reason → 转录文字稿
使用 GPT-5.5 Instant 的 GPT-Live-1 对话示例
首先，结果必须足够快地返回，才能在正在进行的对话中发挥作用。因此，从路由、提示处理到推理和工具调用，我们必须最大限度降低整条委派路径的延迟。与此同时，产品中的其他系统仍需要离散消息，因此我们必须将持续对话表示为它们能够理解的形式。
---
让委派快到如同自然对话
发出委派任务后，我们会重点优化前沿模型产出对当前对话有用内容所需的时间。当前沿模型进行推理或使用工具时，语音模型可以短暂维持交流，但无法掩盖任意漫长的响应延迟。因此，我们将整个委派循环——路由、提示处理、推理和工具调用——都纳入响应时间预算。
第一项优化，是在请求委派之前准备好前沿模型及其所需的所有工具。语音会话开始时，应用服务器会为前沿模型创建推理会话，并使用初始对话上下文进行预填充，确保在第一个委派请求发出前已完整处理提示。
随后，我们会在整个语音对话期间保持该推理会话可用，并为连续请求采用稳定的会话亲和性。这些技术与提示缓存结合使用，既能改善延迟，也能轻松从工作节点故障中恢复。
推理强度、输出限制、工具架构以及模型与工具间的往返也会影响对话获得有用结果的时间，因此我们调整了这些因素来加快响应。通过尽量减少委派路径上的工作量，我们让语音模型能够迅速整合前沿模型返回的结果。
从连续语音中提取离散轮次
尽管语音模型处理的是连续语音流，周边许多系统仍以用户和助手的轮次为单位运行，包括 ChatGPT 的对话界面，以及部分分析和安全基础设施。因此，应用服务器会梳理彼此重叠、偶尔含义不明的对话，将其拆分为离散消息。
音频到达时，服务器会利用部分转写和时间信号来推断当前由谁发言，并构建消息队列。最新消息仍是暂定的；随着更多语音到达，其文本、时间和说话者归属都可能改变。当某位说话者持续发言的时间足以确保归属可靠后，服务器便会确定相应消息。
多人同时说话会让情况更加复杂。用户说话时，助手简短回应一句（例如"嗯哼"或"好的"），不一定要单独成为一条消息。但助手插入的实质性内容通常应该单独成条。同样，即使用户中途开口，我们也会优先确保显示的助手回复连贯。
任何分段策略都必须在时效性与确定性之间取舍。过早确定会产生碎片化的历史记录和不稳定的顺序；等待太久则会延迟转写及依赖转写的功能。因此，系统会维护两个相互关联的对话视图：反映当前状态的推测视图，以及记录实际对话内容的权威版本。应用界面中的对话视图可以处理更新，因此采用推测视图。但向分析管道写入日志时，需要最终转写文本。
这样，ChatGPT 的其他部分便能稳定地了解对话内容，而不必让实时语音路径受轮次机制约束。
---
使用更快的协议启动会话
用户点击按钮的那一刻，快速响应就已经开始。使用 GPT‑Live 时，系统必须先建立媒体路径并开始将音频送入模型，对话才能开始。这使启动流程的每个环节都位于关键路径上。
如上所述，WebRTC 提供了强大的实时基础，但启动标准 WebRTC 会话需要执行数量惊人的协议握手和网络往返。WebRTC 出现得较早，并未受到后来塑造 QUIC 等协议的"尽量减少往返"理念影响。因此，其底层协议结合使用时，有时会重复执行相同工作。例如，每个协议都有自己的抗 DoS 机制，即使在完整 WebRTC 栈中并不需要。
我们分析了该协议栈，并开发出 WebRTC 精简往返协议（WARP），将媒体和数据的启动过程从六次网络往返减少到一次。WARP 通过一组向后兼容的协议改进实现这一点：在 ICE 上捎带 DTLS 握手（SPED）、使用更快的 DTLS 1.3 握手、预协商 SCTP 握手（SNAP），以及预协商数据通道而非使用 DCEP。
我们与 WebRTC 社区的合作者共同将 WARP 设计为一组开放规范，使更广泛的生态系统也能从中受益。我们正通过 IETF 的 TSVWG 工作组推进这些提案；libwebrtc 和 Pion 均已加入 WARP 支持，其他 WebRTC 实现也在推进相关工作。
优化媒体握手后，还有一项延迟格外突出：WebRTC 建立连接前，用于共享 SDP 参数的信令交换。为了将这项交换移出关键路径，我们开发了名为 Instant Connect 的机制。它会提前协商这些参数，无需预留服务器容量，也无需改动现有 WebRTC 实现。
Instant Connect 与标准信令流程并行运行。如果预协商参数有效，服务器可以在收到第一个媒体包时创建会话。如果参数已过期或无效，信令流程也已在进行，因此客户端可以回退，且不会增加额外延迟。
Instant Connect 与 WARP 相结合，大幅缩短了从用户产生意图到实时媒体开始流动的时间。SDP 交换移出关键路径、WARP 精简传输握手后，客户端现在只需发送一个 UDP 包即可启动会话。服务器可以立即响应，让系统的其余部分开始完成用户真正关心的工作：倾听并回应。
---
使用真实数据在生产环境中安全测试 GPT‑Live
一个系统在纸面上可能很快，但面对真实语音流量时仍可能卡顿。在让 GPT‑Live 与用户对话之前，我们进行了一次静默测试，将一小部分生产环境中的 ChatGPT 语音会话同时路由至现有的高级语音模式体验和新系统，并逐步提高这一比例。高级语音模式继续照常为用户提供服务，而影子路径则以只读模式运行推理。这样既能让系统面对真实的客户端、网络、会话时长和地域分布，又不会改变用户听到的内容。
我们最先得到的经验之一是，不能仅用 GPU 吞吐量来衡量容量。语音会话会保持连接并持续发送帧，因此 CPU 端的流处理程序、队列和网络路径必须与推理能力同步扩展。在真实负载下，一个辅助组件比负载测试预测的更早达到饱和，导致推理请求积压，延迟不断叠加。我们将容量问题从"一块 GPU 能处理多少请求？"改为"在确保每一帧都按时处理的前提下，系统能维持多少个并发会话？"
这项测试也让地域成为首要考量。将会话路由到较远地区的容量资源，可能在启动和流式传输的多个环节增加延迟。我们开始结合区域容量和流量调度配置来验证模型发布，并按流量来源地域细分延迟。将推理移至更靠近用户的位置确实有所帮助，但也进一步印证了一个更广泛的经验：端到端响应速度取决于路径上的每项服务，而不只是模型服务器。
还有一些故障只会在真实的会话生命周期中出现。长时间运行的会话暴露出内存和持久化压力。重新连接会对压缩和状态恢复机制形成考验。普通的客户端断开连接暴露了关闭握手中的竞态问题。这些问题在短时负载测试中很少出现，因为它们取决于时间、累积状态以及跨服务边界的行为。
最后，生产环境测试促使我们改进了可观测性和发布控制。我们发现，有些指标混淆了不同的延迟来源，有些仪表板的汇总数据掩盖了个别异常引擎，测试系统与已部署系统之间还存在配置偏差。为此，我们增加了更细粒度的遥测、基于已验证配置的校验、分阶段放量，以及快速隔离或停用单条路径的能力。这次静默测试成为发布前的一次预演：它不仅检验系统能承载多少流量，也检验我们能多快地发现、控制故障并从中恢复。
---
从客户端到模型，始终快速响应
要让 GPT‑Live 达到 ChatGPT 的规模，需要围绕一项基本原则构建全新系统：让语音持续流动。流式推理持续向全双工模型输送音频。专用媒体路径确保音频帧可靠送达。异步委派让更深入的思考能够并行进行。经过优化的传输机制让用户全程获得快速响应的体验。
GPT‑Live 背后的架构已开始发展为更广泛的实时交互平台。随着 ChatGPT 语音从对话扩展到智能体协同，该架构为其提供支持，也将成为即将推出的 GPT‑Live API 的基础。随着时间推移，它将使语音体验覆盖更多设备、应用和模态，同时保留让语音对话如同实时交流般自然的即时性。
如果你也想解决这类工程问题，欢迎加入我们。