詳細を読む
OpenAIは8月3日、対話型音声AI「GPT-Live」を支えるリアルタイム基盤の設計を公開しました。従来の音声AIが使っていた「話し終えたか」を推測する小型モデルを音声の経路から取り除き、聞くことと話すことを同時に行う全二重モデルを中核に据えたことで、人間同士の会話に近い1秒未満の応答を実現したといいます。担当エンジニアは半年かけて、推論・文脈管理・伝送の全層を作り直しました。
これまでの音声AIは、テキストLLMのターン制をそのまま引き継いでいました。小型の判定器がユーザーの発話終了を推測し、その決定が出るまで大きなモデルは動き出せず、早すぎれば言葉を遮り、遅すぎれば反応が鈍く感じられます。GPT-Liveはこの判定器を音声経路から外し、モデル自身が会話の主導権を握る構成へ切り替えました。
新基盤の要は、音声の流れとアプリケーション処理を明確に分けた点です。音声はクライアントとモデルを結ぶ専用の高速経路を流れ、ツール実行や外部連携は非同期のRPC境界の向こう側で処理されるため、遅いツール呼び出しが音声を止めることはありません。媒体処理と推論制御はPythonのasyncioからGoへ書き換えられ、フレーム配信の安定性は新方式のp95が旧方式のp50に並ぶ水準まで改善しました。
長時間の通話を支えるのが、モデルインスタンス間の無停止の引き継ぎです。切り替えが必要になると、複製先を先に温めて現在の文脈を読み込ませ、両方で並行して推論したうえで準備が整った時点で切り替えます。文脈が上限に近づいたときの圧縮も同じ仕組みで裏側に逃がすため、KVキャッシュの再構築による沈黙が会話に現れません。
深い思考が必要な場面では、GPT-5.5などのフロンティアモデルに処理を委ねます。音声セッションの開始時点でフロンティア側の推論セッションを作って初期文脈を先に処理させ、プロンプトキャッシュとセッション固定を組み合わせることで、結果が返るまでの時間を削っています。会話画面や分析・安全性の仕組みは今も発話単位のメッセージを前提とするため、アプリサーバーが暫定的な文字起こしと時間情報から話者を推定し、確度が高まった時点でメッセージを確定させています。
接続の立ち上がりも作り直しました。WebRTCの手順を整理した新プロトコルWARPで開始時の往復を6回から1回に減らし、接続情報を事前に交渉するInstant Connectと合わせて、単一のUDPパケットで会話を始められるようにしています。本番トラフィックの一部を読み取り専用で流すシャドーテストでは、GPUの処理量だけでは必要な容量を測れないことが判明し、同時セッション数を基準に据え直したといいます。