OpenAI语音AI架构解读：Relay+Transceiver如何解决WebRTC与Kubernetes冲突

摘要

实时语音 AI 的体验不仅取决于模型速度。连接建立、UDP 路由、抖动、丢包和会话粘性都会表现为停顿、抢话失败或语音被截断。OpenAI 在 2026 年 5 月披露了 WebRTC 基础设施重构：由轻量 Relay 接收公网媒体包，再转发给持有完整 ICE、DTLS 和 SRTP 状态的 Transceiver。该架构不改变客户端标准 WebRTC 行为，同时缩小公网 UDP 暴露面，让有状态媒体会话适配 Kubernetes 弹性伸缩。

背景：语音 Agent 优化的是整条链路

语音系统需要在用户仍在说话时持续接收音频，并尽早转写、推理、调用工具或生成语音。WebRTC 已标准化 ICE 与 NAT 穿透、DTLS/SRTP 加密、编解码协商、RTCP 质量控制、回声消除和抖动缓冲，因此适合作为浏览器和移动端的实时入口。

但标准协议不会自动解决大规模部署问题。OpenAI 面临三个约束：每会话一个 UDP 端口不适合 Kubernetes；ICE 和 DTLS 需要稳定的进程所有权；全球用户又要求首跳尽可能靠近用户。

技术要点一：为什么选择 Transceiver 而不是 SFU

SFU 适合多人通话，它接收每个参与者的媒体流并选择性转发。OpenAI 的主要语音负载是 1:1：一个用户或应用连接一个实时模型，每轮都对延迟敏感。

因此系统选择 Transceiver 模式：边缘服务终止客户端 WebRTC，再将媒体和事件转换为更简单的内部协议，交给推理、转写、语音生成、工具调用和编排服务。

Transceiver 是唯一持有完整会话状态的组件，包括 ICE 检查、DTLS 握手、SRTP 密钥和生命周期。后端服务不需要成为 WebRTC 参与者，可以按普通服务扩缩容。这一边界减少了整个后端理解实时媒体协议的成本。

技术要点二：UDP 端口与会话粘性的冲突

传统 WebRTC 常为每个会话分配公开 UDP 端口。高并发下，这会产生几个问题：

• 云负载均衡和 Kubernetes Service 不擅长管理大规模公开 UDP 端口；
• 大端口范围扩大攻击面，网络策略更难审计；
• Pod 会新增、销毁和迁移，稳定预留端口与弹性调度冲突；
• 健康检查、发布切流和故障恢复更复杂。

改成每台服务器一个共享端口虽然减少端口，却无法自动保证会话粘性。创建 ICE/DTLS 会话的进程必须持续收到同一会话的数据包，否则握手、解密或 ICE Restart 可能失败。

真正目标是：只暴露少量固定公网端口，同时将每个包确定性路由到会话所有者。

技术要点三：Relay 与 Transceiver 分离状态和转发

正式架构将包路由与协议终止拆开：

• Relay 暴露少量稳定的公网 VIP 和 UDP 端口；
• Transceiver 位于其后，继续持有完整 WebRTC 状态；
• Relay 不解密媒体，不运行 ICE 状态机，也不参与编解码协商；
• 客户端仍然使用标准 WebRTC，不感知内部转发层。

Relay 只读取确定目标所需的包元数据，后续 DTLS、RTP 和 RTCP 数据保持不透明。相比让每个后端服务理解 WebRTC，复杂度被集中在一层很薄、可水平扩展的转发服务中。

技术要点四：用 ICE ufrag 完成首包路由

第一个数据包到达时，Relay 还没有流表。如果同步查询外部控制面，会把网络依赖放进建连关键路径。

WebRTC 的 ICE 握手自带 username fragment，即 ufrag。服务端在信令阶段生成 ufrag，并在其中编码目标集群和 Transceiver 路由提示。客户端得到的 SDP 只暴露共享 Relay 地址和端口。

首个媒体路径数据包通常是 STUN Binding Request。Relay 解析服务端 ufrag，得到目标并转发给会话所有者。路由建立后，后续包依据内存中的“客户端 IP:Port 到 Transceiver IP:Port”映射直接转发。

若 Relay 重启丢失状态，下一个 STUN 包可从 ufrag 重建路由；Redis 还保存已建立映射，以便更早恢复。这是典型的协议内路由：利用握手已有字段，避免额外热路径查询。

技术要点五：全球入口与简单 Go 数据面

固定公网入口后，Relay 可以全球部署。信令通过地理和邻近路由进入附近集群，SDP 返回附近 Global Relay 地址；媒体先进入靠近用户的 Relay，再沿内部网络前往会话所在集群，从而缩短信令和首次 ICE 检查往返。

Relay 使用 Go 实现，没有引入内核旁路。关键优化包括：

• 使用 SO_REUSEPORT，让多个 Worker 绑定同一 UDP 端口；
• 将 UDP 读取 Goroutine 固定到 OS 线程，提高 Cache 局部性；
• 预分配 Buffer、减少拷贝和对象分配；
• 只保存短生命周期流状态、计数器和清理计时器。

官方表示，该实现已能承载全球实时媒体流量，因此没有先承担内核旁路的运维复杂度。

研发视角

这套架构最值得复用的不是具体技术栈，而是四个原则。

第一，状态边界清晰。加密密钥和协议状态只放在 Transceiver，Relay 只做可恢复转发。

第二，复杂度集中在薄层。客户端继续使用标准 WebRTC，后端保持普通 RPC 形态，只有路由层定制。

第三，首包路径避免慢控制面。能从协议原生字段推导路由，就不要同步查询中心服务。

第四，按常见负载选架构。1:1 实时会话适合 Transceiver；多人会议、录制和复杂转发仍可能更适合 SFU。

实践建议

分别监控信令建立、首次 STUN、DTLS 握手、首个音频包和媒体 RTT，同时观察抖动、丢包、Relay 重建和会话失败。

路由提示应具备完整性保护和短生命周期，不能允许客户端任意选择内部目标。Relay 只解析必要字段，并限制包大小、速率和异常 STUN 流量。

容量规划要同时观察带宽、包速率和会话数。语音包较小，高并发时 PPS、系统调用和 GC 可能比带宽更早成为瓶颈。

故障演练应覆盖 Relay 重启、Redis 不可用、Transceiver 下线、ICE Restart、跨地域网络抖动和负载均衡切换。

风险与限制

官方文章没有公开建连时间、媒体 RTT、单实例容量或成本数据，无法量化该架构相对 TURN 或 SFU 的完整收益。

Relay 仍增加一次转发跳数和自定义协调面；Redis 映射恢复也带来一致性问题。ufrag 中编码路由提示需要防止泄露内部拓扑或形成可伪造入口。

此外，该设计针对点对点、强实时负载优化。多人媒体、复杂策略或频繁参与者变更可能仍需要 SFU 或混合架构。

结语

低延迟语音 AI 的关键不只是更快的模型，而是让网络、协议状态和计算服务承担合适职责。Relay + Transceiver 提供了一个清晰范式：保持客户端标准协议不变，把不可丢失的状态集中到唯一所有者，再用可重建的薄转发层连接公网与弹性集群。

参考来源

1. OpenAI Engineering：How OpenAI delivers low-latency voice AI at scale
   https://openai.com/index/delivering-low-latency-voice-ai-at-scale/