OpenAI の低遅延音声インフラの内部構造

音声 AI が自然に感じるのは、会話が会話の速度で行われる場合だけです。ネットワークが邪魔になると、人々はすぐにぎこちない一時停止、切り捨てられた中断、または遅れた割り込みとしてそれを聴きます。これは ChatGPT の音声機能にとって重要であり、Realtime API を使って構築する開発者にとって重要であり、対話型ワークフローで動作するエージェントにとって重要であり、ユーザーがまだ話している間にオーディオを処理する必要があるモデルにとっても重要です。 OpenAI のスケールにおいて、これは 3 つの具体的な要件に翻訳されます: - 9 億人以上の週次アクティブユーザーに対するグローバルな到達範囲 - ユーザーがセッション開始と同時に話し始められるようにするための高速な接続セットアップ - ターンテイクが鮮明に感じられるよう、ジッターとパケットロスが低く安定したメディア往復時間 リアルタイム AI インタラクションを担当する OpenAI のチームは、スケールにおいて衝突し始めた 3 つの制約に対処するために、WebRTC スタックを再設計しました。その制約とは、セッションごとの 1 ポートでのメディア終端が OpenAI のインフラストラクチャに適合しないこと、ステートフルな ICE（Interactive Connectivity Establishment）および DTLS（Datagram Transport Layer Security）セッションには安定した所有権が必要であること、そしてグローバルルーティングは最初のホップのレイテンシを低く保つ必要があることです。この投稿では、クライアントに対して標準的な WebRTC の動作を維持しつつ、OpenAI のインフラストラクチャ内でのパケット経路変更を実現するために構築した「リレーとトランスシーバの分離」アーキテクチャについて詳しく解説します。 WebRTC は、ブラウザ、モバイルアプリ、サーバー間で低遅延のオーディオ、ビデオ、データを転送するためのオープン標準です。ピアツーピア通話とよく関連付けられていますが、インタラクティブメディアの難しい部分を標準化しているため、クライアントからサーバーへのリアルタイムシステムの堅牢な基盤としても機能します。具体的には、接続確立および NAT（ネットワークアドレス変換）透過のための ICE、暗号化転送のための DTLS および SRTP（Secure Real-time Transport Protocol）、オーディオの圧縮・復号化のためのコーデックネゴシエーション、品質制御のための RTCP（Real-time Transport Control Protocol）、そしてエコーキャンセレーションやジッターバッファリングなどのクライアントサイド機能などが標準化されています。 この標準化は AI プロダクトにとって極めて重要です。WebRTC がなければ、NAT を越えた接続確立方法、メディアの暗号化手法、コーデック（送信および復元のために選択される符号化・復号化器）のネゴシエーション、そして変化するネットワーク条件への適応方法について、各クライアントが個別に異なる対応策を必要とするでしょう。WebRTC を用いることで、ブラウザやモバイルプラットフォームですでに実装済みのプロトコルスタックの上に構築し、リアルタイムメディアとモデルを接続するインフラストラクチャの開発に注力することが可能になります。 私たちは WebRTC エコシステムそのものにも依存しており、そこには成熟したオープンソースの実装や、ブラウザ、モバイルアプリ、サーバー間の相互運用性を維持するための標準化活動が含まれています。WebRTC の元アーキテクトの一人である Justin Uberti 氏と、Pion（Pion）の作成者かつメンテナである Sean DuBois 氏による基盤的な取り組みにより、私たちのようなチームは低レベルの転送、暗号化、輻輳制御の動作をゼロから作り直すのではなく、実戦で検証されたメディアインフラストラクチャの上に構築することが可能になりました。Justin 氏と Sean 氏が現在 OpenAI の同僚として在籍し、WebRTC とリアルタイム AI をより密接に統合する方法を導いてくれていることは、私たちにとって幸運なことです。 AI において最も重要な特性は、音声データが連続ストリームとして到着することです。話者エージェントは、ユーザーが発話を完了するのを待たずに、発話中にすでに文字起こし、推論、ツールの呼び出し、または音声生成を開始できます。これが「会話らしい」システムと「プッシュ・トゥ・トーク（押し話）」のようなシステムの決定的な違いです。 WebRTC を採用した後の次の課題は、その終端地点をどこに設定するか（つまり、WebRTC 接続を受け取り管理する場所、例えばエッジ上か）であり、またそれらのセッションを推論バックエンドにどのように接続するかという点でした。終端地点の選定が重要なのは、それがリアルタイムセッションの状態処理、メディア転送、ルーティング、レイテンシ、および障害分離の方法を決定づけるからです。 SFU（Selective Forwarding Unit）とは、各参加者から WebRTC ストリームを 1 つ受け取り、他の参加者に対してストリームを選択的に転送するメディアサーバーのことです。このモデルでは、SFU は各参加者ごとに個別の WebRTC 接続を終端し、AI もセッション内の別の参加者として加わります。これは、グループ通話や教室、共同会議など、本質的に複数参加型の製品には適しています。音声コーデック、RTCP メッセージ、データチャネル、録画機能、ストリームごとのポリシーをすべて 1 か所に集約できるためです。 クライアントから AI への製品であっても、SFU はデフォルトの起点としてよく選ばれます。これは、シグナリング、メディアルーティング、録画、観測性（Observability）、および将来的な拡張機能（人間のハンドオフや参加者数の増加など）に対して、1 つの実証済みのシステムを再利用できるためです。 私たちのワークロードはこれとは異なります。ほとんどのセッションは 1:1 です。つまり、1 人のユーザーが 1 つのモデルと対話するか、1 つのアプリケーションが 1 つのリアルタイムエージェントと対話する形であり、すべてのターンでレイテンシ（遅延）に敏感です。このようなトラフィックの形状に対して、私たちはトランスシーバー（Transceiver）モデルを採用しました。これは、WebRTC エッジサービスがクライアント接続を終端し、その後、メディアやイベントを、モデル推論、文字起こし、音声生成、ツール使用、オーケストレーションのためのより単純な内部プロトコルに変換するものです。 この設計において、トランシーバーは ICE 接続チェック、DTLS ハンドシェイク、SRTP 暗号化キー、セッションライフサイクルを含む WebRTC セッション状態を所有する唯一のサービスです。ここで言う「終端（Termination）」とは、トランシーバーがそれらのハンドシェイクを完了し、メディアの暗号化または復号化を行うエンドポイントであることを意味します。この状態を一つの場所に保持することで、セッション所有権の理解が容易になり、バックエンドサービスが WebRTC ピア自体として振る舞うのではなく、通常のサービスのようにスケーリングできるようになりました。 トランシーバーモデルを選択した後、最初の導入では Pion を基盤とした単一の Go サービスを実装し、シグナリングとメディア終端の両方を処理しました。このサービスは ChatGPT ボイス、Realtime API の WebRTC エンドポイント、および多数の研究プロジェクトを支えています。 運用面において、トランシーバーサービスは以下の 2 つの役割を担います： - シグナリング: SDP ネゴシエーション、コーデック選択、ICE クレデンシャル、セッションセットアップ - メディア: 下流側の WebRTC 接続の終端と、推論およびオーケストレーションのためのバックエンドサービスへの上流側接続の維持 このサービスをインフラストラクチャの他の部分と同様に動作させることを目指しました。つまり、Kubernetes 上で実行し、需要の変化に応じてワークロードをスケールアップ・ダウンさせ、ホスト間を移動できるようにすることです。しかし、従来の「セッションごとに 1 ポート」という WebRTC モデルは、そのような環境にはあまり適していません。なぜなら、これは大規模な公開 UDP ポート範囲に依存しており、ポッドの追加、削除、再スケジューリングの際に、これらのポートを公開し、セキュリティを確保し、維持することが困難だからです。 2 最初の課題は、セッションごとに 1 つのポートを使用するモデルそのものでした。高い同時接続数では、非常に大きな UDP ポート範囲を公開して管理することを意味します。 - クラウドロードバランサーや Kubernetes サービスは、サービスあたり数万の公開 UDP ポートを想定して設計されていません。追加される各範囲は、ロードバランサー設定、ヘルスチェック、ファイアウォールポリシー、ロールアウトの安全性において運用上の複雑さを増大させます。 - 大きな UDP ポート範囲はセキュリティが困難です。外部から到達可能な表面積が拡大し、ネットワークポリシーの監査が難しくなるためです。 - また、オートスケーリングにも不向きです。Kubernetes ではポッド（Pod）が絶えず追加・削除・再スケジュールされます。各ポッドが大規模で安定したポート範囲を予約して広告することを要求すると、その弾力性が脆くなります。 そのため、多くの WebRTC システムは、サーバーごとに 1 つの UDP ポートを使用し、その背後でアプリケーションレベルでのデマルチプレクシング（demultiplexing）を行う方向へ移行しています。 サーバーごとの単一ポート設計はポート数の問題を解決しますが、ファーム全体にわたって各セッションの所有権を維持するという第 2 の課題を導入します。 ICE や DTLS は状態保持型プロトコルです。セッションを作成したプロセスが、そのセッションのパケットを受け取り続けなければなりません。これにより接続チェックの有効化、DTLS ハンドシェイクの完了、SRTP の復号化、および ICE リスタートなどの後のセッション変更処理が可能になります。同じセッションのパケットが異なるプロセスに届いた場合、セットアップが失敗したりメディアが切断されたりします。 これにより、私たちが目指した具体的な目標は、パブリックインターネットに対して小さく固定された UDP の表面を公開しつつ、すべてのパケットを対応する WebRTC セッションを所有するトランスシーバーへルーティングすることでした。 私たちはそこへ到達するためのいくつかの方法を検討しました。その中には TURN（NAT 周囲のルーターを使用したトランザバース）も含まれており、エッジ上のルーターがクライアントのアロケーションを終端し、代わりにトラフィックを転送する方式です。 **アプローチ** **利点** **欠点** セッションごとに一意な IP:ポート（ネイティブ直接 UDP とも呼ばれる） クライアントからサーバーへのメディア経路が直接確立される データパスに転送層が存在しない セッションごとに 1 つの公開 UDP ポートが必要となる 大規模なポート範囲を公開してセキュリティを確保するのは困難である Kubernetes やクラウドロードバランサーには適合性が低い サーバーごとに一意な IP:ポート セッションごとの公開に比べ、パブリック UDP のフットプリントが大幅に小さい サーバーごとに 1 つの共有ソケットで多数のセッションをデマルチプレックス可能 単一ホスト上ではきれいに動作するが、それ自体では共有ロードバランサー付きのファーム全体には対応できない 単一ホスト内でのセッションデマルチプレックスは、パケットがそのホストに到達した後にのみ有効であり、ロードバランサー付きのファーム全体では最初のパケットが誤ったインスタンスに到着する可能性があるため、各セッションをそれを所有するプロセスへ誘導するための決定論的な方法 still 必要である TURN ルーター（プロトコル終端型） クライアントは TURN ルーターアドレスとポートへの到達のみでよい エッジでポリシーを一元化できる TURN アロケーションにはセットアップの往復遅延が発生する TURN サーバー間でのアロケーションの移動や回復はまだ困難である ステートレスフォワーダー＋ステートフルターミネーター（OpenAI のリレー＋トランスシーバー） 小さなパブリック UDP フットプリント トランスシーバーは WebRTC セッション全体を依然として所有している メディアが所有するトランスシーバーに到達する前に、転送ホップが 1 つ追加される リレーとトランスシーバー間のカスタム調整が必要 私たちが実装したアーキテクチャでは、パケットルーティングとプロトコル終端を分離しています。シグナリングはセッション設定のために依然としてトランスシーバーに到達しますが、メディアはまずリレーを通じて入ってきます。リレーは小さなパブリックフットプリントを持つ軽量な UDP 転送層であり、その背後にある状態管理型 WebRTC エンドポイントがトランスシーバーです。 リレーはメディアの復号化を行わず、ICE ステートマシンを実行せず、コーデック交渉にも参加しません。必要なパケットメタデータのみを読み取り、宛先を選択して、セッションを所有するトランスシーバーにパケットを転送します。トランスシーバーは通常の WebRTC フローを依然として見ており、すべてのプロトコル状態を依然として所有しています。クライアントの視点からは、WebRTC セッションに関する何の変化もありません。 このセットアップにおける鍵となるステップが最初のパケットルーティングです。リレーは、パケットパス自体上にセッションが存在する前に、外部のルックアップサービスで停止することなく、クライアントからの最初のパケットをルーティングする必要があります。 すべての WebRTC セッションには、プロトコルネイティブなルーティングフックが既に含まれています：ICE ユーザー名フラグメント、または*ufrag*です。これはセッション設定時に交換される短い識別子であり、STUN 接続チェックでエコーされます。サーバー側の ufrag を生成することで、リレーが宛先クラスターと所有トランスシーバーを推論するのに十分なルーティングメタデータを含ませています。 シグナリング中、トランシーバーはセッション状態を割り当て、SDP 応答内で共有リレー VIP と UDP ポートを返します。VIP はリレーファームの前面に位置する仮想 IP アドレスであり、ポートと組み合わせることで、その背後に多数のリレーインスタンスが存在していても、クライアントには `203.0.113.10:3478` のような単一の安定した宛先が提供されます。クライアントからの最初のメディア経路パケットは通常、STUN（Session Traversal Utilities for NAT）バインディング要求であり、ICE はこれを使用して、パケットが広告されたアドレスに到達できるかを確認します。 リレーは、最初の STUN パケットからサーバーの ufrag を読み取り、ルーティングヒントをデコードし、そのパケットを所有するトランシーバーへ転送するために必要な最小限の部分のみを解析します。各トランシーバーは共有 UDP ソケットでリスニングしており、これはセッションごとに 1 つずつソケットがあるのではなく、内部 IP:ポートにバインドされた 1 つの OS エンドポイント（オペレーティングシステムのエンドポイント）を意味します。リレーがクライアントのソース IP:ポートからそのトランシーバー宛先へセッションを作成した後、その後の DTLS、RTP、RTCP パケットは、ufrag の再デコードなしでセッション内で流れます。 リレーのセッションは意図的に最小限に設計されており、パケット転送を通知するためのメモリー内セッションと、監視用の必要なカウンタ、およびセッションの有効期限切れとクリーンアップのためのタイマーのみで構成されています。この設計により、パケット経路がパケットパス上で直接維持されます。リレーが再起動してセッションを失った場合、次の STUN パケットによって ufrag ルーティングヒントからセッションが再構築されます。さらに信頼性を高めるため、ルートが確立された後は Redis キャッシュを使用して * * のマッピングを保持し、次の STUN パケットが到着する前に早期に復元できるようにしています。 パブリック UDP サーフェスを少数の安定したアドレスとポートに削減した後、同じリレーパターンをグローバルに展開できるようになりました。Global Relay は、すべてが同じパケット転送動作を実装する地理的に分散されたリレーイングレスポイントのファームです。 広範な地理的イングレスにより、最初のクライアントから OpenAI へのホップが短縮されます。パケットは、ユーザーに近い地理およびネットワークトポロジー上のリレーでネットワークに入力できるため、まず遠隔地へパブリックインターネットを横断する必要がありません。実用的には、これはトラフィックがバックボーンに到達する前に、レイテンシの低下、ジッターの減少、そして回避可能な損失バーストの削減を意味します。 シグナリングには Cloudflare の地理情報および近接性に基づくルーティング（geo and proximity steering）を使用し、初期の HTTP または WebSocket リクエストが近くのトランスシーバ・クラスターに到達するようにしています。リクエストのコンテキストがセッションの場所を決定し、クライアントに対してどのグローバル・リレーのイングレスポイントが広告されるかを指定します。SDP アサーはグローバル・リレーのアドレスを提供し、ufrag にはグローバル・リレーがメディアを指定されたクラスターへルーティングし、リレーが宛先のトランスシーバへ転送するために十分な情報が含まれています。 地理情報に基づくシグナリングとグローバル・リレーを組み合わせることで、セットアップとメディアの両方を近くの入口経路に配置しつつ、セッションは1つのトランスシーバにアンカー（固定）されたまま維持されます。これにより、シグナリングおよび最初の ICE 接続チェックの往復時間が短縮され、ユーザーが音声開始まで待つ時間が直接的に短くなります。 リレー・サービスは Go で記述し、意図的に実装範囲を狭く保ちました。Linux では、カーネルのネットワークスタックがマシンのネットワークインターフェースから UDP パケットを受け取り、プロセスが IP:ポートをバインドした後に読み取る OS エンドポイントであるソケットへパケットを配信します。リレーはユーザー空間で動作するため、通常の Go プロセスがそのソケットからパケットヘッダーを読み取り、少量のフロー状態を更新し、WebRTC を終了させることなくパケットを転送します。より高いパケットレートのためにユーザー空間プロセスがネットワークキューを直接ポーリングできるようにするカーネル・バイパス・フレームワークは不要でした。これは運用上の複雑さを増すためです。 主要な設計判断： - プロトコル終端なし：リレーは STUN ヘッダーと ufrag のみを解析し、その後の DTLS、RTP、RTCP にはキャッシュされた状態を使用し、パケットを不透明なまま維持します。 - エフェメラル（一時的）な状態：フローの状態と観測性を保つため、クライアントアドレスからトランスシーバー宛先へのマッピングを、小さく短時間タイムアウトのメモリ内マップとして保持します。 - 水平スケーラビリティ：複数のリレーインスタンスがロードバランサー背後で並列実行されます。状態は WebRTC のハードな状態ではないため、再起動によるトラフィックの減少は最小限に抑えられ、フローの回復も迅速に行われます。 効率化のための対策: - SO_REUSEPORT は、同一マシンの複数のリレーワーカーが同じ UDP ポートにバインドできるようにする Linux ソケットオプションです。カーネルはこのオプションにより、着信パケットをこれらのワーカー間で分散し、単一の読み込みループによるボトルネックを回避します。 - runtime.LockOSThread は、各 UDP 読み取り用ゴルーチンを特定の OS スレッドに固定します。SO_REUSEPORT と組み合わせることで、同じフロー（ソースと宛先の IP:ポートおよびプロトコル）からのパケットが同一の CPU コア上に留まる傾向があり、キャッシュの局所性が向上し、コンテキストスイッチングが削減されます。 - 事前割り当てバッファと最小限のコピーにより、解析と割り当てのオーバーヘッドを低く抑え、Go におけるガベージコレクションを回避します。 この実装により、比較的狭いリレーのフットプリントでグローバルなリアルタイムメディアトラフィックを処理できたため、カーネルバイパス方式を採用するよりもシンプルな設計を維持しました。 このアーキテクチャにより、数千の UDP ポートを公開することなく Kubernetes で WebRTC メディアを実行できます。これは重要です。なぜなら、小さく固定された UDP 表面はセキュリティと負荷分散が容易であり、大規模なパブリックポート範囲を予約せずにインフラをスケールできるからです。Kubernetes からのより良いインフラサポートと、表面領域の縮小によるセキュリティ向上により、この設計はクライアントに対して標準的な WebRTC の動作を維持し、SFU なしの設計が私たちのワークロードにとって適切なデフォルトであったことを確認します。セッションの大部分はポイントツーポイントであり、推論サービスが WebRTC ピアのように動作する必要がない場合、レイテンシに敏感でスケールしやすいものです。 より広範な教訓として、複雑性を追加する最適な場所は、すべてのバックエンドサービスやカスタムクライアント動作ではなく、薄いルーティング層にあります。ルーティングメタデータをプロトコルネイティブのフィールドにエンコードすることで、決定論的な最初のパケットルーティング、小さなパブリック UDP フットプリント、そして世界中のユーザーに近い場所にイングレスを配置するための十分な柔軟性が得られました。 いくつかの選択が特に重要でした： - エッジ上でプロトコルの意味論を維持する。クライアントは標準的な WebRTC を使用し続けることで、ブラウザとモバイル間の相互運用性を保つ。 - 厳密なセッション状態を一点に集約する。Transceiver が ICE、DTLS、SRTP、およびセッションライフサイクルを管理し、リレーはパケットの転送のみを行う。 - セットアップ時に既に存在する情報に基づいてルーティングする。ICE の ufrag（ユーザー名）が、ホットパスルックアップ依存性を追加することなく、最初のパケットのルーティングフックを提供した。 - カーネルバイパスに頼る前に一般的なケースを最適化する。SO_REUSEPORT の慎重な使用、スレッドピンニング、低割り当て型のパーシングを組み合わせた狭い範囲の Go 実装で、当社のワークロードには十分だった。 リアルタイム音声 AI は、インフラストラクチャがレイテンシを感じさせない場合にのみ機能する。私たちにとってそれは、クライアントが WebRTC から期待するものを変えずに、WebRTC デプロイメントの形状を変えることを意味した。

OpenAI の低遅延音声インフラの内部構造

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト