近期，OpenAI 发布了一份 GPT-Live 工程报告，详细拆解了这套系统的设计思路。其核心策略是将对延迟敏感的媒体处理链路与更广泛的应用工作负载剥离开来，同时保证语音会话不会中断。实时路径由媒体处理管道和推理循环构成，而任务委派、工具调用、数据持久化以及其他应用逻辑，则全部排在异步 RPC 边界之后执行。
这一设计折射出实时人工智能应用要面对的根本矛盾：哪怕其他操作存在可变延迟，或者不得不依赖外部服务，对话本身也必须保持响应速度。OpenAI 的报告还提到，系统为每个会话提供了专用的有状态推理机制。会话会在分配到的实例上预留计算资源，一旦资源耗尽或逼近上下文上限，该会话的上下文就能迁移到另一个实例继续运行。
在媒体传输层面，OpenAI 依旧把 WebRTC 作为基础框架，同时推出了 WebRTC Abridged Roundtrip Protocol（WARP）优化方案和即时连接机制，用来压低服务启动延迟。正式上线之前，团队还做了一次静默测试：接收真实的入站语音流量，但生成的结果直接丢弃。据 OpenAI 介绍，这种测试方式暴露了合成测试此前没能覆盖的、与负载相关的异常行为。
OpenAI 实时人工智能负责人 Justin Uberti 接受了 InfoQ 的采访，就这套架构及其运营层面的权衡做了进一步说明。
InfoQ：GPT-Live 通过异步边界把对延迟要求极高的媒体路径和应用逻辑拆开了。你们是怎么划定这条边界两侧内容的？哪些产品功能最难与实时交互路径解耦？
Justin Uberti： 我们很清楚，要达到延迟目标，媒体传输的连续性绝不能断——说白了，就是"语音必须畅通无阻"。所以我们的原则很直接：实时路径只跑媒体管道和推理循环，其余所有内容，包括任务委派、工具使用、数据持久化以及其他应用逻辑，都放到异步 RPC 边界之后。这样的架构选择让我们能把优化精力集中在最关键的组件上，也避免了对时间不敏感的工作拖累整体性能。
话虽如此，我们仍会关注把任务交给前沿模型的速度能有多快，同时也得重新思考语音数据如何接入安全系统。这些组件各自都需要专门的工程投入，但单独优化它们，远比把它们绑在关键路径上一起优化要轻松得多。
InfoQ：连续语音对话本质上是有状态的，但系统又必须可扩展、能从故障中恢复。你们采用了什么样的架构方案来管理会话状态？这又给可用性、弹性和运维复杂度带来了什么影响？
Justin Uberti： 关键决策在于采用有状态的专用推理机制，同时允许在必要时把会话上下文实时迁移到新的模型实例上。每个会话都会在分配的实例上预留容量，但当某个实例正在释放资源，或者某个会话快要撞上上下文限制时，我们可以把新会话引导到有可用容量的实例，并迁移现有会话。这样一来，我们就获得了运维上需要的灵活性，能够按实际需求动态调整实例数量。
InfoQ：你们保留了 WebRTC，但引入了 WARP 和 Instant Connect 来降低启动延迟。在扩展 WebRTC 协议栈之前，你们有没有考虑过更新的传输标准或其他替代方案？最终是哪些互操作性和运营上的权衡促成了这个选择？
Justin Uberti： WebRTC 提供了一套经过实战检验的低延迟媒体协议栈，内置了错误恢复能力。虽然我们认为 RIP over QUIC 这类尝试很有前景，但这些协议目前只解决了传输层的问题，并不是完整的媒体管道。即便是传输层，也还缺一些关键能力，比如 GCC 拥塞控制和基于 RTT 的路径选择。
所以我们的判断是：简化 WebRTC 的握手流程，比在客户端和服务器端同时替换传输层更简单，风险也更低。WARP 的每一项改进——SPED、DTLS 1.3 和 SNAP——都可以独立部署，这让我们能够逐项测试效果并验证收益。更重要的是，现有的 WebRTC 应用不需要改任何代码就能享受这些好处，对整个生态来说这是实打实的加分项。归根结底，我认为 WebRTC 会越来越像 QUIC，反过来也一样。到那时，你就不必在两者之间做选择了。
InfoQ：静默测试把生产环境的语音会话镜像分流到 GPT-Live，同时不改变用户听到的内容。哪些架构机制保证了这种测试的安全性和场景代表性？它又暴露了哪些传统负载测试发现不了的故障模式？
Justin Uberti： 我们设计静默测试的方式，是让应用服务在只读模式下运行，而且不使用用户凭据。传入的语音数据会送进模型，但输出结果直接丢弃。这样我们就能用真实语音流量来压测媒体循环和推理服务，同时对客户体验零影响。
与通常依赖预录或合成语音的传统负载测试不同，静默测试捕捉到了真实语音会话的多样性和地理分布特征。它帮我们发现了系统在高负载场景下的性能下降问题，而这些情况是合成测试根本测不出来的。我们通过有针对性的优化和错误修复解决了这些问题。举个例子，在某些区域，部分 GPU 与给它喂数据的 CPU 并不在同一个机房，结果带来了意料之外的延迟。利用正式环境的真实生产流量来验证这些修复方案，让我们更有把握它们在正式上线当天能够稳定运行。
原文链接：https://www.infoq.com/news/2026/09/openai-gpt-live/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
发表于 1 小时前
|
查看: 5|
回复: 0
