OpenAI 近日釋出 GPT-Live 工程文章，詳細披露了新版 ChatGPT 語音系統背後的架構改造。其中最引人注目的資料是：新系統的 p95 音訊幀延遲已降至舊系統 p50 的水平，意味著新系統中最慢的 95% 的音訊幀，現在都能跑得和舊系統中最快的 50% 音訊幀一樣順滑。雖然 OpenAI 未公佈具體毫秒數，但這一結果說明改造主要壓縮了那些偶發但明顯的慢幀。

GPT-Live 的核心變化在於不再等待使用者說完一句話再開始工作，而是讓聲音持續進入模型，模型生成的語音也持續返回使用者。搜尋、工具呼叫和複雜推理則被移到另一條非同步路徑。這一設計借鑑了人類神經系統的多級延遲通道，構建了多路即時傳輸網路：快速通道負責“不假思索”的反饋，處理音訊流的截斷、情緒隨動；深度通道由 GPT-5.5 等主力模型處理複雜的語義理解和長程推理；非同步任務則包括搜尋、工具呼叫和資料儲存等，被徹底移出主路徑。

在工程實現上，OpenAI 將媒體前端和部分推理邏輯從 Python asyncio 改寫為 Go，因為 Python 在高併發下的執行緒排程、記憶體分配和垃圾回收過程中的不可控停頓是製造 p95 延遲的元兇。同時，OpenAI 優化了 Linux 核心層，使用 SO_REUSEPORT 讓多個工作單元共享同一個 UDP 埠，由核心實現負載均衡；負責讀取 UDP 的 Go 協程固定在作業系統執行緒上，減少執行緒遷移和 CPU 快取失效；預分配接包緩衝區，減少記憶體複製。這些後端改進最終反映在 p95 上：新系統不是隻降低平均延遲，而是讓絕大多數音訊幀都能穩定按時到達。

在網路層面，OpenAI 開發了名為 WARP 的自定義協議，將 DTLS 握手、SCTP 建立和資料通道協商合併，將通道啟動從 6 次網路往返縮短到 1 次。具體做法是把路由提示寫進 WebRTC 的 ICE ufrag，使 Relay 在收到第一個包時無需查詢遠端 Redis 就能知道該把資料送往哪個例項，在記憶體中直接建立對映，消滅了一次跨網路查詢。雖然從 6 次往返縮短到 1 次並不意味著整體啟動速度提高 6 倍，但它移除了多次必須等待網路返回的步驟，對於跨地區連線，減少完整網路往返通常比壓縮服務端程式碼更有效。

音訊傳輸穩定後，GPT-Live 還需解決模型在持續對話中管理發言權和會話狀態的問題。過去的語音系統依賴獨立的回合檢測器，根據靜音時間判斷使用者是否說完；GPT-Live 則把這項判斷放進語音模型本身，音訊持續進入模型，模型一邊理解內容，一邊決定繼續聽、開始回答、暫停輸出或接受打斷。這要求主模型在整場會話中持續執行，但 OpenAI 尚未公佈這種方式增加的計算成本，也未給出誤搶話和錯誤打斷的資料。

打斷是其中最難處理的一環。使用者可能在第 4 秒插話，但模型已生成到第 10 秒，部分音訊甚至已發到客戶端。系統不能只停止繼續生成，還要分別記錄模型生成到哪裡、伺服器傳送到哪裡、使用者實際聽到哪裡，下一輪對話只能以使用者真正聽見的部分為準。OpenAI 未公開播放確認和音訊撤銷的具體協議，但文章提到最新訊息的文字、時間範圍和說話者歸屬都可以繼續修改，意味著模型輸出不會立即成為最終記錄。

持續語音還要求模型例項能夠在不中斷會話的情況下遷移。一場長會話會儲存對話上下文和 KV Cache，直接切換到空白例項會導致新例項重新處理全部歷史，語音可能出現停頓。OpenAI 的做法是讓舊例項繼續執行，同時啟動新例項並完成 Prefill，新例項補齊準備期間新增的音訊、追上當前進度後，系統才切換媒體流。上下文壓縮也沿用這套機制，舊例項繼續對話，後台壓縮歷史並準備新例項，等新例項完成狀態追趕後再接管，但會暫時佔用雙份推理資源。至於多次壓縮後長期要求、未完成任務和工具狀態能保留多少，官方尚未公佈資料。

雙模型架構真正難處理的不是把任務交給後台，而是保證結果回來時仍接得上當前對話。GPT-5.5 開始搜尋或呼叫工具後，GPT-Live 不會停下來等待，而是繼續接收聲音、回應使用者。期間使用者可能補充條件、改變問題甚至取消原任務，後台模型返回的答案即使正確也可能已不適用。因此每個後台任務都需繫結發起時的上下文位置，結果返回後要先判斷當前對話是否仍延續原意圖，可理解為一次帶狀態校驗的“斷點續傳”。OpenAI 未公開任務版本、取消訊號和過期結果的具體處理機制，但這些能力決定了系統能否避免讀出已失效的答案。

此外，模型處理的是連續聲音，而 ChatGPT 的搜尋、日誌、安全和聊天記錄需要一條條明確的訊息。應用伺服器會先維護一份允許修改的臨時記錄，再根據時間、轉錄和發言權確認最終訊息。介面使用更新更快的推測狀態，日誌、分析和部分安全系統則依賴順序更穩定的權威記錄。正式上線前，OpenAI 通過影子測試將真實語音會話同時送入新舊系統，發現一個輔助元件比預期更早飽和並拖慢推理佇列，說明雙模型協作能否穩定接續不只取決於模型速度，還取決於網路、佇列和狀態服務能否共同跟上。

從公開內容看，GPT-Live 的技術重點不是某個單獨模型變快了，而是重新劃分了即時語音系統中的責任：音訊被放進獨立快速路徑，WebRTC 入口被拆成 Relay 和 Transceiver，路由資訊被放進連線協議本身，模型例項可帶著上下文遷移，複雜任務則交給預熱好的後台模型。這些設計也帶來額外成本，如持續推理增加主模型佔用、例項切換和上下文壓縮短時間使用雙份算力、Relay 增加一次內部轉發、雙模型系統需處理任務過期和狀態不同步。目前 OpenAI 公佈了 p95 達到舊系統 p50 的音訊幀資料，以及 WebRTC 網路往返從 6 次降到 1 次，但持續推理的單位成本、實際打斷準確率、長會話多次壓縮後的資訊損失以及後台結果過期的比例仍未披露。

GPT-Live 的這次工程拆解給全行業提了個醒：即時性不是模型的恩賜，而是系統排程的紅利。系統的瓶頸往往不在 GPU 推理，而是某個輔助元件（如日誌或狀態儲存）的先飽和。OpenAI 改寫 GPT-Live 的核心思路在於不再只關注 GPU 每秒處理多少 Token，而關注系統能同時維持多少場“幀穩定”的語音會話。雖然持續推理的單位成本、長會話壓縮後的資訊損失等資料仍有待進一步驗證，GPT-Live 目前已經證明持續語音已從單純的模型“實驗室能力”變成了一套可以在 ChatGPT 規模下執行的完整工程系統。對於國產 Agent 開發者來說，或許不必再死等 GPT-5 變快，真正拉開差距的戰場在 WebRTC 的握手包裡、在 Go 的記憶體管理裡、在那個能隨時回滾的狀態機裡。