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