<mark id="oztn4"></mark>
0
| 本文作者： 鄭佳美 | 2026-08-06 21:47 |
作者丨鄭佳美
編輯丨岑 峰
在實時語音交互中，延遲是唯一的“死線”。
文字回答慢幾百毫秒，用戶頂多覺得體驗不佳；但音頻只要卡頓一次，那種“非人”的割裂感就會瞬間摧毀信任。為了解決這個工程頑疾，OpenAI 耗時 6 個月重做了整個語音系統。
剛剛，OpenAI 發布了一篇 GPT-Live 工程文章，詳細披露了新版 ChatGPT 語音系統背后的架構改造。其中最值得注意的一組數據是：新的媒體系統，其 p95 音頻幀延遲已經降到了舊系統 p50 的水平。
這意味著，新系統中最慢的 95% 的音頻幀，現在都能跑得和舊系統中最快的 50% 音頻幀一樣的順滑。
雖然 OpenAI 沒有公布具體毫秒數，但這個結果說明，改造主要壓縮了那些偶發但明顯的慢幀。
現在的 GPT-Live 不再等待用戶說完一句話再開始工作，而是讓聲音持續進入模型，模型生成的語音也持續返回用戶。搜索、工具調用和復雜推理則被移到另一條異步路徑。
01
GPT-Live 首先改掉的是音頻在服務器中的傳輸方式。
長期以來，開發者的通常做法是將語音 Agent 視為“語音轉文字->模型推理->文字轉語音”的單體推理系統，過去的語音系統音頻處理、模型調用、工具請求和聊天記錄保存，可能在同一套異步服務中運行。只要其中一個環節變慢，后面的任務就會排隊。
這種設計在文字產品中問題不大，但音頻幀不能長時間排隊。每一幀聲音都有對應的播放位置。它遲到以后，即使最終處理完成，也可能已經沒有意義。舊音頻一旦持續積壓，后續聲音也會越來越慢，整場對話逐漸落后于用戶當前所處的時間。雷峰網
OpenAI 參照人類神經系統的多級延遲通道構建了一套多路實時傳輸網絡：
快速通道：負責“不假思索”的反饋。處理音頻流的截斷、情緒隨動（如“嗯”、“我在聽”）。這一層對延遲極度敏感，通常由極小模型或硬編碼邏輯在邊緣側或前端處理；
深度通道：GPT-Live 的另一項核心設計是把實時交流和復雜推理解耦，構建邏輯中樞。由 GPT-5.5 等主力模型處理復雜的語義理解和長程推理；
異步任務：包括搜索、工具調用和數據保存等。這些任務被徹底移出主路徑，后臺任務可以推遲自己的結果，但不能卡住音頻。
媒體前端和部分推理邏輯也從 Python asyncio 改寫成了 Go。這并非簡單的“誰比誰快”的爭論，實時音頻處理的是大量體積很小、但時效要求極高的UDP數據包，Python在高并發下的線程調度、內存分配、數據復制和垃圾回收過程中的不可控停頓，則是制造p95延遲的元兇。
OpenAI 還進一步優化了Linux內核層：它使用 Linux 的 SO_REUSEPORT，讓多個工作單元共享同一個 UDP 端口，由內核實現負載均衡；
負責讀取 UDP 的 Go 協程會固定在操作系統線程上，減少線程遷移和 CPU 緩存失效；預分配接包緩沖區，減少內存復制。
這些后端工程上的改進，最終反映在 p95 上：新系統不是只把平均延遲降低，而是讓絕大多數音頻幀都能穩定按時到達。雷峰網(公眾號：雷峰網)
02
在網絡層面，標準 WebRTC 的建立需要 6 次網絡往返（RTT）。對于跨地區連接，光速的限制就足以造成明顯的首字延遲。
OpenAI 開發了名為 WARP 的自定義協議，將 DTLS 握手、SCTP 建立和數據通道協商合并。結果是將通道啟動從 6 次往返縮短到了 1 次。
OpenAI 的做法是把路由提示寫進 WebRTC 本來就會攜帶的 ICE ufrag，將路由提示直接寫進連接協議。Relay（轉發層）在收到第一個包時，不需要查詢遠程 Redis 就能知道該把數據送往哪個實例，在內存中直接建立映射，徹底消滅了一次跨網絡查詢。
雖然把從 6 次網絡往返縮短到 1 次并不意味著整體啟動速度提高了 6 倍（因為服務器調度、丟包、客戶端處理和模型準備仍然需要時間），但它確實移除了多次必須等待網絡返回的步驟。對于跨地區連接，減少完整網絡往返通常比繼續壓縮幾毫秒的服務端代碼更有效。
03
音頻傳輸穩定之后，GPT-Live 還要解決另一個更難的問題：模型如何在持續對話中管理發言權和會話狀態。
過去的語音系統通常依靠獨立的回合檢測器，根據靜音時間判斷用戶是否說完，再啟動主模型。GPT-Live 則把這項判斷放進語音模型本身。
音頻持續進入模型，模型一邊理解內容，一邊決定繼續聽、開始回答、暫停輸出，還是接受打斷。這樣可以結合語義、語氣和上下文判斷停頓，但也意味著主模型需要在整場會話中持續運行。
OpenAI 尚未公布這種方式增加了多少計算成本，也沒有給出誤搶話和錯誤打斷的數據。
打斷是其中最難處理的一環。用戶可能在第 4 秒插話，但模型已經生成到第 10 秒，部分音頻甚至已經發到客戶端。系統不能只停止繼續生成，還要分別記錄模型生成到哪里、服務器發送到哪里、用戶實際聽到哪里。下一輪對話只能以用戶真正聽見的部分為準，否則模型會誤以為某些內容已經講過。
OpenAI 沒有公開播放確認和音頻撤銷的具體協議，但文章提到，最新消息的文字、時間范圍和說話者歸屬都可以繼續修改。這意味著模型輸出不會立即成為最終記錄，而要根據打斷和實際播放情況重新確認。
持續語音還要求模型實例能夠在不中斷會話的情況下遷移。
一場長會話會保存對話上下文和 KV Cache。直接切換到空白實例，新實例需要重新處理全部歷史，語音就可能出現停頓。
OpenAI 的做法是讓舊實例繼續運行，同時啟動新實例并完成 Prefill。新實例還要補齊準備期間新增的音頻，追上當前進度后，系統才會切換媒體流。
上下文壓縮也沿用這套機制。舊實例繼續對話，后臺壓縮歷史并準備新實例，等新實例完成狀態追趕后再接管。這樣可以避免明顯中斷，但會暫時占用雙份推理資源。
至于多次壓縮后，長期要求、未完成任務和工具狀態能保留多少，官方目前還沒有公布數據。
04
雙模型架構真正難處理的，不是把任務交給后臺，而是保證結果回來時仍然接得上當前對話。
GPT-5.5 開始搜索或調用工具后，GPT-Live 不會停下來等待，而是繼續接收聲音、回應用戶。期間，用戶可能補充條件、改變問題，甚至取消原任務。后臺模型返回的答案即使本身正確，也可能已經不再適用于此時的會話。
因此，每個后臺任務都需要綁定發起時的上下文位置。結果返回后，系統不能直接播放，而要先判斷當前對話是否仍然延續原來的意圖。
可以把它理解成一次帶狀態校驗的“斷點續傳”：后臺模型從某個會話節點開始工作，完成后再確認這段結果能否安全接回已經向前推進的實時對話。
OpenAI 沒有公開任務版本、取消信號和過期結果的具體處理機制，但這些能力決定了系統能否避免讀出已經失效的答案。
另一個問題是，模型處理的是連續聲音，ChatGPT 的搜索、日志、安全和聊天記錄卻需要一條條明確的消息。用戶和助手可能同時說話，簡短回應未必需要單獨成句，用戶插入幾個字也未必代表真正打斷。應用服務器因此會先維護一份允許修改的臨時記錄，再根據時間、轉錄和發言權確認最終消息。
界面使用更新更快的推測狀態，日志、分析和部分安全系統則依賴順序更穩定的權威記錄。前者保證字幕及時出現，后者保證后臺任務能夠找到可靠的會話斷點。
正式上線前，OpenAI 還通過影子測試，把真實語音會話同時送入新舊系統。測試發現，一個輔助組件比預期更早飽和，并進一步拖慢推理隊列。
這也說明，雙模型協作能否穩定接續，不只取決于模型速度，還取決于網絡、隊列和狀態服務能否共同跟上實時對話。
05
從公開內容看，GPT-Live 的技術重點并不是某一個單獨模型變快了，而是 OpenAI 重新劃分了實時語音系統中的責任。
音頻被放進獨立快速路徑，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 的內存管理里，在那個能隨時回滾的狀態機里。
參考鏈接：
https://x.com/OpenAI/status/2084378418989379822
https://openai.com/index/continuous-voice-interaction-with-gpt-live/
上車，帶你看遍全球 AI 頂會精華
可獨家暢覽：
專家演講PPT
大會報告全文
熱門論文解讀
學術新星訪談
掃描上方二維碼
或點擊「閱讀原文」關注專區。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
