为什么 WebRTC 是语音 AI 的错误选择

OpenAI 最近发布了一篇关于他们如何大规模交付低延迟语音 AI 的技术深度解析。虽然这项工程壮举令人印象深刻，但它揭示了一个根本性的矛盾：他们正在使用 WebRTC——一种为人类对人类会议设计的协议——来驱动人类对 AI 的交互。

对于许多开发者来说，WebRTC 是实时音频的默认选择。然而，随着语音 AI 要求的演进，WebRTC 的局限性——从激进的数据包丢失到令人头疼的连接握手——正成为显著的瓶颈。为了构建真正可扩展、高质量的语音 AI 体验，我们需要超越 WebRTC 这一“协议风衣”，转向 QUIC。

产品错配：延迟 vs. 准确性

WebRTC 是为了一个主要目的而构建的：实时人类对话。在会议通话中，最关键的因素是“现在”。如果丢失了一个数据包，WebRTC 不会关心；它会丢弃音频并继续进行，以保持对话的流动性。这就是为什么你在通话质量差时会听到机器人般的杂音或失真的音频。

在语音 AI 的语境下，这种行为是适得其反的。当用户提出一个复杂的提示词（prompt）时——例如，“我应该步行还是开车去洗车房？”——丢失的一个数据包可能会将其变成“我应该步行还是开车去车？”一个糟糕的提示词会导致糟糕的响应。

虽然低延迟很重要，但用户通常更愿意接受 200ms 的延迟，以确保他们的提示词被准确捕获。WebRTC 对实时交付优于可靠性的硬性坚持，使其不适合 AI 交互的“提示词-响应”本质。

WebRTC 的技术债

实现 WebRTC 是出了名的困难，因为它不是单一协议，而是近 45 个 RFC 和各种事实标准（de-facto standards）的集合。这种复杂性体现在几个关键方面：

1. 连接握手噩梦

建立 WebRTC 连接是一个昂贵的过程。在信令服务器（TCP, TLS, HTTP）和媒体服务器（ICE, DTLS, SCTP）之间，可能需要超过八个往返（RTT）才能启动一个会话。即使使用边缘节点，这种开销也是显而易见的。这种复杂性之所以存在，是因为 WebRTC 是为点对点（P2P）连接设计的，这迫使服务器执行一种在服务器拥有静态 IP 时并不必要的“舞蹈”。

2. 端口扩展性问题

WebRTC 通常期望为每个连接使用一个临时端口，以处理 IP 变更（例如从 WiFi 切换到蜂窝网络）。在大规模应用时，这简直是一场灾难：服务器端口耗尽，且企业防火墙会拦截它们。

为了解决这个问题，许多服务（包括 OpenAI）不得不采取“黑客手段（hacks）”。他们将多个连接复用（mux）到单个端口上，并使用 STUN 头部或 ufrag 来路由数据包。这本质上破坏了协议原生的处理 IP 变更的能力，这意味着开发者只是在寄希望于用户的源 IP 在会话期间不会发生变化。

3. 人为延迟与缓冲

由于文本转语音（TTS）通常可以比实时速度更快地生成音频，因此可以在客户端侧进行缓冲以平滑网络波动。然而，WebRTC 根据到达时间进行渲染，几乎没有缓冲机制。为了防止音频播放过快，服务器必须在发送数据包之前引入人为的“睡眠”周期，这反而增加了拥塞期间数据包丢失的风险。

替代方案：为什么 QUIC 是协议中的“猛男 (Chad)"

如果 WebRTC 是问题所在，那么 QUIC（HTTP/3 的基础）就是解决方案。QUIC 通过设计解决了 WebRTC 最严重的缺陷：

连接 ID vs. IP 映射

不同于 TCP 或 WebRTC，QUIC 使用 CONNECTION_ID（由接收方选择）。这允许连接在即使用户的 IP 地址发生变化时依然保持持久。服务器不需要跟踪源 IP/端口；它只需查看数据包中的 ID。

无状态负载均衡

使用 QUIC-LB，后端服务器可以将自己的 ID 编码进 CONNECTION_ID 中。这意味着负载均衡器不需要全局 Redis 集群或共享状态来知道该将数据包发送到哪里；它只需读取 ID 并将数据包转发到正确的服务器。这实现了零状态、全球任播（anycast）路由。

快速设置

QUIC 将传输层和加密层握手结合在一起，将连接建立过程缩减为单个 RTT。与 WebRTC 的比较，其在“语音生成时间（time-to-speech）”上的差异是巨大无比的。

反方观点与考量

需要注意的是，WebRTC 并没有一无是处。正如一些行业专家指出的，放弃 WebRTC 意味着失去一个成熟的音频 DSP（数字信号处理）流水线生态系统，包括：

  • Acoustic Echo Cancellation (AEC)
  • Noise Suppression
  • VAD (Voice Activity Detection)
  • NAT Traversal maturity

转向 WebSockets 或 QUIC 需要开发者重新实现这些功能，或者寻找替代库。此外，有人认为，对于真正的“实时”感，WebRTC 激进的数据包丢弃机制是防止 AI 的“魔力”被延迟所破坏的必要之恶。

最终结论

WebRTC 是 2005 年时代 P2P 视频通话的绝佳方案。但对于 2026 年时代的语音 AI，它是一个过时的负担。虽然 OpenAI 的工程团队已成功通过“黑客手段”让 WebRTC 在前所未有的规模下工作，但他们本质上是在为一个有缺陷的协议构建复杂的变通方案。

对于那些正在构建下一代语音 AI 的人来说，前路已明：利用 QUIC 的高效性以及 WebTransport 的灵活性。别再试图强行让 WebRTC 适配了。

Sources