只有当网络“消失”时，语音 AI 才会显得自然
OpenAI 发布了一篇罕见的基础设施层面文章，详细说明其如何在全球规模下提供低延迟语音 AI，并概述了对 WebRTC 栈的重新设计，以支持包括 ChatGPT 语音、Realtime API 以及需要在用户仍在说话时处理音频的代理工作流在内的实时语音交互。
这个工程问题很容易描述，却很难解决。相较于许多其他软件交互形式，口语对延迟的容忍度要低得多。当系统犹豫、打断用户，或在用户插话时响应过慢，人们会立刻察觉。OpenAI 将这一挑战归纳为三个具体要求：面向超过 9 亿周活跃用户的全球覆盖；快速建立连接，让用户在会话开始后尽快开口；以及低且稳定的媒体往返时间，并尽可能减少抖动和丢包，从而保持清晰的轮次切换。
这些目标也解释了为什么公司近期的工作重点已不再只是模型行为本身，而是让语音显得即时的传输系统。在语音产品中，模型的智能只是体验的一部分，其余部分取决于数据包传输的速度和可靠性。
为什么 WebRTC 对 AI 产品很重要
OpenAI 的文章强调，WebRTC 仍然是客户端到服务器语音 AI 的实用基础，因为它标准化了交互式媒体传输中最棘手的环节。其中包括通过 ICE 完成连接建立和 NAT 穿越，通过 DTLS 和 SRTP 实现加密传输，通过 RTCP 进行编解码协商和质量控制，以及回声消除和抖动缓冲等客户端能力。
对于同时运行于浏览器、移动应用和服务器基础设施上的公司来说，这种标准化降低了碎片化。如果没有它，每一种客户端环境都需要为连接、加密、编解码支持和网络适配分别寻找方案。OpenAI 表示，依托成熟标准及更广泛的开源 WebRTC 生态，公司可以把工程精力集中在将实时媒体流连接到模型的基础设施上，而不是从零重建整套通信栈。
这对更广泛的 AI 行业来说是一个务实信号。实时 AI 不只是更快地生成音频，而是要以一种既保留熟悉客户端行为、又改变网络更深层发生内容的方式，将既有通信协议与模型服务系统整合起来。
迫使重构的规模约束
据 OpenAI 介绍，其实时 AI 团队之所以重构系统，是因为三项约束开始在规模化场景中相互冲突。首先，按会话占用单个端口的媒体终止方式并不适合 OpenAI 的基础设施。其次，有状态的 ICE 和 DTLS 会话需要稳定的归属关系。第三，全球路由必须尽量降低首跳延迟。
这些都是深层的运维问题，但它们指向更大的架构转变。早期或小规模的实时系统往往可以容忍一些在流量增长后会变得脆弱的设计。适用于大量会话的方案，并不一定适用于跨区域、跨网络条件分布的数百万并发交互。
OpenAI 给出的答案是其所称的“分离式中继加收发器”架构。核心思路是，从客户端视角保持符合标准的 WebRTC 行为，同时改变公司基础设施内部的数据包路由方式。换句话说，外部接口保持熟悉，但内部路径变得更适合 OpenAI 的规模、归属和路由需求。
这一设计选择反映了大型基础设施系统中常见的模式：如果可以把复杂性往内收，就尽量不要破坏客户端。对于构建语音 API 的开发者来说，这一点很有吸引力。边缘侧保持标准行为可以降低集成摩擦，而更困难的全球媒体编排则由服务提供方承担。
