ブログ

by Mari Ikeda

Hardware Transports for AI Networking: UET vs Falcon and Beyond

AIネットワークに求められるハードウェアトランスポート：UET vs Falcon、その先へ

この10年で、ネットワークは「単なる通信網」から、AIモデルの大規模トレーニングを左右する決定的な要因へと変わりました。Llama 4 (2兆パラメータ、30兆トークン対応) や xAIのColossusクラスター (10万台のH100e GPUで構成) といったLLMの登場により、従来のデータセンターのワークロードでは考えられないレベルの負荷がネットワークにかかっているからです。

AIモデルのトレーニングでは、処理を常に同期させる必要があります。すべてのGPU間で、all-reduce、all-gather、reduce-scatter といった同期・分散処理のための通信（集団通信）が完了しない限り次のステップに進めません。そのため、最も遅いパケットやリンクがシステム全体のAIトレーニングスループットを左右します。

先日、Mark Handley氏 (OpenAI & UCL) 、Brad Karp氏 (Google & UCL) 、Costin Raiciu氏 (Broadcom & UPB) らと行ったワークショップでは、ハードウェアトランスポートに話題が集まりました。AIモデルのトレーニングで発生する膨大なワークロードを処理するには、高速かつ信頼性があり、データを確実に運べるプロトコルが欠かせません。その中で、UET (Ultra Ethernet Transport) とFalconの2つが有力候補として挙がりました。

なぜ TCP や RDMA では不十分なのか

TCP：ネットワークやエンドノードの負荷が大きすぎます。カーネルでのプロトコル処理やパケットごとのACK処理によりマイクロ秒の遅延が発生し、400～800Gbpsのリンク速度においては永遠のように感じられます。
RoCE/RDMA：高性能コンピューティング (HCP) 向けに最適化されてはいますが、通信が途切れる可能性があります。RoCEはPFCによりロスレスイーサネット機能を前提としていますが、データの順序が入れ替わるとロスとみなされるため、マルチパスでロードバランシングを行う環境ではコネクションが不安定になります。また、DCQCNなどの輻輳制御をもちいても、集団通信に求められる速度では、即座に反応して安定性を保つことができません。

こうした背景から、低レイテンシーでマルチパスに強く、さらにハードウェアオフロード機能を備えた、AIワークロード専用の新しいトランスポートが求められています。

Ultra Ethernet Transport (UET)

UET (Ultra Ethernet Transport) とは、200社あまりが参画する Ultra Ethernet Consortium (UEC) が策定を進める次世代の標準トランスポート技術です。

主な特徴

パケットスプレーイング：各パケットを異なる経路で送信 (UDPソースポートのランダム性を利用) します。パケットの順序入れ替えへの耐性が必要です。
Trim/NACK + 高速再送：パケットを破棄する代わりに、スイッチがパケットをトリムし、損失を通知します。受信側は即座に損失したシーケンスをNACKにより通知できます。
輻輳制御 (NSCC) ：ECN ( Explicit Congestion Notification) により、パケットへのマーキングにより輻輳を早期に通知するのと、キュー遅延の両方を利用し、より迅速かつ公平に制御できます。
信頼性モード：Reliable ordered (ROD)：信頼性あり・順序保証あり / Reliable unordered (RUD)：信頼性あり・順序保証なし / Reliable unordered idempotent (RUDI)：信頼性あり・順序保証なし（冪等な操作を前提／重複受信があり得る）/ Unreliable unordered (UUD)：信頼性なし・順序保証なし
セキュリティー：暗号化と鍵管理機能を標準実装。
統合性：Libfabricを介すことで、MPI やベンダー製のCCLなど、コレクティブ処理むけライブラリーから利用できます。

UETは、非対称性や小規模インキャスト、マルチパスの利用が避けられないベストエフォート型のファットツリーネットワークでの利用を想定しています。

🔗 Ultra Ethernet Specification (2025)

Falcon

Falconは、Google が Open Compute Project (OCP-NET) の中で提唱する新たなトランスポート技術です。
UETがパケットスプレーイングを使用するのに対し、FalconはMPTCPに似たマルチパス・サブフロー方式を採用しています。

主な特徴

遅延ベースの輻輳制御： ECNより精度が高く、PFCに頼ったフローコントロールを完全に回避できます。
標準Ethernet：特殊なスイッチ機能は必要ありません (トリミングやリンク層での再送が不要) 。
レイテンシー：片道3µs、ホストあたり最大10万コネクションに対応。
マルチパス負荷分散：各コネクションが複数のフローを生成し、サブフローごとに輻輳制御を実施します。
レジリエンス：Tail Loss Probes (RACK-TLP) によりパケットの欠損を迅速に処理します。
対象ユーザー：マルチテナントやオーバーサブスクリプション環境を抱えるクラウドプロバイダー。AI/MLだけでなく、ストレージ、RPC、その他のワークロードにも対応できます。

🔗 Falcon OCP プロジェクト

🔗 Google ブログ： Introducing Falcon

UET と Falcon の機能比較

項目	UET (Ultra Ethernet)	Falcon (Google/OCP)
マルチパス戦略	パケットスプレーイング (パケット単位のランダム性を利用)	マルチパス・サブフロー (MPTCP類似)
順序入れ替えへの耐性	必須 (設計に組み込み済み)	順序入れ替えを回避 (サブフローのマッピングに依存)
スイッチ要件	パケットトリミング、CSIG 輻輳通知、リンク層での再送	なし (標準Ethernetで可)
輻輳制御	ハイブリッド方式：ECN + 遅延 (NSCC)	遅延ベース制御、RACK-TLP
性能目標	AIクラスタでの集団通信 (低レイテンシ重視)	汎用の低遅延ネットワーキング
適用環境	AI専用ファブリック、対称型ファットツリー	クラウド規模のデータセンター、マルチテナント環境
セキュリティー	暗号化と鍵管理を標準実装	ホストスタック/エコシステムに依存

その他のトランスポート技術

RoCEv2 (RDMA over Converged Ethernet)：現在のAIクラスターで依然として主流のプロトコルですが、スケールアウト環境では脆弱です。
Nvidia SpectrumX：スイッチがネットワークの混雑状況に応じて経路を切り替えながらパケットを分散します。
Broadcom Dynamic Load Balancing (DLB)：スイッチドリブンで輻輳状況を考慮しながら経路を選択します。
CSIG (Congestion Signaling) ：最大遅延、可用帯域、ボトルネックの位置など、Googleが提案した詳細な輻輳情報。FalconやUETの輻輳制御を強化する可能性があります。

未解決の課題

UETやFalconといった技術をもってしても、解決すべき課題はまだまだあります。

非対称性：スプレーイングは対称型ファットツリーでは効果的ですが、リンク障害やメンテナンスなどでトポロジーが変わると機能しません。
インキャスト問題：大規模なファンイン (ストレージシステムなど) は依然として大きな課題です。
テレメトリー：集団通信では1ms未満のごく短い時間で膨大な通信負荷（バースト）が発生しますが、その粒度でデバッグや最適化が行えるツールがありません。
マルチテナンシー：AIクラスターは専有環境で利用されるのが一般的ですが、クラウドの環境でファブリックを共有する場合は、テナント間の公平性を確保する仕組みが不可欠です。

まとめ

AIの発展は今やネットワークによって左右されており、業界は大きな分岐点に立っています。

UET：パケットスプレーイング、トリミング、専用のスイッチ機能を軸にトランスポートを再設計し、AIの集団通信を最適化します。
Falcon：標準Ethernetをそのまま活用し、マルチパス・サブフローや遅延ベースの輻輳制御、ハードウェアオフロードを組み合わせることで、クラウド規模のあらゆる環境で性能を発揮します。

どちらもAIの未来にとって有効な技術です。ハイパースケーラーがFalcon型のトランスポートを標準化するのか、それともUECが十分なベンダーを取り込み、UETを次世代のRDMAとして確立するのか。結果を左右するのは、性能そのものだけではなく、デプロイメントにかかる経済的側面かもしれません。