對於開發者來說，要讓 AI 像真人一樣聊天，最難的不是「回答內容」，而是「掌握對話節奏」。傳統的語音 AI 往往有明顯的停頓感，或者在使用者還沒說完時就搶話。OpenAI 在開發 GPT-Live 系統時，核心目標就是打破這種「回合制」的僵局，讓 AI 能夠在毫秒等級內做出反應。
以下將從系統架構、狀態管理、以及網路傳輸三個維度，解析他們如何將語音 AI 從「對講機模式」進化為「真人對話模式」。
打破回合制：從 Turn-based 轉向 Full-duplex
早期的語音 AI 採取的是級聯式架構（Cascaded System），流程是：語音轉文字 (STT) $\rightarrow$ LLM 處理 $\rightarrow$ 文字轉語音 (TTS)。這種方式不僅延遲高，還會丟失語調與情緒等關鍵資訊。即便後來演進到端到端的語音模型 (Speech-to-Speech)，依然依賴一個稱為 Turn Detector（輪詢檢測器）的小模型來判斷使用者是否說完。
Turn Detector 的兩難在於：判斷太快會打斷使用者，判斷太慢則會讓對話顯得遲鈍。
GPT-Live 採取了全雙工 (Full-duplex) 設計，意味著模型可以同時進行聆聽與說話。它直接移除了輪詢檢測器，讓語音流直接進入模型。當需要深層推理或調用工具時，系統會將任務非同步地委託給更強大的模型（如 GPT-5.5），而不會阻塞目前的語音輸出流。
確保流暢度：將媒體路徑與邏輯路徑分離
為了保證語音不會卡頓，工程團隊將系統拆分為兩條路徑：
第一條是快路徑 (Fast Path)，專門處理媒體流。這條路徑只負責讓音訊在客戶端與語音模型之間快速傳遞，不承載任何業務邏輯。為了極大化性能，團隊將媒體前端與推理邏輯從 Python asyncio 遷移到 Go 語言，顯著提升了框架交付的穩定性（p95 延遲降低至原先 p50 的水準）。
第二條是非同步路徑 (Asynchronous Path)，處理委託任務（Delegation）、工具調用或後端服務。這樣即使一個 API 調用很慢，也不會導致使用者的聲音卡住或出現雜音。
狀態管理與動態上下文壓縮
語音對話通常持續時間較長，會導致上下文 (Context) 不斷增長，最終超過模型的限制。此外，模型實例的切換也會帶來延遲。
為了解決這個問題，GPT-Live 引入了無縫接手機制 (Handoff Mechanism)。當需要切換模型實例或進行上下文壓縮 (Context Compaction) 時，系統會在背景準備一個新的實例，將目前的對話狀態預填 (Prefill) 進去，並讓新舊實例短暫並行運行，待新實例就緒後立即切換。
由於上下文壓縮會導致 KV Cache（快取先前處理過 Token 的鍵值對，用以加速推理）失效，必須重新預填，這個過程非常耗時。透過這種「背景準備 $\rightarrow$ 無縫切換」的策略，使用者在對話過程中完全感覺不到系統正在進行記憶體清理或實例遷移。
傳輸層優化：從 6 次往返縮減至 1 次
即便模型推理再快，如果網路握手 (Handshake) 太慢，使用者點擊按鈕後仍會有明顯的空白期。
WebRTC 是目前低延遲媒體傳輸的標準，但標準的 WebRTC 建立連線需要多次網路往返 (Round Trips)。OpenAI 開發了 WARP (WebRTC Abridged Roundtrip Protocol) 協議，透過將 DTLS 握手與 ICE 結合、預協商數據通道等手段，將啟動所需的 6 次往返縮減為 1 次。
此外，他們還推出了 Instant Connect 技術，在使用者正式啟動對話前就預先協商好 SDP 參數（定義媒體能力與連線資訊的協議），讓客戶端可以用單個 UDP 封包就開啟會話。
實務教訓：容量不等於 GPU 吞吐量
在生產環境測試中，團隊發現一個關鍵痛點：語音會話是持續開啟的流，這與傳統的請求-響應模式完全不同。
他們發現，系統的瓶頸不再僅僅是 GPU 的推理速度，而是 CPU 端的流處理器、隊列以及網路路徑的併發能力。因此，他們將性能指標從「GPU 能處理多少請求」轉向「系統能維持多少個併發會話且不掉幀」。
來源：openai.com (How we built a realtime system for responsive voice AI in six months)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。