要約

  • Ultra Ethernet Consortium は、Joint Development Foundation のプロジェクトであり、2023年7月19日に AMD、Arista Networks、Broadcom、Cisco、Eviden/Atos、Hewlett Packard Enterprise、Intel、Meta、Microsoft によって発足した。仕様策定のための業界コンソーシアムであり、通常の企業でもネットワーク事業者でもない。
  • UEC の範囲は、単に高速な Ethernet リンクや RoCE の代替に留まらない。573 ページに及ぶ仕様書 1.0.3 は、ソフトウェア層、トランスポート層、ネットワーク層、リンク層、物理層をカバーし、さらに管理、ストレージ、テスト、コンプライアンスに関する作業も含む。
  • Ultra Ethernet Transport は、複数の配送モード、パケットレベルのマルチパス、選択的再送、送信側／受信側駆動の輻輳制御、ECN、オプションのパケットトリミング、オプションのリンクローカル再送、オプションのクレジットベースフロー制御、オプションのエンドツーエンドトランスポートセキュリティを組み合わせている。
  • AMD、Broadcom、Nokia、Keysight の製品やデモンストレーションは実装が始まっていることを示すが、公的な適合性は主に実装者の自己宣言に依存しており、包括的な独立認証レジストリや大規模展開の調査は公開されていない。
  • UEC の戦略的機会は、既存の Ethernet 基盤とマルチベンダーサプライチェーンにある。最大のリスクは、エンドポイントの複雑さ、オプション機能による断片化、RAND 特許義務、管理・テストの未成熟さ、そして公開仕様と本番環境での実証済み相互運用性とのギャップである。

AI がネットワークをコンピュータの一部にした理由

Ultra Ethernet Consortium は、コンピューティングの経済性の変化から生まれた。一般的なエンタープライズネットワークでは、ファブリックは多数の独立したトラフィックフローを許容可能なスループットと可用性で転送すればよい。しかし、大規模な AI トレーニングシステムや HPC マシンでは、ネットワークは単一の同期計算の一部となる。数千のアクセラレータが集合演算でモデルパラメータ、勾配、科学データを交換する可能性がある。あるフェーズは、最も遅い参加者が必要な情報を受け取るまで進行しない可能性がある。パス間のわずかな不均衡、輻輳イベント、パケット損失が、平均的なファブリック利用率が健全に見えても、高価なプロセッサをアイドル状態にさせる。

そのため、オペレーターの最適化目標が変わる。総帯域幅は依然として重要だが、それだけでは不十分である。ジョブ完了時間、テールレイテンシ、インキャスト、ロスリカバリ、並列パスへのトラフィック分散、エンドポイントが保持すべき状態の量も同様に重要である。ほとんど全てのパケットを高速に配送しながら、ごく一部を遅延させるネットワークは、集合演算全体を停滞させる可能性がある。通常のトラフィックにとって許容可能な再送方式は、長いメッセージの中の１つのパケットが欠落しただけで時間を浪費しうる。単一等価パスに拘束されたフローは、トポロジ内の他の場所に容量が余っていても、アンダーパフォームする可能性がある。

UEC の創設時の主張は、これらの問題が単一の新しいスイッチ機能や改良された輻輳アルゴリズムだけでは解決できないというものだった。通信パスはネットワークの上位、ソフトウェアライブラリやアプリケーションセマンティクスから始まる。メモリ登録、リモート操作、トランスポート状態、パケット配送、輻輳制御、IP 転送、Ethernet リンク、光物理層、物理シグナリングを通過する。これらの層が個別に設計されると、ある部分の最適化が単にボトルネックを移動させるか、他の部分で互換性のない前提を生み出す可能性がある。

UEC の答えは、調整されたアーキテクチャである。オペレーターがこれらの技術に親しんでおり、スイッチ、光トランシーバ、ケーブル、ネットワーク OS、テレメトリ、管理を中心に巨大なサプライチェーンが形成されているため、Ethernet と IP は維持される。同時に、大規模な AI および HPC ワークロードにとって不十分とコンソーシアムが考える領域を変更または拡張する。その結果は、「新しいロゴが付いた普通の Ethernet」ではない。ソフトウェア API からレーン速度まで動作が定義された、特殊なトランスポートを慣れ親しんだネットワークに担わせようとする試みである。

この区別が、UEC がデジタルインフラストラクチャにとって重要である理由を説明する。このプロジェクトはアクセラレータ、工場、データセンター、クラウドリージョンを所有していない。メンバー企業や他の実装者が NIC、スイッチ ASIC、システム、ドライバ、ライブラリ、テスト機器に組み込むことができる契約を定義する。その影響力は、これらの独立した製品が、障害、輻輳、アップグレード、混合ベンダー環境で正しくデータを交換するときに初めて生じる。

UEC とは何か――何でないか

Ultra Ethernet Consortium は、正式名称が Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series である正式プロジェクトの公称である。シリーズ構造は、このプロジェクトを Joint Development Foundation および Linux Foundation ファミリーに位置付ける。参加者が新たな独立法人を設立することなく、メンバーシップ、ガバナンス、知的財産、資金調達、外部関係のための既存の法的枠組みを提供する。

この構造は重要である。なぜなら、UEC がしばしば企業、アライアンス、標準化団体として不正確に説明されるからだ。これは、株主、資本、評価額、個別に提出された財務諸表を持つ商業企業ではない。Ethernet 製品を販売せず、公共ネットワークを運用せず、メンバーが宣伝するハードウェアを所有しない。法的および知的財産の枠組みを持った仕様開発コンソーシアムである。その公開文書は、複数企業間の実装契約となることを意図している。

UEC は Ultra Ethernet Transport と同一でもない。UET は仕様の中核をなすトランスポートアーキテクチャだが、コンソーシアムの作業範囲はより広い。libfabric へのソフトウェアマッピング、パケットおよびメッセージセマンティクス、ネットワーク前提条件、リンク層オプション、物理層要件、管理、ストレージ調整、パフォーマンスとデバッグ、コンプライアンス、テストが含まれる。「新しい RDMA プロトコル」と単純化することは、プロジェクトを野心的かつ困難にしている層横断的な設計を見落とす。

UEC は IEEE 802.3 ワーキンググループでもない。IEEE 802.3 は、独自の正式なプロセスで基本的な Ethernet MAC および PHY 標準を策定する。UEC はこのエコシステムに依拠し、リエゾン関係を維持するが、それを置き換えるものではない。同様の境界は、UET の下位にある IETF メカニズム（IPv4、IPv6、Explicit Congestion Notification）、libfabric を維持する OpenFabrics エコシステム、ストレージ、オープンハードウェア、アクセラレータ相互接続に取り組む組織にも当てはまる。

プロジェクトのウェブサイトは、国際標準化団体の地位を示唆する表現を用いたことがある。より安全で証拠に基づく説明は次の通りである：UEC は JDF の枠組みの下での国際的な仕様開発組織である。UEC が国際標準化機構の一部であること、その文書が ISO 標準であること、または ISO 標準番号を保有していることを示す証拠はない。この違いは言語上の問題にとどまらない。権威がどこに由来するか、参加がどのように機能するか、実装者がどのような法的義務に直面しうるかを示す。

したがって、UEC は実際の機能に基づいて判断されるべきである。競合他社やオペレーターを共通の技術設計の周りに結集させ、仕様を公開し、ワーキンググループと宣言された特許義務を管理し、コンプライアンス文書や隣接組織との関係を発展させる。宣言だけで製品を相互運用可能にすることも、市場にそのアーキテクチャを採用させることもできない。

9 社からなる設立連合

このコンソーシアムは、AI および HPC サプライチェーンの異なる位置に立つ 9 組織によって 2023 年 7 月 19 日に発表された：AMD、Arista Networks、Broadcom、Cisco、Eviden（当時 Atos と関連）、Hewlett Packard Enterprise、Intel、Meta、Microsoft である。この広がりは当初から戦略的優位性であった。スイッチベンダーのみによって開発されたトランスポートは、アプリケーションやエンドポイントの制約を見落とす可能性がある。アクセラレータメーカーのみが主導する設計は、１つのハードウェアエコシステムに狭く最適化される可能性がある。純粋なクラウドプロジェクトは、アーキテクチャを製品に落とし込むために必要なシリコン、光トランシーバ、システムの専門知識を欠くかもしれない。

AMD はプロセッサ、アクセラレータ、エンドポイントネットワーキングを提供した。Arista と Cisco は大規模 Ethernet スイッチングと運用の経験をもたらした。Broadcom はスイッチングシリコン、NIC、高速 SerDes を提供した。HPE と Eviden は HPC システムと特殊インターコネクトの歴史をもたらした。Intel はプロセッサ、Ethernet、ソフトウェアの知識を提供した。Meta と Microsoft はハイパースケールオペレーターを代表し、大規模 AI クラスタの利用率を高め、単一の統合ベンダーへの依存を減らす直接的な関心を持っていた。

この連合は、競合するビジネス上の利益も内包している。メンバーは NIC、スイッチ ASIC、システム、クラウド容量、光トランシーバ、ソフトウェア、サポートを販売している。一部は実装に必要となる可能性のある特許ポートフォリオを保有する。ある者は広範なマルチベンダー標準から利益を得る一方、差別化された独自機能からも収益を得る可能性がある。したがって、コンソーシアムは競争を排除するものではない。競合他社が最小限のインタフェースについて合意し、実装品質、パフォーマンス、統合、商業条件で引き続き競争する場を提供する。

HPE の Slingshot インターコネクトは、技術的出自の有用な例である。Slingshot は、適応型ルーティングと輻輳管理を備えた Ethernet 互換の商用 HPC ファブリックである。HPE 関係者のコメントは、「HPC Ethernet」仕様が UEC に貢献されたと述べ、UET の大部分が Slingshot のトランスポートアイデアに由来すると見積もった。正確な割合は独立検証されておらず、コンソーシアムの計算として扱うべきではない。より大きな論点は十分に文書化されている：UEC は白紙から始まったのではなく、HPC、クラウドネットワーキング、RDMA、Ethernet における本番経験から引き出したのである。

この遺産の混合が、「オープン」という言葉を正確に使わなければならない理由の一つである。批准された UEC 仕様は公開ダウンロード可能である。アーキテクチャはマルチベンダー実装を意図している。しかし、このプロジェクトはメンバーが既存の知識、特許、製品ロードマップを提供する場でもある。文書の公開性が、技術の商業的または法的条件を無効にするわけではない。

競合他社の協業のための法的シリーズ

Joint Development Foundation のモデルは、UEC に、通常の事業会社に変えることなく正式な枠組みを与える。プロジェクトは独自の名称、範囲、メンバークラス、運営委員会、ワーキンググループ、IP 義務を持つ。JDF の傘は、企業および非営利インフラを提供し、プロジェクト資産や契約を保持することができる。これによりコンソーシアム形成のコストが下がり、競合他社に認知された協業手続きを提供する。

運営委員会がプロジェクトを主導する。文書化された責任には、ワーキンググループの調整、メンバーの受け入れ、資産と財務の管理、議長の選任または解任、進捗監視、公開リリースとプロジェクトブランドの管理が含まれる。コンセンサスが優先される。それが成立しない場合、憲章は、出席要件を満たした有資格メンバーによる 4 分の 3 の特別多数決メカニズムを規定する。書面による苦情は議長に提起できる。

初代議長は Meta の Brad Booth であった。現在の仕様 1.0.3 は、議長として AMD の J Metz、副議長として HPE の Barry Davis、技術諮問委員会（TAC）議長として Arista の Hugh Holbrook、TAC 副議長として Marvell の Puneet Agarwal を挙げている。Paul Congdon は仕様の編集者として記載されている。文書は、物理層、リンク、トランスポート、ソフトウェアの作業からのリーダーおよび執筆者も名指ししている。2026 年サミットのアジェンダは、さらに運用上の役職者をリストしている。これらの役割が必ずしも仕様上の正式な肩書に取って代わるものではない。完全な最新組織図は公開されていない。

憲章は、Steering、General、Contributor の 3 つのメンバークラスを認めている。Steering メンバーはガバナンスに参加し、通常は運営委員会に代表者を指名する。General メンバーは全ての技術グループで活動できるが、運営委員会には席を持たない。Contributor メンバーは選択されたグループに参加し、特別多数決では投票権を持たない。現在の公開メンバーページは、General および Contributor ティアを、Linux Foundation メンバーシップに加えて、それぞれ年間プロジェクト料金 20,000 ドル、5,000 ドルで販売している。Steering ステータスへの参加経路や現在の価格は明確に説明されていない。

形式的な権力の差は重要である。幅広いメンバーシップは専門知識と実装範囲を提供できるが、ガバナンスは均等に分配されていない。Steering ポジションを占め、多くのグループにエンジニアを派遣し、特許および製品プログラムを維持できる大企業は、より小規模な Contributor メンバーよりも実質的な影響力を持つ。非メンバーは最終仕様をダウンロードできるが、完全な草案プロセスを見ることはできず、同等の条件で参加することもできない。

プロジェクト内部の情報は通常の企業秘密のように扱われるわけではないが、メンバーは担当委員会が公開を承認する前に草案資料を開示してはならない。これにより、未完成のアイデアに関する競合他社間の議論が、時期尚早な市場シグナルなしに促進される。同時に、部外者は却下された提案、投票記録、実装に関する中間的な懸念、オプション機能の背後にある交渉を閲覧できない。最終版はオープンであるが、そこに至る道筋は部分的にしか見えない。

4 つのワーキンググループから 573 ページの仕様へ

2023 年の最初の公開 UEC 構造は、ソフトウェア、トランスポート、リンク、物理層の 4 つのワーキンググループに焦点を当てていた。その順序は、エンドツーエンドの野心を反映していた。メンバーシップは、無制限の公開メーリングリストとして直ちに開放されたわけではない。200 以上の組織が関心を示し、コンソーシアムはプロセスと独禁法オリエンテーションを伴う段階的なオンボーディングを実施した。参加者が複数の市場で直接競合し、共通の製品およびプロトコル要件について議論することになるため、この慎重さは理解できるものだった。

2023 年 12 月、UEC は約 40 社、300 人以上と報告した。技術諮問委員会（TAC）を設立し、8 つのワーキンググループに拡大していた。TAC の任務はアーキテクチャの一貫性であった。トランスポート設計は、別のグループが合意していないスイッチ動作、シグナリング方法、API を前提としてはいけない。2024 年 3 月、コンソーシアムは 55 社、750 人以上のアクティブ参加者を報告し、計画されたアーキテクチャについて格段に明確な説明を公開した。

3 月のアップデートは、後に規範的仕様に現れるアイデアを導入した：ソフトウェア側 API としての libfabric、パケットスプレーイング、柔軟な順序付け、複数の配送モード、送信側／受信側駆動の輻輳制御、ECN、パケットトリミング、リンク層再送、オプションのクレジットベースフロー制御、トランスポートセキュリティ、将来のインネットワークコレクティブである。また、UET は既存の Ethernet スイッチ上で動作可能であり、拡張スイッチが追加のパフォーマンスを提供できることを強調した。

技術的活動と並行して、組織的な広がりも拡大した。UEC は 2024 年 7 月に 1,193 人のアクティブ参加者、8 月に 97 のメンバー組織を報告した。これらは、完全には公開されていない定義に基づく日付入りのコンソーシアム数値である。これらを後日の数字に機械的に加算してはならない。2025 年、UEC はさらに 27 社が参加したと述べたが、離脱、合併、重複する報告期間のため、正確な現在の総数は不明である。ウェブサイト自体も、全てのメンバーが表示されるわけではないと注記している。

コンソーシアムは、2025 年 6 月 11 日に Ultra Ethernet Specification 1.0 を公開した。これにより、UEC はロードマップから公開実装ベースへと移行した。バージョン 1.0.1 は 9 月に続き、受信側クレジット制御のソースアルゴリズムと編集上の修正を行った。バージョン 1.0.2 は 2026 年 1 月に登場し、輻輳管理アルゴリズムを修正した。公式文書での発行日が 1 月 21 日か 28 日かについて不一致があり、その矛盾は目に見える形で残し、黙って解消すべきではない。

調査基準日現在の最新版は、2026 年 7 月 16 日に公開されたバージョン 1.0.3 である。573 ページで構成され、レーンあたり 200 Gb/s シグナリングのサポートとブーリアンネゴシエーション機能が追加された。リリースノートでは、パケット配送、輻輳クレジット、リンク層再送、物理層の制御順序セットに関する必要な修正、ならびにトランスポートセキュリティ、アトミック操作、トリミングパケットに関する明確化も挙げられている。必要な修正と編集上の明確化の違いは重要である。一部の変更は適合動作に関係し、したがって実装の保守に影響する。

デンバーで開催された 2026 年メンバーサミットは、第 2 の移行を示した。アジェンダは展開、製品化、コンプライアンス、管理、パフォーマンス、デバッグ、ストレージ統合、スイッチおよびエンドポイントテストに焦点を当てた。中心的なアーキテクチャ文書は存在する。プロジェクトの信頼性は今や、実装者が組織の境界を越えてスタックを構築し、認定し、運用し、更新できるかどうかにますます依存している。

5 つの機能層にわたるアーキテクチャ

現在の仕様は、Ultra Ethernet をソフトウェア、トランスポート、ネットワーク、リンク、物理層に分割する。この区分は有用だが、プロジェクトの価値は層を結びつける前提にある。

最上位では、AI フレームワーク、MPI、SHMEM、集合通信ライブラリが OpenFabrics Interfaces、特に libfabric を介して対話する。UET Semantic Services Sublayer は、アプリケーション操作をトランスポートトランザクションに変換する。Packet Delivery Sublayer は、メッセージのパケット化、順序付け、確認応答、回復の方法を決定する。Congestion Management は、ファブリックに流入するデータ量とトラフィックのパス分散を制御する。オプションの Transport Security はエンドポイント間トラフィックを保護する。標準の IPv4 または IPv6 がネットワーク層ルーティングを担う。Ethernet は、オプションの Packet Trimming、Link Layer Retry、Credit-Based Flow Control、Feature Negotiation を備えたリンクを提供する。物理層は、レーンあたり 100 または 200 Gb/s での統計およびシグナリング要件を定義する。

この構造は、既存ネットワークの重要な部分を保存する。UEC は IP ルーティングの代替を定義していない。標準的な Equal-Cost Multipath と ECN 対応スイッチが期待される。インテリジェンスの多くは、エントロピを操作し、トランスポート状態を追跡し、データを配置し、輻輳信号に反応するファブリックエンドポイントに残る。拡張スイッチは機能を追加できるが、UET トラフィックが通過する前に全ての設置がファブリック全体を交換する必要はない設計になっている。

これは移行上の利点をもたらすと同時に、分類上の問題を生む。ある設置では、ECMP と ECN を備えた従来型 Ethernet 上で UET エンドポイントを展開できる。別の設置では、トリミング、リンク再送、仮想チャネルごとのクレジット、より豊富なテレメトリ、そして後にはインネットワーク機能を追加できる。どちらも「Ultra Ethernet」と呼ばれながら、パフォーマンス、回復、運用の複雑さは大きく異なる可能性がある。

5 層アプローチはまた、障害の特定を難しくする。悪い結果は、アプリケーションマッピング、エンドポイントの状態機械、輻輳パラメータ、スイッチキュー設定、DSCP マッピング、光トランシーバ、ファームウェア、またはセキュリティシステムに起因する可能性がある。パケットを転送するだけでは不十分である。システムは、拡張時、混合トラフィック下、障害時、バージョン変更時に、意図されたセマンティクスとパフォーマンスを維持しなければならない。

ソフトウェア契約：独自 API ではなく libfabric

UEC は、適合エンドポイントの基本ノースバウンド API として libfabric 2.0 を選択する。この決定は、各フレームワークに新しい独自インタフェースを採用させる代わりに、プロジェクトを既存の HPC および高度なネットワーキングエコシステムに結びつける。libfabric は既にファブリック、ドメイン、エンドポイント、完了キュー、イベントキュー、アドレスベクトル、メモリ領域、メッセージング、リモートメモリ操作、アトミックを記述する。UEC はこれらの概念をマッピングし制約して、プロバイダが呼び出しを UET の動作に変換できるようにする。

戦略的価値は、トランスポート上位の連続性である。MPI、SHMEM、アクセラレータ通信ライブラリは、下位のプロバイダが変わっても、慣れ親しんだ抽象化を使用できる。原理的には、アプリケーションは、どのベンダーがパケット配送用の NIC を提供しているか、どのスイッチシリコンがパケットを転送しているかを知らずに操作を要求できる。これが、共通トランスポートがベンダー選択を可能にしうる中心的なメカニズムである。

しかし、抽象化は同等の実装を保証しない。プロバイダは、インジェクトサイズ、スキャッター／ギャザー制限、エンドポイント数、アトミック操作、メモリ登録、完了動作、ハードウェアオフロード、セキュリティ機能において異なりうる。同じ API に対してコンパイルされたライブラリが、異なるパフォーマンスや機能制限に遭遇する可能性がある。調達やソフトウェア認定には、「libfabric サポート」のチェックだけでは不十分である。

UEC のソフトウェア層は、ジョブと認可のセマンティクスも扱う。AI および HPC システムは、多くの場合、共通インフラストラクチャ上で複数のジョブを実行し、それぞれが独自のプロセス、メモリ領域、セキュリティ境界を持つ。仕様は、どのエンドポイントがどのジョブに属し、どのバッファにアクセスが許可され、リモート操作がどのようにマッピングされ、完了情報やエラー情報がどのようにソフトウェアに返されるかを決定しなければならない。これらの決定が、高速ネットワークがスケジューラ、ランタイム、アプリケーションにとって使い物になるか、それともパケットベンチマークでのみ見事であるかを決定づける。

プロジェクトは libfabric を所有していないため、OpenFabrics エコシステムに依存している。この関係は UEC のより広範な特徴を示している：アーキテクチャは、異なる場所で管理されるコンポーネントから成る。UEC は自らのトランスポートを libfabric にどうマッピングするかを定義できるが、API のメンテナやユーザーと調整しなければならない。IEEE Ethernet、IETF ネットワーキング、ストレージ組織、ベンダーのオペレーティングシステムにも同様の依存関係が存在する。

ファブリックエンドポイントとワークロードプロファイル

ファブリックエンドポイント（FEP）は、UET が終端する論理的な場所である。オペレーティングシステムインスタンスを 1 つ以上の分離されたファブリックプレーンに接続し、ユーザー空間プロバイダ、カーネルドライバ、NIC 側またはアクセラレータ側のトランスポート、メモリ登録、セキュリティコンテキスト、完了キュー、アドレスベクトル、さらにパケット配送と輻輳制御のための状態を含むことができる。

このエンドポイント中心の設計は、ほとんどのスイッチを識別可能な Ethernet および IP デバイスとして残す。FEP はエントロピ値を選択し、パケットおよび輻輳状態を保持し、認可されたメモリにデータを配置し、確認応答、トリミング、その他のフィードバックを解釈する。これにより、スイッチ内の独自ルーティングインテリジェンスへの依存を減らすことができる。同時に、複雑さは NIC シリコン、ファームウェア、ドライバ、ソフトウェアに集中する。

UEC は 3 つの実装プロファイルを定義する：AI Base、AI Full、HPC である。これらは異なるネットワークタイプではなく、実装がサポートしなければならない機能を規定するパッケージである。AI Base は、より低い実装コストと状態管理コストで通常の AI 通信をカバーすることを意図している。AI Full は、遅延可能送信、完全一致、Fetch や Compare などのアトミック操作を追加する。HPC プロファイルは AI Full の大部分を含むが、遅延可能送信を除外し、順序付け、ショートメッセージ、HPC セマンティクスにより重点を置く。

プロファイルシステムは、全ての製品が最大限の機能を実装しなければならない事態を防ぐことを目的としている。大量生産向けの AI NIC は集合的なデータ移動を優先し、一方 HPC エンドポイントはより強力な順序付けとアトミックを必要とする可能性があることを認識している。それでも、オプション性は消えない。製品はプロファイル内のオプション機能を実装でき、同じプロファイルラベルを持つ 2 つの製品は、セキュリティ、リンク拡張、容量、パフォーマンスで異なりうる。

用語そのものが警告信号である。規範的な仕様 1.0.3 は AI Base、AI Full、HPC を使用している。一方、2025 年の別のコンプライアンス Readme は AI Base、AI Extended、HPC を使用している。最も裏付けのある解釈は、「AI Full」が最新であり、コンプライアンス資料が古いか不整合であるというものである。公開テストパッケージが修正されるまでは、ベンダーと購入者は主張の背後にある仕様バージョンと正確なプロファイル表現の両方を明示すべきである。

アプリケーションの意図からパケット配送へ

UET の内部では、Semantic Services Sublayer がアプリケーションの意図を担う。メッセージアイデンティティ、バッファアドレッシング、タグ付きおよびタグなし操作、リモートメモリアクセス、アトミック、完了動作、ジョブ識別子、バッファ認可、応答、エラーを定義する。次に、Packet Delivery Sublayer が、その意図がどのようにパケットになり、別のエンドポイントに到達するかを決定する。

信頼性モードのために、エンドポイントは Packet Delivery Context（PDC）を設定する。PDC は、パケットシーケンス番号、確認応答、重複検出、順序モード、輻輳情報、リターンパス状態、トラフィッククラスなどの状態を含む。PDC は配送モードとトラフィッククラスに関連付けられ、同一の FEP ペア間に複数の PDC が存在しうる。

この状態は、単なる実装詳細ではない。大規模クラスターは、膨大な数の通信関係を生成しうる。各関係が大規模な宛先状態を要求する場合、エンドポイントのメモリとルックアップコストが制限となる可能性がある。そのため、UEC は全ての操作を単一の接続モデルに押し込めるのではなく、信頼性と順序付けに関する異なる契約を持つ 4 つの配送サービスを定義している。

Reliable Unordered Delivery（RUD）は、各パケットを正確に一度だけセマンティクス層に配送するが、順不同の到着を許容する。複数パスにわたるパケットスプレーイング、選択的再送、重複抑制、直接データ配置をサポートする。宛先がトランスポートの再順序付けバッファを待たずにオフセットに基づいてデータを配置できるため、長い集合演算は、欠落したパケットの後ろに全パケットを直列化することなく、複数のパスを利用できる。

Reliable Ordered Delivery（ROD）は、正確に一度の順序付き配送を保証する。1 つのパスと 1 つのエントロピ値を使用し、順不同のパケットを廃棄し、最初の欠落シーケンス番号から Go-Back-N 回復を使用する。これは RUD ほど洗練されていないように見えるが、厳密な順序付けが必要な操作のセマンティクスを保持する。UEC は順序付けをアプリケーション要件として扱い、全ての転送にそのコストを負わせない。

Reliable Unordered Delivery for Idempotent Operations（RUDI）は、異なる焦点を置く。少なくとも一度配送し、重複を許容することで、宛先での通常のシーケンス状態や確認応答状態を削減する。これは、後続の別個のバリアを伴う選択的リモートメモリ転送など、操作の繰り返しが最終結果を変えない場合に有用である。誤って使用されると危険である。パケット層自体は冪等性を推論しない。ソフトウェアが判断しなければならない。非冪等操作に対する RUDI は、無効なアプリケーション状態を生み出しうる。

Unreliable Unordered Delivery（UUD）は、通常の信頼性や順序付け保証なしにベストエフォートのデータグラムを配送する。同じセマンティクスフレームワークに属するが、RUD や ROD と同じ輻輳制御要件を負わない。アプリケーションは、キューやトラフィッククラスが共有される場合、UUD が輻輳制御トラフィックを害さないようにしなければならない。

これら 4 つのモードは、UEC の中核哲学を示す：ソフトウェアがトランスポートコストを操作のセマンティクスに適合させられるよう、ネットワークは複数のメカニズムを提供すべきである。利点は効率である。代償は、実装とテストの表面積が拡大し、プロバイダ、アプリケーション、またはオペレーターが非互換の組み合わせを選択する機会が増えることである。

パケットスプレーイング：幸運なパスを期待せずにファブリックを活用する

従来の Equal-Cost Multipath は、多くの場合、ハッシュに基づいてフロー全体を 1 つのルートに固定する。広範な Clos ファブリックでは、これが宝くじを生む。複数の大きなフローが同じリンク上で衝突する一方、他の場所では同等の容量が使われずに残る可能性がある。長い AI 転送は、不運なハッシュによってその全ライフタイムにわたって制限される。

UET は、パケットレベルでエントロピを変化させることによってこれに対応する。送信者は数十または数百のエントロピ値を使用でき、スイッチの既存の ECMP メカニズムが多数のルートにパケットを分散する。Packet Delivery Sublayer がシーケンス情報を提供し、Congestion Management Sublayer がエントロピまたはパスを選択し、スイッチは通常のハッシュを実行し、フィードバックがどの値が輻輳の疑いがあるかを送信者に伝える。

パケットスプレーイングが実用的であるのは、設計の他の部分がそれを支えているからに他ならない。パケットは順不同で到着してよい。RUD は完全なトランスポート再順序付けを待たずにデータを直接配置できる。選択的再送は失われたものだけを取り戻す。輻輳フィードバックは問題のあるパスの使用を減らす。したがって、このメカニズムは単独のロードバランシングのトリックではなく、パスの多様性の上に構築されたトランスポートモデルの一部である。

UEC は全てのスイッチに独自の適応型ルーティングアルゴリズムを要求しない。基本的な実装では、標準の ECMP 上でラウンドロビンまたは疑似ランダムなエントロピを使用できる。より高度なエンドポイントは、ECN、レイテンシ、トリミング信号を特定のエントロピ値にマッピングし、輻輳したパスを回避できる。ベンダー固有の適応型転送は UET と共存できるが、パス知識の唯一の源ではない。

その約束は、ファブリック利用率の向上とテールレイテンシの低減である。未解決の問題は、異なるエンドポイントがフィードバックをどれだけ一貫して解釈するか、そしてパケットスプレーイングがスイッチバッファ、再順序付け、障害、混合トラフィックとどのように相互作用するかである。均質な実験室で機能するアルゴリズムが、複数のスイッチ世代とトラフィッククラスを持つ大規模ファブリックでは異なる振る舞いをするかもしれない。独立したマルチベンダー証拠は依然として限られている。

3 つの異なるボトルネックに対する 3 つの輻輳メカニズム

UEC は単一の普遍的な輻輳アルゴリズムを定義していない。ネットワークコアでの輻輳、受信側でのインキャスト、限られたエンドポイントバッファを区別する。

Network-signal Congestion Control（NSCC）は、送信元によって制御される。送信者は輻輳ウィンドウを維持し、飛行中のバイト数を推定し、確認応答、否定応答、タイムアウト、レイテンシ、ECN などのネットワーク信号に基づいてウィンドウを調整する。ウィンドウ動作はパケットレベルのマルチパスと調整される。UEC は、パケットがネットワークから出なくなったときにウィンドウが新規データの取り込みを自ら停止する一方、純粋なレートベースのコントローラはフィードバックの欠如を誤解釈する可能性があると論じている。

これはコンソーシアムのアーキテクチャ上の主張であり、全ての NSCC 実装が DCQCN や他の RoCE 輻輳制御方式より優れているという独立した証明ではない。結果は、アルゴリズムの詳細、スイッチマーキング、トポロジ、トラフィックパターン、パラメータに依存する。「NSCC を使用している」は、それだけでは十分なパフォーマンス表明ではない。

Receiver-credit Congestion Control（RCCC）は、インキャストに対処する。多数の送信元が同時に 1 つの宛先に送信すると、ネットワークコアが輻輳していなくても最終リンクがボトルネックになる可能性がある。受信側は需要を追跡し、送信者間でクレジットを分配して、総到着レートを調整し、各送信元の実効ウィンドウを競合に応じて変化させる。受信側の輻輳とコア輻輳は異なる問題であるため、RCCC は NSCC と連携できる。

Transport Flow Control（TFC）もクレジットを使用するが、バッファが限られたポイントツーポイントサービス向けに設計されている。目標は、ロス耐性が低い場合に受信バッファオーバーフローを直接防ぐことである。TFC はマルチパスの有無にかかわらず使用できる。全てのクレジットメカニズムを同一視することは、それぞれが制御しようとする異なる障害ドメインを覆い隠してしまう。

仕様はファブリック全体での Explicit Congestion Notification を期待しており、エンキュー時だけでなくデキュー時のマーキングを含む、マーキングに関する運用上の前提を含んでいる。エンドポイントは ECN を確認応答、レイテンシ、トリミングと共に解釈する。したがって、統一的なスイッチ設定が不可欠である。正しいトランスポート実装でも、誤った設定のファブリックでは不良な結果を生みうる。

メンテナンス履歴はその難しさを示している。バージョン 1.0.1 は RCCC の送信元アルゴリズムを修正した。1.0.2 は輻輳管理のケースを修正した。1.0.3 はクレジットとリンク層再送の相互作用を修正した。これらは生きた仕様の通常の兆候であるが、同時に、クレジット、再送、パス制御の状態が微妙に絡み合っている証拠でもある。オペレーターは初日の適合性だけでなく、バージョン管理の規律とリグレッションテストを必要とする。

パケットトリミングと高精度な損失回復

パケットトリミングは、適格なスイッチが完全なパケットを保持できない場合の動作を変える。フレームを情報なしに破棄する代わりに、スイッチはペイロードの大部分または全部を除去し、識別に十分なヘッダーとメタデータを保持し、パケットを「トリミング済み」とマークし、その短縮通知を受信者に転送する。受信者はその後、具体的にどのデータが失われたかを送信者に通知できる。

これは ECN マーキングよりも情報量が多い。ECN は輻輳が発生したことを伝えるが、トリミングはペイロードが生き残らなかった特定のパケットを指し示す。RUD および選択的再送と組み合わせることで、タイムアウトを待ったり、1 つの損失のために長いシーケンスを再送したりすることなく、回復を加速できる。

スイッチ機能はオプションだが、適合エンドポイントは該当する要件の下でトリミングされたパケットを受信し解釈できなければならない。この非対称性は、従来型スイッチを介した展開をサポートする一方、拡張ファブリックが豊富な損失情報を提供することを可能にする。同時にアップグレードの問題も生じる。部分的に拡張されたネットワークでは、受信側の全エンドポイントが正しく処理できるよう、トリミングをパス、プロファイル、トポロジごとに制限する必要があるかもしれない。

UEC はまた、リクエスト、制御パケット、再送、トリミングされたトラフィックに対して異なるトラフィッククラスを定義する。オペレーターは DSCP 値、スイッチキュー、エンドポイントキュー、優先度を一貫してマッピングしなければならない。仕様はこのための普遍的な管理システムを提供していない。マッピングの誤りは、制御トラフィックを枯渇させ、輻輳フィードバックを歪め、あるいは回復パケットを本来修復すべきトラフィックと競合させうる。

パケットトリミングは、このプロジェクトのより大きな実装課題を示している。プロトコルはワイヤ上の動作を定義できるが、運用結果はスイッチキューイング、エンドポイントロジック、テレメトリ、設定、エラー処理に依存する。相互運用性はシステム特性であり、単なるパケットフォーマットの特性ではない。

リンク回復、クレジット、機能ネゴシエーション

Link Layer Retry（LLR）は、エンドツーエンドのトランスポートが反応する前に、物理リンク上のエラーを修正しようと試みる。ピアはシーケンスギャップまたは破損フレームを検出し、リンクローカルの否定応答を送信し、送信者にローカルバッファから該当フレームを再送させる。回復が迅速に成功すれば、トランスポートはより長いエンドツーエンド再送を回避できる。

潜在的な価値は、レーン速度とポート密度が上がるほど高まる。散発的な光学的または電気的エラーは、密に同期されたジョブに不釣り合いな遅延を引き起こしかねない。しかし LLR は、シーケンス状態、リプレイバッファ、制御メッセージ、廃棄ウィンドウ、新しいエラーモードを追加する。また、クレジット更新やリンクリセットと共存しなければならない。バージョン 1.0.3 は、CBFC のクレジット情報と LLR の間の競合を含む、いくつかの境界ケースを修正した。

Credit-Based Flow Control（CBFC）は、仮想チャネルごとのリンクレベルで動作する。受信容量がどれだけ残っているかを送信者に伝え、広範な優先度ベースのポーズよりも細かい粒度を実現できる。UEC は、全ての UET ファブリックを完全に無損失にする必要なく、制御された無損失動作のための手段としてこれを説明する。CBFC はオプションであり、UET はベストエフォートネットワーク上でも動作するはずである。

CBFC は単に Priority Flow Control の別名ではない。どちらもバッファオーバーフローを防ぐことを目的とするが、シグナリングと粒度が異なる。CBFC は依然として一貫した設定と、自身の制御フレームの正しい配送を必要とする。また、ローカルクレジットはエンドツーエンドウィンドウや受信者クレジットと相互作用し、複数の入れ子になった制御ループを生み出す可能性がある。

UEC は LLDP ベースのネゴシエーションを使用して、オプションのリンク機能を発見し、片側が隣接機器のサポートしていない機能をアクティブにするのを防ぐ。ネゴシエーションは、プロファイル、仮想チャネル、DSCP および優先度マッピング、リセット、ソフトウェアアップグレード、部分的な機能の組み合わせを考慮しなければならない。バージョン 1.0.3 はブーリアンネゴシエーション機能を追加し、各リンクでの明示的な合意の必要性を強調した。

これらのオプションは、基本的な Ethernet から拡張 Ethernet への道筋を作る。同時に、調達文言が隠蔽しうるマトリックスを生み出す。あるスイッチは、トリミング、LLR、CBFC をサポートせずに UET を完璧に転送できる。別のスイッチは、特定のソフトウェアバージョンまたはポートモードでのみこれらの機能を提供するかもしれない。信頼できる展開の証拠は、コンソーシアムの名称だけでなく、正確な機能セットを必要とする。

レーンあたり 100 および 200 ギガビットの物理シグナリング

物理層は UEC をハードウェアロードマップに固定する。最初の 1.0 の作業はレーンあたり 100 Gb/s シグナリングを対象としていた。バージョン 1.0.3 はレーンあたり 200 Gb/s を追加した。これにより、仕様はより高密度なリンクとシステムの世代に合わせられるが、文書上の能力は全ての UEC 製品がその速度を即座にサポートすることを証明しない。

PHY の作業は、前方誤り訂正（FEC）統計、訂正可能／訂正不可能符号語比率、制御順序セット、リンク品質レポート、物理エラーと LLR の相互作用も扱う。これらの詳細は、回復のためのトランスポート決定が、下位層が観測および報告できる内容に依存するために重要である。

シグナリング速度が向上するにつれて、光トランシーバ、SerDes、FEC、リンク再送、トランスポート回復の間の境界は経済的に有意となる。より強力な FEC は、レイテンシと消費電力の増加を犠牲に残留エラーを低減できる。リンク再送はローカルエラーをより迅速に修正できるが、バッファと状態を必要とする。エンドツーエンド再送はネットワーク全体でより単純だが、より多くの時間を浪費しうる。UEC は、各ベンダーが個別に最適化するのではなく、これらの層がどのように連携するかを定義しようと試みている。

200G レーンの追加は、コンソーシアムの動く目標も示している。バージョン 1.0 の実装者は、互換性を維持しつつ、新しい物理能力を計画しなければならない。テスト機器、ファームウェア、管理システムは、各ポートが何をサポートするかを区別しなければならない。購入者は、一般的な UEC 表明からレーン速度を推測してはならない。

オプションのエンドツーエンドトランスポートセキュリティ

Transport Security Sublayer（TSS）は、エンドポイント間のオプションの保護を提供する。その脅威モデルはスイッチへの信頼を要求しない。機密性、完全性、リプレイ保護、ジョブ分離、セキュアドメイン、グループキー、キーローテーション、ハードウェアベースの信頼ルートの統合を提供しうる。

設計は、メンバーが暗号コンテキストを共有するセキュアドメインを用いる。識別子、アソシエーション番号、エポック、セキュア送信元アイデンティティ、キー導出は、エンドポイントペアごとの独立セッションよりもスケールしやすいように意図されている。これは、アクセラレータの規模やジョブメンバーシップが急速に変化する場合に必要である。

プロトコルはセキュリティシステムの一部に過ぎない。本番環境のオペレーターは、キー権限、証明書またはその他の信頼ルート、ジョブメンバーシップサービス、配布と失効、エポック変更、エンドポイントリカバリ、ハードウェア暗号化、セキュリティテレメトリを運用しなければならない。ネットワークは、全てのオプション TSS 機能をアクティブにすることなく、プロファイルに準拠できる。「UEC 準拠」は自動的に「暗号化されている」を意味しない。

このオプション性は、異なる展開の前提を反映している。専用の物理的に管理されたファブリックは、パフォーマンスを優先し、環境対策に依存するかもしれない。マルチテナントクラウドは、強力な分離と暗号保護を必要とするかもしれない。プロファイルおよび調達システムは、この違いを可視化しなければならない。

最大のリスクは、暗号化オーバーヘッドだけではない。大規模なライフサイクル失敗である：廃止されたメンバーシップ、遅延した失効、一貫性のないエポック、エンドポイント障害後の回復、またはどのジョブがどのメモリにアクセスできるかを証明できないことである。これらの問題は、トランスポートセキュリティをコア仕様外のオーケストレーションおよびアイデンティティシステムと結びつける。

「UEC 準拠」が現在意味するもの

UEC はバージョン 1.0 のコンプライアンス文書の公開を開始したが、公開されているシステムは成熟した独立認証体制ではない。利用可能なパッケージは主に実装者の自己宣言向けに設計されている。マトリックスが仕様要件をプロファイルにマッピングし、テストベッドガイドが推奨されるエンドポイントとスイッチの設定を記述している。独立した機関が完全な UEC プログラムで製品を合格または不合格として登録する包括的な公開レジストリは見つからなかった。

この区別は、市場でさまざまな主張が飛び交っているために本質的である。製品は、進化する UEC 機能を中心に設計されているかもしれない。選択されたワイヤ機能を実装しているかもしれない。特定のソフトウェアバージョンでプロファイルまたはその一部をサポートしているかもしれない。ベンダーは完全な機能適合性を主張するかもしれない。ラボはスイッチを介して UET トラフィックを生成できる。これらの表明のどれも、独立したエンドツーエンドのマルチベンダー認証と自動的に等価ではない。

公開テストベッド推奨は有用だが、意図的に範囲が限定されている。完全なシステム認定ではなく、ベストプラクティストポロジとチェックを提供する。より広範な相互運用性、パフォーマンス、ストレス、スケール、API ライフサイクルは除外されるか、完全にはカバーされない。資料は、UET と RoCE の混合トラフィック、部分的なアップグレード、反復的な障害、大規模キードメイン、コンソーシアムの最も野心的なエンドポイント数における挙動を証明しない。

AI Full と AI Extended の不一致は、コンプライアンスに厳格なバージョニングが必要な理由をさらに示している。購入者は、主張がどの仕様、訂正レベル、プロファイル、オプション機能、リンクモード、セキュリティ機能を対象としているかを尋ねるべきである。回答は、その証拠が内部テスト、二者間デモ、コンソーシアムイベント、または独立ラボに由来するかを説明すべきである。

信頼できる次のステップは、正確な仕様バージョンに紐付いた公開テスト定義、マルチベンダープラグフェスト、否定的結果を含む独立管理された結果、エンドポイント、スイッチ、ソフトウェア、完全なシステムを区別するレジストリであろう。それまでは、「UEC 準拠」は完全な保証ではなく、入口の質問である。

オープンな文書と RAND 特許義務

Ultra Ethernet Specification 1.0.3 は公開ダウンロード可能であり、Creative Commons Attribution-NoDerivatives 4.0 の下で配布される。これにより、表示付きでの共有は許可されるが、改変版の配布はこのライセンス下では許可されない。より重要なことに、著作権アクセスと特許アクセスは分離されている。

文書化されたワーキンググループ憲章は、一般に、合理的かつ非差別的な特許ライセンス（RAND）を伴う伝統的な仕様モデルを用いる。RAND は必ずしもロイヤルティフリーを意味しない。統一価格を保証せず、交渉を排除せず、有効性、必須性、地理的条件、防御的条件に関する紛争を防がない。実際の商業的地位は、個々の宣言特許、メンバーのコミットメント、二者間ライセンスに依存する。

UEC は必要なクレーム宣言の公開レジストリを維持している。基準日現在、Broadcom、Microsoft、Huawei、Qualcomm、AMD、HPE、Google、Marvell などからの宣言が可視化されており、将来の 1.1 作業に関する提出も含まれている。このレジストリは、実装者が製品を開発または出荷する前に知的財産を審査しなければならないことを示すため、透明性を高める。

コンソーシアムは、宣言された特許が有効か、実際に必須か、侵害されているか、特定の価格で利用可能かを明示的に判断しない。また、プールライセンスを公表しない。したがって、小規模な実装者は、大規模メンバーがより容易に吸収できる法的および取引コストを負担する可能性がある。公開利用可能な仕様であっても、特許開放、シリコンコスト、テスト負荷が高い場合、商業的に集中したエコシステムを生み出しうる。

IP フレームワークはガバナンスインセンティブも形成する。企業は、自社製品の広範な市場を創出し、既存の能力が共通設計に反映されるようにするために技術を提供する。特許宣言は、適時かつ十分に明確に行われた場合にのみ、実装者を驚きから保護する。ライセンスが普及後に障壁となる可能性を排除するものではない。

したがって、公正な表現は「RAND 特許義務を伴う、公開されマルチベンダー向け」であり、「普遍的にロイヤルティフリー」ではない。調達チームは技術プロファイルとライセンス経路の両方を必要とする。

最初の製品とテストの波

実装の証拠は 1.0 の公開前後に可視化されたが、例はさまざまな成熟段階にある。

AMD は 2025 年 4 月に AI NIC Pollara 400 を商用利用可能にし、進化する UEC 機能を中心に設計されたと説明した。Pollara はプログラム可能なエンドポイントプラットフォームであり、トランスポートが出荷されるハードウェアに移行したことの重要なシグナルである。表現が決定的である：「進化する UEC 機能向けの設計」は、1.0.3 のすべての最終要件に対する独立認証ではない。

Broadcom は、2025 年 6 月に Tomahawk 6 を毎秒 102.4 テラビットのスイッチング ASIC として発表し、UEC 関連機能を備えるとした。10 月には Thor Ultra 800G NIC を発表し、ベンダーは完全な UEC 機能適合性を主張した。これは重要な表明だが、公開証拠はそれを独立したコンソーシアム認証とはしていない。サンプリング、ソフトウェアの成熟度、正確なプロファイルサポートは別途示される必要がある。

Nokia と Keysight は 2025 年 10 月に、Nokia のデータセンタースイッチファミリ 7220 および 7250 を介した UET トラフィックのエンドツーエンドデモンストレーションを 800 ギガビット Ethernet で発表した。Keysight はトラフィック生成と検証を提供した。テストは、UET トラフィックが商用スイッチングシステムを通過できること、およびテスト機器のサポートが進展していることを示す。完全なマルチベンダーエンドポイントプロファイル、本番規模、全てのオプション機能に対する独立認証を証明するものではない。

他のメンバーは UEC 対応のスイッチ、システム、ソフトウェア、テスト計画を説明しており、2026 年サミットは製品化に大きく焦点を当てた。証拠は実装への移行を支えるが、出荷中の UET NIC、認定スイッチ、本番クラウドリージョン、完全なファブリックの正確な数をまだ裏付けていない。

製品の波を証拠チェーンとして読むのが最も有用である。公開仕様が設計を可能にする。シリコンおよび NIC の発表が投資を示す。トラフィックデモが相互運用性の一部を示す。コンプライアンスマトリックスが要件をマッピングする。オペレーターからの展開報告が運用上の価値を示すであろう。独立したプラグフェストと本番結果が、現在のポートフォリオにまだ欠けている、より広範な信頼性を確立するであろう。

RoCE、InfiniBand、Slingshot、UALink

UEC は、成熟した代替手段と隣接技術が存在する市場に参入する。戦略的主張は、Ethernet が RDMA を運搬したことがないとか、特化ファブリックが機能しないということではない。今日の AI ワークロードの規模と同期性が、より柔軟な配送、パス利用、輻輳制御を備えた新しいエンドツーエンド Ethernet アーキテクチャを正当化するというものである。

RoCEv2 は直接の先行技術であり、重要な既存技術である。ルーティング可能な Ethernet 上で RDMA を転送し、アプリケーションと製品に広くサポートされている。UEC は、典型的な RoCE 導入について、フロー全体の 1 パスへの固定、Go-Back-N 回復、受信側での再順序付け、困難な DCQCN チューニング、多くの設計での Priority Flow Control 依存、インキャストや集合バースト下での脆弱な挙動を批判する。これらは UEC の技術的立場であり、全ての RoCE ネットワークが不良であるという証拠ではない。

比較は動的である。ベンダーは、プログラム可能な NIC に適応ルーティング、パケットスプレーイング、改良された輻輳アルゴリズム、その他の UEC 類似機能を組み込みつつ、RoCE 互換性を保つことができる。AMD の Pollara の説明は、例えば、プログラム可能なハードウェア上で RoCEv2 と UEC RDMA をオプションとして提示している。したがって、UEC は完全なトランスポートとして RoCE と競合すると同時に、将来の RoCE 製品の進化に影響を与えうる。

InfiniBand は最も重要な専用ファブリック代替手段である。RDMA、輻輳、リンク信頼性、管理を統合したエコシステムを提供し、長年にわたる HPC 経験を持つ。InfiniBand Trade Association の 2.0 作業は、レーンあたり 200 Gb/s の XDR サポートと更新されたテレメトリを含む。UEC の最も強力な差別化要因は、InfiniBand がパフォーマンスに欠けるという主張ではない。より広範な Ethernet サプライチェーン、標準 IP ルーティング、より大きなマルチベンダー選択を通じて、AI および HPC 特性を達成できる可能性である。

HPE Slingshot は中間的な位置を占める。適応型ルーティングと輻輳管理を備えた Ethernet 互換の商用 HPC ファブリックであり、UET の重要な技術的先駆けを提供した。特殊な動作が Ethernet 上に構築可能であることを示すと同時に、管理された商用プラットフォームと産業全体の仕様との違いを示す。

UALink は主に補完的であり、直接の代替ではない。現在の公開 200G 仕様は、ポッド内のアクセラレータ間の低レイテンシスケールアップ接続を対象とし、最大 1,024 アクセラレータのシステムを説明している。UEC 1.0 は主に、スイッチを介してノードを接続するスケールアウトファブリックである。データセンターは、コンピュートポッド内でスケールアップリンクを使用し、ポッド間またはノード間で UEC を使用することができる。将来の UEC によるスケールアップトランスポートの最適化やインネットワークコレクティブの作業は、境界を接近させ、収束または競合を生み出す可能性がある。

NVIDIA Spectrum-X および独自のアクセラレータファブリックは別の比較対象である。緊密に統合されたスタックはハードウェア、ソフトウェア、サポートを迅速に最適化できるが、1 つのエコシステムへの依存を高める。UEC は、その統合の一部と引き換えに、共通インタフェースとベンダー選択の約束を提供する。その交換が理にかなっているかどうかは、抽象的な「オープン性」のラベルではなく、パフォーマンス、サポート、特許条件、相互運用性、総所有コストに依存する。

運用上の問題はプロトコルよりも大きい

573 ページの仕様は多くの要件を定義できるが、本番ファブリックには依然として運用モデルが必要である。UEC 1.0 は、重要な管理作業を規範的核心の外側あるいは周縁に残している。オペレーターは、プロファイル、トラフィッククラス、ECN 閾値、エントロピ量、オプションのリンク機能、キー、ファームウェア、テレメトリ、エラールールをエンドポイントとスイッチにわたって一貫して設定しなければならない。

混合トラフィックはこのタスクを複雑にする。データセンターファブリックは、UET、RoCE、TCP、ストレージ、管理、さらに順序付きおよび順序なしの UET サービスを運ぶ可能性がある。キュー割り当てとクラス間の公平性は、各プロトコルが正しく実装されているだけでは解決されない。ある輻輳アルゴリズムは単独では良好に動作しても、異なるフィードバックと前提を持つ別のコントローラとの競合下では不良になる可能性がある。

エンドポイントの複雑さは別の構造的リスクである。UET はマルチパス、直接配置、選択的再送、複数の配送モード、ウィンドウおよびクレジット制御、トリミング受信、セキュリティ、大量の状態を FEP に配置する。これは、NIC のダイ面積、ファームウェアサイズ、検証労力、消費電力、診断すべきエラー状態の数を増加させうる。エンドポイントのインテリジェンスは広範なサプライチェーンを可能にするが、最も困難な実装を、全てのサーバーが購入しなければならないコンポーネントに移す可能性がある。

オプション機能は、製品差別化と断片化を同時に生み出す。あるベンダーは、従来型の ECMP と ECN 向けに基本的な AI Base エンドポイントを最適化するかもしれない。別のベンダーは AI Full、TSS、Trimming、LLR、CBFC をサポートする。どちらも UEC エコシステムに属するが、オペレーターは同等のセマンティクス、パフォーマンス、セキュリティを前提としてはならない。コンプライアンスマトリックスは、運用上の能力マトリックスへと発展しなければならない。

バージョン管理は継続的になる。1.0.1 から 1.0.3 への修正は、輻輳、クレジット、再送、パケット動作に影響を与えた。大規模クラスターは複数の NIC ファームウェアバージョン、スイッチリリース、テストツールを含みうる。他の層との調整なしに 1 つの層を更新すると、コンソーシアムが回避しようとしているまさにその層横断的な競合状態を引き起こす可能性がある。

したがって、UEC の外部アライアンスは形式的なものではなく、中心的なものである。Open Compute Project はトランスポートをオープンシステムおよびハードウェアと結びつける。OpenFabrics Alliance と libfabric コミュニティはアプリケーションを接続する。IEEE 802.3 は正式な Ethernet 作業を提供する。SNIA と NVM Express はストレージおよび管理要件をもたらす。IETF 技術は IP、ECN、関連メカニズムを提供する。これらの組織は異なる意思決定プロセスとロードマップを持っている。リエゾンは重複作業を減らすが、同時採用を保証するものではない。

最終的な運用テストは稼働中のインフラストラクチャである。文書は動作を規定でき、ベンダーは製品を発表でき、コンソーシアムはサミットを組織できる。これらのいずれも、独立したエンドポイントとスイッチが輻輳、障害、アップグレード下で実際のジョブを完了し、オペレーターが何が起こったかを説明できるクラスターに取って代わるものではない。

現在の関連性：仕様の成功から実装の信頼性へ

2026 年 7 月までに、UEC は開始時には不確実だったいくつかの目標を達成した。幅広い連合を形成し、統合された 5 層アーキテクチャを作成し、完全な 1.0 仕様を公開し、修正バージョンで保守し、1 レーンあたり 200G を追加し、特許宣言を開示し、製品およびテストの発表を引き寄せた。プロジェクトは活発であり、アジェンダは明らかに実装へと移行している。

この進展は、次の不確実性をより重要にし、小さくはしない。正確な現在のメンバーシップと Steering 名簿は、単一の信頼できるレジストリに公開されていない。公開メンバーページと憲章はアクセスを異なって説明している。正式な TAC リーダーシップはサミットの役割と完全には整合していない。1.0.2 の日付は公式文書間で矛盾している。コンプライアンスパッケージは古いプロファイル用語を使用している。これらの点はいずれもアーキテクチャを破壊しないが、各ポイントは正確なバージョンが重要であるプロジェクトにおける文書管理と透明性のシグナルである。

より重大なギャップは採用に関するものである。UEC は展開調査も、独立検証された製品レジストリも、独立予算も、監査済み財務諸表も公開していない。公開証拠は、コンソーシアムの最大規模目標における完全に相互運用可能な UEC 1.0 ネットワークを証明していない。ベンダーのデモと主張は貴重だが、商業的利害を持つ当事者によるものである。最新の RoCE、InfiniBand、統合 Ethernet プラットフォームとのニュートラルなパフォーマンス比較は依然として限られている。

機会は依然として大きい。Ethernet はデータセンターの共通分母であり、AI インフラ市場は新世代の NIC、スイッチ、光トランシーバ、ソフトウェアにとって十分に大きい。オペレーターはシングルベンダー依存を回避し、アクセラレータ利用率を高める強いインセンティブを持つ。共通スタックはこれらのインセンティブを購買力に変換しうる。

リスクは、「Ultra Ethernet」が非互換の機能サブセットのための傘となることである。基本的な転送が機能する一方で、プロファイル、輻輳、セキュリティ、管理が分岐すれば、ブランドは相互運用性よりも速く普及する可能性がある。RAND ライセンスが高価または不明瞭であれば、ベンダーの輪は狭まるかもしれない。新しいトランスポートなしに RoCE 製品が最も魅力的なアイデアを採用すれば、UEC は市場に影響を与えても支配的ラベルにはならないかもしれない。

決定的な問いは、コンソーシアムが高度な仕様を公開できるかどうかではなくなった。それは達成された。問いは、独立した組織が同じ契約を実装し、必要な技術をライセンスし、大規模にファブリックを運用し、進化の過程で互換性を維持できるかどうかである。UEC は、これらの主張が稼働中のコードとの接触に耐える程度に応じてのみ、インフラストラクチャとなる。