對於語音 AI 而言，知道何時該說話比聽起來更困難。人類說話者能在一瞬間輕鬆地互相交接，但先前的語音 AI 系統卻無法跟上這種節奏。它們的輪流式架構依賴於稱為「輪流偵測器」的微小模型，這些模型面臨著一項艱鉅的任務：猜測太早，使用者會被中斷；猜測太晚，回應則會顯得遲緩。只有在偵測器做出決定後，規模更大的 LLM 才能開始工作。

GPT-Live 是我們的第三代語音系統，它將輪流偵測器從音訊路徑中移除。其語音模型是全雙工的，這意味著它可以同時聽取和說話。這消除了對獨立偵測器的需求，使對話感覺更即時、更自然。當需要更深入的推理或工具使用時，GPT-Live 也能諮詢我們的前沿模型，例如 GPT-5.5，而不會中斷對話流程。這些能力共同賦予 GPT-Live 前所未有的對話回應速度和智慧結合。

要大規模提供這種體驗，需要一個針對低延遲優化的新系統架構。與典型的請求-回應推論不同，我們的系統將傳入的音訊串流到語音模型中，並將傳出的語音串流回使用者，同時在獨立的非同步路徑上處理委派任務。在過去六個月中，我們重新設計了模型推論、上下文管理和媒體傳輸，以確保語音從頭到尾流暢無阻。

該架構還在核心語音路徑和應用程式邏輯之間建立了清晰的界線。這使得客製化應用程式行為變得容易，而不會影響回應速度。這個基礎支援了 ChatGPT Voice 中日益增長的功能，包括新推出的在 ChatGPT 桌面應用程式中控制電腦和協調代理的能力。

在這篇文章中，我們將解釋為什麼早期的輪流式系統無法滿足我們的需求，以及我們如何在每個層面設計新系統以實現回應速度。我們將涵蓋有狀態推論、動態上下文管理、非同步委派和協定級別優化，所有這些都協同工作，讓 GPT-Live 感覺真正「即時」。

早期的語音架構繼承了文字 LLM 的輪流式特性，但每個輪流都表示為一個離散的音訊區塊而非文字。在串聯系統中，語音轉文字、LLM 和文字轉語音都依序運行。這種排序增加了延遲，並忽略了語氣和語速等線索。

語音轉語音模型透過直接處理音訊改進了這種方法。訓練模型原生理解和生成語音，使其能夠保留轉錄中丟失的細節並更快地回應。但系統仍然依賴輪流偵測器來決定何時可以開始推論。模型處理了更多的互動，但互動仍然是輪流式的。

GPT-Live 讓語音模型掌控對話：音訊流入和流出模型，而更深入的推理和工具使用則非同步發生。系統的主要工作是維持不間斷的媒體迴圈。其他工作，例如調用前沿模型和持久化對話，則發生在即時路徑之外。

保持這個媒體迴圈不間斷並非總是那麼簡單。傳輸、處理或推論中的任何延遲都可能變成可聽見的停頓或雜音。先前的輪流式系統可以容忍音訊區塊到達時間的一些變化。然而，即時媒體系統需要按時傳遞每個音訊幀。

ChatGPT Voice 和 Realtime API 的早期工作為我們奠定了重要基礎。我們已經重建了語音基礎設施，以更低、更可預測的延遲直接將音訊和視訊串流進出我們的系統。GPT-Live 進一步推動了這一設計，透過為連續對話而構建的新有狀態推論系統，將媒體一路串流到模型。

然而，串流推論只是解決方案的一部分。為了使其在生產中良好運行，我們還必須確保從客戶端到推論堆疊的可靠音訊傳輸，並處理有狀態性帶來的挑戰。

我們早期做的一個決定是將媒體流與應用程式和業務邏輯明確分離。音訊在客戶端和語音模型之間透過專用的快速路徑移動。委派、工具使用和其他應用程式工作則發生在非同步 RPC 邊界之後。一個緩慢的工具調用或後端服務可能會延遲其自身的結果，但不會阻礙媒體流的傳輸。

這種分離也為系統提供了清晰的客製化邊界。應用程式可以更改其工具、策略和後端行為，而不會影響負責保持音訊移動的媒體前端。即時路徑保持小巧、可預測，並專注於必須即時發生的工作。

我們使用 Go 語言編寫了媒體前端和推論邏輯，取代了以前的 Python asyncio 實作。這顯著改善了幀傳輸的流暢度，新系統的 p95 表現與舊系統的 p50 相當。

WebRTC 提供了傳輸基礎。它專為低延遲媒體設計，即使在封包遺失、時鐘漂移和客戶端連線變更的情況下也能繼續運行。如果封包延遲到達，WebRTC 可以巧妙地拉伸音訊以防止間隙，然後短暫加速播放以追趕回即時。

透過最小化整個系統中的緩衝和阻塞，我們可以提供人類對話所期望的亞秒級回應速度。

有狀態推論有其自身的營運權衡。語音會話可能會長時間保持活躍，但其上下文會持續增長，並且模型實例會根據需求啟動和關閉。

為了解決這些問題，我們建立了跨模型實例的無縫交接機制。當需要轉換時，我們可以在現有模型實例旁邊預熱一個替換模型實例，用當前會話上下文預填充它，並行地對兩者運行推論，並在新實例完全準備好時進行切換。

相同的基本機制也支援動態上下文壓縮。隨著對話的進行，其累積的上下文最終可能會超出模型的上下文限制。壓縮可以減小上下文大小以適應限制，但此操作需要時間。而且由於它改變了過去的上下文，它也會使模型的鍵值 (KV) 快取失效，該快取儲存了先前處理過的 token 的注意力鍵和值。重建該狀態需要新的預填充，這會引入額外的延遲。

相反，我們將壓縮視為另一種受管理的轉換。當原始模型實例繼續聊天時，系統會壓縮上下文並準備一個帶有新上下文的替換模型實例。一旦該實例準備就緒，我們就可以在不中斷媒體的情況下進行切換。這使得系統能夠支援長時間通話，並在必要時進行壓縮。

繁重的工作都保留在即時路徑之外，因此即使在交接過程中，對話也從未中斷。

GPT-Live 能夠調用現有的前沿模型，這賦予它強大的能力，有效地將「說話」與更深入的「思考」解耦。但要讓這種雙模型架構感覺像一個系統，需要解決兩個相關的工程問題。

首先，結果必須足夠快地返回，以便在正在進行的交流中有用，因此我們必須最小化整個委派路徑的延遲，從路由和提示處理到推論和工具調用。同時，產品中其他地方的系統仍然需要離散的訊息，因此我們必須以它們能理解的形式表示正在進行的對話。

當委派被分派時，我們優化的是前沿模型產生對對話有用的內容所需的時間。語音模型可以短暫地保持交流進行，同時前沿模型進行推理或使用工具，但它無法隱藏任意緩慢的回應。因此，我們將完整的委派迴圈——路由、提示處理、推論和工具調用——視為回應速度預算的一部分。

第一個優化是在請求委派之前設置好前沿模型及其所需的任何工具。當語音會話開始時，應用程式伺服器會為前沿模型創建一個推論會話，並用初始對話上下文預填充它，確保在第一個委派請求之前提示已完全處理。

然後，我們在語音對話期間保持該推論會話可用，並為連續請求使用穩定的會話親和性。這些技術與提示快取結合使用，可以改善延遲，同時工作器故障仍然易於恢復。

推理工作量、輸出限制、工具架構和模型-工具往返時間也會影響對話何時收到有用的結果，我們調整了這些槓桿以獲得更快的響應。透過最小化委派路徑所需的工作，我們使語音模型能夠快速整合來自我們前沿模型的結果。

儘管語音模型在連續的語音流上運行，但其周圍的許多系統仍然在使用者和助理的輪流上運行，包括 ChatGPT 的對話 UI 以及我們的分析和安全基礎設施的一部分。因此，應用程式伺服器將重疊、偶爾模糊的對話分解為離散的訊息。

當音訊到達時，伺服器使用部分轉錄和時間信號來推斷哪個說話者佔據主導地位，並建立一個訊息佇列。最新的訊息仍然是暫定的；隨著更多語音的到來，其文字、時間和說話者分配都可能改變。一旦說話者持續佔據主導地位足夠長的時間以確保歸屬可靠，伺服器就會最終確定相應的訊息。

說話者重疊使這變得更加複雜。助理在使用者說話時的簡短確認（例如「嗯哼」或「好的」）不一定會成為一個獨立的訊息。然而，實質性的助理插話通常應該如此。同樣，即使使用者在中間說話，我們也優先考慮顯示的助理回應的連貫性。

每個分割策略都在新鮮度與確定性之間進行權衡。過早提交會產生零碎的歷史記錄和不穩定的排序；等待太久會延遲轉錄和依賴它們的功能。因此，系統維護了對話的兩個相關視圖：當前狀態的推測視圖和所說內容的權威記錄。應用程式 UI 中的對話視圖可以處理更新，因此它使用推測視圖。但記錄到分析管道需要最終的轉錄。

這為 ChatGPT 的其餘部分提供了穩定的交流視圖，而無需在即時語音路徑上強制執行輪流。

回應速度從使用者點擊按鈕的那一刻就開始了。對於 GPT-Live，系統必須建立媒體路徑並開始透過模型傳輸音訊，然後對話才能開始。這使得啟動序列的每個部分都處於關鍵路徑上。

如上所述，WebRTC 提供了強大的即時基礎，但啟動一個普通的 WebRTC 會話需要驚人的協定握手和網路往返。WebRTC 早於後來塑造 QUIC 等協定的最小化往返的重點。因此，其底層協定在一起使用時有時會重複工作。例如，每個協定都包含自己的反 DoS 機制，即使在完整的 WebRTC 堆疊上下文中並不需要它。

我們將 WARP 設計為一組開放規範，並與合作夥伴合作。