OpenAI 如何为 9 亿用户构建低延迟语音 AI：WebRTC 架构深度解析

原文来源：OpenAI Engineering Blog — OpenAI 工程团队详解如何重构 WebRTC 堆栈，支撑超 9 亿周活用户的实时语音 AI 体验。

一、背景：语音 AI 的工程挑战

2026 年 5 月，OpenAI 工程团队发表了一篇深度技术文章，揭示了他们如何为 ChatGPT Voice、Realtime API 和 Agent 工作流提供低延迟语音服务的架构方案。

当前 OpenAI 服务着 超过 9 亿周活跃用户，语音交互对延迟有着严苛的要求：

快速连接建立 — 用户启动会话后应能立即开始说话
低且稳定的媒体往返时间 — 低抖动、低丢包、清晰的轮换
全球覆盖 — 世界各地的用户都能获得一致体验

这些要求听起来简单，但在这种规模下，WebRTC 的工程挑战急剧放大。

—— 广告 ——

二、WebRTC 基础

WebRTC 是一个开放标准协议栈，提供了实时通信的核心能力：

ICE — NAT 穿透与连接性检查
DTLS + SRTP — 加密传输
编解码协商 — 选择压缩/解压缩算法
RTCP — 质量控制、抖动缓冲、回声消除

对于 AI 语音场景，WebRTC 的独特价值在于支持持续的音频流——模型可以在用户还在说话的同时进行转录、推理、调用工具或生成语音，实现自然对话所必需的无缝轮换。

三、架构选型：Transceiver 胜出

OpenAI 评估了两种架构方案：

方案	优点	缺点
SFU（选择性转发单元）— AI 作为一个参与者加入	适合多人场景（群聊、课堂）	对 1:1 会话过于复杂
Transceiver — 边缘节点终结 WebRTC，转换为内部协议	专为 1:1 会话优化；后端服务像普通服务一样伸缩	需要构建自定义路由层

最终选择了 Transceiver 模型，因为绝大多数语音会话都是 1:1（用户↔模型）。Transceiver 负责所有 WebRTC 状态（ICE、DTLS、SRTP 密钥、会话生命周期），后端服务（推理、转录、语音生成）不再是 WebRTC 对等体。

四、核心挑战：在 Kubernetes 上运行 WebRTC

OpenAI 的第一版实现是一个基于 Pion（Go 语言 WebRTC 库） 构建的单一 Go 服务，同时处理信令和媒体终结。这个服务支撑着 ChatGPT Voice、Realtime API WebRTC 以及研究项目。

但这个架构在 K8s 上遇到了两个核心问题：

问题 1：端口耗尽

每个 WebRTC 会话需要一个 UDP 端口。这意味着单台服务器需要开放数万乃至数十万个 UDP 端口。

云负载均衡器和 Kubernetes 都不是为管理大范围 UDP 端口设计的
安全风险增大，攻击面过大
自动伸缩变得脆弱——Pod 必须预留和通告稳定的端口范围

问题 2：状态粘性

ICE 和 DTLS 是有状态的——数据包必须到达创建会话的进程。即使通过单个共享套接字减少了端口数，但如何跨负载均衡集群路由到正确的实例仍然是难题。

方案	优点	缺点
每会话独立 IP:端口	路径直接	端口范围过大，K8s 兼容性差
每服务器独立 IP:端口	占用空间更小	仍需确定性路由到正确实例
TURN 中继（协议终结）	集中策略控制	增加设置延迟，恢复困难
无状态转发器 + 有状态终结器（OpenAI 方案）	UDP 占用极小，Transceiver 拥有完整会话	增加一跳路由，需要自定义协调

五、OpenAI 的方案：Relay + Transceiver

核心思路是将数据包路由与协议终结分离：

Relay（中继） — 轻量级 UDP 转发器，公共暴露面极小
Transceiver（收发器） — 有状态的 WebRTC 端点，运行在 Relay 之后

Relay 不解密媒体、不运行 ICE 状态机、不协商编解码器。它只读取足以决定目的地的数据包元数据，然后转发。

基于 ICE 凭据的路由

每个 WebRTC 会话在建立期间会交换一个 ICE 用户名片段（ufrag）——一个短标识符。OpenAI 在服务端生成的 ufrag 中嵌入了路由元数据（集群 ID + Transceiver ID）。

连接流程：

客户端通过 HTTP/WebSocket 信令连接到 Transceiver，分配会话状态
Transceiver 在 SDP answer 中返回共享 Relay VIP（如 203.0.113.10:3478）
客户端向该 VIP 发送第一个 STUN 绑定请求
Relay 解析 STUN 数据包，读取 ufrag，解码路由提示，转发到对应的 Transceiver
Relay 创建内存中的会话映射 <客户端 IP:端口 → Transceiver IP:端口>，后续的 DTLS、RTP、RTCP 数据包无需再次解码
Redis 缓存 保存该映射，以便 Relay 重启后快速恢复

六、优势与工程启示

这个架构方案的精妙之处在于：

极小的公共端口暴露 — 无论有多少用户，Relay 只需要少量公网端口
无状态转发 — Relay 可以随意水平伸缩，不绑定到特定实例
会话隔离 — Transceiver 完全隐藏在内部，不受外部直接访问
容错性强 — Relay 崩溃后可从 Redis 重建映射，Transceiver 崩溃后仅影响其上的会话

七、总结

OpenAI 的 WebRTC 架构重构是一个教科书级的工程案例，展示了如何在不牺牲实时通信性能的前提下，将有状态的协议引入无状态的云原生环境。

对于正在构建语音 AI 产品的团队，这个方案有两个核心启示：

不要为 1:1 场景设计多人方案 — Transceiver 模型远比 SFU 适合 AI 语音场景
将状态推入透明层 — 通过 Relay 将路由和协议终结分离，各自独立伸缩

这篇文章不仅展示了 OpenAI 如何在 9 亿用户的规模下保持低延迟语音体验，也为整个行业的实时语音 AI 架构设计提供了有价值的参考。