OpenAI如何扛住9亿用户的语音AI：WebRTC“中继+收发器”分

OpenAI 如何扛住 9 亿用户的语音 AI：WebRTC “中继+收发器”分层架构解析 实时语音 AI 的自然感，不取决于模型多聪明，而在于网络延迟能否“隐身”。一旦用户说话出现尴尬停顿或抢话延迟，体验就会崩塌。OpenAI 在支撑超 9 亿周活用户时，面临的核心难题是：传统 WebRTC “每会话一个 UDP 端口”的模式，在 Kubernetes 里会引发端口耗尽、安全策略复杂、弹性伸缩脆弱等问题。 [微风]为什么传统 WebRTC 在 Kubernetes 里“水土不服” - 端口耗尽：高并发下需暴露/管理海量 UDP 端口，云负载均衡与防火墙策略难以维护。 - 状态粘滞：ICE/DTLS 等状态协议要求同一会话包持续到达同一处理进程，容器漂移会断流。 - SFU 并非最优：多数场景是 1:1（用户↔模型），SFU 更适配多方会议，且会把复杂度引入后端。 [玫瑰]OpenAI 的解法：Relay（中继）+ Transceiver（收发器） - Transceiver（状态端）：终止 WebRTC 连接，持有 ICE/DTLS/SRTP 会话状态与密钥，负责加解密与协议生命周期；后端服务可像普通微服务一样伸缩。 - Relay（轻量转发层）：对外暴露少量固定 UDP 端口/地址，不终止 WebRTC、不解密；仅解析首包 STUN 中的 ICE "ufrag"（用户名片段），据此把包路由到所属 Transceiver。 - 路由关键： "ufrag" 由服务端生成并嵌入路由元数据，Relay 据此做确定性首包路由；后续 DTLS/RTP/RTCP 直接转发，Relayer 仅维护最小内存会话用于转发与可观测。 [礼物]全球化与性能要点 - Global Relay + 就近接入：全球分布中继入口让首跳更短，降低抖动与丢包，配合就近信令，连接建立与首轮 ICE 检查更快，用户“能说话”的等待更短。 - Relay 实现细节：Go 用户态实现，利用 "SO_REUSEPORT"、线程绑定、预分配缓冲与低拷贝，避免单循环瓶颈与 GC 压力；无内核旁路也足以支撑全球实时流量。 - 韧性：Relay 重启可借 "ufrag" 提示或 Redis 缓存的地址映射快速恢复会话转发状态。 [万柿如意]工程启示 把“复杂状态”锁在少数有状态组件（Transceiver），把“接入与转发”做成无状态、可水平扩展的薄层（Relay），并用协议原生字段做首包路由，既保留标准 WebRTC 客户端兼容性，又让媒体平面在 Kubernetes 里像普通服务一样运维。 📎 原文：openai点com/index/delivering-low-latency-voice-ai-at-scale/