# 策展 · X (Twitter) 🔥🔥🔥🔥🔥

> 作者：OpenAI Developers (@OpenAIDevs) · 平台：X (Twitter) · 日期：2026-05-05

> 原始來源：https://x.com/OpenAIDevs/status/2051453905343828350

## 中文摘要

OpenAI 重新設計 WebRTC 堆疊實現低延遲語音 AI。

OpenAI 即時 AI 互動團隊透過「分離式 relay 加 transceiver」架構，解決大規模部署 WebRTC 的埠耗盡、狀態黏著與全球路由延遲問題，服務超過 9 億週活躍使用者，讓語音對話跟上說話節奏，避免尷尬停頓或截斷插話。

**WebRTC 在 AI 產品的核心價值**

WebRTC 作為開放標準，標準化 ICE（互動式連線建立）、DTLS（資料包傳輸層安全協定）、SRTP（安全即時傳輸協定）、codec 協商、RTCP（即時傳輸控制協定）與客戶端功能如回音消除與抖動緩衝，讓 OpenAI 無需從頭處理 NAT 穿透、加密與網路適應，直接聚焦連接媒體與模型。  
對語音 Agent 而言，音訊連續流到達最關鍵，使用者說話中即可轉錄、推理、呼叫工具或產生語音，區別於「按下說話」式系統。  
團隊建構於 Pion 開源實作與 Justin Uberti（WebRTC 原始架構師）、Sean DuBois（Pion 創建者）基礎，如今兩人皆為 OpenAI 同事，強化 WebRTC 與即時 AI 整合。

**媒體架構選擇：transceiver 優於 SFU**

SFU（選擇性轉發單元）適合多方通話如群組或會議，將音訊 codec、RTCP、資料通道集中處理，但 OpenAI 多為 1:1 延遲敏感 session（如使用者對模型或應用對 Agent），故選 transceiver 模型。  
- transceiver 在邊緣終結 WebRTC 連線，擁有 ICE、DTLS 握手、SRTP 金鑰與 session 生命週期，將媒體轉為簡單內部協定供推論、轉錄、生成與調度。  
- 後端服務無需扮演 WebRTC peer，更易擴展；狀態集中簡化所有權，避免分散複雜。

**Kubernetes 部署痛點：埠耗盡與狀態黏著**

首版 transceiver 以 Go 基於 Pion 實作，處理信令（SDP 協商、codec 選擇、ICE 憑證）與媒體（終結下游 WebRTC、上游後端連線），驅動 ChatGPT 語音、Realtime API 與研究專案。  
傳統「每個 session 一個埠」模型不適 Kubernetes：  
- 高並發需數萬 UDP 埠，雲端負載平衡器、健康檢查、防火牆與 rollout 複雜，擴大攻擊面，阻礙 pod 新增/移除/調度彈性。  
- 「每台伺服器一個 UDP 埠」解埠問題，但 ICE/DTLS 有狀態，封包須黏著原行程，否則連線檢查、握手、解密或 ICE restart 失敗，媒體中斷。

**核心架構：relay + transceiver 分離**

解決方案分離「封包路由」與「協定終結」：信令直達 transceiver 設定 session，媒體先經 relay（輕量 UDP 轉發層，小固定公開介面），relay 只讀 metadata 轉發，不解密、不執行 ICE、不協商 codec，客戶端視為標準 WebRTC。  
- **首封包路由基於 ICE ufrag**：伺服器端產生含路由 metadata 的 ufrag（username fragment），SDP answer 回傳共享 relay VIP（如 203.0.113.10:3478），首 STUN binding request 經 ufrag 解碼轉發至 transceiver（共享單 UDP socket，非每個 session 一 socket）。  
- **後續封包**：經快取（Redis 保存 <客戶端 IP:Port, transceiver IP:Port>）透明轉發，狀態極簡（記憶體 session、計數器、逾時清理），重啟僅短暫丟失，下 STUN 重建。

**全球部署：Global Relay 與地理導向**

Global Relay 為地理分散入口，縮短首跳延遲、減抖動與封包遺失。  
Cloudflare geo/proximity steering 導信令至鄰近 transceiver 叢集，決定 session 地點與 Global Relay 位址；ufrag 導媒體至指定叢集與 transceiver。  
結合讓信令與媒體走鄰近路徑，縮短首次 ICE 檢查往返時間，使用者更快開始說話。

**Relay 實作與效能優化**

以 Go 撰寫精簡 userspace 實作，無 kernel-bypass，避免維運複雜：  
- 不終結協定，只解析 STUN/ufrag；後續 DTLS/RTP/RTCP 用快取不透明轉發。  
- 暫態記憶體狀態，水平擴展，多實例後負載平衡，重啟快速恢復。  
效率措施：  
- SO_REUSEPORT：多 worker 綁定同一 UDP 埠，核心分配封包避瓶頸。  
- runtime.LockOSThread：goroutine 釘 OS 執行緒，同 flow 封包留同一 CPU 核心，優快取局部性、減 context switching。  
- 預配置緩衝、最少記憶體複製減解析開銷、避垃圾回收。  
小規模 relay 已承載全球流量，證明無需 kernel bypass。

**成果與關鍵心得**

架構讓 WebRTC 在 Kubernetes 運行，無需暴露數千 UDP 埠，提升保全、負載平衡與擴展；小攻擊面、更好基礎設施支援，確認無 SFU 適合 1:1 延遲敏感負載，推論服務更易擴展。  
心得強調複雜度置薄路由層，而非後端或客戶端自訂：  
- 邊緣保留 WebRTC 語義，保瀏覽器/行動互通。  
- 硬狀態集中 transceiver，relay 只轉發。  
- 用 ICE ufrag 現有鉤子實現確定性首封包路由，無熱路徑查詢。  
- 先優一般情況，再 kernel bypass；Go + SO_REUSEPORT 等足夠。  
即時語音 AI 需基礎設施讓延遲「不可察覺」，OpenAI 改變 WebRTC 部署形態，但維持客戶端期望。

## 標籤

功能更新, OpenAI