我們如何在六個月內打造即時回應的語音 AI 系統

對語音 AI 而言，判斷何時該說話比想像中更難。人類可以在不到一秒內自然地交替發言，但過去的語音 AI 系統跟不上這種節奏。這類系統採用輪次制架構，仰賴稱為輪次偵測器的小型模型。輪次偵測器必須完成一項吃力不討好的任務。如果判斷太早，使用者會遭到打斷；判斷太晚，回應又會顯得遲鈍。只有輪次偵測器做出決定後，規模大得多的 LLM 才能開始運作。

我們的第三代語音系統 GPT‑Live⁠ 已移除音訊路徑中的輪次偵測器。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 專為低延遲媒體設計，即使發生封包遺失、時鐘漂移或用戶端連線變動，仍能繼續運作。若封包延遲抵達，WebRTC 可以稍微拉長音訊以避免出現空隙，再短暫加快播放速度，追上即時串流進度。

盡量減少整個系統的緩衝與阻塞後，我們便能達到人們在對話中期待的亞秒級回應速度。

有狀態推論在操作上也有取捨。語音工作階段可能長時間保持作用中，上下文會持續增加，而模型執行個體也會隨需求啟動或關閉。

為了解決這些問題，我們建立了模型執行個體之間的無縫交接機制。需要轉換時，我們可以在既有模型執行個體運作期間預熱替代執行個體，以目前的工作階段上下文預填替代執行個體，讓兩者並行執行推論，等新執行個體完全就緒後再切換。

同一套基本機制也支援動態上下文壓縮。隨著對話持續進行，累積的上下文最終可能超出模型的上下文上限。壓縮可以縮減上下文，使內容維持在上限內，但這項作業需要時間。壓縮也會改變先前的上下文，導致模型的鍵值 (KV) 快取失效。這項快取儲存先前處理之 Token 的注意力鍵和值。若要重建相關狀態，就必須重新預填，因此會增加延遲。

我們改將壓縮視為另一次受控轉換。原有模型執行個體持續對話期間，系統會壓縮上下文，並以新的上下文準備替代模型執行個體。替代執行個體就緒後，我們便能切換，而且不會中斷媒體串流。系統因此能支援長時間通話，並在需要時壓縮上下文。

繁重的工作不會進入即時路徑，因此即使正在交接，對話也不會中斷。

GPT‑Live 能呼叫既有的前沿模型，因此具備強大能力，實質上將「說話」與更深入的「思考」解耦。然而，要讓這套雙模型架構如同單一系統般運作，必須解決兩項相關的工程問題。

首先，結果必須迅速傳回，才能用於正在進行的對話。因此，我們必須盡量降低整條委派路徑的延遲，涵蓋路由、提示詞處理、推論和工具呼叫。同時，產品中的其他系統仍需要一則則獨立訊息，因此我們必須把持續進行的對話轉換成這些系統能理解的形式。

委派送出後，我們會盡量縮短前沿模型產生對話可用結果所需的時間。前沿模型進行推理或使用工具時，語音模型可以短暫維持對話，但如果回應過慢，語音模型也無法一直掩飾延遲。因此，我們將完整的委派迴路，包括路由、提示詞處理、推論和工具呼叫，全都納入回應延遲預算。

第一項最佳化措施，是在收到委派要求前先設定好前沿模型及所需工具。語音工作階段開始時，應用程式伺服器會為前沿模型建立推論工作階段，並以初始對話上下文預填這個工作階段，確保提示詞在第一個委派要求送出前已處理完畢。

接著，我們會在整段語音對話期間保留這個推論工作階段，並透過穩定的工作階段親和性處理後續要求。這些技術配合提示詞快取，能縮短延遲；即使工作節點故障，也很容易復原。

推理強度、輸出限制、工具結構描述，以及模型與工具之間的往返次數，也會影響對話取得可用結果的時間。我們逐一調整這些因素來加快回應。盡量減少委派路徑所需的處理後，語音模型便能快速納入前沿模型產生的結果。

雖然語音模型處理的是連續語音串流，但周邊許多系統仍以使用者和助理的對話輪次運作，包括 ChatGPT 的對話介面，以及部分分析和安全性基礎架構。因此，應用程式伺服器會將彼此重疊且有時難以判定歸屬的對話拆分成個別訊息。

音訊抵達時，伺服器會利用即時逐字稿片段和時間訊號，推斷目前由哪位說話者發言，並建立訊息佇列。最新訊息會維持暫定狀態。隨著後續語音抵達，最新訊息的文字、時間和說話者歸屬都可能改變。某位說話者持續發言的時間夠長，說話者歸屬足以可靠判定後，伺服器才會將對應訊息定稿。

多人同時說話會讓情況更加複雜。在使用者說話期間，助理的簡短附和，例如「嗯哼」或「好」，不一定要自成一則訊息。不過，如果助理插入的是實質內容，通常應獨立成一則訊息。即使使用者中途發言，我們仍會優先維持畫面上助理回應的連貫性。

每種分段政策都必須在即時性與確定性之間取捨。過早定稿會造成對話記錄零碎、順序不穩定；等待太久則會延誤逐字稿和依賴逐字稿的功能。因此，系統會維護兩種相互關聯的對話檢視，一種是目前狀態的暫定檢視，另一種是實際發言內容的最終記錄。應用程式介面中的對話檢視可以隨資訊更新，因此採用暫定檢視；分析管線中的記錄則需要最終逐字稿。

如此一來，ChatGPT 的其他部分便能取得穩定的對話內容，同時不必在即時語音路徑上強制切分發言輪次。

即時回應的體驗，從使用者按下按鈕的瞬間就開始。使用 GPT‑Live 時，系統必須先建立媒體路徑，並開始將音訊送入模型，對話才能展開。因此，啟動流程的每個環節都位於關鍵路徑上。

如上所述，WebRTC 提供了穩健的即時通訊基礎，但啟動一般 WebRTC 工作階段卻需要多次通訊協定交握和網路往返，次數多得出乎意料。WebRTC 問世的時間早於後來形塑 QUIC 等通訊協定的「盡量減少往返次數」設計理念。因此，底層通訊協定一起使用時，有時會重複相同工作。例如，每個通訊協定都有自己的 DoS 防護機制，即使整套 WebRTC 堆疊已不需要各自提供這項防護。

我們分析這套堆疊後，開發了 WebRTC 精簡往返通訊協定 (WARP⁠(在新視窗中開啟))，將媒體和資料的啟動程序從六次網路往返縮減至一次。WARP 採取幾項向後相容的通訊協定改良措施，包括將 DTLS 交握搭載於 ICE 上 (SPED⁠(在新視窗中開啟))、採用速度更快的 DTLS 1.3 ⁠(在新視窗中開啟)交握、預先協商 SCTP 交握 (SNAP⁠(在新視窗中開啟))，以及預先協商資料通道而不使用 DCEP⁠(在新視窗中開啟)。

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

完成媒體交握的最佳化後，另一項延遲顯得格外突出。WebRTC 連線前，必須透過訊號交換傳遞 SDP 參數。為了將這項交換移出關鍵路徑，我們開發了名為 Instant Connect 的技術。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 基礎。未來，這套架構能將語音體驗延伸至更多裝置、應用程式和模態，同時保有讓語音對話宛如現場互動的即時感。

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