OpenAI如何為9億使用者提供低延遲語音AI
本文詳細介紹了OpenAI如何透過WebRTC和創新的架構分離策略，為9億使用者提供低延遲的語音AI服務。文章分析了傳統WebRTC部署在Kubernetes上的問題，並展示了OpenAI如何透過無狀態中繼和有狀態收發器的分離，利用ICE ufrag進行路由，以及全球中繼部署來最佳化延遲。
OpenAI每週為9億使用者提供語音AI服務，為了實現低延遲，他們選擇了WebRTC協議。WebRTC最初是為具有穩定IP和埠的伺服器設計的，而Kubernetes將地址視為可丟棄的，這給部署帶來了挑戰。傳統的解決方案是使用SFU（選擇性轉發單元），但OpenAI的流量主要是使用者與模型的一對一對話，因此他們選擇了一種更高效的架構。
該架構將系統分為兩部分：一個無狀態中繼，負責協議感知的資料包路由，位於地理邊緣；一個有狀態收發器，負責所有WebRTC狀態。兩者之間的關鍵連線是利用ICE使用者名稱片段（ufrag），該欄位在連線建立期間交換，中繼可以從新會話的第一個資料包中讀取它，並將其作為路由金鑰。此方法避免了熱路徑上的資料庫查詢或隨機路由帶來的延遲。
在信令階段，收發器生成一個共享中繼VIP和UDP埠，客戶端將資料包傳送到該穩定地址。中繼維護一個記憶體中的源地址到收發器目的地的對映，用於後續資料包。如果中繼重啟，Redis快取可快速恢復對映。為了進一步降低延遲，OpenAI部署了全球中繼，即分佈在全球的中繼入口點。所有中繼執行相同的包轉發行為，僅地理位置不同。這減少了客戶端到OpenAI網路的第一個網路跳數，從而降低了延遲並提高了穩定性。
除了架構本身，OpenAI還進行了套接字級最佳化，例如使用共享UDP套接字來避免埠耗盡，並實現了使用者空間Go實現以提高效能。這些最佳化共同確保了語音AI體驗的流暢性，使其如同真實對話而非對講機。此外，OpenAI的工程團隊還考慮了SFU和TURN等替代方案，但最終選擇了中繼-收發器分離架構，因為它在1:1對話場景下更高效。整個系統依賴於ICE ufrag中的編碼路由後設資料，使得第一包路由無需額外資料庫查詢，從而在保持低延遲的同時實現了全球可擴充套件性。