OpenAI 如何在大规模下实现低延迟语音 AI

#引言
实时语音交互正迅速成为对话式 AI 的新前沿。与文本聊天不同(在文本聊天中,用户早已习惯看着 token 逐个在屏幕上输出),语音通信需要完全不同的技术范式。人类对话对延迟的容忍度极低;哪怕只有几百毫秒的延迟,也会让交流显得极不自然,导致尴尬的打断并破坏交谈节奏。
近期,OpenAI 发布了一篇备受瞩目的工程技术更新,详细阐述了他们是如何向高达 9 亿的周活跃用户提供低延迟语音 AI 服务的。在如此庞大的规模下提供实时媒体服务,是一项极其艰巨的基础设施挑战。在这篇文章中,他们揭示了一个引人注目的架构转变:摒弃了传统的媒体服务器架构,转而采用了基于 WebRTC 协议构建、经过深度优化的自定义方案。
对于构建实时 AI 应用的工程师而言,OpenAI 的方法无疑是一节大师课——它挑战了默认的技术假设,并针对特定用例对网络拓扑进行了极致优化。让我们深入剖析他们构建了什么,为什么要这样构建,以及这给整个行业带来了哪些技术启示。
#遇到了什么问题
当工程团队需要通过互联网传输亚秒级的实时音视频时,WebRTC 是无可争议的行业标准。它开箱即用地解决了公共互联网中那些棘手的现实问题,比如 NAT 穿透、丢包隐藏、拥塞控制和安全传输。
然而,扩展 WebRTC 架构的默认方式是使用选择性转发单元(SFU)。SFU 主要是为多方会议(如 Zoom 或 Google Meet)设计的。它们接收来自一个参与者的媒体流,并选择性地将其转发给许多其他参与者。
OpenAI 意识到他们的工作负载在本质上是不同的。AI 语音交互严格来说是 1:1 的——即一个用户与一个模型进行对话。在 1:1 架构中依赖 SFU 会引入不必要的计算和路由开销。此外,随着规模的不断扩大,OpenAI 在使用传统 WebRTC 终结方案时遇到了三个关键瓶颈:
- 端口管理: 标准的 WebRTC 实现通常每个会话需要一个或多个 UDP 端口。在处理 9 亿用户的规模时,边缘服务器上的端口耗尽问题成为了一个严重的基础设施瓶颈。
- 会话稳定性: WebRTC 依赖状态握手,例如用于 NAT 穿透的交互式连接建立 (ICE) 以及用于加密的数据报传输层安全 (DTLS)。这些协议需要与拥有该会话状态的特定节点保持高度稳定的连接。
- 全局路由: 为了达到媲美人类对话的极低延迟,必须尽可能缩短“第一跳”——即从用户手机到 OpenAI 网络的连接距离。这就要求在全球的边缘存在点(PoP)终结连接,而不是将流量通过公共互联网回传到集中的数据中心。
#为什么这很重要
为了突破这些在大规模场景下的限制,OpenAI 决定剥离后端推理服务器中沉重的 WebRTC 逻辑,并在边缘引入了一个专用的处理层。他们将此称为分离中继加收发器架构 (split relay plus transceiver architecture)。
OpenAI 并没有强迫后端的 Python 或 C++ 推理服务器去扮演完全合规的 WebRTC 对等端(这需要它们管理复杂的 ICE 和 DTLS 状态机),而是将专用的中继节点部署在了网络边缘。
这些轻量级的边缘节点处理客户端所需的所有复杂协议语义。对于用户的移动端应用来说,它似乎是在与一个标准的 WebRTC 节点进行通信。然而在内部,这些边缘节点充当了高效的数据包路由器。它们从 WebRTC 载荷中解包出媒体数据,并使用一种优化的、确定性的内部协议将其转发给后端推理服务器。
这种架构上的解耦至关重要,原因有二。首先,推理服务器本身就已经承担了运行庞大神经网络这一极其消耗计算资源的任务;卸载媒体传输逻辑极大地简化了它们的部署和扩展。其次,这个边缘层允许 OpenAI 进行激进的流量复用,在服务数百万并发会话的同时,显著降低了面向公共网络的 UDP 端口占用。
#技术启示
这一新架构的核心是 Pion,这是一个用 Go 语言编写、高度模块化的开源 WebRTC 实现。Pion 之所以成为 WebRTC 社区的宠儿,正是因为它没有将开发者禁锢在僵化的 SFU 框架内。其可组合的特性使得工程团队能够仅提取他们需要的特定组件,从而构建出高度定制化的传输层。
OpenAI 利用 Pion 构建了他们的自定义收发器。让我们对比一下他们的方法与传统的媒体服务器架构有何不同:
| 特性 | 传统 SFU 架构 | OpenAI 分离中继架构 |
|---|---|---|
| 主要工作负载 | 多方会议 (N:M) | 人机交互 (1:1) |
| 终结点 | 集中的媒体服务器 | 分布式边缘节点 |
| 后端职责 | AI 推理 + WebRTC 状态管理 | 仅对原始/优化的媒体数据进行推理 |
| 公网端口占用 | 高(通常每个流/会话 1 个) | 低(在边缘进行激进的复用) |
| 流量路由 | 通常需要检查数据包载荷 | 通过协议原生元数据实现确定性路由 |
这种架构的一个显著特点是确定性路由。通过将路由元数据编码到标准协议原生的字段中,新会话的第一个数据包就能立刻知道目标后端推理集群是哪一个。这基本上将连接建立的延迟降至零,使用户在 UI 显示已连接的瞬间即可开始讲话。此外,通过在边缘层保持高度稳定的媒体往返时间 (RTT) 并最大程度地减少抖动,AI 的对话响应显得异常利落和自然。
#展望未来
OpenAI 披露的架构细节标志着行业的一个重要转折点。随着更广泛的科技生态系统跨越基于文本的 LLM,开始着手构建多模态、实时的语音智能体,传统的网络基础设施模式势必迎来变革。
我们可以预见从这一转变中将涌现出几个趋势:
- 边缘终结的媒体服务: 云基础设施提供商很可能会开始提供专为 1:1 AI 工作负载设计的、托管的专用 WebRTC 终结层,从而降低初创公司的入局门槛。
- Pion 的持续繁荣: Go 语言的灵活性以及 Pion 生态系统使其成为现代定制化网络编程的默认选择。预计将会涌现大批模仿 OpenAI 收发器模型的开源框架。
- 协议演进: 业界可能会推动专门针对 AI 工作负载量身定制的 WebRTC 扩展,优化握手过程以实现更快的会话恢复。
#结语
向近十亿用户提供低延迟、实时的语音 AI 是一项史无前例的工程壮举。通过摆脱传统的多方媒体服务器,并拥抱基于 Go 构建的自定义分离中继架构,OpenAI 为 AI 网络设定了新的黄金标准。
他们的工程决策凸显了系统设计中的一个关键教训:当应用工作负载发生根本性转变时,必须重新构想底层的基础设施。一个为视频会议设计的协议并非开箱即用地完美适合 1:1 的 AI 交互,但借助诸如轻量级路由层这样智能的抽象,它完全可以被改造,从而在全球范围内提供令人惊叹的对话体验。