Why WebRTC is the Wrong Choice for Voice AI

OpenAI 最近發表了一篇技術深度解析，探討他們如何在大規模應用中提供低延遲的語音 AI。雖然這項工程成就令人印象深刻，但它揭示了一個根本性的矛盾：他們正在使用 WebRTC——一種為人類對人類會議設計的協定——來驅動人類對 AI 的互動。

對於許多開發者來說，WebRTC 是即時音訊的預設選擇。然而，隨著語音 AI 的需求不斷演進，WebRTC 的限制——從激進的封包遺失到令人噩夢般的連線握手——正成為顯著的瓶頸。為了構建真正具備擴展性且高品質的語音 AI 體驗，我們需要超越 WebRTC 這個「協定大衣」，轉向 QUIC。

The Product Mismatch: Latency vs. Accuracy

WebRTC 是為了單一主要目的而構建的：即時人類對話。在視訊會議中，最關鍵的因素是「現在」。如果一個封包遺失了，WebRTC 並不在乎；它會直接丟棄音訊並繼續進行，以保持對話流暢。這就是為什麼你在通話品質不佳時會聽到機器人般的雜音或失真的音訊。

在語音 AI 的情境下，這種行為是適得其反的。當使用者問一個複雜的問題時——例如，「我應該走路還是開車去洗車場？」——一個遺失的封包可能會將其變成「我應該走路還是開車去車？」一個錯誤的提示詞（prompt）會導致錯誤的回答。

雖然低延遲很重要，但使用者通常會寧願接受 200ms 的延遲，以確保他們的提示詞被準確捕捉。WebRTC 對於即時傳輸優於可靠性的硬性堅持，使其不適合「提示詞-回應」性質的 AI 互動。

The Technical Debt of WebRTC

實作 WebRTC 非常困難，因為它不是單一協定，而是近 45 個 RFC 和各種事實上的標準（de-facto standards）的集合。這種複雜性體現在幾個關鍵方面：

1. The Connection Handshake Nightmare

建立 WebRTC 連線是個昂貴的過程。在信令伺服器（TCP, TLS, HTTP）與媒體伺服器（ICE, DTLS, SCTP）之間，可能需要超過八個往返（RTT）才能啟動一個工作階段（session）。即使使用邊緣節點，這種開銷也是顯而易見的。這種複雜性之所以存在，是因為 WebRTC 是為點對點（P2P）連線設計的，這迫使伺服器執行一場不必要的「舞蹈」，當伺服器擁有靜態 IP 時，這其實是多餘的。

2. The Port Scaling Problem

WebRTC 通常預期每個連線使用一個臨時埠（ephemeral port）來處理 IP 變更（例如從 WiFi 切換到行動網路）。在大規模應用時，這會是一場災難：伺服器會耗盡埠號，且企業防火牆會阻擋它們。

為了這個問題，許多服務（包括 OpenAI）採取了「黑客手段（hacks）」。他們將多個連線複用（mux）到單一埠號上，並使用 STUN 標頭或 ufrag 來路由封包。這本質上破壞了協定原生的處理 IP 變更的能力，這意味著開發者只是在寄望於使用者的來源 IP 在工作階段期間不會改變。

3. Artificial Latency and Buffering

由於文字轉語音（TTS）通常可以比即時速度更快地生成音訊，因此有機會在用戶端進行音訊緩衝以平滑網路波動。然而，WebRTC 是根據到達時間進行渲染的，幾乎沒有緩衝機制。為了防止音訊播放得太快，伺服器必須在發送封包前引入人工的「睡眠」時段，這反而增加了擁塞期間封包遺失的風險。

The Alternative: Why QUIC is the "Chad" of Protocols

如果 WebRTC 是問題所在，那麼 QUIC（HTTP/3 的基礎）就是解決方案。QUIC 從設計上解決了 WebRTC 最嚴重的問題：

Connection IDs vs. IP Mapping

與 TCP 或 WebRTC 不同，QUIC 使用 CONNECTION_ID（由接收端選擇）。這允許連線在使用者 IP 地址變更時依然保持持續。伺服器不需要追蹤來源 IP/埠號；它只需查看封包中的 ID。

Stateless Load Balancing

使用 QUIC-LB，後端伺服器可以將自己的 ID 編碼到 CONNECTION_ID 中。這這意味著負載平衡器不需要全域的 Redis 集群或共享狀態來得知要將封包發送到哪裡；它只需讀取 ID 並將封包轉發到正確的伺服器。這實現了無狀態、全域任播（anycast）路由。

Rapid Setup

QUIC 結合了傳輸與加密握手，將連線建立過程縮減至單個 RTT。與 WebRTC 的多步驟過程相比，「從建立連線到發聲」的時間差異非常巨大。

Counterpoints and Considerations

值得注意的是，WebRTC 並非一無是處。正如一些業界專家所指出的，放棄 WebRTC 意味著失去一個成熟的音訊 DSP（數位信號處理）管線生態系統，包括：

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

轉向 WebSockets 或 QUIC 需要開發者重新實作這些功能，或者尋找替代函式庫。此外，有人認為，為了追求真正的「即時」感，WebRTC 激進的丟包策略是為了防止 AI 的「魔力」被延遲所毀掉而必須承擔的惡行。

Final Verdict

WebRTC 是 2005 年時代點對點（P2P）視訊通話的絕佳解決方案。但對於 2026 年時代的語音 AI，它是一個遺留負擔。雖然 OpenAI 的工程團隊已成功透過黑客手段讓 WebRTC 在前所未有的規模下運作，但他們本質上是為了一個有缺陷的協定構建了一個複雜的權宜措施。

對於正在構建下一代語音 AI 的人來說，前進的路徑很明確：利用 QUIC 的效率與 WebTransport 的靈活性。別再試圖讓 WebRTC 變得可行了。

Sources