GPT-Liveの設計を読み解く：低遅延で状態を保つ音声対話基盤

はじめに

音声アシスタントの品質は、発話を正しく認識して回答できるかだけで決まりません。ツール呼び出しや外部サービスの処理中も、会話が途切れず自然に続くことが重要です。OpenAIがGPT-Liveの技術報告と関連インタビューで示した設計は、リアルタイム経路を短く予測可能に保ち、それ以外の機能を非同期境界の後ろへ分離するという考え方に基づいています。

リアルタイム経路に含めるものを絞る

GPT-Liveの遅延に敏感な経路は、メディア処理パイプラインと推論ループを中心に構成されます。音声の受信・処理とモデル応答の生成は、処理時間が変動しやすい外部処理によって止められてはいけません。そのため、タスク委任、ツール利用、データ永続化、その他のアプリケーションロジックは非同期RPC境界の後段で実行されます。

この分離により、ユーザーが直接感じる部分へ最適化を集中できます。より高性能なモデルへの委任や、音声入力を安全対策へ接続する処理も重要ですが、それらを同じクリティカルパスに組み込まなければ、機能ごとに性能と信頼性を改善できます。リアルタイム性を守るために、すべてを高速化するのではなく、まず経路を分ける発想です。

状態を持つ推論とセッション移行

継続的な対話には状態が必要です。一方、すべての会話を単一インスタンスへ固定すると、需要変動への対応や障害復旧が難しくなります。GPT-Liveでは、専用の状態付き推論機構を使い、各セッションに割り当てたインスタンス上で容量を確保します。インスタンスがリソース解放中になった場合や、会話がコンテキスト上限に近づいた場合は、コンテキストを別のモデルインスタンスへ移行できます。

これにより、基盤を調整しても会話を最初からやり直す必要がなく、需要に応じてインスタンス数を変更できます。ただし、容量予約、移行のタイミング、コンテキストの整合性を管理する必要があり、完全なステートレスサービスより運用は複雑になります。連続音声対話では、この複雑さを受け入れて状態の維持を優先した形です。

WebRTCを捨てずに起動を短縮

OpenAIはWebRTCを置き換えるのではなく、WebRTC Abridged Roundtrip Protocol（WARP）と即時接続の仕組みを導入して起動遅延を抑えています。WebRTCは低遅延のメディア処理とエラー回復を備えた実績ある基盤です。一方、新しい伝送方式には将来性があっても、完全なメディアパイプラインや輻輳制御、RTTに基づく経路選択などが不足する場合があります。

WARPの改良を個別に展開・検証でき、既存のWebRTCアプリケーションもコード変更なしで恩恵を受けられる点は大きな利点です。クライアントとサーバーの伝送層を同時に置き換えるより、段階的な導入の方が大規模サービスのリスクを抑えられます。

実際の音声を使うサイレントテスト

正式提供前には、出力をユーザーへ返さないサイレントテストも実施されました。アプリケーションサービスを読み取り専用かつユーザー認証情報なしで動かし、実際の受信音声をメディア処理と推論へ流しながら、生成結果は破棄します。ユーザー体験を変えずに、本番に近い挙動を確認できる方法です。

録音済み音声や合成音声による負荷試験と比べ、実トラフィックには話し方、地域、負荷の多様性があります。ある地域では、GPUとデータを供給するCPUが同じ施設に配置されておらず、予想外の遅延が見つかりました。これは、リアルタイムAIの課題がモデル速度だけでなく、配置構成にも左右されることを示します。音声サービスでは、経路分離、状態移行、実トラフィックによる検証を基盤機能として考える必要があります。

出典：InfoQ 中文