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中的編碼路由元數據，使得第一包路由無需額外數據庫查詢，從而在保持低延遲的同時實現了全球可擴展性。