meng shao@shao__meng · X为实现语音AI的自然对话感，OpenAI采用WebRTC支持音频流式处理。针对1:1场景，采用Transceiver模型集中管理WebRTC状态，使后端可横向扩展。为解决WebRTC与K8s的端口和状态粘性问题，设计了Relay+Transceiver架构：轻量Relay层收敛公网UDP入口，并利用ICE ufrag字段编码路由信息，实现首包精准转发至对应Transceiver。该设计保留了协议语义，状态集中，并通过全球部署Relay优化路径，最终在K8s上实现了低延迟、高可扩展的语音交互系统。
OpenAI 如何实现规模化的低延迟语音 AI
语音交互的"自然感"完全建立在毫秒级响应之上。一旦网络抖动、首包慢、丢包，用户立刻感知为停顿、被打断或抢话失败。OpenAI 面对的约束有三条： · 全球可达：服务 9 亿+ 周活用户 · 首连快：会话建立后用户能立刻开口 · 媒体 RTT 低且稳：低抖动、低丢包，让对话节奏紧凑
为什么选 WebRTC？ WebRTC 把实时音视频里最难的部分（NAT 穿透、加密传输、编解码协商、抖动缓冲、回声消除等）做成了浏览器与移动端原生支持的标准栈。对 AI 产品而言，最关键的特性是 音频以连续流的形式到达--模型可以在用户还在说话时就开始转写、推理、调用工具乃至生成回答，这是"对讲机"和"对话感"的分水岭。
媒体架构选择：放弃 SFU，采用 Transceiver 模型 · SFU（选择性转发单元）：适合多方会议，把所有参与者的音视频汇聚后选择性转发。 · OpenAI 的实际负载：绝大多数会话是 1：1（一个用户对一个模型），对每一轮延迟都极敏感。
因此选择了 Transceiver 模型：边缘的 transceiver 服务终结 WebRTC 连接，再把媒体和事件转换为更简单的内部协议送往后端推理服务。所有 WebRTC 状态（ICE、DTLS 握手、SRTP 密钥、生命周期）只集中在 transceiver 一处，后端服务因此能像普通服务一样横向扩展，而不必充当 WebRTC 对端。