OpenAI 详解 GPT-Live 实时语音系统架构

对于语音 AI 来说，知道何时开口比听上去要难得多。人类能轻松地在瞬间完成话轮交接，但此前的语音 AI 系统跟不上这种节奏。它们基于轮次的架构依赖一个被称为“话轮检测器”的小模型：猜太早，用户会被打断；猜太晚，响应又显得迟缓。只有当检测器做出判断后，大语言模型才开始工作。

GPT-Live 是 OpenAI 的第三代语音系统，它把话轮检测器从音频路径中移除。其语音模型采用全双工设计，可以同时听和说，对话也因此更自然即时。需要更深层推理或工具调用时，GPT-Live 还能请求 GPT-5.5 等前沿模型，且不会打断对话。

为了大规模交付这种体验，OpenAI 构建了一套面向低延迟优化新架构。与典型的请求-响应推理不同，它把输入音频直接流式送入语音模型，再把输出语音流式传回用户，同时通过另一条异步路径处理委派任务。过去六个月，OpenAI 重构了模型推理、上下文管理和媒体传输。新架构还在核心语音路径与应用逻辑之间建立了清晰边界，方便自定义应用行为而不影响响应速度。ChatGPT Voice 中控制电脑、协调多个 AI 智能体等新能力都建立在这套架构之上。

从轮流说话到流式交互

早期语音架构继承了大语言模型的轮次特性，只是每一轮变成一段音频。在级联系统中，语音转文字、大模型、文字转语音依次串行执行，不仅增加延迟，还丢失了语气和节奏等线索。语音到语音模型直接处理音频，改进了这一点，但系统仍依赖话轮检测器决定何时开始推理。GPT-Live 则让语音模型掌控对话：音频持续流入流出，深度推理和工具调用异步进行，系统的核心任务是维持一个不间断的媒体循环。

连续的推理

保持媒体循环不中断并不容易。传输、处理或推理中的任何延迟都可能变成明显停顿。OpenAI 此前就已经重建了语音基础设施，将音频直接流式传入系统。GPT-Live 进一步把媒体直接流式送入模型，基于全新的有状态推理系统实现连续对话。

一个关键设计是分离媒体流与应用逻辑。音频通过专用快速通道在客户端和语音模型之间传输；委派、工具调用等工作在异步 RPC 边界之后进行，一个缓慢的工具调用不会拖住媒体流。媒体前端和推理逻辑用 Go 编写，取代了之前的 Python asyncio 实现，帧传输平滑度显著提升，新系统 p95 延迟达到旧系统 p50 的水平。传输方面，WebRTC 提供了低延迟媒体基础，能应对丢包和时钟漂移，系统通过最小化缓冲实现了亚秒级响应。

让有状态会话持续进行

有状态推理也有运维上的取舍。语音会话可能持续很久，上下文不断增长，模型实例需要动态伸缩。OpenAI 构建了跨实例的无缝切换机制：先预热新实例，用当前上下文预填，并行推理，等新实例就绪后再切换。同一机制也用于动态上下文压缩。长时间对话的上下文最终会超出模型限制，而压缩会使 KV 缓存失效。OpenAI 把压缩也当作一次受控切换：原模型实例继续对话，系统在后台压缩上下文并准备新实例，就绪后无感切换，长对话因此可以持续进行。

委派时不阻塞对话

GPT-Live 调用前沿模型，将“说话”和“思考”解耦。要让双模型架构像一个系统，需要解决两个问题：委派结果必须足够快返回，同时系统其他部分需要离散消息，因此必须把连续会话表示为它们能理解的形式。

为了让委派足够自然，OpenAI 优化了从路由、提示处理到推理、工具调用的完整链路。一个关键优化是提前准备前沿模型和工具：语音会话开始时，应用服务器就为前沿模型创建推理会话，并用初始上下文预填。随后整个会话期间保持该会话可用，并使用稳定会话亲和性，配合提示缓存降低延迟。推理强度、输出限制、工具定义和模型与工具的来回调用也会影响结果到达时间，OpenAI 逐一调整了这些参数。

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

虽然语音模型处理的是连续语音流，但 ChatGPT 的对话界面、分析和安全设施仍依赖离散话轮。应用服务器把重叠且有歧义的对话切分成消息，利用部分转写和时间信号判断当前说话者，构建消息队列。最新消息是暂定的，其文本、时间和说话者归属都可能随更多语音到来而变化。语音重叠时，助手在用户说话过程中的简短回应（如“嗯”“好”）不会独立成消息，实质性插话则应当独立。每条切分策略都在新鲜度和确定性之间权衡。系统因此维护两种会话视图：一个推测性的当前状态视图和一个权威的最终记录，UI 用推测视图，日志用最终转写。

更快的会话启动协议

响应从点击按钮那一刻就开始了。完整 WebRTC 握手需要大量协议交换和网络往返。OpenAI 设计了 WARP 开放规范，与 WebRTC 社区合作推进 IETF TSVWG 标准化，libwebrtc 和 Pion 已支持。优化媒体握手后，剩余延迟来自连接前的 SDP 参数信令交换。OpenAI 开发了 Instant Connect，提前协商参数，且不预留服务器容量、无需改动现有 WebRTC 实现。如果预协商参数有效，服务器收到第一个媒体包时即可创建会话；如果参数过期，则回退到标准流程。结合 WARP，客户端现在只需发送单个 UDP 数据包即可启动会话。

用真实流量安全测试

系统在纸面上可能很快，真实流量下却可能停顿。OpenAI 在让 GPT-Live 与用户对话前做了静默测试：将少量生产 ChatGPT Voice 会话逐渐分流到新系统，以只读模式运行推理，用户听到的仍是原有体验。

测试的第一课是容量不能只看 GPU 吞吐量。语音会话保持打开并持续发送帧，CPU 端流处理器、队列和网络路径必须与推理同步扩展。地理因素同样重要，OpenAI 将模型发布与区域容量、流量调度一起验证，并按来源地区拆分延迟。其他故障只在真实会话生命周期中暴露：长时间会话带来内存和持久化压力；重连考验压缩与状态恢复；普通断开暴露了关闭握手的竞争条件。最后，生产测试还迫使 OpenAI 改进可观测性和发布控制，增加更精细的遥测、配置校验和分阶段发布。

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

GPT-Live 能扩展到 ChatGPT 规模，是因为围绕一个基本原则构建了整套新系统：语音必须流动。流式推理保证全双工模型持续获得音频；专用媒体路径保证帧传递可靠；异步委派让深度思考并行进行；优化的传输协议让体验始终保持响应。这套架构正在成为实时交互的基础平台，支撑 ChatGPT Voice 从对话扩展到智能体协调，也将成为未来 GPT-Live API 的底座。

---

原文链接：OpenAI Blog
本文由前途科技编辑整理