OpenAI 详解 GPT-Live 架构如何实现了连续的有状态语音交互

作者 ｜ Eran Stiller

译者 ｜ 平川

最近，OpenAI 发布了一篇 关于 GPT-Live 的工程报告。该报告详细描述了他们如何设计这个系统，将对延迟敏感的媒体处理与更广泛的应用工作分离，同时保持语音交互的连续性。实时路径包含媒体处理管道和推理循环，而任务委托、工具使用、数据持久化及其他应用逻辑则在异步 RPC 边界之后运行。

该设计反映了实时人工智能应用面临的核心挑战：即使其他操作存在可变延迟或依赖外部服务，对话也必须保持响应性。OpenAI 的报告还描述了针对每个会话的专用有状态推理机制。会话会在其分配的实例上预留计算资源，但当资源耗尽或对话达到上下文限制时，其上下文可以迁移至另一实例。

OpenAI 继续将 WebRTC 作为其媒体传输的基础框架，同时推出了 WebRTC Abridged Roundtrip Protocol（WARP）优化方案与即时连接机制，以降低服务启动延迟。在正式上线前，该公司还开展了一项静默测试：处理真实的入站语音流量，但直接丢弃生成的输出内容。据 OpenAI 介绍，这种测试方式发现了合成测试此前未能覆盖的、与负载相关的异常行为。

OpenAI 实时人工智能负责人 Justin Uberti 就该架构及其运营权衡问题接受了 InfoQ 的采访。

InfoQ：GPT-Live 通过异步边界将对延迟要求极高的媒体路径与应用逻辑分离。你们是如何决定该边界两侧分别包含哪些内容的？哪些产品功能最难与实时交互路径解耦？

Justin Uberti：我们知道，要达到延迟目标，就必须确保媒体传输的连续性——简而言之，就是“语音必须畅通无阻”。因此，我们遵循的原则是：实时路径只应该运行媒体管道和推理循环，而其他所有内容——包括任务委派、工具使用、数据持久化及其他应用逻辑——都应在异步 RPC 边界之后进行。这种架构选择使我们能够将优化工作集中在最关键的组件上，并避免对时间敏感度较低的工作所引发的性能退化。

尽管如此，我们还是继续关注将任务委托给前沿模型的速度能有多快，同时也必须重新思考如何将语音数据输入到安全系统中。这些组件各自都需要进行特定的设计工作，但将它们单独优化要比将其作为关键路径的一部分进行优化容易得多。

InfoQ：本质上，连续语音对话是有状态的，但系统必须具备可扩展性并能从故障中恢复。你们采用了什么样的架构方案来管理会话状态？这又对可用性、弹性和运维复杂性产生了怎样的影响？

Uberti：关键决策在于采用有状态的专用推理机制，同时允许在需要时将会话上下文实时地迁移到新的模型实例上。每个会话都会在其分配的实例上预留容量，但当某个实例正在释放资源或某个会话接近其上下文限制时，我们可以将新会话引导至具有可用容量的实例，并迁移现有的会话。这为我们提供了所需的运维灵活性，让我们能够根据需求动态地调整实例数量。

InfoQ：你们保留了 WebRTC，但引入了 WARP 和 Instant Connect 来降低启动延迟。在扩展 WebRTC 协议栈之前，你们是否考虑过更新的传输标准或其他替代方案？又是哪些互操作性和运营方面的权衡促使你们做出了这一选择？

Uberti：WebRTC 提供了一个经过实战检验的、具有内置错误恢复功能的低延迟媒体协议栈。虽然我们认为，像 RIP over QUIC 这样的尝试前景广阔，但这些协议目前仅提供传输层，而非完整的媒体管道。即使在传输层，也仍然存在着一些缺失的功能，例如 GCC 拥塞控制和基于 RTT 的路径选择。

因此，我们认为，简化 WebRTC 的握手过程，比在客户端和服务器端同时替换传输层更为简单，而且风险更低。WARP 的每一项改进——SPED、DTLS 1.3 和 SNAP——都可以独立部署，这使我们能够逐项测试其影响并验证其优势。此外，现有的 WebRTC 应用程序不需要更改任何代码就可以获得这些优势。对于整个生态系统而言，这是一大福音。最终，我认为，WebRTC 将越来越像 QUIC，反之亦然。这意味着你将不需要在两者之间做选择。

InfoQ：这种“静默测试”将生产环境的语音会话镜像分流到 GPT-Live 中，同时不改变用户听到的内容。哪些架构机制确保了这种测试的安全性和场景代表性？它又揭示了哪些传统负载测试无法发现的故障模式？

Uberti：我们设置了这种静默测试，实质上，是让应用服务在只读模式下运行，而且不使用用户凭据。这样，传入的语音数据会被输入到模型中，但输出结果则会被直接丢弃。这使我们能够利用真实的语音流量测试媒体循环和推理服务，同时不会对客户体验造成任何影响。

与通常依赖预录或合成语音的传统负载测试不同，“静默测试”捕捉到了真实语音会话的多样性和地理覆盖范围。它发现了我们的系统在高负载场景下的性能下降问题，而这些情况是我们的合成测试无法测试出来的。我们通过有针对性的优化和错误修复解决了这些问题。例如，在某些地区，部分 GPU 并未与为其提供数据的 CPU 部署在同一机房，从而导致了意外的延迟。通过使用正式环境的真实生产流量对这些修复方案进行验证，使我们可以更加确信它们在正式上线的当天能够稳定运行。

https://www.infoq.com/news/2026/09/openai-gpt-live/

声明：本文为 InfoQ 翻译，未经许可禁止转载。