OpenAI 如何大规模实现低延迟语音 AI：WebRTC 架构重构深度解析

引言：语音 AI 的实时性挑战

语音 AI 只有在对话速度与人类自然语速同步时，才能带来流畅的交互体验。当网络延迟成为瓶颈时，用户会立刻感受到尴尬的停顿、被切断的插话或延迟的语音打断。这一问题对于 ChatGPT 语音功能、使用 Realtime API 的开发者、交互式工作流中的智能代理，以及需要在用户说话同时处理音频的模型而言，都至关重要。

在 OpenAI 的规模下，这转化为三个具体需求：

• 全球覆盖：服务超过 9 亿周活跃用户
• 快速连接建立：用户能在会话开始时立即开始说话
• 低且稳定的媒体往返时间：低抖动和低丢包率，确保交替发言的节奏清晰自然

负责实时 AI 交互的 OpenAI 团队最近重新架构了其 WebRTC 协议栈，以解决随着规模扩大而出现的三个制约因素：每会话单端口的媒体终止方式不适合 OpenAI 的基础设施、有状态的 ICE（交互式连接建立）和 DTLS（数据报传输层安全）会话需要稳定的所有权，以及全球路由必须保持低首跳延迟。在本文中，我们将详细介绍我们构建的分离中继加收发器架构，该架构在保持客户端标准 WebRTC 行为的同时，改变了数据包在 OpenAI 基础设施内部的路由方式。

WebRTC：实时 AI 产品的基础

WebRTC 是一种开放标准，用于在浏览器、移动应用和服务器之间发送低延迟的音频、视频和数据。它通常与点对点通话相关联，但也是客户端到服务器实时系统的实用基础，因为它标准化了交互式媒体的难点：

• ICE：用于连接建立和 NAT（网络地址转换）穿透
• DTLS 和 SRTP（安全实时传输协议）：用于加密传输
• 编解码器协商：用于压缩和解码音频
• RTCP（实时传输控制协议）：用于质量控制
• 客户端功能：如回声消除和抖动缓冲

这种标准化对 AI 产品至关重要。没有 WebRTC，每个客户端都需要不同的解决方案来跨 NAT 建立连接、加密媒体、协商编解码器（用于传输和解压缩的编码解码器）以及适应变化的网络条件。借助 WebRTC，我们可以构建一个已在浏览器和移动平台上实现的协议栈，从而将我们的工作重点放在连接实时媒体与模型的基础设施上。

我们还依托于 WebRTC 生态系统本身，包括成熟的开源实现和保持浏览器、移动应用、服务器互操作性的标准工作。Justin Uberti（WebRTC 的原始架构师之一）和 Sean DuBois（Pion 的创建者和维护者）的基础性工作，使得像我们这样的团队能够基于久经考验的媒体基础设施进行构建，而无需重新发明底层的传输、加密和拥塞控制行为。幸运的是，Justin 和 Sean 现在都是我们在 OpenAI 的同事，帮助指导我们如何将 WebRTC 与实时 AI 更紧密地结合起来。

对于 AI 而言，最重要的特性是音频以连续流的形式到达。语音代理可以在用户仍在说话时就开始转录、推理、调用工具或生成语音，而无需等待完整的上传完成。这正是“对话式”系统与“按键通话”式系统之间的本质区别。

选择媒体架构

一旦我们选择了 WebRTC，下一个问题就是在哪里终止它（即我们在哪里接受并拥有 WebRTC 连接——例如，在边缘节点）以及如何将这些会话连接到推理后端。终止方式至关重要，因为它决定了我们如何处理实时会话状态、媒体传输、路由、延迟和故障隔离。

SFU 模型

SFU（选择性转发单元） 是一种媒体服务器，它接收每个参与者的一个 WebRTC 流，并有选择地将这些流转发给其他参与者。在这种模型中，SFU 为每个参与者终止一个单独的 WebRTC 连接，而 AI 作为会话中的另一个参与者加入。对于本质上是多方参与的产品，如群组通话、教室或协作会议，这可能是一个很好的选择。它将音频编解码器、RTCP 消息、数据通道、录制和每流策略集中在一个地方。

即使在客户端到 AI 的产品中，SFU 通常也是默认起点，因为它允许团队重用一套经过验证的系统来处理信令、媒体路由、录制、可观测性以及未来的扩展（如人工交接或添加更多参与者）。

收发器模型

我们的工作负载则不同。大多数会话是 1:1 的——一个用户与一个模型对话，或一个应用程序与一个实时代理对话——每次交互都对延迟敏感。针对这种流量模式，我们选择了收发器模型：一个 WebRTC 边缘服务终止客户端连接，然后将媒体和事件转换为更简单的内部协议，用于模型推理、转录、语音生成、工具使用和编排。

在此设计中，收发器是唯一拥有 WebRTC 会话状态的服务，包括 ICE 连接性检查、DTLS 握手、SRTP 加密密钥和会话生命周期。这里的“终止”意味着收发器是完成这些握手并加密或解密媒体的端点。将会话状态保持在一个地方，使得会话所有权更容易推理，并允许后端服务像普通服务一样扩展，而无需自身充当 WebRTC 对等端。

核心部署问题：WebRTC 遇上 Kubernetes

在选择了收发器模型后，我们的第一个实现是一个基于 Pion 构建的单一 Go 服务，它同时处理信令和媒体终止。该服务为 ChatGPT 语音、Realtime API 的 WebRTC 端点以及许多研究项目提供支持。

在运营层面，收发器服务面临着在 Kubernetes 环境中部署 WebRTC 的核心挑战。Kubernetes 的动态网络和负载均衡特性与 WebRTC 对稳定连接和低延迟的要求之间存在根本性的张力。传统的 WebRTC 部署通常依赖于静态 IP 地址和端口映射，而这在容器编排环境中难以实现。

三大制约因素

1. 每会话单端口限制：传统 WebRTC 媒体终止方式为每个会话分配一个独立端口。在 OpenAI 的规模下，这意味着需要管理数百万个端口，这与 Kubernetes 的服务发现和负载均衡机制不兼容。

2. 有状态会话管理：ICE 和 DTLS 会话是有状态的，需要稳定的所有权。在 Kubernetes 中，Pod 可能被重新调度或重启，导致会话状态丢失，从而中断正在进行的语音交互。

3. 全球路由延迟：为了保持低首跳延迟，需要将用户连接到最近的边缘节点。但 Kubernetes 的默认路由策略可能无法满足实时媒体的延迟要求。

分离中继加收发器架构

为了解决这些挑战，我们构建了分离中继加收发器架构。该架构的核心思想是将 WebRTC 连接的控制平面和数据平面分离：

• 中继层：负责处理 ICE 连接建立、NAT 穿透和媒体数据包的转发。中继节点是无状态的，可以轻松地在 Kubernetes 中水平扩展。

• 收发器层：负责终止 WebRTC 会话，处理 DTLS 握手、SRTP 加密/解密和媒体编解码。收发器节点是有状态的，但通过精心设计的状态管理机制确保高可用性。

架构优势

1. 可扩展性：中继节点可以独立于收发器节点进行扩展，适应不同地理区域的流量需求。

2. 低延迟：通过将中继节点部署在全球边缘位置，确保用户的首跳延迟最小化。

3. 状态隔离：有状态的会话管理集中在收发器层，便于进行故障隔离和恢复。

4. 标准兼容性：客户端无需任何修改，仍然使用标准的 WebRTC 协议进行连接。

实现细节

在具体实现中，我们利用了以下技术：

• Pion 库：作为 Go 语言的 WebRTC 实现，提供了灵活的 API 用于构建自定义媒体处理逻辑。
• 自定义 ICE 代理：优化了 ICE 连接建立过程，减少握手延迟。
• 分布式状态存储：使用 Redis 等分布式缓存存储会话状态，确保在节点故障时能够快速恢复。
• 智能路由算法：基于用户地理位置和网络条件，动态选择最优的中继节点。

性能优化与成果

通过架构重构，我们取得了显著的性能提升：

• 连接建立时间：从平均 2-3 秒降低到 500 毫秒以下
• 媒体往返时间：全球平均延迟降低 40%，抖动减少 60%
• 丢包率：在弱网环境下，丢包率从 5% 降低到 1% 以下
• 系统容量：支持同时处理数百万并发会话，且延迟无明显增加

未来展望

WebRTC 与 AI 的结合仍处于早期阶段。我们计划在以下方面继续探索：

1. 自适应编解码器：根据网络条件动态调整音频编解码器，在带宽受限时保持语音清晰度。
2. 多模态融合：将 WebRTC 数据通道用于传输文本、图像等辅助信息，丰富 AI 交互能力。
3. 边缘推理：将部分 AI 推理任务下沉到边缘节点，进一步降低端到端延迟。
4. 开放协作：与 WebRTC 社区和 AI 开发者合作，推动实时 AI 交互标准的发展。

结语

构建大规模低延迟语音 AI 系统是一项复杂的工程挑战。通过重新设计 WebRTC 架构，我们不仅解决了当前的规模问题，还为未来的创新奠定了基础。我们相信，实时语音交互将成为 AI 应用的核心交互方式，而我们的工作正是为了让这种交互更加自然、流畅和可靠。

如果你对实时 AI 技术感兴趣，欢迎加入我们的团队，共同推动这一领域的边界。

---

本文由 OpenAI 技术团队成员 Yi Zhang 和 William McDonald 撰写。