在開發即時語音 AI 應用時，延遲是決定使用者體驗的最關鍵因素。如果對話之間有明顯的停頓，AI 就會失去自然感。OpenAI 最近分享了他們如何在大規模全球環境下，調整 WebRTC 的架構來實現低延遲的語音互動。對於習慣傳統 WebRTC 實作的工程師來說，OpenAI 的作法提供了一個將協定複雜度與擴展能力解耦的絕佳範例。
首先我們需要理解 WebRTC 是什麼。WebRTC 全稱 Web Real-Time Communication，是一套讓瀏覽器或行動裝置能直接進行即時音訊、視訊傳輸的開源標準。它之所以重要，是因為它內建了處理網路複雜度的機制，例如 NAT Traversal（NAT 穿越，解決私有 IP 無法直接從外網訪問的問題）、加密傳輸、編解碼協商以及抖動緩衝（Jitter Buffering，處理網路封包到達時間不均的問題）。
在傳統的 WebRTC 部署中，伺服器通常扮演媒體終端（Media Termination）的角色。然而，當系統規模擴大到全球且部署在 Kubernetes 這種雲端環境時，傳統模式會遇到嚴重的運維挑戰。最核心的問題在於 UDP 埠號的管理。WebRTC 依賴 UDP 傳輸，若每個會話（Session）都需要在伺服器上開啟特定的公網 UDP 埠，將導致埠號管理極其複雜，且容易造成伺服器資源利用不均，導致系統在更新或擴展時變得非常脆弱。
為了克服這些問題，OpenAI 放棄了將 AI 模型視為會議參與者的 SFU（Selective Forwarding Unit，選擇性轉發單元）模式。SFU 通常用於多方視訊會議，將媒體流分發給多個使用者，但對於 AI 語音對話這種一對一（1:1）的場景，SFU 過於沉重且不必要。
OpenAI 採取的解決方案是將架構拆分為兩層：輕量級轉發層（Relay）與狀態轉發層（Transceiver）。
第一層是 Relay。這是一個極其簡單且幾乎無狀態（Stateless）的層級。它的唯一工作就是接收來自使用者的封包並將其轉發到後端。因為 Relay 不處理複雜的協定邏輯，它能快速部署在靠近使用者的邊緣節點，大幅降低公網 UDP 的暴露風險，並縮短媒體傳輸的來回時間（RTT）。
第二層是 Transceiver。這裡才是真正處理 WebRTC 核心邏輯的地方。所有的狀態管理，包括 ICE 協商（決定最佳傳輸路徑）、DTLS 握手（建立加密通道）、SRTP 加密以及整個會話的生命週期管理，全部集中在 Transceiver 層。
這種拆分設計的實務意義在於將複雜度集中化。對於工程師來說，最糟糕的設計是將複雜的協定邏輯分散在每個後端服務中，或者強迫客戶端去適應後端的不便。OpenAI 的做法是將 WebRTC 的複雜性封裝在一個薄薄的路由層（Transceiver）中，而讓前端的 Relay 保持高效與簡單。
總結來說，這種架構為開發即時媒體系統提供了重要的思考方向：在邊緣端保留協定行為，將沉重的會話狀態集中管理，並將擴展的複雜度移至輕量級的路由層。這不僅解決了雲端環境下 UDP 埠號管理的痛點，更確保了全球使用者都能獲得穩定且低延遲的 AI 語音體驗。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。