OpenAI 重構 WebRTC 語音堆疊：900M 週活用戶、Go 寫的 relay 為核心
OpenAI 5 月 4 日公布語音 AI 基礎建設細節—為了支撐每週 9 億活躍用戶（Weekly Active Users）的語音 AI 服務、團隊重新設計 WebRTC 堆疊、把媒體連線層從傳統「一個埠對一個 session」的架構、改寫為以 Go 撰寫的薄型 relay、把所有 WebRTC session 狀態集中在一個叫「transceiver」的服務。OpenAI 官方部落格解釋、這套架構同時支援 ChatGPT 語音模式、Realtime API、與多項研究專案。對任何在做語音 AI 工程的團隊、本案是「全球規模語音 AI 怎麼撐起來」的少見技術文獻。
三個技術限制：傳統 WebRTC 在 OpenAI 規模下都撞牆
OpenAI 工程團隊在文中明確指出三個「在規模放大後互相衝撞」的限制：
- 傳統「一 session 一埠」的媒體終結（per-session port termination）方式不適合 OpenAI 基建—當每週 9 億用戶可能同時開啟語音 session、每個都佔用一個埠的設計會耗盡網路資源
- 有狀態的 ICE（Interactive Connectivity Establishment）與 DTLS（Datagram Transport Layer Security）會話、需要穩定的擁有者—在分散式系統裡、若 session 狀態被多個服務分擔、容錯與遷移會極為複雜
- 全球路由必須維持低首跳延遲（first-hop latency）—語音 AI 的「自然感」決定於 turn-taking（對話切換）的順暢、首跳超過 100ms 就會明顯卡頓
OpenAI 的需求清單同樣明確：全球觸及（覆蓋 9 億+ 用戶）、快速 session 建立（用戶開口就能說話）、低且穩定的媒體 round-trip time（包含低 jitter 與封包遺失）。
廣告 - 內文未完請往下捲動
解法：Go 寫的薄 relay + 集中式 transceiver 服務
OpenAI 的架構分為兩層：
Relay 層—用 Go 撰寫、實作刻意保持簡單。一個普通的 Go process、從 socket 讀封包標頭、更新少量流量狀態、轉發封包、不終結 WebRTC。這是讓 relay 可橫向擴展的關鍵—不需要維持完整 WebRTC 狀態、relay 之間互換無痛、單點故障也不會中斷整個 session。
Transceiver 層—唯一擁有 WebRTC session 狀態的服務、包含 ICE 連線檢查、DTLS 握手、SRTP 加密金鑰、與 session 生命週期管理。把這些狀態集中到一個服務、讓 session 的歸屬好推理、後端服務可以像普通服務那樣擴展、不必各自當 WebRTC peer。
這個設計的精妙之處在於：把「需要狀態的部分」和「無狀態的部分」嚴格分離。Relay 是無狀態的數據平面（可大量複製）、transceiver 是有狀態的控制平面（少量但狀態完整）。這個分層也讓 OpenAI 可以隨用量水平擴展、不必擔心 WebRTC 連線數量爆炸。
為什麼用 Go：語音 AI 工程的選擇邏輯
OpenAI 文中明確說明 relay 用 Go 寫、實作刻意保持窄。這個選擇背後的工程邏輯：
- Go 的 goroutine 對「一個埠處理數萬連線」這類 IO-bound 任務原生支援、不必複雜的事件迴圈
- 標準函式庫的 net 套件可直接讀 UDP 封包、不必綁定 C 函式庫
- 編譯後是單一靜態 binary、部署、容器化、跨架構（x86/ARM）都簡單
- Go 的記憶體管理對「大量短壽命物件」（每個封包都要解析）友好、GC 暫停時間可控
這也說明為什麼 Go 在現代基建層（Cloudflare、Tailscale、HashiCorp 等）的滲透率持續上升—不是「Go 比某語言更厲害」、而是「Go 在 IO-bound、需橫向擴展的基建場景中、寫起來最直接」。
Cloudflare 的對位：Realtime Voice AI 戰場
Cloudflare 同期間（5 月初）也發布技術部落格〈Cloudflare 是建構即時語音代理最好的地方〉、與 OpenAI 對位提出自家方案。兩家路線分歧：
- OpenAI：自建 WebRTC relay／transceiver 堆疊、不依賴第三方、把媒體層也納入自家技術棧
- Cloudflare：把 WebRTC 媒體服務作為自家 Workers 平台的延伸、給開發者「一站式」基建
對中小型 AI 應用團隊、Cloudflare 路線更實用—直接呼叫 API、不必自建 WebRTC 基建。對 OpenAI 規模的團隊、自建是必經之路—外部服務的 SLA、計費結構、地理分佈都不可能完全配合。
後續觀察：transceiver 開源、Realtime API 規模、競爭對手回應
下一階段的觀察重點：
- OpenAI 是否將 transceiver / relay 部分開源—Anthropic、Google、xAI 等競爭對手都在自建語音堆疊、若 OpenAI 開源、會成為產業標準
- Realtime API 的計費與規模—目前主要靠 ChatGPT 訂閱攤提、若 API 收入成長、會否成為獨立產品線
- Anthropic 與 Google 的對應—Claude 與 Gemini 都已支援語音、但延遲與規模相比 OpenAI 仍有差距、本次技術揭露會否加速他們的工程跟進
對台灣 AI 應用開發者、語音 AI 是 2026 下半年的關鍵戰場—客服、教育、車載、IoT 等場景都需要低延遲對話。OpenAI 這次的工程揭露、是判斷「該自建語音堆疊還是用第三方 API」最重要的參考之一。
風險提示
加密貨幣投資具有高度風險，其價格可能波動劇烈，您可能損失全部本金。請謹慎評估風險。
