Metaが100万GPU規模を想定した新通信プロトコル「MetaRoCE」を発表、パケットロスを前提にEthernetでAIクラスタを高速接続

親愛なる読者の皆さまへ。ご存じの通り価格高騰などの悪影響でサーバー運営がとても苦しい状態です。回線や台数を整理し見直せる部分は全て見直しましたが、やはりまだ危険水域です。このままだと1ページを10分割ぐらいして無理矢理PVを増やさざるを得なくなってしまいます。そこで、GIGAZINEの物理的なサーバーたちを、たった1円でも良いので親愛なる読者の皆さまに支援してもらえればとっても助かります！今すぐ寄付は上のボタンから！ ・ これまでGIGAZINEを支援してくれたメンバーのリスト

Metaが2026年8月24日、100万GPU規模のAIインフラをEthernetで接続することを想定した新しいプロトコル「MetaRoCE」を発表しました。従来のRoCEv2が前提としていた「パケットを順番通りに届ける」「できるだけパケットを失わせない」という考え方を見直し、パケットの到着順が入れ替わったり一部が失われたりする大規模ネットワークでも高い通信性能を維持できるよう設計されています。 MetaRoCE: A New RDMA Transport Built for AI-Scale Ethernet - Engineering at Meta https://engineering.fb.com/2026/08/24/networking-traffic/metaroce-rdma-transport-ai-ethernet/ 大規模なAIモデルを複数のGPUで学習させる場合、GPU同士は計算結果を頻繁に交換する必要があります。例えば「All-Reduce」や「All-to-All」と呼ばれる処理では多数のGPUがデータをやり取りするため、通信が遅いGPUが1台あるだけでも処理全体が遅れてしまいます。AIの推論でもモデルを複数のマシンに分割して動かす場合は通信遅延が応答時間に影響するため、GPUの台数が増えるほどネットワーク性能が重要になります。

GPU間通信で使われている技術の1つが「Remote Direct Memory Access(RDMA)」です。RDMAはCPUによるデータコピーなどをできるだけ介さず、ネットワーク経由で別のマシンのメモリと直接データをやり取りする仕組み。Ethernet上でRDMAを利用する仕組みは「RDMA over Converged Ethernet(RoCE)」と呼ばれ、Metaも大規模な分散AI学習にRoCEを利用してきました。 従来のRoCEv2は基本的にパケットが順番通り届くことを想定しており、「Priority Flow Control(PFC)」と呼ばれるフロー制御を利用してパケットロスを防ぐ構成が一般的ですが、ネットワークが巨大化して通信経路が増えると、複数の経路へパケットを分散させた方が帯域を有効活用できます。 MetaRoCEでは巨大なネットワークを1本の大きな通信経路として扱うのではなく多数の細かな論理経路に分け、通信を担当するNIC(ネットワークインターフェースカード)が個別に状態を把握します。各経路の状態をNIC側に伝えることで、NICが混雑している経路だけ通信量を減らしたり、問題が起きた経路を避けたりできるなどのメリットがあるとのこと。以下の画像では、左側の従来方式がネットワーク全体を1本の「パイプ」として扱うのに対し、右側ではMetaRoCEが採用する細かな経路単位の方式により、経路ごとの往復時間や混雑状況を把握できることが示されています。

複数経路へ積極的にパケットを振り分ける場合、パケットの到着順は送信順通りではありません。MetaRoCEには「Native Out-of-Order Delivery」が導入され、順不同でのパケット到着を異常ではなく通常の動作として扱います。各パケットに「メモリのどの位置に書き込めばよいか」という書き込み先の情報を持たせることで、先に到着したパケットから最終的なメモリ位置へ直接書き込めるようになったとのこと。

MetaRoCEの「Native Multipathing」では1つの接続で複数の経路を使い、パケット単位で通信を振り分けます。それぞれの経路について通信量や往復時間を個別に管理するため、1本の経路が混雑したり故障したりしても接続全体が巻き込まれにくくなっています。 またMetaRoCEはEthernet上でパケットロスが発生することも前提にしています。従来のようにPFCを使ってパケットロス自体を極力発生させないのではなく、各経路でパケット番号を管理して失われたパケットを検出。256ビットの選択確認応答(SACK)ビットベクトルを使って欠けたパケットを特定し、失われたパケットだけを再送するとのこと。 混雑制御では送信側が「Explicit Congestion Notification(ECN)」と呼ばれる混雑通知を参照するだけでなく、受信側から送信側に通信速度を伝える仕組みがあります。多数のマシンから1台へ通信が集中する「インキャスト」が起きた場合でも、受信側が利用可能な帯域を知らせることで通信量を素早く調整できるとMetaは説明しています。

MetaRoCEがネットワーク側に求める主な機能は、混雑を通知するECNと複数の同等な経路へ通信を分散する「Equal-Cost Multi-Path(ECMP)」です。パケットの一時停止をスイッチへ要求するPFCや特殊なネットワーク内テレメトリーなどを必須としないため、さまざまなEthernet構成で利用できるとのこと。既存のRDMA Verbs APIやソフトウェアスタックも基本的には変更せず利用できるほか、独立した複数のネットワーク面を並列に使う「マルチプレーン」などの機能を拡張APIから扱えます。 MetaはAMDと協力してPensandoのプログラマブルNICにMetaRoCEを実装し、64ノードのAMD GPUクラスタでRoCEv2との比較を行いました。以下はMetaが示した比較結果。縦軸はRoCEv2を基準とした処理完了時間の差を示しており、横軸は送信するデータのサイズを示しています。MetaRoCEを使用した場合、特にAll-Reduceにおいて幅広いデータサイズで処理時間が短縮されていることがわかります。一方でAll-to-Allでは一部のデータサイズで0％を上回る値もあり、データサイズによって結果にばらつきがあります。

パケットロスを発生させたテストでは、MetaRoCEは1％のパケットロスでも約86％のスループットを維持し、10％という大きなパケットロスが発生しても通信を継続できたとのこと。また4面および8面のマルチプレーンネットワークで最大4000件の接続を同時に扱った試験では、ネットワーク面の増加に合わせてスループットが伸び、経路を意図的に故障させてもアプリケーションや管理者の操作なしで通信が再分配されたと報告されています。 MetaはMetaRoCEの仕様をOpen Compute Project(OCP)を通じて公開し、異なるメーカーが互換性のあるハードウェアを開発できるようにする方針です。AMD Pensando以外のNICへの実装も進められています。 Metaは2026年10月の「2026 OCP Global Summit」でMetaRoCEの仕様、高速なパケット処理を行うためのソフトウェア基盤「Data Plane Development Kit(DPDK)」向けに最適化したリファレンス実装、製品が仕様に準拠しているか確認するためのテスト環境を公開する予定とのこと。今後はデータセンター内の大規模