OpenAI 公開 GPT-Live 幕後架構捨棄輪次偵測器，連線往返從 6 次減為 1 次

OpenAI 於 8 月 3 日發布技術文章，說明驅動 ChatGPT Voice 的語音系統 GPT-Live 是怎麼做出來的。文章記錄了長達 6 個月的改造：把猜測說話空檔的輪次偵測器從音訊路徑上移除，並將建立連線時的網路往返從 6 次壓縮到 1 次。這並不是一次模型發表，而是關於支撐這個模型每天運轉的底層架構說明。

讓模型自己決定何時開口

過去的語音 AI 仰賴一個稱為輪次偵測器（turn detector）的小型模型判斷使用者是否說完，要等它做出結論，體積大得多的 LLM 才能開始運作^[1]。判斷得太早會打斷使用者，判斷得太晚則回應遲鈍。無論偏向哪一邊，對話都會失去自然感，對一個小模型來說是相當吃力不討好的角色。

GPT-Live 是 7 月 8 日發表的第三代語音模型，採用可以同時聆聽與說話的全雙工架構^[2]。要說話、繼續聆聽、保持安靜、插話還是呼叫工具，這些判斷由模型本身每秒做出多次^[2]。輪次偵測器這個中間裁判從音訊路徑上消失之後，對話節奏就不再依賴外部的猜測^[1]。

把音訊通道與其他處理分開

設計初期就確立的一點，是把媒體流與應用程式邏輯明確分離^[1]。音訊走的是客戶端與語音模型之間的專用快速通道，而委派給前沿模型、執行工具等工作則在非同步 RPC 邊界之後進行。緩慢的工具呼叫只會拖延自己的結果，無法中斷媒體流。

這樣的分離也讓系統更容易擴充。應用程式可以更動工具、政策與後端行為，而不影響負責讓音訊持續流動的媒體前端。即時路徑維持精簡、可預測，只承擔必須即時完成的工作^[1]。

在實作上，媒體前端與推論邏輯從原本的 Python asyncio 改寫為 Go。影格傳送的流暢度明顯改善，新系統的 p95 已達到舊系統 p50 的水準^[1]。傳輸層採用 WebRTC，能在封包遺失、時脈漂移與客戶端連線變動的情況下繼續運作。封包延遲抵達時，WebRTC 會些微拉長音訊以避免出現空隙，接著短暫加速播放追回即時進度^[1]。

對話拉長也能無中斷更換模型執行個體

有狀態推論有它自己的維運代價。語音工作階段可能長時間保持開啟，脈絡卻不斷增長，而模型執行個體會隨需求啟動與關閉。

OpenAI 的做法是打造一套無縫接手機制。需要切換時，系統會預熱一個替換用的執行個體，以目前的工作階段脈絡預先填充，讓兩者並行推論，等新執行個體完全就緒後再切換過去^[1]。

同一套機制也用於脈絡的動態壓縮（compaction）。對話持續下去，累積的脈絡最終會超出模型上限。壓縮可以把它縮回限制之內，但因為改寫了過去的脈絡，會讓保存已處理 token 注意力鍵值的 KV 快取失效，重建這些狀態需要重新預先填充，因而產生額外延遲。把壓縮視為另一次受管理的切換來處理，原執行個體繼續對話，系統則在背景準備好帶有壓縮後脈絡的新執行個體，就緒後無中斷切換。繁重的工作留在即時路徑之外，對話不會漏掉任何一拍^[1]。

更深入的思考交給背景的 GPT-5.5

當請求需要搜尋或更深入的推論時，GPT-Live 會委派給 GPT-5.5 這類前沿模型^[1][2]。問題在於結果能不能及時回到對話裡。語音模型可以短暫維持交流，卻無法掩蓋任意緩慢的回應，因此整條委派路徑，包含路由、提示處理、推論與工具呼叫，都被納入了回應速度的預算之中^[1]。

具體做法是，語音工作階段一開始，應用程式伺服器就為前沿模型建立推論工作階段並預先填充初始對話脈絡，確保在第一次委派請求抵達之前提示已經處理完畢。之後這個推論工作階段會在整通對話期間保持可用，搭配穩定的工作階段親和性與提示快取進一步縮短等待時間^[1]。

另一項不太顯眼卻同樣關鍵的工作，是把連續的語音切分成離散的訊息。ChatGPT 的對話介面以及部分分析與安全基礎架構，至今仍以使用者與助理的輪次為單位運作。應用程式伺服器會利用部分逐字稿與時間訊號推斷由誰握有發言權，建立訊息佇列，並把最新一則視為暫定狀態，其文字、時間與說話者歸屬都可能隨後續語音而改變。助理簡短的附和不必自成一則訊息，實質性的插話則通常應該^[1]。

任何切分策略都是在即時性與確定性之間取捨：太早確定會讓歷史變得零碎，等太久則逐字稿落後。系統因此維持兩種對話檢視，一種是目前狀態的推測檢視，一種是已說內容的權威紀錄。能夠處理更新的介面使用推測檢視，分析管線則收到最終逐字稿^[1]。

WARP 與 Instant Connect：把 6 次往返壓成 1 次

從使用者按下按鈕的那一刻起，回應速度就開始被計算。WebRTC 為低延遲媒體而設計，但要啟動一次工作階段，卻需要出乎意料多的交握與網路往返。它誕生的時間早於 QUIC 等後續協定對減少往返的重視，因此各個子協定之間存在重複的工作，例如各自都帶有自己的抗 DoS 機制^[1]。

OpenAI 分析整個協定堆疊後，開發出 WARP（WebRTC Abridged Roundtrip Protocol），把媒體與資料的啟動從 6 次往返減少為 1 次。它由一組向後相容的改良組成：透過 SPED 讓 DTLS 交握搭載於 ICE 之上、採用更快的 DTLS 1.3 交握、透過 SNAP 預先協商 SCTP 交握，以及預先協商資料通道而不使用 DCEP^[1]。

值得注意的是，這項成果並沒有自我封閉。WARP 被設計成一組開放規格，由 WebRTC 社群的合作者共同參與，並正在 IETF 的 TSVWG 工作組推進標準化。其中的 SPED 已在 IETF 資料追蹤器登記為草案，被描述為讓 ICE 與 DTLS 並行進行的向後相容擴充^[3]。libwebrtc 與 Pion 已加入 WARP 支援，其他實作的工作也在進行中^[1]。

搭配的 Instant Connect 則把 SDP 信令交換移出關鍵路徑。它與標準信令流程並行運作，若預先協商的參數有效，伺服器會在第一個媒體封包抵達時直接建立工作階段；若參數已失效，一般信令流程本來就在進行，客戶端可以在不增加延遲的情況下退回。與 WARP 結合之後，客戶端只需一個 UDP 封包就能開啟工作階段^[1]。

以正式流量進行的靜默測試發現了什麼

一套系統在紙上看起來很快，遇到真實語音流量仍可能卡住。在讓使用者接觸 GPT-Live 之前，OpenAI 進行了靜默測試，把正式環境中一小部分並逐步增加的 ChatGPT Voice 工作階段，同時導向既有的 Advanced Voice Mode 與新系統。Advanced Voice Mode 照常服務使用者，新系統只以唯讀模式執行推論，使用者聽到的內容完全沒有改變^[1]。

第一個教訓是，容量無法簡化成 GPU 的處理量。語音工作階段會保持開啟並持續送出影格，因此 CPU 側的串流處理、佇列與網路路徑都必須與推論一起擴展。在真實負載下，一個周邊元件比負載測試的估計更早飽和，導致推論請求堆積、延遲層層累加。於是容量問題從一顆 GPU 能處理多少請求，改成在確保每一個影格準時送達的前提下系統能同時維持多少工作階段^[1]。

地理位置同樣成為第一線的考量。把工作階段導向較遠的容量，會在啟動與串流的多個環節增加延遲。長時間的工作階段暴露出記憶體與持久化的壓力，重新連線考驗壓縮與狀態還原，而一般的客戶端斷線則暴露了關閉交握中的競爭條件。這些問題都依賴時間與累積的狀態，短時間的負載測試很少能發現^[1]。

觀測與發布控制也一併重做。團隊發現有些指標把不同來源的延遲混在一起，有些儀表板的彙總值掩蓋了個別不健康的引擎，測試環境與部署環境之間還存在設定漂移。為此他們加入了更細緻的遙測、與已知良好設定的比對驗證、分階段放量，以及能快速隔離或停用個別路徑的能力^[1]。