OpenAI 的 WebRTC 方案可能不是语音 AI 的最优解

OpenAI 前几天发了一篇技术博客，讲他们怎么用 WebRTC 做语音 AI 的实时通信。结果被一个 WebRTC 老兵怼了——不是普通的批评，是从协议层面说你根本不该用这个。

写文章的人叫 Luke Curley，在 Twitch 写过 WebRTC SFU，在 Discord 用 Rust 重写过 WebRTC SFU。用他自己的话说："我大概算个认证级 WebRTC 专家。所以我再也不想用 WebRTC 了。"

他的核心观点很直接：WebRTC 和语音 AI 的适配度很差。

问题出在哪

WebRTC 的设计目标是视频会议——低延迟、实时交互、丢包了就丢了。但语音 AI 的需求不一样：

你的语音输入是一次昂贵的 prompt。 你对着手机说"我应该走路还是开车去洗车店"，这句话被送到 OpenAI 的服务器上，跑一遍 LLM 推理，再 TTS 生成语音回复。整个过程里，用户的输入就是 prompt，丢了等于白花钱。

WebRTC 的做法是：网络不好时 aggressively drop packets（ aggressively 丢弃数据包）来保持低延迟。开会通话里你听到断断续续的声音就是这个原因。对开会来说，延迟比音质重要。对语音 AI 来说，一个完整的 prompt 比 200ms 延迟重要得多。

更麻烦的是，WebRTC 在浏览器里不支持重传音频包。Discord 试过，搞不定 SDP munging。就算能打开 audio NACKs，WebRTC 的 jitter buffer 也太小了。

结果就是：用户说的一句话，在网络不好的时候被截断了，LLM 收到的是一个残缺的 prompt，返回的也是错误的回答。用户不会知道是自己的网络问题——他只会觉得这个 AI 很蠢。

另一个技术细节更有趣。

OpenAI 的 TTS 生成语音的速度比实时快（比如 2 秒 GPU 生成 8 秒音频）。理想情况是：边生成边发送，客户端缓存起来再播放。这样网络抖动时，本地缓存能兜底。

但 WebRTC 没有缓冲机制，数据包到了就按到达时间渲染。为了补偿这个缺陷，OpenAI 不得不在发送每个音频包之前故意加一段 sleep，让包在正确的时间到达客户端。

这等于人为引入延迟，然后又 aggressively 丢包来"保持低延迟"。作者在原文里用了个很形象的比喻：这就像用屏幕分享来放 YouTube 视频，而不是用缓冲播放。

WebRTC 还有一个工程上的坑：端口管理。

TCP 服务器开一个端口（比如 443）就能服务所有连接。WebRTC 需要管理大量 UDP 端口，每个连接都要协商 ICE、STUN、TURN。在大规模部署时，这是一个不小的运维负担。

OpenAI 的博客里花了不少篇幅讲他们的 load balancer 怎么解决这个问题。作者的潜台词是：如果你用的协议不需要这些 workaround，你就不用花这些力气。

文章推荐的替代方案是 MoQ（Media over QUIC）——一个基于 QUIC 的实时媒体协议，正在 IETF 标准化中。Cloudflare 已经提供了 CDN 支持。

MoQ 的优势在于：

当然，MoQ 还没到生产级。IETF 标准还在 draft 阶段，生态远不如 WebRTC 成熟。但对于语音 AI 这个新兴领域，现在做技术选型可能比以后回头改要省事得多。

这篇文章的价值不在于"OpenAI 做错了"，而在于提醒了我们：语音 AI 的基础设施选型还在早期阶段，WebRTC 可能是路径依赖而不是最优解。

视频会议的协议直接拿来用做语音 AI，就像用 HTTP/1.1 做实时游戏通信——能用，但不是最合适的工具。

对于正在构建语音 AI 产品的团队，建议认真评估一下 WebRTC 的 trade-off。如果你的场景里 prompt 完整性比 200ms 延迟更重要，可能值得看看 QUIC-based 的方案。

主要来源：