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

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

跳转到主要内容

[](http://openai.com/)

• 研究
• 产品
• 企业
• 开发者
• 公司
• 基金会（在新窗口中打开）

登录 尝试 ChatGPT（在新窗口中打开）

• 研究
• 产品
• 企业
• 开发者
• 公司
• 基金会（在新窗口中打开）

尝试 ChatGPT（在新窗口中打开） 登录

OpenAI

目录

2026 年 5 月 4 日

工程

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

作者：Yi Zhang 和 William McDonald，技术团队成员

分享

语音 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（选择性转发单元）是一种媒体服务器，它从每个参与者接收一个 WebRTC 流，并有选择地将流转发给其他参与者。在此模型中，SFU 为每个参与者终止一个独立的 WebRTC 连接，AI 作为会话中的另一个参与者加入。这种模式非常适合本质上为多方的场景，如群组通话、课堂或协作会议。它将音频编解码器、RTCP 消息、数据通道、录制和每流策略集中管理。

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

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

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

核心部署问题：WebRTC 遇上 Kubernetes

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

从运维角度看，收发器服务承担两项职责：

• 信令：SDP 协商、编解码器选择、ICE 凭据和会话建立
• 媒体：终止下游 WebRTC 连接，并维持与后端服务的上游连接，用于推理和编排

我们希望该服务像其他基础设施一样运行：在 Kubernetes 上，工作负载可根据需求动态扩缩容并在主机间迁移。但传统的“每个会话一个端口”WebRTC 模型与该环境不兼容，因为它依赖大量公开的 UDP 端口范围，这些端口在 Pod 增加、移除或重新调度时难以暴露、保护和保持稳定。

#### 端口耗尽

第一个问题是“每个会话一个端口”模型本身。在高并发下，这意味着必须暴露和管理非常大的 UDP 端口范围。

• 云负载均衡器和 Kubernetes 服务并非围绕每服务数万个公共 UDP 端口设计。每个额外的端口范围都会增加负载均衡配置、健康检查、防火墙策略和发布安全性的运维复杂性。
• 大范围 UDP 端口难以保障安全，因为它们扩大了外部可访问的攻击面，使网络策略更难审计。
• 它们也不适合自动扩缩容。Kubernetes 中的 Pod 不断被添加、移除和重新调度。要求每个 Pod 预留并通告一个大而稳定的端口范围，会使这种弹性变得脆弱。

这正是许多 WebRTC 系统转向每个服务器一个 UDP 端口、并在该端口后进行应用层解复用的原因。

#### 状态粘性

每个服务器一个端口的设计解决了端口数量问题，但引入了第二个问题：在集群中保持每个会话的所有权。

ICE 和 DTLS 是有状态协议。创建会话的进程必须持续接收该会话的数据包，以便验证连接检查、完成 DTLS 握手、解密 SRTP，并处理后续会话变更（如 ICE 重启）。如果同一会话的数据包被发送到不同进程，设置可能失败或媒体中断。

这为我们设定了明确目标：向公共互联网暴露一个小而固定的 UDP 接口，同时确保每个数据包都能路由到拥有对应 WebRTC 会话的收发器。

#### WebRTC 媒体架构对比

我们评估了多种实现方式，包括 TURN（通过中继绕过 NAT），其中边缘中继终止客户端分配并代为转发流量。

方法 | 优点 | 缺点 ---|---|--- 每个会话唯一 IP:端口（又称原生直接 UDP）| 直接客户端到服务器的媒体路径<br>数据路径中无转发层 | 每个会话需一个公共 UDP 端口<br>大端口范围难以暴露和保护<br>与 Kubernetes 和云负载均衡器不兼容 每个服务器唯一 IP:端口 | 公共 UDP 范围远小于按会话暴露<br>每个服务器共享一个套接字可解复用多个会话 | 在单台主机上运行良好，但无法单独在共享负载均衡集群中工作<br>单主机解复用仅在数据包到达该主机后有效；在负载均衡集群中，首个数据包仍可能落在错误实例上，因此仍需确定性方式将每个会话引导至拥有它的进程 TURN 中继（协议终止）| 客户端只需连接到 TURN 中继地址 |