OpenAI语音AI架构解读RelayTransceiver如何解决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 端口不适合 KubernetesICE 和 DTLS 需要稳定的进程所有权全球用户又要求首跳尽可能靠近用户。技术要点一为什么选择 Transceiver 而不是 SFUSFU 适合多人通话它接收每个参与者的媒体流并选择性转发。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、减少拷贝和对象分配只保存短生命周期流状态、计数器和清理计时器。官方表示该实现已能承载全球实时媒体流量因此没有先承担内核旁路的运维复杂度。研发视角这套架构最值得复用的不是具体技术栈而是四个原则。第一状态边界清晰。加密密钥和协议状态只放在 TransceiverRelay 只做可恢复转发。第二复杂度集中在薄层。客户端继续使用标准 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 提供了一个清晰范式保持客户端标准协议不变把不可丢失的状态集中到唯一所有者再用可重建的薄转发层连接公网与弹性集群。参考来源OpenAI EngineeringHow OpenAI delivers low-latency voice AI at scalehttps://openai.com/index/delivering-low-latency-voice-ai-at-scale/