OpenAI 如何为 9 亿用户提供低延迟语音 AI

OpenAI 每周为 9 亿用户提供语音 AI 服务，底层依赖 WebRTC 协议传输实时音频。文章基于 OpenAI 工程团队公开资料，解析其如何在大规模 Kubernetes 环境中部署 WebRTC，让全球用户获得接近自然对话的语音交互体验。

为什么必须用 WebRTC

语音 AI 与传统文件传输最大的区别在于「连续流」特性：音频必须在用户说话过程中持续到达模型，模型才能在用户还在讲时就启动转写、推理与工具调用。一旦流被打断，体验就会退化成对讲机式的 push-to-talk。

对 OpenAI 而言，这意味着三项硬性约束：

服务必须覆盖每周 9 亿活跃用户，且用户分布全球。
会话建立必须足够快，使用户点开后能立刻开始说话。
音频往返时延必须低且稳定，轮替交互要干脆清晰。

WebRTC 是业界为此类场景打造的协议族，由 ICE、DTLS、SRTP、RTCP 等子协议组成。值得注意的是，WebRTC 的两位核心架构师 Justin Uberti、Pion 维护者 Sean DuBois 目前都在 OpenAI 任职，这一背景也体现在 OpenAI 最终的架构选择上。

Kubernetes 与 WebRTC 的两难

OpenAI 早期方案是用一个基于 Pion 的 Go 服务同时承担信令协商（SDP 交换、编解码选择、ICE 凭据生成）与媒体终结（连接客户端与后端的推理、转写、TTS、工具调用等服务）。这套组合服务支撑了 ChatGPT 语音、Realtime API 的 WebRTC 端点以及若干研究项目。

问题出在部署环节。Kubernetes 把算力假设为廉价且可移动的——Pod 不断被调度、重调度、替换；而传统 WebRTC 部署要求 IP 与端口长期稳定。两套假设在两个具体位置发生冲突：

端口耗尽：传统 WebRTC 部署每路会话占用一个 UDP 端口。OpenAI 规模下单个服务需要数万个公网 UDP 端口，云负载均衡器难以高效管理，且 K8s 自动扩缩容与预留大段稳定端口的需求相冲突。
状态粘性：ICE 与 DTLS 是有状态协议，启动会话的进程必须持续接收同一会话的包，才能完成连通性校验、DTLS 握手、SRTP 解密以及后续的 ICE restart。若包落到另一进程上，建立失败或媒体中断。

拆分：用 ICE ufrag 当路由键

OpenAI 最终的架构将流量处理拆成两块：

无状态中继：地理边缘的协议感知分组路由器，按会话特征转发。
有状态收发器：持有完整 WebRTC 状态、完成加密与媒体终结。

两者的衔接关键在 ICE ufrag——这是握手期间协议原本就要交换的字段，被当作路由键使用。无状态中继只需要读取新建会话的第一个包，就能判断该交给哪个收发器处理。其余的能力——Global Relay、Pion 的 Go 用户态实现、Redis 缓存、socket 层面的优化——都建立在这一核心思路之上。

对用户而言，客户端体验保持不变；对运维而言，计算节点可以像普通 Kubernetes Pod 一样被随意调度，而不必担心会话被中断。

结语

把协议设计中已经存在的字段重新当作控制面信号，是这套架构最值得借鉴的一笔。它让 OpenAI 不用重写互联网处理实时音频的方式，就在 Kubernetes 上把 WebRTC 跑到了每周 9 亿用户的规模。文章也明确说明内容基于公开资料，欢迎读者指出不准确之处。