OpenAI 如何构建大规模低延迟语音 AI 的 WebRTC 架构

事件概述

OpenAI 工程团队近期公开了其大规模语音 AI 系统背后的 WebRTC 架构设计。为了满足超过 9 亿周活跃用户的实时语音交互需求，团队放弃了传统 WebRTC 的每会话一端口模式，转而构建了一套“中转 (Relay) + 收发器 (Transceiver)”架构，以适配 Kubernetes 环境并保证低延迟和会话稳定性。

核心信息

• 架构选择：OpenAI 评估了两种媒体架构。对于 1:1 的用户-模型对话场景，他们选择了收发器模型——边缘服务终止 WebRTC 客户端连接，再将媒体和事件转换为内部协议用于推理、转录、语音生成等，而不是采用通常用于多方通话的 SFU（选择性转发单元）。
• 部署挑战：传统 WebRTC 每会话独占一个 UDP 端口的方式在 Kubernetes 中面临两个问题：
  • 端口耗尽：高并发下需要大量公共 UDP 端口，而云负载均衡器和 Kubernetes 服务难以管理，且手动扩缩容时端口范围固定，限制弹性。
  • 状态粘性：ICE 和 DTLS 是有状态协议，要求同一会话的所有包到达同一个进程；而在负载均衡的集群中，首个包可能落到错误的实例上。
• 解决方案：OpenAI 实现了中转 + 收发器架构：
  • 中转 (Relay)：在全球多个边缘位置部署轻量级 UDP 中继，每个中继只使用一个公共 UDP 端口，通过 ICE 凭证进行路由，将包分发到正确的收发器进程。
  • 收发器 (Transceiver)：终止 WebRTC 连接，处理信令和媒体，并与后端推理服务通信。
• 技术细节：使用 ICE 凭证（用户名和密码）作为路由键，确保包始终到达同一会话所属的收发器。全球部署的中继节点配合地理导向的信令，减少了首跳延迟。
• 性能结果：这一架构在生产中稳定运行，支撑了 ChatGPT 语音、Realtime API 等产品，提供了低抖动、低丢包率的媒体传输。

值得关注

OpenAI 的方案表明，在大规模实时 AI 产品中，将 WebRTC 终止于边缘并采用自定义路由逻辑，比直接使用标准 WebRTC 设施更适合云原生环境。这种设计思路对面临类似高并发、低延迟需求的团队具有参考价值。