OpenAI 重塑 WebRTC 架构 实现语音 AI 低延迟全球部署

OpenAI 公布重构 ChatGPT Voice 与 Realtime API 底层通信栈的工程方案。团队为应对超 9 亿周内活跃用户带来的规模挑战，放弃原生单会话单端口模式，转向 Split relay 结合 transceiver 的新型设计。这构成了 OpenAI WebRTC 架构改造 的核心路径，旨在兼顾标准协议兼容性与云端状态管理效率。

架构选型权衡：SFU 模式与 Transceiver 路线对比

WebRTC 为实时 AI 交互提供了经过广泛验证的底层标准，涵盖用于 NAT 穿越的 ICE、用于加密传输的 DTLS 与 SRTP，以及编解码协商机制。对于 ChatGPT 这类大多为单用户一对一交互的应用，OpenAI 团队评估了两条技术路线。传统的 SFU（选择性转发单元）模式要求 AI 作为独立参与者加入会话，这种方案在处理多人会议等原生多端场景时表现出色，并能集中处理策略与录制。针对低延迟敏感与单向交互为主的负载分布，团队最终选择了 Transceiver 模式。在该模式下，WebRTC 连接在边缘层完全终止。边缘服务将媒体流与事件转换为简化的内部协议，直接对接后端的推理、语音合成与工具调用管线。这种设计剥离了推理后端对 WebRTC Peer 状态的依赖，使其能够以常规微服务的形态弹性伸缩。

OpenAI WebRTC 架构改造 应对 Kubernetes 部署瓶颈

架构设计确定后，工程团队面临的核心约束在于如何将 Transceiver 服务平稳运行于 Kubernetes 环境。原生 WebRTC 强依赖大范围的公网 UDP 端口来隔离会话，这与 Kubernetes 的网络调度逻辑存在根本冲突。在大规模并发场景下，暴露数万端口不仅增加负载均衡配置与审查复杂度，还会显著扩大外部攻击面。此外，Kubernetes 频繁的 Pod 调度与扩缩容操作会导致端口分配断裂，破坏系统弹性。为解决这一困境，团队采用了单端口接收策略。该策略仅暴露固定的少量公网 UDP 地址，但必须确保同一 WebRTC 会话的所有数据包始终由同一个处理实例接管。ICE 检查与 DTLS 握手等状态保持需求迫使系统在负载均衡器后方设计确定性路由，确保流量精准落入拥有该会话实例的 Pod 中。

基于 ufrag 的中继路由与全球就近接入

最终落地的工程方案将协议终止与包转发彻底解耦。团队构建了轻量级 relay 层与状态保持型 transceiver 层。Relay 仅解析 STUN 保活报文中的 ufrag，提取其中封装的路由提示后，将原始数据流无状态地转发给目标 transceiver。Transceiver 接收数据后，仍将其视为标准 WebRTC 流进行完整处理。该路由机制无需引入外部查询服务作为冷路径依赖。首个数据包的 STUN 请求携带 ufrag 即直接决定转发目标。后续数据包依托操作系统级别会话表直接透传。Relay 状态表保持极简，若发生服务重启，流量丢失的恢复时间仅限于下一次 STUN 请求到达。针对全球延迟问题，团队结合了 Cloudflare 的地理位置路由分发信令。客户端初始握手就近接入，SDP 响应返回 Global Relay 地址，确保媒体流同样在全球网络边缘就近入网，显著降低首跳延迟与抖动。

内核旁路之外的传输层与调度优化路径

在传输层优化路径的选择上，团队放弃了引入高复杂度的内核旁路框架，而是通过精细的用户态 Go 语言实现满足性能需求。Relay 代码库刻意保持窄化设计，不终结任何 WebRTC 协议栈，仅维持流级别的无状态映射并执行内存级转发。为了最大化单节点吞吐量，系统启用了 Linux 的 SO_REUSEPORT 特性，允许同一 UDP 端口被多个工作进程同时绑定，由内核分配入网流量以避免单线程瓶颈。结合 runtime.LockOSThread 将读取数据的协程固定于特定操作系统线程，该方案保障了同一数据流向持续命中相同的 CPU 核心，大幅提升缓存命中率。此外，预分配缓冲区与低拷贝读取机制有效抑制了 Go 语言垃圾回收产生的暂停延迟。这套轻量架构最终满足了 ChatGPT 语音交互对全球规模与极低延迟的需求。结语： OpenAI WebRTC 架构改造 的经验表明，在大规模实时推理场景中，将协议状态收敛至单一边缘组件、在数据包头部寻找确定性路由线索，是解耦云原生弹性与低延迟传输的有效手段。此类面向极致首字延迟与全局稳定性的基础设施优化，将为下一代实时多模态交互提供更坚实的底层支撑。