OpenAI が 9 億人のユーザー向けに低遅延音声 AI をどのように提供しているか（17 分読み）

Matic は、あなたの家を目にするように見て、あなたが望む通りに掃除ができる、世界初の視覚知能型ロボット掃除機です。**Matic の主要機能:** - カメラのみで動作し、障害物を巧みに回避して移動します - 床の種類を認識し、吸引と拭き取りを自動切り替えします - 大きな車輪と高さを調整可能な清掃ヘッドが、厚手のラグも対応します - 会話時の音量より静かな、55 デシベルの低騒音設計です - ペットの毛を詰まらせたり絡めたりすることなく処理できます - 1 つのバッグで乾いたゴミと湿ったゴミの両方を収集—オムツや塩、汚れた水はゲル化され、抗菌パウダーがカビを防ぎます - バッグには毎回新しい HEPA フィルター（High Efficiency Particulate Air filter）が搭載されており、空気をより清潔に保ちます。洗浄や交換の必要はありません。 180 日間の返金保証付きで、Matic とともに自律型掃除体験を味わってください。 [Matic を入手する](https://go.bytebytego.com/Matic_070126) OpenAI は週に 9 億人のユーザーに対して音声 AI を提供しており、そのために WebRTC（Web Real-Time Communication）を利用しています。なぜなら、代替手段を選べばインターネットがライブオーディオを扱う方法をゼロから再構築する必要が生じるからです。 ただし、WebRTC は安定した IP アドレスとポートを持つサーバー向けに設計されており、Kubernetes はそれらのアドレスを一時的なものとみなします。この規模における従来の解決策は SFU（Selective Forwarding Unit）ですが、これはグループビデオ通話のような多者間ワークロードには適しています。一方、OpenAI のトラフィックの大半は、1 人のユーザーが 1 つのモデルと対話するという形態です。 これに対処するため、彼らのアーキテクチャはスタックを 2 つの部分に分割しています： - ステートレスなリレーは、地理的エッジにおいてプロトコル認識型のパケットルーティングを処理します。 - ステートフルな送受信機は、すべての重い WebRTC の状態を管理します。 これらをつなぐ秘訣は、ICE ufrag（ICE 接続確立時にプロトコルがすでに交換するフィールド）を、リレーが新しいセッションの最初のパケットから読み取れるルーティングキーとして使用することです。Global Relay からユーザー空間の Go 実装、Redis キャッシュ、そして慎重なソケットレベルの最適化に至るまで、すべてがこの核となるアイデアの上に構築されています。 この記事では、OpenAI のエンジニアリングチームが直面した課題とともに、その全体像を詳細に解説します。 *免責事項：本投稿は Open AI エンジニアリングチームから公開された詳細に基づいています。不正確な点にご注意の場合はコメントをお願いします。 Voice AI は、会話のように感じられるか、それともトランシーバー（無線機）のように感じるかの違いです。その境界線はミリ秒単位で測られます。 ネットワークがユーザーの発言を聞き取り、応答する間に一時停止すると、その錯覚は崩れます。間延びした沈黙は awkward になり、割り込みは切り捨てられ、ユーザーは AI の話の途中でも強制的に遮らざるを得なくなります。これもまた失礼な行為です。つまり、会話が会話の速度で進む場合のみ、Voice AI は自然に感じられるのです。 その背後にあるより厳しい制約は、連続ストリームの性質です。音声はユーザーが話し終わった後の単一のアップロードとしてではなく、モデルに一定の流れとして届く必要があります。このストリームこそが、ユーザーがまだ話している最中にモデルが文字起こしを開始し、推論を行い、ツールを呼び出すことを可能にします。これが崩れると、体験はプッシュ・トゥ・トーク（押し話）に後退してしまいます。 OpenAI にとって、これらの制約は以下の 3 つの具体的な要件へと翻訳されます: - システムは、ユーザーがどこにいようと、週次アクティブユーザー数 9 億人に到達できなければなりません。 - コネクション設定は、セッション開始と同時にユーザーが話し始められるほど迅速に完了する必要があります。 - 音声の往復時間（RTT）は低く安定した状態を維持し、ターンテイク（話者交代）が鮮明に感じられるようにする必要があります。 WebRTC は、この種の作業のために業界が構築したプロトコルです。これは、ファイアウォールを越えて 2 つのエンドポイントが互いに到達する方法を見つける ICE、チャネルの暗号化を行う DTLS、音声パケット用の SRTP、品質フィードバック用の RTCP など、より小さなプロトコルの集合体（バンドル）です。WebRTC の元々のアーキテクトの一人である Justin Uberti と、OpenAI が構築する基盤となる Pion ライブラリを維持している Sean DuBois は、現在ともに OpenAI で働いています。このようなプロトコルレベルの深さは、彼らが実装したアーキテクチャに現れています。 OpenAI の WebRTC インフラストラクチャの最初のバージョンは、Pion を基盤とした単一の Go サービスでした。この 1 つの場所で両方の役割を処理していました: - シグナリング側では、サービスが SDP（セッションを記述するためにクライアントとサーバーが使用するフォーマット）の交渉を行い、コーデックを選択し、ICE 認証情報を生成してセッションを設定しました。 - メディア側では、サービスの WebRTC 接続をクライアントから終了し、推論、文字起こし、音声生成、ツール使用、オーケストレーションを実行するバックエンドサービスへのアップストリーム接続を維持しました。 この統合されたサービスは現在も ChatGPT の音声機能や Realtime API の WebRTC エンドポイント、およびいくつかの研究プロジェクトを支えており、その役割を十分に果たしてきました。OpenAI が直面した課題は、現代のクラウドインフラの多くを実行しているコンテナオーケストレーションシステムである Kubernetes 上でこれをどのように展開するかという点でした。 Kubernetes は計算リソースが安価で移動可能であると仮定しています。ポッド（Pod）は起動し、利用可能な容量がある場所にスケジューリングされ、しばらく実行された後、再スケジューリングまたは置き換えられます。一方、標準的な WebRTC の展開パターンはその逆を前提としています。この不一致は 2 つの具体的な場所で顕著に現れます。 1 つ目はポート枯渇の問題です。 WebRTC をデプロイする従来の方法は、セッションごとに UDP ポート 1 つを使用します。OpenAI のスケールでは、これはサービスあたり数万の公開 UDP ポートを意味します。クラウドロードバランサは少数のよく知られたポート向けに設計されているため、追加される各範囲がロードバランサの設定、ヘルスチェック、ファイアウォールポリシー、およびロールアウトの安全性において運用上の複雑さを増大させます。露出する表面領域もセキュリティ監査を困難にします。Kubernetes の自動スケールは、大規模で安定したポート範囲を予約するという要件と競合し、弾力性を脆弱なものにしてしまいます。 2 つ目はステートスティッキネス（状態の固定性）です。 サーバーごとに UDP ポート 1 つを実行し、その背後でセッションをデマルチプレックスすることでポートの問題は解決します。しかし、ICE や DTLS はステートフルなプロトコルです。セッションを開始したプロセスは、接続チェックの有効化、DTLS ハンドシェイクの完了、SRTP の復号化、および ICE リスタートのような後のセッション変更の処理のために、パケットを継続して受信し続ける必要があります。既存セッションのパケットが異なるプロセスに届いた場合、セットアップが失敗するか、メディアが切断されます。 両方の圧力は同じ答えを示しています。デプロイアーキテクチャは変更されなければなりませんが、クライアントエクスペリエンスは同一のまま維持されるべきです。 OpenAI が実装したアーキテクチャでは、パケットルーティングとプロトコル終端を分離しました。 ステートレスなリレーが前面に位置し、インターネットに対して小さな公開領域のみを提供します。一方、ステートフルなトランスシーバはその背後にあり、すべての重い WebRTC の状態を管理します。シグナリングは依然としてトランスシーバへ直接送信されます。メディアはまずリレーを経由して入力されます。 リレーの範囲は意図的に狭く設定されています。各パケットから宛先を選択するのに十分な部分を読み取り、残りは暗号化されたペイロードとして転送します。オーディオは通過中も暗号化されたまま保たれ、ICE 状態機械はトランスシーバーに留まり、コーデックのネゴシエーションは別の場所で行われます。クライアントの視点から見ると、WebRTC セッションはあらゆる点で通常通り動作しています。 トランスシーバーが記憶すべき WebRTC の部分を担当します。ICE 接続チェック、DTLS ハンドシェイク、SRTP 暗号化キー、そしてセッションライフサイクルはすべてここに存在します。トランスシーバーはハンドシェイクを完了し、実際のメディアの暗号化または復号化を行うエンドポイントです。 以下の図をご覧ください： チームが評価したが却下した明白な代替案が存在しました。 SFU（Selective Forwarding Unit）とは、大規模な WebRTC における標準的なメディアサーバーアーキテクチャです。これは各参加者ごとに 1 つの WebRTC 接続を終端し、ストリームをそれらの間で選択的に転送します。AI ももう一つの参加者として加わります。 この方式は、グループ通話、教室、共同会議など、本質的に多人数を対象とした製品ではよく機能します。しかし OpenAI のワークロードは異なります。ほとんどのセッションは 1:1 で、一人のユーザーが一つのモデルと対話する形です。そのようなトラフィックに対して SFU モデルを採用するとオーバーヘッドが生じ、バックエンドサービス自体が WebRTC ピアのように振る舞うことを強いることになります。一方、トランスシーバーモデルであれば、バックエンドは通常のサービスとして維持できます。 SFU 方式を示す以下の図をご覧ください： TURN も検討されましたが却下されました。 TURN は NAT 迂回に使用される標準的なプロトコル終端リレーです。問題は、TURN の割り当てを行うとメディアが流れる前にセットアップの往復遅延が発生し、サーバー間でそれらを移行または回復させるのが困難だということです。レイテンシに敏感なワークロードでは、これらの追加の往復遅延が問題となります。 この分割方式は原則としてポートと状態の問題を解決します。残っている問題は、リレーが最初のパケットを正しくルーティングできるようにすることです。 新しいセッションにおける最初のパケットが最も困難なものです。 その後のパケットは容易です。なぜなら、リレーには「このソース IP とポートからのパケットはこのトランスシーバーへ送られる」というマッピングが存在するからです。最初のパケットこそがこのマッピングを作成するものであり、リレーはそのパケット自体から宛先を特定する必要があります。 以下の図をご覧ください： 2 つの単純な選択肢が考えられました。 - ホットパスでのデータベース参照はレイテンシを追加し、別のサービスの健全性に対する堅牢な依存関係を生み出します。 - ランダムなトランスシーバーへのルーティングと内部転送は機能しますが、ホップ数が倍増してしまいます。 OpenAI は3 つ目の選択肢を選びました。 その答えは、WebRTC がすでに交換しているフィールドの中にあります。すべての WebRTC セッションには ICE ユーザー名フラグメント（ufrag と呼ばれます）が含まれており、これはセッションセットアップ中に生成され、STUN バインディングリクエストでエコーされます。STUN バインディングリクエストは、ICE が2つのエンドポイントが実際に互いに到達可能であることを検証するために使用するパケットであり、通常、クライアントがメディアパス上で最初に送信するものです。 ポイントは、OpenAI がシグナリング時にサーバー側で ufrag を生成していることです。彼らはそこに何を望んでも埋め込めるので、ルーティングメタデータをそこにエンコードしています。リレーは最初の STUN バインディング要求から ufrag を読み取り、ルーティングヒントをデコードし、セッションを所有するトランスシーバにパケットを転送するために必要な分だけ解析します。最初のパケット以降のすべてのパケットは確立されたセッションマッピングを通じて流れ、ufrag 解析ステップを完全にスキップします。 接続確立シーケンスの詳細を示す以下の図をご覧ください: フリートの各トランスシーバは、内部 IP とポートにバインドされた 1 つのオペレーティングシステムエンドポイントである共有 UDP ソケットでリスニングしています。そのトランスシーバのすべてのセッションは、その背後で多重化されます。 シグナリング中、トランスシーバは SDP アサーで共有リレー VIP と UDP ポートを返します。VIP は仮想 IP アドレスであり、これは整個リレーフリートの前面に位置するため、クライアントは 203.0.113.10:3478 のように安定した単一の宛先を認識しますが、実際にはそのアドレスの背後に多数のリレーインスタンスが存在します。クライアント側からはパケットを送信する場所が 1 つだけあり、セッションの存続期間中それは変わりません。 リレーの状態は意図的に極めて小さく保たれています。これは、送信元アドレスからトランスシーバ宛先へのインメモリマップと、監視用のカウンタ、セッションクリーンアップ用のタイマを保持するものです。リレーインスタンスが再起動してマッピング情報を失った場合、次の STUN パケットが ufrag からマッピングを再構築します。回復速度を向上させるため、Redis キャッシュにはルートが確立された後の送信元から宛先へのマッピング情報が格納されます。再起動したリレーは、この Redis から即座にマッピング情報を参照できます。 ここで示される原則は広く一般化可能です。ホットパス上でデータが必要な場合、プロトコルが既に交換している内容を確認してください。ペイロード内のフィールドを解析することは本質的に無料です。新しい照合を行うことは、レイテンシの増加、依存関係の追加、そして故障する可能性のある要素の増大を意味します。 公開 UDP サーフェスが少数の固定アドレスに縮小されたことで、同じリレーパターンがグローバルに展開可能になりました。 Global Relay は OpenAI が運用する地理的に分散したリレーイングレスポイントの集合体です。これらすべてが上記で説明した同一のパケット転送動作を実行しています。唯一変化するのは、地図上の配置場所だけです。 地理的な分散により、最初のクライアントから OpenAI へのホップ距離が短縮されます。ユーザーに近い地理的・ネットワークトポロジー上の位置にあるリレーを通じてネットワークに進入するパケットは、まず遠隔地を経由して到達しなければならないパケットと比較して、はるかに容易に処理されます。実質的な効果として、OpenAI のバックボーンにトラフィックが到達する前に、レイテンシの低減、タイミングの安定化、および損失プロファイルの改善がもたらされます。 OpenAI は、シグナリング側において地理的および近接性のステアリングに Cloudflare を使用しています。セッションを設定する初期の HTTP または WebSocket リクエストは、近くのトランスシーバクラスターへルーティングされます。その後、リクエストコンテキストに基づいて、SDP アサーでクライアントに広告されるグローバルリレーのイングレスポイントが決定されます。ufrag には、メディアを適切なクラスターへルーティングし、かつそのクラスターのリレーから適切なトランスシーバへルーティングするために十分な情報が含まれています。 その結果、シグナリング経路とメディア経路の両方が、ユーザーに近い地点で OpenAI ネットワークに進入しますが、セッション自体はその全ライフタイムを通じて特定の 1 つのトランスシーバにアンカーされたままとなります。セットアップの往復時間と最初の ICE コネクティビティチェックが短縮されるため、ユーザーが発話を開始するまでの待ち時間が直接的に削減されます。 リレーは、ユーザースペースで実行されている Go サービスです。つまり、通常の UDP ソケットから読み取る通常のプロセスのことです。 Linux カーネルはネットワークインターフェースから UDP パケットを受け取り、リレーの IP とポートにバインドされたソケットへ配信します。その後、Go プロセスがそのソケットから読み込み、少量のフロー状態を更新し、各パケットを適切なトランスシーバへ転送します。 OpenAI はカーネルバイパスフレームワーク（ユーザースペースプロセスがネットワークカードのキューに直接ポーリングすることを可能にするもの）を検討しましたが、採用は見送りしました。バイパスは運用上の複雑さを増大させる代わりにパケットスループットを向上させます。チームの負荷量は、慎重に実装された Go 実装で処理可能な範囲内に収まっていました。 パフォーマンス負荷の大部分を担う実装上の選択肢は3つあります。 - SO_REUSEPORT は、同じマシン上の複数のワーカーが同一の UDP ポートをバインドできるようにする Linux ソケットオプションです。カーネルはこのオプションにより、着信パケットをそれらのワーカー間で分散処理するため、単一の読み込みループによるボトルネックが解消されます。 - runtime.LockOSThread は、各 UDP 読み取り用ゴルーチン（Go 言語における軽量スレッド）を特定の OS スレッドに固定します。SO_REUSEPORT と組み合わせることで、同一フローからのパケットが同じ CPU コア上に留まる傾向があり、キャッシュの局所性が向上し、コンテキストスイッチの回数が削減されます。 - パケット解析時に事前割り当て済みバッファを使用し、コピーを最小限に抑えることで、割り当てオーバーヘッドを低く保ち、Go のガベージコレクタへの負荷をかけないようにしています。 要点は、通常の最適化手法で十分だったということです。このリレーは、比較的小さなリソースフットプリントで OpenAI のグローバルなリアルタイムメディアトラフィックを処理しています。 あらゆるアーキテクチャにはトレードオフが伴うものであり、この設計にも理解しておくべきいくつかのトレードオフが存在します。 - この設計全体は、1 対 1 のセッションを中心に構築されています。もし OpenAI が今後、複数参加機能（グループ通話、単一の AI セッション内での複数の参加者、通話中の人間へのハンドオフ）を追加したい場合、このアーキテクチャの大部分を再構築する必要が生じるでしょう。トランシーバモデルと SFU をスキップする選択は、ほとんどのセッションが正確に 2 つのエンドポイントしか持たないという前提に基づいています。 - OpenAI はまた、カスタムインフラストラクチャの負担も引き受けました。標準的な SFU（Selective Forwarding Unit: 選択転送ユニット）にはドキュメント、コミュニティ、そして実戦で検証されたパターンが付属しています。一方、リレー、トランシーバ、およびそれらの間の調整はすべて内部コードです。このスタックに取り組むすべてのエンジニアは、内側から外側までこれを習得する必要があります。 - 「ステートレス」なリレーは、実際には精神的にのみステートレスであることがわかりました。これはメモリー内のフローテーブルを保持し、再起動時にそのテーブルを回復するために Redis キャッシュを使用します。このアーキテクチャが機能するのは、プロトコルが ufrag からテーブルを再構築できるからですが、ソフトな状態（soft state）も依然として状態です。 - 最後に、ufrag のトリックは、シグナリングの両端を制御することに依存しています。OpenAI はサーバー側の ufrag を生成するため、自由にルーティングメタデータを埋め込むことができます。市販のシグナリングスタックを使用するチームにとっては、この技術を直接適応させることが難しい場合があるでしょう。 - OpenAI が音声 AI のために構築したアーキテクチャは、特定の圧力に対する慎重な対応です。WebRTC は安定したサーバー向けに設計されましたが、現代のクラウドインフラストラクチャはその逆の前提に基づいて動作しています。OpenAI のチームには、WebRTC セッションをそもそも 1 つのプロセス内で実行する必要があるかどうかを判断するためのプロトコルの深さがありました。 その答えは、作業を2つの部分に分割するものです。ステートレスなリレーがユーザーの近くでパケットを転送します。一方、特定の場所に固定されたステートフルなトランスシーバーが、ICE、DTLS、SRTP、およびセッションライフサイクルを管理します。この2つの部分は、WebRTC のハンドシェイクに既に含まれている情報を通じて通信し、ルーティング判断をパケットパス自体上に維持します。 実装の選択は意図的にシンプルに保たれました。ユーザー空間でのGo言語、SO_REUSEPORT、スレッドピンニング、そして慎重なメモリ管理が、カーネルバイパスが解決するべき役割を果たしました。その結果、比較的小さなリレーの足跡で、週次9億人のユーザーを処理できる体制が整っています。 参考文献：** - How OpenAI delivers low-latency voice AI at scale

OpenAI が 9 億人のユーザー向けに低遅延音声 AI をどのように提供しているか（17 分読み）

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

関連記事

調べる

選ぶ

サイト