OpenAIは8月3日、音声AI基盤「GPT-Live」のシステム設計を解説する技術ブログを公開した。エンジニアのJustin Uberti氏とZahan Malkani氏による記事では、応答の遅延を最小限に抑えるためにターン検出モデルを音声パスから排除し、音声モデル自身が会話を主導する「フルデュプレックス」方式に切り替えた経緯と、その裏側にある通信・推論の仕組みを明らかにしている。
従来の音声AIは、ユーザーの発話が終わったかどうかを小型の「ターン検出」モデルが判定し、それを受けてから大型LLMが応答を生成する仕組みだった。判定が早すぎればユーザーの発話を遮り、遅すぎれば応答がもたつく。GPT-Liveはこの検出モデルを廃止し、音声モデルが聞きながら同時に話せる全二重構成にすることで、人間同士の会話に近いテンポを実現したという。深い推論やツール利用が必要な場面では、会話の流れを止めずにGPT-5.5などのフロンティアモデルに処理を委譲する。
基盤側では、音声を流し続ける「メディアパス」とアプリケーションロジックを明確に分離した。メディア処理と推論のコードは従来のPython asyncioからGoに書き直し、フレーム配信の安定性を大きく改善したとしている。文中では「新システムのp95レイテンシが旧システムのp50と同水準になった」という具体的な数値が示されている。長時間セッションでの文脈圧縮も、既存の推論インスタンスを稼働させたまま新インスタンスへ無停止で切り替える方式を採用し、音声が途切れる瞬間を作らない設計にしたという。
この基盤は現在ChatGPTの音声機能を支えており、ChatGPTデスクトップアプリで新たに搭載されたパソコン操作や複数エージェントの連携指示にも使われている。今後提供予定のGPT-Live APIの基盤にもなる見通しだ。
接続開始を6往復から1往復に縮めた独自プロトコル「WARP」
OpenAIはWebRTCの接続確立に必要な複数のハンドシェイクが冗長であることに着目し、DTLSハンドシェイクをICEに乗せる、DTLS 1.3を使う、SCTPハンドシェイクを事前ネゴシエートするなど複数の改善を組み合わせた独自仕様「WARP(WebRTC Abridged Roundtrip Protocol)」を開発した。これによりメディア・データ通信の起動に必要なネットワーク往復を6回から1回に削減したという。加えて、SDPパラメータを事前に交換しておく「Instant Connect」という仕組みも実装し、条件が揃えばUDPパケット1つでセッションを開始できるようにした。WARPはIETFのTSVWGワーキンググループに提案済みで、オープンな仕様としてlibwebrtcとPionにはすでに実装が入っており、他のWebRTC実装でも対応が進んでいるという。
本番トラフィックへの「サイレントテスト」で見えたボトルネック
公開前には、既存の音声機能(Advanced Voice Mode)を使うユーザーのトラフィックの一部をGPT-Liveにも複製して流し、応答は返さずに裏側だけ稼働させる検証を段階的に拡大しながら実施した。この過程で、処理能力の制約はGPUの推論性能だけでは決まらず、常時ストリームを受け続けるCPU側のハンドラやキューが先に飽和するケースがあることが分かったという。また、ユーザーとの物理的な距離が起動時や配信中の遅延に直結することも判明し、モデルのロールアウトを地域ごとの処理能力・トラフィック制御と合わせて検証する体制に変更した。長時間セッションでのメモリ圧迫や再接続時の状態復元など、短時間の負荷テストでは見つからない不具合も本番規模の検証で洗い出したとしている。
フロンティアモデルへの委譲を会話の外で片づける設計
GPT-Liveは会話中にGPT-5.5などへ処理を委譲するが、その結果が遅すぎれば会話は不自然に止まってしまう。OpenAIはセッション開始時点でフロンティアモデル側の推論インスタンスをあらかじめ用意し、初期の会話文脈を先読みさせておくことで、実際に委譲が発生した瞬間から即座に処理を始められるようにした。同じ推論インスタンスをセッション中ずっと使い回す「セッションアフィニティ」とプロンプトキャッシュを組み合わせ、ワーカーに障害が起きても復旧しやすい構成にしているという。
もう一つの課題は、音声モデルが処理する連続的な発話の流れを、ChatGPTの会話UIや分析基盤が扱える「ユーザーの発言」「アシスタントの発言」という離散的な単位に変換することだった。GPT-Liveのアプリケーションサーバーは、部分的な文字起こしと発話タイミングから話者を推定し続け、相槌程度の短い割り込みは独立した発言として扱わない一方、内容のある割り込みは発言として確定させる。確定前の「暫定的な会話ビュー」と、確定後の「正式な記録」を並行して保持することで、UI表示の即時性とログの正確性を両立させているという。
