在即時 AI 應用中，最核心的挑戰在於如何讓對話保持流暢且反應迅速。當使用者與 AI 進行語音對話時，任何微小的延遲或卡頓都會讓互動顯得不自然。OpenAI 最近公開了 GPT-Live 的工程實作細節，揭露了他們如何透過特定的系統架構，在處理複雜的應用邏輯與維持低延遲媒體傳輸之間取得平衡。
背景與核心設計挑戰
語音互動與文字對話不同，它對時間極其敏感。在一個完整的語音 AI 系統中，必須處理音訊的採集、傳輸、模型推理以及最後的語音合成。然而，系統在運作時還需要處理其他非即時的任務，例如呼叫外部工具、儲存對話術紀錄或執行權限驗證。如果將這些具有不確定延遲的任務與語音傳輸放在同一個處理路徑上，一旦外部服務回應緩慢，使用者就會感受到明顯的對話中斷。
為了克服這個問題，OpenAI 採取了路徑分離的設計策略。他們將系統分為兩個主要部分：即時路徑（Live Path）與非同步路徑。即時路徑僅包含媒體管線（Media Pipeline）與推理迴圈（Inference Loop），確保語音數據能像流水一樣持續且穩定地傳遞。而所有其他應用邏輯，例如委派任務（Delegation）、工具調用（Tool Use）與持久化儲存（Persistence），則被放置在一個非同步的遠端程序呼叫（RPC, Remote Procedure Call）邊界之外。RPC 是一種允許程式在不同地址空間或不同機器上執行子程序的機制，透過將其設為非同步，系統可以在不阻塞語音流的情況下，在後台處理較慢的業務邏輯。
狀態管理與動態擴展
連續的語音對話本質上是具備狀態的（Stateful），這意味著模型必須記得之前的對話內容才能維持上下文。在分散式系統中，管理狀態通常會增加擴展的難度，因為使用者必須被固定在特定的伺服器實例上。
OpenAI 採用了專屬且具狀態的推理方式。每個對話會話會在指定的實例上預留計算資源，以確保回應速度。然而，為了維持系統的彈性與可用性，他們設計了一套實時遷移機制。當某個伺服器實例需要回收資源（Draining）或者對話的上下文長度接近上限時，系統能將該會話的狀態動態地遷移到另一個模型實例中。這種設計讓 OpenAI 能夠根據需求隨時增加或減少伺服器數量，而不會導致使用者的對話中斷。
傳輸層的優化與 WebRTC 的演進
在媒體傳輸方面，OpenAI 選擇保留 WebRTC（Web Real-Time Communication）作為基礎。WebRTC 是一種開放標準，旨在讓瀏覽器和行動應用程式能夠在不需要插件的情況下進行即時音訊、視訊與數據傳輸，它具備成熟的錯誤恢復機制與低延遲特性。
雖然業界有如 RTP over QUIC 等新興協議，但 OpenAI 認為這些協議目前僅提供傳輸層，缺乏完整的媒體管線支持，且在擁塞控制（GCC, Google Congestion Control）與路徑選擇等功能上尚未完善。因此，他們選擇在 WebRTC 的基礎上開發一套名為 WARP（WebRTC Abridged Roundtrip Protocol）的改良方案，旨在簡化握手流程以降低啟動延遲。
WARP 包含多項獨立改進，例如 SPED、DTLS 1.3 以及 SNAP。這些模組化設計讓工程團隊可以單獨測試每一項優化對效能的影響。此外，由於這是在 WebRTC 標準之上進行的改良，現有的 WebRTC 應用程式無需修改代碼即可獲益，對整個生態系具有正面影響。
實務驗證與沉默測試
在正式上線前，OpenAI 採取了一種特殊的驗證方式，稱為沉默測試（Silent Test）。他們將真實的生產環境語音流量鏡像到 GPT-Live 系統中，但將應用服務設定為唯讀模式且不含用戶憑證，最關鍵的是，系統會處理所有輸入並生成輸出，但隨即將輸出捨棄，不傳回給使用者。
這種做法的意義在於，傳統的壓力測試通常使用合成的語音樣本，無法模擬真實世界中全球不同地理位置、不同網絡環境與多樣化語音特性的複雜度。沉默測試揭露了合成測試無法發現的性能瓶頸。例如，工程團隊發現某些地區的 GPU 與負責餵資料的 CPU 並未部署在同一物理位置，導致產生意料之外的延遲。透過在真實流量中驗證修復結果，OpenAI 才能確保系統在正式發布時能承受實際的負載。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。