2026 年 5 月 4 日，OpenAI 发布了一篇工程博客，披露了其语音 AI 基础设施的重大重构。按官方说法，这套系统现在支撑着 9 亿周活用户，端到端延迟控制在 300 毫秒以内。首次音频响应 < 300-500ms，抢答反应 < 200ms。
这些数字听起来很性感。但真正有意思的，是他们在重构中踩的那些坑、做出的那些反直觉选择。
WebRTC 的噩梦：Kubernetes 时代的水土不服
WebRTC 在设计之初，考虑的不是大规模服务器部署。它的连接模型是 one-port-per-session——每个通话占用一个独立的 UDP 端口。对于点对点场景，这没问题。但当你要在 Kubernetes 上跑一个需要同时处理百万并发的语音服务时，这套模型就成了噩梦。
负载均衡器复杂度爆炸。 传统 HTTP 流量可以用七层负载均衡，根据 URL、Header 做路由。但 WebRTC 的媒体流走的是 UDP + ICE（Interactive Connectivity Establishment），负载均衡器根本不知道该把数据包往哪儿送。你没法简单地在入口处做个流量分发——每个连接都是"有状态"的。
安全攻击面急剧扩大。 每个新连接都要在负载均衡层维持一个 UDP 端口状态，这给了攻击者大量可蹭的点。放大攻击、端口耗尽攻击，花样繁多。系统需要为每个端口维护复杂的心跳和超时机制，这本身就是 DoS 攻击向量。
自动扩缩容脆弱得像纸糊的。 当 Pod 被调度到新节点时，它的 UDP 端口信息是"写死"的。负载均衡器知道的老节点已经不存在了，但旧的连接状态还挂在那里。流量打过来，一部分去了新 Pod，一部分去了已经不存在的 Pod，网络抖动随之而来。
这三条加起来，就是为什么很多团队的 WebRTC 服务在规模上去之后，延迟抖动的根因往往不是代码质量，而是基础设施层面的架构约束。
解决方案：Relay + Transceiver 分离架构
OpenAI 的解法是把"路由"和"协议状态"彻底拆开。原来的 WebRTC 服务器承担了两件事：转发 UDP 数据包并且维护 ICE/DTLS/SRTP 的协议状态。他们拆成了两层：
Relay 层：无状态的 UDP 转发节点。它只做一件事——把数据包送到正确的目的地。但它需要知道"目的地在哪儿"。OpenAI 的方案是将路由元数据编码到 ICE 用户名片段（ufrag） 中。Relay 解析 ufrag，首包路由，之后建立映射关系。
Transceiver 层：有状态的 WebRTC 端点。它拥有完整的 ICE/DTLS/SRTP 协议状态，处理加密、会话协商、媒体控制。这层可以独立调度、扩缩容，不影响流量分发。
这个拆分的精妙之处在于：Relay 变成了纯网络组件，可以无脑水平扩展；而协议状态被封装到 Transceiver 中，与 Kubernetes 的 Pod 调度解耦。
ICE ufrag 路由：把元数据写进协议字段
具体怎么把路由信息传过去？OpenAI 用了一个看似取巧、实则精妙的设计：把路由元数据编码进 ICE 用户名片段中。
ICE 协议本身有 ufrag 字段，用于身份认证和会话绑定。通常这个字段只是随机生成的标识符，但 OpenAI 在里面塞进了"这封信该去哪个 Transceiver"的信息。Relay 层只需要解析 ufrag，就能知道该把数据包转发到哪个 Pod，完全不用维护复杂的会话表。
这个设计的代价是：ufrag 本身是明文传输的（ICE 协议规范），不能用来传递真正敏感的数据。但对于路由信息来说，这完全够用。
用协议原生字段做路由，而不是自建控制面，是这个方案最值得借鉴的地方。不要自己发明协议字段，利用现有协议的可扩展性。
Global Relay：地理分布式接入
OpenAI 在北美部署了三个主要接入点：Chicago、Virginia、Austin。用户接入时，先到最近的点，然后通过 Relay 层路由到实际处理请求的 Transceiver。
这套架构依赖 Cloudflare 的地理和邻近性引导能力。Cloudflare 在边缘做了大量协议层面的优化，可以让 UDP 数据包以最短路径到达最近的 Relay 节点。
有意思的是，这套系统服务的场景是 1:1 的点对点语音，不是多方会议。OpenAI 在博客中明确说了"为什么不用 SFU（Selective Forwarding Unit）"——SFU 是为多人会议场景设计的，需要在全参与者之间转发媒体流。但他们的产品模型是用户和 AI 一对一对话，1:1 连接，不需要 SFU 的复杂路由能力。
这里有个反直觉的点：最合适的技术架构，取决于你的业务场景，而不是业界最火的概念。 SFU 很热，但在这个场景下是过度设计。
Relay 实现细节：Go + Pion + Redis
Relay 层的实现用 Go 语言，WebRTC 库选的是 Pion（https://github.com/pion/webrtc）。Pion 是纯 Go 实现的 WebRTC 堆栈，比起 Google 的 libwebrtc（C++ 实现），它更适合在 Kubernetes 环境中做水平扩展——没有 native 依赖，部署简单，goroutine 模型天然适合高并发 UDP 转发场景。
Relay 本身是无状态的。但网络总有抖动，有丢包。OpenAI 的方案是用 Redis 作为备份状态存储。当 Relay 需要临时缓存会话映射时，Redis 提供了快速访问和故障恢复能力。这不算真正的有状态——只是"有备无患"的状态缓存。
这套架构的性能表现：端到端延迟 P99 控制在 300ms 以内。考虑到用户遍布全球，这是一个相当激进的目标。
五个实践教训
1. 明确定义延迟预算，分清 P50/P95/P99。 "低延迟"是一个模糊的目标。OpenAI 把延迟拆成了多个维度：首包延迟、网络传输延迟、编解码延迟、应用处理延迟。每个维度有独立的 SLO。这比笼统地说"300ms 以内"要可操作得多。
2. 分离路由和协议状态是架构演进的关键。 当你发现扩缩容遇到瓶颈时，首先检视"什么在阻止我水平扩展"。通常答案是某个组件把两件不该绑在一起的事情放到了同一个进程里。
3. 利用协议原生字段做路由，而不是自建控制面。 在 ufrag 里塞路由信息，看起来是个 hack，但它避免了引入额外的服务发现组件。协议本身就有扩展性，用它。
4. VAD（Voice Activity Detection）和端点检测是产品决策，不是技术决策。 什么时候判定用户说完了？用 VAD 检测音量阈值，还是等 NLP 模型确认意图？这会影响整体延迟和产品体验。OpenAI 的做法是把端点检测做成了可配置的策略，让产品侧可以根据场景调优。
5. 生产环境的实时语音用 WebRTC，不要用 WebSocket。 WebSocket 是基于 TCP 的，TCP 的拥塞控制和重传机制在弱网环境下会让延迟"糊掉"。WebRTC 的 UDP 路线虽然丢包风险更高，但延迟表现更稳定。实时语音宁可丢包，也不要让数据包迟到。
平台对比：选谁不选谁？
目前做实时语音 AI，有三条路：
| 维度 | OpenAI Realtime API | LiveKit Agents | 自建（Pion） |
|---|---|---|---|
| 线路协议 | WebRTC（或 WebSocket 降级） | WebRTC（LiveKit SFU） | WebRTC（自定义） |
| 托管 | 仅 OpenAI 云 | 自托管或 LiveKit Cloud | 你的基础设施 |
| 模型灵活度 | 仅 OpenAI 模型 | 任意模型 | 任意模型 |
| 原型搭建 | 数小时 | 数天 | 数周到数月 |
| 多 Agent 房间 | 否 | 是 | 自行实现 |
| 规模上限 | OpenAI 的基础设施 | 取决于部署 | 无上限（你的问题） |
对于大多数团队，LiveKit Agents 是当前性价比最优的起点——开源、可控、社区活跃。等业务量上来、需求更清晰了，再考虑迁移到 OpenAI 或者深度自建。
FAQ
为什么 WebRTC 在 Kubernetes 上难扩展？
核心矛盾是 one-port-per-session 模型。WebRTC 每个连接独占一个 UDP 端口，而 Kubernetes 的 Pod 调度是"无状态的"——Pod 随时可能被调度到新节点，但端口和连接状态是跟着 Pod 的。负载均衡器不知道该把数据包送往哪里，因为它找不到连接对应的当前 Pod。
Relay + Transceiver 架构的核心优势是什么？
路由层无状态，可以水平扩展；协议状态封装在 Transceiver 中，与 Pod 调度解耦。Relay 只做 UDP 转发，不维护会话状态，所以可以快速扩缩容，不用担心状态迁移问题。
ICE ufrag 路由的实现有什么风险？
ufrag 是明文传输的（ICE 协议规范），不适合存放敏感信息，只适合存放路由元数据。另外，ufrag 长度有限（通常 <= 256 字节），编码量受限，不能塞太多信息进去。
为什么 OpenAI 不用 SFU？
SFU 适合多人会议场景，需要在全参与者之间转发媒体流。但 OpenAI 的产品模型是 1:1 用户-AI 对话，1:1 连接，不需要 SFU 的路由能力。用 SFU 是过度设计。
实时语音用 WebSocket 还是 WebRTC？
生产环境建议用 WebRTC。WebSocket 基于 TCP，弱网环境下 TCP 的拥塞控制和重传会让延迟变高。WebRTC 的 UDP 路线丢包风险更高，但延迟更稳定，实时语音宁可丢包也不要迟到。
小团队做实时语音 AI，该从哪个平台入手？
LiveKit Agents 是当前性价比最优的开源选择，支持自托管，社区活跃。等业务规模上来、需求更清晰后，再考虑迁移到 OpenAI Realtime API 或完全自建。
参考资料
- OpenAI 工程博客：How OpenAI delivers low-latency voice AI at scale（2026年5月4日）
- Pion WebRTC：github.com/pion/webrtc
- OpenAI 开发者更新：Updates for developers building with voice