5月4日，OpenAI 工程团队发布了一篇技术博文，首次公开了支撑 ChatGPT 语音、Realtime API 和交互式 Agent 的大规模实时语音架构。这不是一篇产品公告——没有新模型、没有新 API——但它回答了一个很多人一直在猜的问题：每天 9 亿周活用户的语音对话，到底是怎么跑的？

语音 AI 的"延迟容忍度"接近零

打字聊天慢半秒没关系，但语音对话不一样。你说话时如果对方隔了 300 毫秒才回应，你会觉得"这人怎么不说话了"；你想打断时如果 barge-in 不灵，你会觉得"它根本没在听"。

OpenAI 在博文中列出了三项硬指标：

• 全球覆盖：9 亿周活用户分布在世界各地，不能只靠少数几个机房
• 快速建连：用户点开语音，不等就能说
• 低且稳的媒体 RTT：延迟低、抖动小、丢包少，回合切换才干脆

这三个指标看上去简单，但在 OpenAI 的规模下，每一个都是工程难题。

为什么选 WebRTC，而不是自建协议

很多人听到 WebRTC 第一反应是"视频会议用的"。但 OpenAI 解释了一个关键点：WebRTC 对 AI 产品最大的价值不是"视频"，而是它标准化了实时媒体传输中最难的那一堆事——NAT 穿越（ICE）、加密（DTLS/SRTP）、编解码协商、RTCP 质量控制、客户端回声消除和抖动缓冲。

如果没有 WebRTC，每个客户端都得自己解决"怎么穿过你家路由器的 NAT""怎么加密音频流""用什么编解码器"这些底层问题。有了 WebRTC，这些协议在浏览器和移动平台上已经实现好了，OpenAI 可以把精力集中在"怎么把音频流接上模型"。

更重要的是，WebRTC 让音频以连续流的方式到达。模型可以在用户还在说话的时候就开始转录、推理、调用工具、生成语音——而不是等用户说完整句话再上传。这就是"对话感"和"对讲机感"的区别。

SFU vs Transceiver：OpenAI 选了后者

在 WebRTC 架构中，最常见的媒体服务器是 SFU（Selective Forwarding Unit），它为每个参与者终止一条 WebRTC 连接，AI 作为另一个参与者加入。这对多人通话很好用——群聊、课堂、协作会议，SFU 能把编解码、RTCP、录制、分流策略集中在同一个地方。

但 OpenAI 的场景不一样。绝大多数会话是 1:1——一个用户对一个模型，或者一个应用对一个实时 Agent。每个回合的延迟都很敏感。

所以 OpenAI 选择了 transceiver 模型：一个 WebRTC 边缘服务终止客户端连接，然后把媒体和事件转换成更简单的内部协议，发给后端的推理、转录、语音生成、工具调用和编排服务。

好处很直接：

• 只有 transceiver 持有 WebRTC 会话状态（ICE 连接检查、DTLS 握手、SRTP 密钥、会话生命周期），后端服务不需要处理这些复杂状态
• 后端服务可以像普通微服务一样扩缩，不用充当 WebRTC peer
• 会话所有权清晰，故障隔离更容易做

真正的难题：WebRTC 遇上 Kubernetes

选了 transceiver 模型之后，OpenAI 的第一版实现是一个基于 Pion（Go 语言的 WebRTC 开源库）的单一服务，同时处理信令和媒体。这个服务支撑了 ChatGPT 语音和 Realtime API 的 WebRTC 端点。

但问题来了。传统的 WebRTC 采用"每会话一端口"模型——每个语音会话需要一个独立的 UDP 端口。在 Kubernetes 里，这种模型和基础设施打架：

• 云负载均衡器和 K8s Service 不是为每服务数万 UDP 端口设计的。每个额外端口范围都增加运维复杂度——负载均衡器配置、健康检查、防火墙策略、滚动发布安全
• 大端口范围难安全审计。暴露的 UDP 端口越多，攻击面越大，网络策略越难管
• Pod 频繁调度，端口范围无法稳定保留。K8s 的核心能力就是自动扩缩和迁移 Pod，但传统 WebRTC 端口模型要求每个 Pod 持有一块稳定的端口范围——这和 K8s 的调度哲学直接矛盾

OpenAI 的解决方案是 split relay + transceiver 架构：把信令和媒体分离，用多路复用替代每会话一端口，让会话状态锚定在 relay 层，transceiver 可以自由迁移。这样，WebRTC 的客户端行为完全保留（浏览器和 App 不用改），但内部路由方式彻底变了。

WebRTC 两大元老加入了 OpenAI

博文中有一个值得注意的细节：OpenAI 提到 Justin Uberti 和 Sean DuBois 现在都是 OpenAI 的同事。Justin Uberti 是 WebRTC 的原始架构师之一，Sean DuBois 是 Pion（Go 语言 WebRTC 实现）的创始人和维护者。

这意味着 OpenAI 在实时媒体层的投入不是"试水"，而是从协议层开始打地基。对使用 Realtime API 的开发者来说，这个信号很明确：OpenAI 认为实时语音交互是核心方向，而不只是 ChatGPT 的一个附属功能。

对开发者的启示

• WebRTC 是当前构建实时语音 AI 的最佳协议基础。如果你在做语音 Agent、实时语音交互产品，直接上 WebRTC 比自建协议靠谱得多
• Transceiver 模式暗示 1:1 语音交互是主战场。如果你做的是多方语音场景，SFU 仍然更合适；但如果是用户跟 AI 聊天，transceiver 架构在延迟和扩展性上都更有优势
• 理解这层架构有助于优化连接策略。比如，知道 OpenAI 用了 split relay，意味着信令和媒体走的是不同路径，你的客户端实现可以针对性地做超时和重连逻辑

局限

• 这是一篇工程博文，没有发布新模型或新 API 能力
• 架构细节偏底层，对普通用户的影响是间接的（你只会觉得"语音更流畅了"，但不会直接感知到 transceiver 或 split relay）
• 部分内部实现（如 relay 的具体实现、实际延迟数据）未完全公开

---

*来源：OpenAI 官方工程博客（2026年5月4日）*

参考来源

• https://openai.com/index/delivering-low-latency-voice-ai-at-scale/

说明：该页面由基础模板稳定生成，后续可继续局部润色样式或补充模块，再进入发布检查。