對於開發即時語音 AI 的工程師來說，最核心的挑戰不是模型能回答什麼，而是「對話感」。如果網路延遲導致出現尷尬的停頓、對話被截斷或反應遲緩，使用者會立刻感覺到這不是自然的交談。
要讓數億名使用者感受到像真人一樣的流暢對話，OpenAI 必須解決一個技術矛盾：WebRTC 協議的設計初衷與現代雲端原生（Cloud Native）基礎設施（如 Kubernetes）的運作方式並不相容。
了解 WebRTC 的基礎與痛點
WebRTC（Web Real-Time Communication）是一個開放標準，旨在讓瀏覽器或行動裝置能以低延遲傳輸音訊、視訊和數據。它解決了許多極其困難的網路問題，包括：
ICE（Interactive Connectivity Establishment）：一種連線建立機制，用來穿透 NAT（網路地址轉換），確保兩端設備能找到彼此並建立連線。 DTLS 與 SRTP：負責對傳輸內容進行加密，確保通話安全。 Codec（編解碼器）：將音訊壓縮以減少傳輸量，並在接收端還原。
對 AI 而言，WebRTC 最重要的地方在於它提供的是「連續流（Continuous Stream）」。這意味著 AI 可以在使用者還在說話時，就同步開始轉錄、思考並生成回應，而不是像傳統的「按下對講機（Push-to-talk）」模式，必須等使用者說完並上傳整個檔案後才處理。
傳統 WebRTC 架構在 Kubernetes 上的困境
在實作時，OpenAI 選擇了 Transceiver（收發器）模型。簡單來說，Transceiver 是一個邊緣服務，它負責終止 WebRTC 連線，將媒體流轉換為內部協議傳給後端 AI 模型。
但這在 Kubernetes 環境中遇到了三個大問題：
首先是連接埠耗盡（Port Exhaustion）。標準的 WebRTC 通常為每個連線分配一個 UDP 連接埠。當併發量極高時，伺服器需要開放數萬個公網 UDP 連接埠。這對雲端負載平衡器（Load Balancer）和防火牆來說是噩夢，且極難維護。
其次是狀態黏性（State Stickiness）。ICE 和 DTLS 是有狀態的協議。如果一個連線的封包在傳輸過程中，因為負載平衡被導向了不同的 Pod（容器實例），該實例沒有之前的握手狀態，連線就會直接中斷。
最後是全球分發的延遲。如果所有流量都集中在少數幾個區域，遠端使用者的第一跳（First-hop）延遲會很高，導致對話啟動緩慢。
OpenAI 的解決方案：Relay 與 Transceiver 分離架構
為了克服上述問題，OpenAI 重新設計了架構，將「封包路由」與「協議終止」拆分開來。
Relay（中繼層）：這是一個輕量級的 UDP 轉發層。它不負責解密、不處理 ICE 狀態機，也不參與編解碼協商。它的唯一任務是：讀取封包標頭，決定這個封包該送往哪個 Transceiver，然後快速轉發。
Transceiver（收發器層）：這是真正的 WebRTC 端點。它持有完整的會話狀態（ICE、DTLS 密鑰等），負責處理真正的業務邏輯與模型互動。
這種設計讓公網對外的 UDP 表面積大幅縮小，且讓後端服務能像一般無狀態服務一樣在 Kubernetes 中自由伸縮。
如何實現精準的封包路由
最關鍵的技術在於：Relay 如何在沒有建立會話的情況下，知道第一個封包該送去哪？
OpenAI 利用了 WebRTC 協議內建的 ufrag（ICE username fragment）。在會話建立的信令階段，Transceiver 會生成一個包含路由資訊的 ufrag 給客戶端。當客戶端發送第一個 STUN 封包（用來測試連通性）時，Relay 會解析這個 ufrag，從中提取目的地資訊，將封包導向正確的 Transceiver。
一旦路徑建立，Relay 會將「客戶端 IP:Port」與「Transceiver IP:Port」的映射關係暫存在記憶體或 Redis 快取中，後續的媒體封包就能直接快速轉發，無需再次解析。
全球分發與性能優化
為了極致降低延遲，OpenAI 部署了 Global Relay（全球中繼網路）。使用者會透過地理位置導向（Geo-steering）連接到最近的 Relay 進入點，縮短第一跳的距離，減少抖動（Jitter）與丟包。
在實作 Relay 時，為了避免 Go 語言的性能瓶頸，他們採取了幾項優化：
使用 SO_REUSEPORT：允許多個工作進程綁定同一個 UDP 連接埠，由核心分發封包，避免單一讀取迴圈成為瓶頸。 執行緒綁定（Thread Pinning）：使用 runtime.LockOSThread 將讀取封包的 Goroutine 固定在特定 CPU 核心，提高快取命中率並減少上下文切換。 減少記憶體分配：預先分配緩衝區，盡量減少對 GC（垃圾回收）的依賴。
總結與啟發
這套架構給我們的啟發是：當標準協議與現代基礎設施衝突時，不要試圖修改客戶端行為，也不要讓所有後端服務都變成複雜的協議端點。
最理想的做法是在邊緣建立一個「極薄」的路由層（Thin Routing Layer），將複雜的狀態管理集中在單一點（Transceiver），而將簡單的轉發交給可橫向擴展的 Relay。這樣既能保留 WebRTC 的標準兼容性，又能享受 Kubernetes 的彈性伸縮與全球分發的低延遲。
來源：openai.com - How OpenAI delivers low-latency voice AI at scale
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。