← #793

OpenAI 是怎么把语音 AI 的延迟做到全球可扩展的

文章摘要

OpenAI 这篇工程博客披露了他们如何为 9 亿+ 用户提供实时语音 AI 服务的底层架构。核心挑战是要同时满足三个条件：全球覆盖、快速建立连接、低抖动低丢包的稳定媒体传输——任何一项不达标，对话就会从”自然交流”退化为”对讲机体验”。

他们的解决方案是 Relay + Transceiver 双层架构，把”包路由”和”协议终结”拆开：

Relay 层：一个轻量级 UDP 转发服务，几乎无状态，只读取包头元数据决定路由，不解密媒体、不跑 WebRTC 协议状态机。Relay 部署在全球多地，让用户就近接入。
Transceiver 层：完整的 WebRTC 端点，承接 ICE 连通性、DTLS 握手、SRTP 加密、codec 协商等所有有状态工作。

最巧妙的工程取舍是路由信号嵌入协议本身——他们没有用外部查找表，而是把路由信息编码到 ICE username fragment（ufrag）里，这样 Relay 收到第一个包就能确定性地路由到对的 Transceiver。这是利用了 WebRTC 协议本身已有的”原生路由钩子”，零额外开销。另一个收益是单端口模型：把对外暴露的 UDP 端口压缩到一小批稳定地址，解决了”每会话一个端口”在 Kubernetes 部署下的水土不服。

实现细节也值得抄：Relay 用 Go 写，借助 SO_REUSEPORT 把负载分摊到多个 worker，配合 OS 线程绑定提升 cache 命中率，预分配 buffer 减少 GC 压力。没有用 kernel-bypass 框架（DPDK/XDP）——朴素的 userspace 实现已经够用。这套设计对客户端完全保留 WebRTC 标准语义（不需要私有 SDK），同时让 OpenAI 后端能在 Kubernetes 里水平扩展，不用对外暴露成千上万个 UDP 端口。

HN 评论精华

Sean-Der（Pion WebRTC 作者）：从 WebRTC 专家视角给出客观评价——OpenAI 没办法控制推理服务器的延迟，所以只能在自己能掌控的环节（WebRTC 传输层）上把功夫做到极致。这是务实的工程取舍，不是拍脑袋造轮子。
doctorpangloss：质疑这套方案部分是”重新发明轮子”——libwebrtc 本身就有不少 feature flag 能解决类似问题；但承认 OpenAI 选择自研可能是出于运维可控性考虑。
ericmcer：把矛头指向产品体验——网络层的微秒优化重要，但更要命的是模型本身的 VAD（语音活动检测）和反应速度。用户感受到的”卡”主要来自模型，不是网络。
Lucasoato：吐槽核心问题——Realtime API 用的还是老版 4o 模型，前沿模型的能力没下放到语音。希望 OpenAI 优先把新一代实时音频模型放出来，这比 WebRTC 调优收益大十倍。
legohead：从 UX 角度指出一个让人崩溃的痛点——自然停顿会被识别成”用户说完了”，GPT 立刻开始抢话。这让对话节奏变得不自然，与其优化 50ms 网络延迟，不如先解决这个 turn-taking 的产品问题。
hadlock：用 Realtime 跑技术讨论被”完全脑残化”——同一个模型在文本端能聊得很深，到语音端就只会复读教科书定义。这种”语音版被砍 60% 智能”的现状，是当前 OpenAI 语音方案的真正软肋。
评论区共识：技术博客本身写得很扎实（WebRTC 工程师圈子里少见的高质量产业实践），但产品层面，OpenAI Voice 的瓶颈早已不是网络层。