OpenAI が大規模低遅延音声 AI を実現する手法

会話の速度で会話が進行するときにのみ、Voice AI は自然に感じられます。ネットワークが邪魔になると、人々はすぐにぎこちない一時停止、切り捨てられた中断、または遅れた割り込みとしてそれを聴き取ります。これは ChatGPT の音声機能にとって重要であり、Realtime API を使って構築する開発者にとって重要であり、対話型ワークフローで動作するエージェントにとって重要であり、ユーザーがまだ話している間にオーディオを処理する必要があるモデルにとっても重要です。 OpenAI のスケールにおいて、これは3 つの具体的な要件に翻訳されます: - 9 億人以上の週次アクティブユーザーに対するグローバルな到達範囲 - ユーザーがセッション開始と同時に話し始められるようにするための高速な接続セットアップ - 低いジッターとパケットロスを持つ低く安定したメディア往復時間により、ターンテイクが鮮明に感じられること リアルタイム AI インタラクションを担当する OpenAI のチームは最近、スケールにおいて衝突し始めた3 つの制約に対処するために WebRTC スタックを再設計しました。1 セッションあたり 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 エッジサービスがクライアント接続を終端し、その後、メディアとイベントをモデル推論、文字起こし、音声生成、ツール使用、オーケストレーションのためのより単純な内部プロトコルに変換するものです。 この設計において、トランシーバーは WebRTC セッションの状態（ICE 接続チェック、DTLS ハンドシェイク、SRTP 暗号化キー、セッションライフサイクルを含む）を所有する唯一のサービスです。ここで言う「終端」とは、トランシーバーがそれらのハンドシェイクを完了し、メディアの暗号化または復号化を行うエンドポイントであることを意味します。この状態を一つの場所に保持することで、セッションの所有権について推論しやすくなり、バックエンドサービスが 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 つの共有ソケットで多数のセッションをデマルチプレックス可能 単一ホスト上ではきれいに動作するが、それ自体では共有ロードバランサー化されたファーム全体には対応できない 単一ホスト内でのセッションデマルチプレックスは、パケットがそのホストに到達した後にのみ機能する。ロードバランサー化されたファーム全体では、最初のパケットが誤ったインスタンスに到着する可能性があり、そのため依然として各セッションをそれを所有するプロセスへ誘導するための決定論的な方法が必要となる TURN リレー（プロトコル終端型） クライアントは TURN リレーのアドレスとポートへの到達のみでよい エッジ側でポリシーを一元化できる TURN アロケーションにはセットアップの往復遅延が発生する TURN サーバー間でのアロケーションの移動や回復はまだ困難である ステートレスフォワーダー＋ステートフルターミネーター（OpenAI のリレー＋トランスシーバー） 小さなパブリック UDP フットプリント トランシーバーは WebRTC セッション全体を依然として所有している メディアが所有するトランシーバーに到達する前に、転送ホップが 1 つ追加される リレーとトランシーバー間のカスタム調整が必要 私たちが実装したアーキテクチャでは、パケットルーティングとプロトコル終端を分離しています。シグナリングはセッション設定のために依然としてトランシーバーに到達しますが、メディアはまずリレーを通じて入ってきます。リレーは小さなパブリックフットプリントを持つ軽量な UDP 転送層であり、その背後にある状態管理型 WebRTC エンドポイントがトランシーバーです。 リレーはメディアの復号化を行わず、ICE（Interactive Connectivity Establishment）ステートマシンを実行せず、コーデックネゴシエーションにも参加しません。必要なパケットメタデータのみを読み取り、宛先を選択してセッションを所有するトランシーバーへパケットを転送します。トランシーバーは通常の 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:ポートにバインドされた OS エンドポイントが 1 つだけであることを意味します。リレーがクライアントのソース IP:ポートからそのトランシーバー宛先へセッションを作成した後、DTLS、RTP、RTCP パケットはセッション内で流れるようになり、ufrag の再デコードは不要になります。 リレーのセッションは意図的に最小限に設計されており、パケット転送を通知するためのメモリー内セッションと、監視用の必要なカウンタ、およびセッションの有効期限切れとクリーンアップのためのタイマーのみで構成されています。この設計により、パケットルーティングがパケットパス上で直接維持されます。リレーが再起動してセッションを失った場合、次の STUN パケットによって ufrag ルーティングヒントからセッションが再構築されます。さらに信頼性を高めるため、ルートが確立された後は Redis キャッシュを使用して * * のマッピングを保持し、次の STUN パケットが届く前に早期に復元できるようにしています。 パブリック UDP サーフェスを少数の安定したアドレスとポートに削減した後、同じリレーパターンをグローバルに展開できるようになりました。Global Relay は、すべてが同じパケット転送動作を実装する地理的に分散されたリレーイングレスポイントのファームウェアです。 広範な地理的イングレスにより、最初のクライアントから OpenAI へのホップが短縮されます。パケットは、遠隔地を経由してパブリックインターネットを横断するのではなく、ユーザーに近い地理およびネットワークトポロジー上のリレーでネットワークに入力できるためです。実用的には、これはトラフィックがバックボーンに到達する前に、レイテンシの低下、ジッターの減少、回避可能な損失バーストの削減を意味します。 シグナリングには Cloudflare の地理情報および近接性ステアリング機能を使用し、初期の HTTP または WebSocket リクエストが近くのトランスシーバ・クラスターに到達するようにしています。リクエストのコンテキストがセッションの場所を決定し、クライアントに対してどのグローバル・リレーイングレスポイントが広告されるかを指定します。SDP アサーはグローバル・リレーのアドレスを提供し、ufrag にはグローバル・リレーがメディアを指定されたクラスターへルーティングし、リレーが宛先のトランスシーバへ転送するために十分な情報が含まれています。 地理情報に基づくシグナリングとグローバル・リレーを組み合わせることで、セットアップとメディアの両方を近くの入口経路に配置しつつ、セッションは1つのトランスシーバにアンカー（固定）されたまま維持されます。これにより、シグナリングおよび最初の ICE 接続チェック（ICE connectivity check）の往復時間が短縮され、ユーザーが音声開始を待つ時間が直接的に短くなります。 リレーサービスは 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 言語におけるガベージコレクションを回避します。 この実装により、比較的狭いリレーのフットプリントでグローバルなリアルタイムメディアトラフィックを処理できたため、カーネルバイパス経路を採用するよりもシンプルな設計を維持しました。 このアーキテクチャにより、Kubernetes 上で WebRTC メディアを実行しつつ、数千の UDP ポートを公開する必要がなくなります。これは重要です。なぜなら、小さく固定された UDP の表面領域はセキュリティと負荷分散が容易であり、大規模なパブリックポート範囲を予約することなくインフラをスケールできるからです。Kubernetes からのより良いインフラサポートと、表面領域の縮小によるセキュリティ向上により、この設計はクライアントに対して標準的な WebRTC の動作を維持し、SFU-less（SFU なし）の設計が私たちのワークロードにとって適切なデフォルトであったことを確認しています。セッションの大半はポイントツーポイントであり、レイテンシに敏感で、推論サービスが WebRTC ピアのように振る舞う必要がない場合にスケールしやすいものです。 より広範な教訓として、複雑性を追加する最適な場所は、すべてのバックエンドサービスやカスタムクライアント動作ではなく、薄いルーティング層にあります。ルーティングメタデータをプロトコルネイティブのフィールドにエンコードすることで、決定論的な最初のパケットルーティング、小さなパブリック UDP フットプリント、そして世界中のユーザーに近い場所にイングレスを配置するための十分な柔軟性が得られました。 いくつかの選択が特に重要でした： - エッジ上でプロトコルの意味論を維持する。クライアントは標準的な WebRTC を使用し続けることで、ブラウザとモバイル間の相互運用性が保たれます。 - 厳密なセッション状態は単一の場所に保持します。Transceiver が ICE、DTLS、SRTP、およびセッションライフサイクルを管理し、リレーはパケットの転送のみを行います。 - セットアップ時に既に存在する情報に基づいてルーティングします。ICE の ufrag は、ホットパスルックアップ依存性を追加することなく、最初のパケットに対するルーティングフックを提供しました。 - カーネルバイパスに頼る前に一般的なケースを最適化します。SO_REUSEPORT の慎重な使用、スレッドピンニング、低割り当てパーシングを適切に組み合わせた狭い範囲の Go 実装で、私たちのワークロードには十分でした。 リアルタイム音声 AI は、インフラストラクチャがレイテンシを感じさせない場合にのみ機能します。私たちにとってそれは、クライアントが WebRTC から期待するものを変えずに、WebRTC デプロイメントの形状を変えることを意味しました。

OpenAI が大規模低遅延音声 AI を実現する手法

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

関連記事

調べる

選ぶ

サイト