我們如何在六個月內建構迅速回應的實時語音 AI 系統

對語音 AI 而言，判斷何時說話比想像中困難。人們能毫不費力地在一瞬間交替發言，但以往的語音 AI 系統無法跟上這種節奏。其輪流對話架構依賴稱為輪次偵測器的小型模型，面對一項棘手任務：判斷太早會打斷用戶，太遲則令回應顯得遲緩。只有偵測器作出決定後，規模大得多的 LLM 才能開始處理。

我們的第三代語音系統 GPT‑Live⁠，從音訊路徑移除了輪次偵測器。其語音模型採用全雙工運作，可同時聆聽和說話。這消除了另設偵測器的需要，讓對話更即時自然。需要更深入的推理或使用工具時，GPT‑Live 亦可在不中斷對話流程的情況下，諮詢 GPT‑5.5 等前沿模型。這些能力結合起來，讓 GPT‑Live 同時具備前所未有的對話回應速度和智能。

要大規模提供這種體驗，需要一套針對低延遲優化的新系統架構。有別於一般的請求—回應式推理，我們的系統會將傳入音訊串流至語音模型，再把輸出語音串流給用戶，同時透過另一條非同步路徑處理委派。過去六個月，我們重新設計了模型推理、上下文管理和媒體傳輸，讓語音端到端流暢傳送。

這套架構亦在核心語音路徑與應用程式邏輯之間建立清晰邊界。因此，我們可輕易自訂應用程式行為，而不影響回應速度。這項基礎支援 ChatGPT 語音日益豐富的功能，包括新推出的電腦控制功能，以及在 ChatGPT 桌面應用程式中協調代理的能力。

本文將說明以往的輪流對話系統為何無法滿足需要，以及我們如何從每一層着手設計新系統，以確保迅速回應。我們將介紹有狀態推理、動態上下文管理、非同步委派和協定層級優化，說明它們如何協同運作，讓 GPT‑Live 真正帶來實時體驗。

早期語音架構沿用文字 LLM 的輪流對話模式，但每個輪次以獨立音訊資料塊而非文字表示。在級聯系統中，語音轉文字、LLM 和文字轉語音依次執行。這種順序增加了延遲，亦忽略了語氣和節奏等線索。

語音到語音模型透過直接處理音訊，改善了這種方式。訓練模型原生理解和生成語音，讓它保留轉錄時流失的細節，並更迅速回應。但系統仍依賴輪次偵測器來決定何時可開始推理。模型處理了更多互動，但互動方式仍是輪流對話。

GPT‑Live 讓語音模型主導對話：音訊持續進出模型，而更深入的推理和工具使用則以非同步方式進行。系統的首要任務，是維持不中斷的媒體迴路。調用前沿模型和持久保存對話等其他工作，則在實時路徑以外進行。

要讓這個媒體迴路保持暢通並非易事。傳輸、處理或推理的任何延遲，都可能變成可聽見的停頓或雜音。以往的輪流對話系統可以容許音訊資料塊的抵達時間略有差異。然而，實時媒體系統必須準時傳送每一個音訊幀。

我們早前在 ChatGPT 語音和 Realtime API 上的工作奠定了重要基礎。我們早已重建語音基礎設施⁠，讓音訊和視像直接串流進出系統，延遲更低亦更可預測。GPT‑Live 進一步推展這項設計，透過專為持續對話而建的新型有狀態推理系統，將媒體一路串流至模型。

不過，串流推理只是解決方案的一部分。要在生產環境中良好運作，我們亦須確保音訊從客戶端可靠傳送至推理堆疊，並應對有狀態系統帶來的挑戰。

我們早期作出的一項決定，是將媒體流與應用程式及業務邏輯明確分開。音訊透過專用快速路徑，在客戶端與語音模型之間傳輸。委派、工具使用和其他應用程式工作，則在非同步 RPC 邊界之後進行。緩慢的工具呼叫或後端服務可能延遲自身結果，卻無法阻礙媒體流動。

這種分隔亦為系統提供清晰的自訂邊界。應用程式可以更改工具、政策和後端行為，而不影響負責維持音訊流動的媒體前端。實時路徑因而保持精簡、可預測，並專注於必須實時完成的工作。

我們使用 Go 編寫媒體前端和推理邏輯，取代先前採用 Python asyncio 的實作。這大幅提升了幀傳送的流暢度，新系統的 p95 達到舊系統 p50 的水平。

WebRTC 提供傳輸基礎。它專為低延遲媒體而設，即使出現封包遺失、時鐘漂移或客戶端連線變化，仍可繼續運作。如果封包延遲抵達，WebRTC 可細微拉長音訊以避免中斷，然後短暫加速播放以追上實時進度。

透過盡量減少整個系統的緩衝和阻塞，我們能夠提供人們期望對話具備的亞秒級回應速度。

有狀態推理亦有其運作上的取捨。語音工作階段可能長時間保持活躍，但上下文會持續增長，而模型執行個體則會按需求啟動和關閉。

為處理這些問題，我們建立了跨模型執行個體的無縫交接機制。需要轉換時，我們可在現有模型執行個體旁預熱替代執行個體，以目前工作階段的上下文預填，並行在兩者上執行推理，待新執行個體完全就緒後才切換。

同一套基本機制亦支援動態上下文壓縮。隨着對話持續，累積的上下文最終可能超出模型的上下文限制。上下文壓縮可縮減上下文，使其符合限制，但這項操作需時。此外，由於它會更改過往上下文，亦會令模型的鍵值（KV）快取失效；該快取儲存先前已處理 token 的注意力鍵和值。重建該狀態需要重新預填，因而帶來額外延遲。

因此，我們將上下文壓縮視為另一項受管理的轉換。原有模型執行個體繼續對話的同時，系統會壓縮上下文，並以新上下文準備替代模型執行個體。該執行個體就緒後，我們便可切換，而不會中斷媒體。這讓系統可支援長時間通話，並在有需要時進行上下文壓縮。

繁重工作不會進入實時路徑，因此即使交接期間，對話亦能保持流暢。

GPT‑Live 能夠調用現有的前沿模型，帶來強大能力，實際上將「說話」與更深入的「思考」分離。但要讓這種雙模型架構用起來像一套系統，我們必須解決兩個相關的工程問題。

首先，結果必須迅速返回，才能在持續交流中發揮作用。因此，我們須盡量降低整條委派路徑的延遲，涵蓋路由、提示詞處理、推理以至工具呼叫。與此同時，產品中的其他系統仍需要獨立訊息，因此我們須以它們能夠理解的形式呈現持續進行的對話。

發出委派後，我們會盡量縮短前沿模型產生對對話有用內容所需的時間。前沿模型推理或使用工具時，語音模型可短暫維持交流，但無法掩蓋過於緩慢的回應。因此，我們將整個委派迴路——路由、提示詞處理、推理和工具呼叫——都納入回應時間預算。

第一項優化，是在要求委派前準備好前沿模型及其所需工具。語音工作階段開始時，應用程式伺服器會為前沿模型建立推理工作階段，並以初始對話上下文預填，確保提示詞在首個委派請求前已處理完畢。

然後，我們在整段語音對話期間維持該推理工作階段可用，並為連續請求採用穩定的工作階段親和性。這些技術配合提示詞快取，可改善延遲，同時讓系統輕易從工作節點故障中復原。

推理量、輸出限制、工具結構描述，以及模型與工具之間的往返，亦會影響對話何時收到有用結果；我們調整了這些因素以加快回應。透過盡量減少委派路徑所需的工作，我們讓語音模型能迅速採用前沿模型的結果。

雖然語音模型處理連續語音串流，但周邊許多系統仍按用戶與助理的對話輪次運作，包括 ChatGPT 的對話介面，以及部分分析和安全基礎設施。因此，應用程式伺服器會梳理互相重疊、偶爾含糊的對話，將其拆分成獨立訊息。

音訊抵達時，伺服器會利用部分轉錄內容和時間訊號推斷誰正在發言，並建立訊息佇列。最新訊息仍屬暫定；隨着更多語音抵達，其文字、時間和講者歸屬均可能改變。當一名講者持續發言至足以可靠判定歸屬時，伺服器便會落實相應訊息。

講者聲音重疊令情況更複雜。用戶說話時，助理簡短回應（例如「嗯」或「好的」）未必需要獨立成為一則訊息。然而，助理有實質內容的插話通常應獨立處理。同樣，即使用戶中途說話，我們仍會優先確保畫面所示的助理回應連貫。

每種分段政策都須在即時性與確定性之間取捨。過早落實會令對話記錄零碎、次序不穩；等待太久則會延遲轉錄內容及依賴它的功能。因此，系統會維持兩個相關的對話檢視：當前狀態的推測檢視，以及實際對話內容的權威記錄。應用程式介面中的對話檢視能夠處理更新，因此採用推測檢視。但將記錄傳送至分析管道時，則需要最終轉錄內容。

這讓 ChatGPT 的其他部分可穩定掌握交流內容，而無須在實時語音路徑中強制輪流對話。

用戶點擊按鈕的一刻，迅速回應的體驗便已開始。使用 GPT‑Live 時，系統必須先建立媒體路徑，並開始將音訊輸入模型，對話才能展開。因此，啟動程序的每一環都在關鍵路徑上。

如上所述，WebRTC 為實時通訊奠定穩固基礎，但啟動標準 WebRTC 工作階段所需的協定交握和網絡往返次數多得驚人。WebRTC 的出現早於 QUIC 等後來協定對盡量減少往返次數的重視。因此，其底層協定一起使用時，有時會重複執行相同工作。例如，即使在完整 WebRTC 堆疊中並無需要，每項協定仍各自包含防禦 DoS 的機制。

我們分析了整個堆疊，並開發 WebRTC 簡化往返協定（WARP⁠（在新視窗中開啟）），將媒體和數據的啟動程序從六次網絡往返減至一次。WARP 透過一系列向後兼容的協定改進實現這一點：在 ICE 上附帶進行 DTLS 交握（SPED⁠（在新視窗中開啟））、採用更快的 DTLS 1.3⁠（在新視窗中開啟） 交握、預先協商 SCTP 交握（SNAP⁠（在新視窗中開啟）），以及預先協商數據通道而非使用 DCEP⁠（在新視窗中開啟）。

我們與 WebRTC 社群的協作者合作，將 WARP 設計成一套開放規格，讓更廣泛的生態系統受惠於這項工作。我們正透過 IETF 的 TSVWG 工作小組推進這些提案；libwebrtc 和 Pion 已加入 WARP 支援，其他 WebRTC 實作亦正展開相關工作。

優化媒體交握後，尚有一項延遲格外明顯：WebRTC 連線前用來共享 SDP 參數的訊號交換。為將這項交換移出關鍵路徑，我們開發了稱為 Instant Connect 的技術。它可預先協商這些參數，無須預留伺服器容量，亦無須更改現有 WebRTC 實作。

Instant Connect 與標準訊號流程並行運作。如果預先協商的參數有效，伺服器可在首個媒體封包抵達時具現化工作階段。如果參數已過時或無效，訊號流程亦已同步展開，因此客戶端可改用後備流程而不增加延遲。

Instant Connect 與 WARP 結合，可大幅縮短從用戶表達意圖到實時媒體開始流動的時間。SDP 交換移出關鍵路徑，加上 WARP 精簡傳輸交握後，客戶端現只需一個 UDP 封包即可啟動工作階段。伺服器可立即回應，讓系統其他部分開始處理用戶真正關心的工作：聆聽和回應。

系統在規格上看似快速，面對真實語音流量時仍可能停滯。在讓 GPT‑Live 與用戶對話前，我們進行了靜默測試，將一小部分生產環境中的 ChatGPT 語音工作階段同時導向現有的進階語音模式體驗和新系統，並逐步提高比例。進階語音模式如常為用戶提供服務，而影子路徑則以唯讀模式執行推理。這讓系統接觸真實的客戶端、網絡、工作階段長度和地理分佈，同時不改變用戶聽到的內容。

我們最早汲取的其中一個教訓，是不能單憑 GPU 吞吐量衡量容量。語音工作階段會保持開啟並持續傳送幀，因此 CPU 端的串流處理程式、佇列和網絡路徑必須與推理能力同步擴展。在真實負載下，一個輔助元件比負載測試估算更早飽和，導致推理請求積壓，延遲亦隨之疊加。我們不再問「一個 GPU 可以處理多少個請求？」，而改問「在確保每一幀都準時處理的情況下，系統可持續支援多少個並行工作階段？」

這項測試亦顯示，地理位置是首要考慮因素。將工作階段路由至遠端容量，可能在啟動和串流期間的多個環節增加延遲。我們開始同時驗證模型推出安排、區域容量和流量導向設定，並按來源地區細分延遲。將推理移近用戶確有幫助，但亦再次印證更廣泛的教訓：端到端回應速度取決於路徑上的每項服務，而非只有模型伺服器。

其他故障只會在貼近實況的工作階段生命週期中出現。長時間運行的工作階段暴露了記憶體和持久化方面的壓力。重新連線考驗了上下文壓縮和狀態還原機制。一般的客戶端中斷連線揭示了關閉交握中的競態問題。這些問題很少在短時間的負載測試中出現，因為它們取決於時間、累積狀態及跨服務邊界的行為。

最後，生產環境測試促使我們改善可觀測性和推出控制。我們發現有些指標混合了不同的延遲來源、有些儀表板的彙總數據掩蓋了個別運作異常的引擎，測試系統與已部署系統之間亦出現設定偏差。為此，我們加入更細緻的遙測、以已知良好設定作驗證、分階段提高流量，以及迅速隔離或停用個別路徑的能力。這項靜默測試成為正式推出前的早期演練，不僅測試系統可承受多少流量，亦測試我們偵測、控制故障並從中復原的速度。

要將 GPT‑Live 擴展至 ChatGPT 的規模，我們需要建構一套以基本原則為核心的全新系統：讓語音持續流動。串流推理持續向全雙工模型提供音訊。專用媒體路徑確保每一幀可靠送達。非同步委派讓更深入的思考可並行進行。經優化的傳輸讓用戶端全程保持迅速回應。

GPT‑Live 背後的架構，已逐漸發展成支援實時互動的更廣泛平台。隨着 ChatGPT 語音從對話擴展至代理協調，這套架構為其提供支援，亦將成為即將推出的 GPT‑Live API 之基礎。長遠而言，它將讓語音體驗延伸至更多裝置、應用程式和模態，同時保留實時語音對話的即時感。

如果你也想解決這類工程難題，歡迎加入我們⁠。