OpenAI如何实现大规模低延迟语音AI：WebRTC架构重构揭秘

2026年5月4日，OpenAI发布技术博客，详细披露了其为支持ChatGPT语音模式、Realtime API及实时智能体而重构的WebRTC基础设施。通过全新“中继+收发器”（relay + transceiver）架构，OpenAI在全球900百万周活跃用户规模下，实现了快速会话建立、低且稳定的媒体往返时延（RTT）、低抖动与丢包率，让语音交互真正接近自然对话速度。

实时语音AI的核心挑战

语音AI的自然度取决于“说话速度”的响应——网络延迟会导致尴尬停顿、打断失败或迟缓介入。这对ChatGPT语音、开发者使用的Realtime API、交互式工作流中的智能体，以及需边听边处理的模型至关重要。

OpenAI团队面临三大规模约束：

· 全球覆盖900百万+周活用户；

· 快速连接建立，让用户一启动会话即可说话；

· 低且稳定的媒体RTT、低抖动与丢包，确保轮流对话流畅。

传统WebRTC在高并发下暴露出问题：单会话单端口媒体终止与OpenAI基础设施不兼容；有状态的ICE（交互式连接建立）和DTLS（数据报传输层安全）会话需稳定归属；全球路由需保持首跳低延迟。

从SFU到收发器模型的演进

早期，OpenAI采用选择性转发单元（SFU）架构，每个参与者独立终止WebRTC连接，AI作为另一参与者加入。但对于1:1会话（用户与模型对话）为主的负载，这种模式效率不高。

团队转向收发器（transceiver）模型：边缘WebRTC服务终止客户端连接，将媒体与事件转换为内部简化协议，供模型推理、转录、语音生成、工具调用与编排使用。收发器是唯一拥有WebRTC会话状态的服务，包括ICE连通性检查、DTLS握手、SRTP加密密钥及会话生命周期。

这一设计让后端服务像普通服务一样弹性扩展，而非充当WebRTC对等方。

Kubernetes规模化的关键创新：中继+收发器架构

传统单端口/会话模型在Kubernetes环境下遇到两大瓶颈：

1. 端口耗尽：高并发需暴露大量公共UDP端口范围，增加负载均衡、防火墙与自动扩缩容的复杂性与安全风险。

2. 状态粘性：ICE和DTLS为有状态协议，会话数据包必须路由回原始拥有进程，否则握手失败或媒体中断。

OpenAI构建的边缘中继（edge relay）+收发器架构解决了这些问题：

· 边缘中继暴露极小的固定UDP表面，处理客户端NAT穿透与初始连接；

· 收发器负责完整会话所有权与媒体处理；

· 内部采用简化协议连接推理后端。

该架构保留了客户端标准的WebRTC行为，同时在OpenAI基础设施内部实现了高效路由。团队基于Pion（由Sean DuBois维护）构建初始Go服务，并得到WebRTC原架构师之一Justin Uberti的指导。

性能与生态影响

新架构显著降低了端到端延迟，提升了全球一致性，并支持Kubernetes原生弹性伸缩。OpenAI表示，这不仅服务于ChatGPT语音与Realtime API，还支撑了多项研究项目。

WebRTC作为开放标准，为浏览器与移动端提供了成熟的连接、加密、编解码协商与拥塞控制能力，让OpenAI能专注于将实时媒体与AI模型深度结合，而非重复造轮子。

未来展望

随着实时语音AI向更复杂智能体工作流演进，低延迟基础设施将成为核心竞争力。OpenAI的实践为行业提供了可借鉴的规模化路径：如何在标准协议之上，通过架构创新平衡性能、安全与运维弹性。

未来，类似“收发器+中继”模式或将普及，推动语音AI从“对话”向“实时协作”全面升级。OpenAI正以工程实力，持续定义实时AI体验的上限。

评论

0 条

登录后才可以发表评论。

立即登录

暂无评论，快来抢沙发。