OpenAI 语音 AI 延迟降低 50%:背后架构首次公开

说句话就能得到回答，这种”实时对话感”是语音 AI 产品的核心竞争力。但在大规模场景下，降低延迟远比听起来困难。2026年5月4日，OpenAI 工程团队发布了关于低延迟语音 AI 架构的详细技术博客，首次公开了他们如何解决这个问题的完整思路。

这篇文章没有止步于”我们做了优化”——它直接拆解了从 WebRTC 选型到 Kubernetes 部署的每一个工程决策。对正在做或想了解 AI 语音应用的人来说，这是难得的一手资料。

问题出在哪里

语音 AI 和普通 HTTP 请求不同。用户的语音数据要持续流转，同时 AI 要边听边转写、边推理、边生成回复。如果等用户说完了再处理，整段对话就会变成”按一下说一句”的尴尬体验。

OpenAI 当时面临的工程困境是：他们的语音产品（如 ChatGPT 语音模式）已经触达超过 9 亿周活用户，需要同时满足三个要求——全球覆盖、快速连接（用户一进来就能说话）、稳定且低延迟的媒体传输。

但 WebRTC 的标准部署方式（大容量公网 UDP 端口池）在 Kubernetes 环境下遇到了三个硬墙：

端口耗尽。 每个 WebRTC 会话需要一个独立公网 UDP 端口。Kubernetes 环境下 pods 不断扩缩，端口范围管理变得极其复杂。云负载均衡器、防火墙策略、灰度发布都与此绑定，一个出错就影响大量用户。

状态粘性。 WebRTC 使用 ICE 和 DTLS 等有状态协议，一旦数据包路由到错误的进程，握手可能失败，媒体流会断掉。在 Kubernetes 自动调度环境下保持状态一致性，是工程团队必须解决的问题。

全球延迟。 用户分布在世界各地，如果语音包要先跨公网绕到远端服务器再回来，延迟会直接飙升。

怎么解决：Relay + Transceiver 架构

OpenAI 的方案是分离转发层和协议终止层，他们称之为 Relay + Transceiver 架构。

Transceiver 是有状态的 WebRTC 端点，负责完整的 WebRTC 会话状态，包括 ICE 连接检查、DTLS 握手、SRTP 加密密钥，以及会话生命周期管理。它同时处理信令（SDP 协商、会话建立）和媒体（终止下游 WebRTC 连接，维持到推理后端的上游连接）。

Relay 是一个轻量级 UDP 转发层，不解密媒体，不运行 ICE 状态机，也不参与编码协商。它只读取数据包的元数据来选择目标，然后转发给拥有该会话的 transceiver。

关键设计：Relay 通过 ICE 用户名片段（ufrag）里的路由元数据来路由第一个数据包。 transceiver 在会话设置时就已经把路由信息编码进了 ufrag，Relay 无需查询外部服务，就能直接把数据包送到正确的 transceiver。整个 Relay 层的设计是无状态的——如果 Relay 重启丢失了会话，下一个 STUN 数据包会从 ufrag 重建路由。

这样做有两个直接好处：公网 UDP 暴露面积极小（Relay 只需一个共享 UDP 端口），同时 transceiver 可以像普通服务一样扩缩，不用担心端口管理问题。

全球入口：Global Relay

在解决了 Kubernetes 内部的问题后，OpenAI 进一步把 Relay 部署扩展到全球，命名为 Global Relay。

通过 Cloudflare 的地理和邻近度 steering，用户的信令请求（HTTP 或 WebSocket）会先到达最近的 transceiver 集群，然后 SDP 回复里提供的 Global Relay 地址包含了足够路由信息，让媒体包从用户最近的入口进入 OpenAI 网络，而不是绕道跨洋。

结果是：延迟降低，抖动减少，避免了不必要的丢包。

为什么这个架构值得注意

这是语音 AI 系统工程化的里程碑事件。从 GPT-4o 语音演示到今天，语音实时对话已经成为 AI 产品竞争的主战场。但大家拼的不仅是模型能力——基础设施架构的合理性直接决定用户体验的天花板。

OpenAI 这次公开的架构有几个值得国内 AI 开发者参考的设计原则：

用协议原生的机制做路由，而不是额外引入查找服务。 ufrag 本身就是 WebRTC 会话的一部分，把它当作路由键使用，省掉了额外的状态存储依赖。Redis 缓存只用来加速故障恢复，正常路径完全自包含。

分离控制面和数据面。 信令走 transceiver，媒体走 Global Relay，两条路径各司其职。好处是扩缩独立，故障隔离也更容易。

无状态转发的哲学。 Relay 不保存会话，只保存临时的转发映射。即使全部重启，用户侧的下一个 STUN 包会自动重建路由，服务自动恢复，无需人工介入。

对中国读者的实际启发

启发一：如果你的产品也在用 WebRTC，重新评估端口暴露策略。 一port-per-session 在小规模场景没问题，但在 Kubernetes 环境下面向大规模用户时，OpenAI 的 relay 模式值得直接借鉴。特别是需要服务超过百万并发的团队，这个架构节省的运维复杂度是实实在在的。

启发二：语音 AI 延迟优化不只是模型推理的事。 很多团队以为把推理速度从 500ms 压到 200ms 就解决了延迟问题，实际上从用户麦克风到模型输入的网络路径优化往往能带来更大的端到端改善。Global Relay 的思路——让用户流量在最靠近的地方进入网络——同样适用于有自建语音服务的团队。

启发三：关注基础设施的工程化。 OpenAI 这次展示了什么叫”工程化严谨的产品级系统”。Relay 层无状态自愈、控制面和数据面分离、用 ufrag 做路由而非外部存储——这些不是黑科技，而是扎实的系统设计。国产大模型在追赶模型能力的同时，基础设施的工程化水平才是最终决定产品体验能否稳定的关键。

语音 AI 的竞争还在加速。架构公开之后，下一步看的是：谁能把这些工程思路落地到自己的产品里，真正把延迟压到”感觉不到”的程度。