概要

  • 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 トレーニングシステムや高性能コンピューティングマシンでは、ネットワークは単一の同期された計算の一部になります。何千ものアクセラレーターが、集団操作の一部としてモデルパラメーター、勾配、科学データを交換することがあります。最も遅い参加者が必要な情報を受信するまで、次のフェーズに進めないこともあります。そのため、パス間のわずかな不均衡、輻輳、あるいは単一のパケット損失が、ファブリックの平均使用率が良好に見えても、高価なプロセッサーを待機状態にしてしまう可能性があります。

これにより、オペレーターが最適化しようとする対象が変わります。総容量は依然として重要ですが、それだけでは十分ではありません。ジョブ完了時間、テールレイテンシ、インキャスト、損失回復、並列パスへのトラフィック分散、エンドポイントが保持すべき状態量も重要です。大半のパケットを高速に配信しても、ごく一部を遅延させるネットワークは、集団操作全体を妨げる可能性があります。従来のトラフィックでは許容できる再送方式も、長いメッセージの単一パケット損失では遅すぎるかもしれません。また、単一の等コストパスに固定されたフローは、トポロジの他の場所に容量が余っていてもパフォーマンスが低下する可能性があります。

UEC の設立前提は、こうした問題はスイッチの新機能や輻輳アルゴリズムの変更だけでは解決できないというものでした。通信パスはネットワークの上、つまりソフトウェアライブラリやアプリケーションセマンティクスから始まり、メモリ登録、リモート操作、トランスポート状態、パケット配信、輻輳制御、IP ルーティング、Ethernet リンク、光学系、物理シグナリングへと続きます。これらの層が独立して設計されると、ある部分の最適化がボトルネックを移動させたり、別の部分で互換性のない前提を生んだりする可能性があります。

UEC の答えは、調整されたアーキテクチャです。Ethernet と IP を維持するのは、オペレーターが精通しており、スイッチ、光学系、ケーブル、ネットワークオペレーティングシステム、テレメトリ、管理の周りに巨大なサプライチェーンが成長してきたからです。同時に、コンソーシアムは大規模な AI や HPC のワークロードに不適切と見なす部分を変更または拡張します。結果は「新しいロゴの付いた標準的な Ethernet」ではなく、ソフトウェアインターフェイスから物理的なワイヤ速度まで動作が定義された特殊なトランスポートを、使い慣れたネットワーク上で実現しようとする試みです。

この点が、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 は時に企業、アライアンス、標準化団体として不正確に説明されることがあるからです。UEC は、株主、資本、評価額、独立した会計を持つ営利企業ではありません。Ethernet 製品を販売せず、パブリックネットワークを運営せず、メンバーが推進するハードウェアを所有していません。これは、法的および知的財産の枠組み内での仕様開発コンソーシアムです。公開文書の目的は、複数企業間の実装契約となることです。

また、UEC は Ultra Ethernet Transport そのものではありません。UET は仕様の中核にあるトランスポートアーキテクチャですが、コンソーシアムの作業範囲はより広範です。libfabric とのソフトウェア連携、パケットおよびメッセージセマンティクス、ネットワークの前提、リンク層オプション、物理層要件、管理、ストレージ連携、パフォーマンスとデバッグ、コンプライアンスとテストが含まれます。このプロジェクトを「新しい RDMA プロトコル」とだけ表現すると、それを野心的かつ困難にしているクロスレイヤ設計の全体像が見えなくなります。

UEC は IEEE 802.3 ワーキンググループでもありません。IEEE 802.3 は、独自の正式なプロセスを通じて、MAC および物理層におけるコア Ethernet 標準を開発しています。UEC はそのエコシステムに依存し、連携関係を維持していますが、取って代わるものではありません。同様の境界は、UET が使用する IETF メカニズム（IPv4、IPv6、Explicit Congestion Notification）、libfabric を管理する OpenFabrics エコシステム、ストレージ、オープンハードウェア、アクセラレーター相互接続の団体にも適用されます。

プロジェクトのウェブサイトでは、国際標準化団体としての地位を示唆する表現が使われていました。より安全で証拠に基づいた説明は、UEC が JDF フレームワーク内の国際的な仕様開発組織であるというものです。UEC が International Organization for Standardization の一部である、その文書が ISO 標準である、または ISO 標準番号を持つという証拠はありません。この区別は単なる言葉の問題ではなく、権限の源泉、参加方法、実装者が直面する可能性のある法的義務を規定するものです。

したがって、UEC は実際に果たす役割に基づいて評価されるべきです。競合他社とオペレーターを共通の技術設計で調整し、仕様を公開し、ワーキンググループと宣言された特許コミットメントを管理し、コンプライアンス資料と隣接団体との関係を構築しています。しかし、単に宣言するだけでは、製品を相互運用可能にしたり、市場にアーキテクチャの採用を強制したりすることはできません。

9 社による設立コンソーシアム

このコンソーシアムは 2023 年 7 月 19 日に、AI と HPC のサプライチェーンの異なる層を占める 9 つの組織によって発表されました：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、スイッチ、システム、クラウド容量、光学系、ソフトウェア、サポートを販売しています。一部は、実装に必要となる可能性のある特許ポートフォリオを保持しています。一部は、広範なマルチベンダー標準から利益を得る一方で、差別化された独自機能からも利益を得ることができます。したがって、コンソーシアムは競争を排除するのではなく、競合他社が最低限のインターフェイスに合意し、実装品質、パフォーマンス、統合、商業条件で競争を続ける場を作り出します。

HPE の Slingshot は、技術的起源を示す有用な例です。これは、アダプティブルーティングと輻輳管理を備えた、Ethernet 互換の商用 HPC ファブリックです。HPE 関連のコメントでは、「HPC Ethernet」仕様が UEC に提供され、UET のかなりの部分が Slingshot のトランスポートのアイデアに由来していると推定されています。正確な割合は独立して検証されておらず、コンソーシアムの公式な計算として提示すべきではありません。より広い点は十分に裏付けられています。UEC は白紙から始めたのではなく、HPC、クラウドネットワーキング、RDMA、Ethernet における生産経験を活用しました。

こうした既存システムの混在が、「オープン」という言葉を慎重に使う理由です。承認された仕様は公開ダウンロード可能であり、アーキテクチャはマルチベンダー実装向けに設計されています。しかし、このプロジェクトはまた、メンバーが既存の知識、特許、製品ロードマップを提供する場でもあります。文書の公開は、その技術を取り巻く経済的または法的条件を取り除くわけではありません。

競合他社の協業のために設計された法的チェーン

Joint Development Foundation モデルは、UEC コンソーシアムに、従来の営利企業にすることなく正式な構造を与えています。このプロジェクトには、名前、範囲、メンバーシップカテゴリ、Steering Committee、ワーキンググループ、そして知的財産コミットメントがあります。JDF アンブレラは非営利の制度的構造を提供し、プロジェクトの資産と契約を保持できます。これにより、コンソーシアム設立のコストが削減され、競合他社に認知された協業プロセスが提供されます。

Steering Committee がプロジェクトガバナンスを担当します。文書化された責任には、ワーキンググループの調整、メンバーの受け入れ、資産と資金の管理、議長の選任または交代、進捗の監視、公開情報とプロジェクトマークの管理が含まれます。コンセンサスが優先されます。それが不可能な場合、運営文書は出席要件を満たす資格のある参加者の 4 分の 3 の超多数決メカニズムを規定しています。書面による異議は議長に提出できます。

Meta の Brad Booth が初代議長でした。現在の仕様 1.0.3 では、AMD の J Metz が議長、HPE の Barry Davis が副議長、Arista の Hugh Holbrook が Technical Advisory Committee 議長、Marvell の Puneet Agarwal が TAC 副議長とされています。Paul Congdon が仕様の編集者として記載されています。また、この文書では物理、リンク、トランスポート、ソフトウェア作業のリーダーや著者も挙げられています。2026 年サミットのアジェンダには、追加の運営担当者が記載されています。これらの役割は必ずしも仕様に記載された正式な役職に取って代わるものではなく、完全かつ最新の公開組織図は存在しません。

運営文書には、Steering、General、Contributor の 3 つのメンバーシップカテゴリが含まれています。Steering メンバーはガバナンスに参加し、通常は Steering Committee に代表者を指名します。General メンバーはすべての技術グループで活動できますが、委員会の議席は持ちません。Contributor メンバーは選ばれたグループに参加し、超多数決の決定には投票しません。公開メンバーシップページでは現在、General と Contributor カテゴリがそれぞれ年額 20,000 ドルと 5,000 ドルで表示されており、Linux Foundation メンバーシップも必要ですが、Steering カテゴリの受け入れパスや現在の価格は明確に説明されていません。

正式な権限の違いは重要です。幅広いメンバーシップは専門知識と実装の広がりをもたらしますが、ガバナンスは平等に分配されていません。Steering 議席を満たし、複数のグループにエンジニアを割り当て、特許および製品プログラムを管理できる大企業は、小規模な Contributor メンバーよりも実質的な影響力を持ちます。非メンバーは最終仕様をダウンロードできますが、ドラフトプロセス全体を見ることはできず、対等に参加することもできません。

プロジェクトの内部情報は通常の企業秘密データとして扱われませんが、メンバーは、担当委員会が公開を承認するまでドラフト資料を開示することを禁じられています。これにより、競合他社が早期の市場シグナルなしに未完成のアイデアを議論できる可能性があります。しかし、これは同時に、一般の人々が却下された提案、投票記録、中間実装の懸念、オプション機能を生み出した交渉を見られないことも意味します。最終仕様は公開されていますが、そこに至る道のりは部分的にしか見えません。

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

UEC の最初の公開構造は 2023 年に、ソフトウェア、トランスポート、リンク、物理層の 4 つのワーキンググループに焦点を当てていました。この積み重ねは、プロジェクトのエンドツーエンドの野心を反映していました。メンバーシップは、無制限の公開メーリングリストとして直ちに開放されたわけではありません。200 を超える組織が関心を示し、コンソーシアムは手続きと独占禁止法のガイダンスを条件に、段階的に参加を実施しました。参加者は複数の市場で直接競合しており、製品とプロトコルの共通要件について議論することになるため、この慎重さは理解できます。

2023 年 12 月までに、UEC は約 40 社、300 人以上が参加していると報告しました。Technical Advisory Committee を設立し、8 つのワーキンググループに拡大しました。TAC の目的はアーキテクチャの一貫性を維持することでした。つまり、トランスポート設計が、他のグループがサポートに同意していないスイッチの動作、シグナリング方法、API を前提とすべきではないということです。2024 年 3 月には、コンソーシアムは 55 社、750 人以上のアクティブ参加者がいると報告し、意図するアーキテクチャについてより明確な説明を公開しました。

3 月のアップデートでは、後に標準仕様に現れる中心的なアイデアが提示されました：ソフトウェア指向 API としての libfabric、パケットスプレッディング、柔軟な順序付け、複数の配信モード、送信側と受信側の輻輳制御、ECN、パケットトリミング、Link Layer Retry、オプションのクレジットベース制御、トランスポートセキュリティ、将来のインネットワーク集団操作です。また、UET は既存の Ethernet スイッチ上で動作可能であり、強化されたスイッチは追加のパフォーマンスを提供することも強調されました。

技術的な作業と並行して、組織的な参加者も増加しました。UEC は 2024 年 7 月に 1,193 人のアクティブ参加者、8 月に 97 のメンバー組織がいると報告しました。これらはコンソーシアムが発表した日付付きの数字であり、完全には公開されていない定義に依存しているため、後の発表と機械的に合算すべきではありません。2025 年には、コンソーシアムはさらに 27 社が参加したと発表しましたが、脱退、合併、期間の重複により、正確な現在の総数を確認することはできません。ウェブサイト自体も、すべてのメンバーがページに表示されるわけではないと述べています。

コンソーシアムは 2025 年 6 月 11 日に Ultra Ethernet Specification 1.0 をリリースしました。これが、UEC がロードマップから実装のための公開ベースラインに移行した瞬間でした。9 月に 1.0.1 が続き、レシーバクレジット輻輳制御のソースアルゴリズムと編集上の問題が修正されました。1.0.2 は 2026 年 1 月にリリースされ、輻輳管理アルゴリズムが修正されましたが、公式文書ではリリース日が 1 月 21 日か 28 日かについて矛盾があります。この矛盾は、説明なしに解消するのではなく、そのまま示すべきです。

2026 年 7 月 16 日に公開されたバージョン 1.0.3 が、調査時点での最新のリファレンスです。573 ページにわたり、200 Gbps レーンシグナリングと論理的なネゴシエーション機能が追加されています。リリースノートでは、パケット配信、輻輳クレジット、Link Layer Retry、物理層の制御順序セットに関する必須の修正が特定されており、トランスポートセキュリティ、アトミック操作、トリムドパケットの明確化も含まれています。必須の修正と編集上の明確化の区別は重要です。なぜなら、一部の変更は適合動作に影響し、実装のメンテナンスを必要とするからです。

2026 年のデンバー メンバー サミットは、2 つ目の移行を示しました。アジェンダは、展開、仕様の製品化、コンプライアンス、管理、パフォーマンスとデバッグ、ストレージ統合、スイッチとエンドポイントのテストに焦点を当てていました。中核となるアーキテクチャ文書は存在します。プロジェクトの信頼性は現在、実装者が組織の境界を越えてスタックを構築、認定、運用、アップグレードする能力にかかっています。

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

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

最上部では、AI フレームワーク、MPI、SHMEM、集団操作ライブラリが OpenFabrics Interfaces、特に libfabric を介して対話します。UET Semantic Services Sublayer は、アプリケーションの意図をトランスポート操作に変換します。Packet Delivery Sublayer は、メッセージのセグメント化、順序付け、確認応答、回復方法を決定します。輻輳管理は、ファブリックに入るデータ量とトラフィックのパスへの分散方法を制御します。オプションのトランスポートセキュリティがエンドツーエンドのトラフィックを保護します。標準の IPv4 または IPv6 がネットワーク層のルーティングを提供します。Ethernet は、オプションでパケットトリミング、Link Layer Retry、Credit-Based Flow Control、機能ネゴシエーションを備えたリンクを提供します。物理層は、100 Gbps または 200 Gbps レーンでの統計とシグナリング要件を指定します。

この構造は、既存のネットワークの重要な部分を保持します。UEC は IP ルーティングの代替を指定しません。代わりに、従来の ECMP と ECN 対応スイッチを前提としています。インテリジェンスの大部分は Fabric Endpoints に残されており、これらはエントロピー値の変更、トランスポート状態の追跡、データの配置、輻輳信号への応答を行います。強化されたスイッチは機能を追加できますが、UET トラフィックを通過させる前にファブリック全体の交換を強制する設計ではありません。

これは移行の利点を提供しますが、分類問題を引き起こします。ある展開では、ECMP と ECN を備えた標準 Ethernet 上で UET エンドポイントを使用するかもしれません。別の展開では、トリミング、リンクリトライ、仮想チャネルごとのクレジット、より豊富なテレメトリ、将来のインネットワーク操作を追加するかもしれません。パフォーマンス、回復特性、運用の複雑さが根本的に異なるにもかかわらず、どちらも Ultra Ethernet と呼ばれる可能性があります。

5 層アプローチは、実装障害の分離をより困難にします。パフォーマンスの低下は、アプリケーションの連携、エンドポイントのステートマシン、輻輳パラメーター、スイッチキューイング、DSCP アライメント、光学系、ファームウェア、セキュリティシステムに起因する可能性があります。パケットが通過するだけでは十分ではありません。システムは、スケール、混合トラフィック、障害、バージョン変更にわたって、意図されたセマンティクスとパフォーマンスを維持する必要があります。

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

UEC は、準拠するエンドポイントの主要な上位 API として libfabric 2.0 を選択しています。この選択は、各フレームワークに新しい独自インターフェイスの採用を要求するのではなく、プロジェクトを HPC と高度なネットワーキング向けの既存のソフトウェアエコシステムに結びつけます。libfabric はすでに、ファブリック、ドメイン、エンドポイント、完了キュー、イベントキュー、アドレスベクトル、メモリ領域、メッセージ、リモートメモリ操作、アトミック操作を表現しています。UEC はこれらの概念を調整および制約し、プロバイダーが呼び出しを UET の動作に変換できるようにします。

戦略的価値は、トランスポートを超えた継続性にあります。MPI、SHMEM、アクセラレーター通信ライブラリは、下位のプロバイダーが変わっても、使い慣れた抽象化を使用できます。原則として、アプリケーションは、配信を実装する NIC ベンダーやパケットをルーティングするスイッチシリコンの種類を知らなくても操作を要求できます。これは、共有トランスポートがベンダー間の選択肢を生み出す主要なメカニズムの 1 つです。

抽象化は同等の実装を保証しません。プロバイダーは、異なるインジェクトサイズ、異なるスキャッター/ギャザー制限、異なるエンドポイント数、アトミック操作、メモリ登録手法、完了動作、ハードウェアオフロード、セキュリティ機能をサポートする場合があります。同じ API 上に構築されたライブラリでも、パフォーマンスと機能の上限が異なる可能性があります。そのため、調達とソフトウェアの認定には、「libfabric 対応」というフラグ以上のものが必要です。

ソフトウェア層は、タスクのセマンティクスと委任も担います。AI および HPC システムは、多くの場合、共有インフラストラクチャ上で多数のタスクを実行し、それぞれが独自のプロセス、メモリ領域、セキュリティ境界を持ちます。仕様では、各タスクに属するエンドポイント、アクセス可能なメモリ、リモート操作の照合方法、完了またはエラー情報がソフトウェアに戻る方法を定義する必要があります。これらの決定が、高速ネットワークがスケジューラ、ランタイム、アプリケーションによって使用可能かどうかを決定します。単にパケットテストでの印象的な数値ではありません。

プロジェクトは libfabric を所有していないため、OpenFabrics エコシステムに依存しています。この関係は、UEC のより広範な特性を示しています。アーキテクチャは、異なる場所でガバナンスされるコンポーネントから構成されています。コンソーシアムは、そのトランスポートの libfabric とのアライメントを指定できますが、API のメンテナーやユーザーと調整する必要があります。同様の依存関係は、IEEE の Ethernet、IETF のネットワークメカニズム、ストレージ団体、ベンダー オペレーティングシステムにも存在します。

Fabric Endpoints とワークロードプロファイル

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

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

UEC は、AI Base、AI Full、HPC の 3 つの実装プロファイルを定義しています。これらは個別のネットワークタイプではなく、実装がサポートしなければならない機能を定義するバンドルです。AI Base は、より低いコストと実装状態で一般的な AI 通信をカバーすることを意図しています。AI Full は、遅延可能送信、完全一致、フェッチまたは比較形式のアトミック操作などの機能を追加します。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 がアプリケーションの意図を伝えます。メッセージ ID、バッファアドレス、タグ付きおよびタグなし操作、リモートメモリアクセス、アトミック操作、完了動作、タスク識別子、バッファ委任、応答とエラーを定義します。Packet Delivery Sublayer が、この意図をパケットに変換し、別のエンドポイントに到達させる方法を決定します。

信頼性モードでは、エンドポイントが Packet Delivery Contexts（PDC）を作成します。PDC には、パケットシーケンス番号、確認応答、重複検出、順序付けポリシー、輻輳情報、リターンパス状態、トラフィッククラスなどの状態が含まれます。1 つの PDC は 1 つの配信モードと 1 つのトラフィッククラスに関連付けられ、同じ FEP ペア間に複数の PDC が存在できます。

この状態は些細な詳細ではありません。大規模なクラスターでは、膨大な数の通信関係が生まれます。各関係がターゲットで広範な状態を必要とする場合、エンドポイントメモリとルックアップコストが制約となる可能性があります。したがって、UEC はすべての操作を単一の接続モデルに強制せず、信頼性と順序付けに関する異なる契約を持つ 4 つの配信モードを定義しています。

Reliable Unordered Delivery（RUD）は、各パケットをセマンティック層に正確に 1 回配信し、順不同の到着を許可します。複数パスでのパケットスプレッディング、選択的再送、重複防止、直接データ配置をサポートします。ターゲットは、トランスポート順序付けバッファを待つ代わりにオフセットに従ってデータを配置できるため、長い集団操作では、欠落したパケットの後ろにすべてのパケットを並べることなく、複数のパスを使用できます。

Reliable Ordered Delivery（ROD）は、順序どおりの 1 回限りの配信を提供します。単一のパスと 1 つのエントロピー値を使用し、順不同パケットをドロップし、最初の欠落シーケンス番号から Go-Back-N に依存します。RUD よりも単純に見えますが、厳密な順序付けが重要な場合に必要なセマンティクスを保持します。UEC は順序付けをアプリケーション要件として扱い、コストをすべてのトランスポートに課しません。

Reliable Unordered Delivery for Idempotent Operations（RUDI）は、異なるトレードオフを提供します。少なくとも 1 回の配信を保証し、重複を許可するため、ターゲットでの通常のシーケンスおよび確認状態が削減されます。これは、操作の繰り返しが最終結果を変更しない場合に役立ちます。たとえば、別のバリアが続く一部のリモートメモリ移動などです。しかし、誤って使用すると危険です。パケット層は操作が冪等かどうかを判断しません。ソフトウェアが判断する必要があります。RUDI を非冪等操作に使用すると、不正なアプリケーション状態が生じる可能性があります。

Unreliable Unordered Delivery（UUD）は、通常の信頼性や順序付けの保証なしにベストエフォートのデータグラムを提供します。同じセマンティックフレームワーク内にありますが、RUD や ROD と同じ輻輳制御要件はありません。アプリケーションは、UUD がキューやクラスを共有する場合に、制御されたトラフィックに損害を与えないようにする必要があります。

この 4 つのモードは、中心的な哲学を示しています。ネットワークは複数のメカニズムを提供し、ソフトウェアがトランスポートコストを操作セマンティクスに一致させることができるようにすべきです。利点は効率性であり、コストはより大きな実装とテストの対象領域であり、ベンダー、アプリケーション、またはオペレーターが互換性のない組み合わせを選択する機会が増えることです。

パケットスプレッディング：幸運なパスに頼らずファブリックを活用

従来の ECMP は、多くの場合、ハッシュによってフロー全体を単一のパスに配置します。大規模な 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）は、インキャスト問題を対象としています。多数の送信元が同時に単一の宛先に送信する場合、ネットワークコアが輻輳していなくても、最終リンクがボトルネックになる可能性があります。受信側は需要を追跡し、送信側にクレジットを分配して、総到着レートを調整し、競合に応じて各送信元の実効ウィンドウを変更します。RCCC は、受信側のプレッシャーとコア輻輳が異なる問題であるため、NSCC と並行して実行できます。

Transport Flow Control（TFC）もクレジットを使用しますが、バッファが制限されたポイントツーポイント接続にサービスを提供します。直接的な目標は、損失許容度が低い場合に受信側バッファのオーバーフローを防ぐことです。マルチパスありまたはなしで使用できます。すべてのクレジットメカニズムを同じものとして扱うと、それぞれが対処するように設計された異なる障害範囲が隠れてしまいます。

仕様では、ファブリック全体で Explicit Congestion Notification が使用されることを想定しており、マーキングに関する運用上の前提を定めています。これには、エンキューだけに依存するのではなく、デキューでのマーキングも含まれます。エンドポイントは、ECN を確認応答、レイテンシ、トリミングとともに解釈します。したがって、スイッチ設定の一貫性が不可欠になります。トランスポートの実装が正しくても、ファブリックの設定が不適切だとパフォーマンスが低下する可能性があります。

メンテナンス履歴は、その難しさを示しています。1.0.1 では RCCC のソースアルゴリズムが修正され、1.0.2 では輻輳管理のケースが修正され、1.0.3 ではクレジットと Link Layer Retry の間の相互作用が修正されました。これらは生きた仕様の通常の兆候ですが、クレジット、再送、パス制御の状態が微妙に相互作用する可能性があることも示しています。オペレーターは、初期の準拠だけでなく、バージョン規律と回帰テストが必要になります。

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

パケットトリミングは、対応可能なスイッチが完全なパケットを保持できない場合に行う動作を変更します。追加情報なしにフレームをドロップする代わりに、ペイロードの大部分またはすべてを削除し、パケットを識別するのに十分なヘッダーとメタデータを保持し、トリムドマークを付けて、切り詰められた通知を受信側に向けて送信します。受信側はその後、失われた具体的なデータを送信側に通知できます。

これは ECN マーキングよりも具体的な情報を提供します。ECN は輻輳が発生したことを示しますが、トリミングはペイロードが生き残っていないパケットを特定します。RUD と選択的再送を使用すると、タイムアウトや、単一の損失による長い再シーケンシングを待たずに回復を加速できます。

スイッチ機能はオプションですが、準拠するエンドポイントは、要件が適用される場合にトリムドパケットを受信して解釈する必要があります。この非対称性は、標準スイッチ上での UET の展開を支援する一方で、強化されたファブリックがより豊富な損失情報を提供できるようにします。しかし、アップグレードの問題も生じます。部分的に強化されたネットワークでは、受信側のすべてのエンドポイントが正しく処理できるように、パス、プロファイル、またはトポロジごとにトリミングを制限する必要があるかもしれません。

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 Gbps および 200 Gbps での物理シグナリング

物理層は UEC をハードウェアロードマップに結びつけます。初期の 1.0 作業は、レーンあたり 100 Gbps のシグナリングを中心に設計されました。1.0.3 ではレーンあたり 200 Gbps のサポートが導入されました。これは、より高密度の相互接続とシステムの世代に合致しますが、仕様上の機能であり、すべての UEC 製品が即座にサポートする証拠ではありません。

PHY 作業では、前方誤り訂正（FEC）の統計、修正されたコードワードと修正不能なコードワードの比率、制御順序セット、リンク品質レポート、および物理エラーと LLR の間の相互作用も扱われます。これらの詳細は重要です。なぜなら、トランスポートの回復決定は、下位層が何を観測し報告できるかに依存するからです。

より高いシグナリング速度では、光学系、SerDes、FEC、リンクリトライ、トランスポート回復の間の境界が経済的に重要になります。より強力な FEC は、レイテンシと電力を犠牲にして残留エラーを減らす可能性があります。ローカルリトライはエラーをより速く回復するかもしれませんが、バッファと状態を必要とします。エンドツーエンドの再送はネットワーク全体でより単純ですが、より多くの時間を浪費する可能性があります。UEC は、各ベンダーが独自に最適化するのではなく、これらの層がどのように連携するかを定義しようとしています。

200G レーンの追加は、目標が動いていることも示しています。1.0 インプリメンターは、新しい物理機能の計画を維持しながら互換性を維持する必要があります。テスト機器、ファームウェア、管理システムは、ポートごとの機能を区別する必要があります。バイヤーは、UEC サポートの一般的な主張からレーン速度を推測すべきではありません。

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

Transport Security Sublayer（TSS）は、エンドポイント間のオプションの保護を提供します。脅威モデルはスイッチの信頼を前提としていません。機密性、整合性、リプレイ保護、タスク分離、セキュアドメイン、グループキー、キー ローテーション、ハードウェア信頼ルートとの統合を提供できます。

この設計では、メンバーが暗号コンテキストを共有するセキュリティドメインを使用します。識別子、関連付け番号、エポック、安全な送信元 ID、キー導出は、エンドポイントの各ペアに対して個別のセッションを設定するよりもはるかに優れたスケーリングを実現するように設計されています。これは、アクセラレーターのセットとタスクメンバーシップが急速に変化する場合に必要です。

プロトコルは、セキュリティシステムの一部にすぎません。本番オペレーターは、キーおよび証明書の機関またはその他の信頼ルート、タスクメンバーシップサービス、配布と失効、エポック遷移、エンドポイントの回復、ハードウェア内の暗号化、セキュリティテレメトリを運用する必要があります。ネットワークは、TSS のすべてのオプション機能を有効にすることなく、プロファイルに準拠できます。「UEC 準拠」は、トラフィックが暗号化されていることを自動的に意味するわけではありません。

このオプション性は、異なる展開の前提を反映しています。物理的に制御された専有ファブリックは、パフォーマンスを優先し、環境制御に依存する可能性があります。マルチテナントクラウドは、強力な分離と暗号保護を必要とするかもしれません。プロファイルと調達システムはこの違いを明らかにする必要があります。

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

現在の「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 は必ずしもロイヤルティフリーを意味せず、普遍的な価格を保証せず、交渉を排除せず、有効性、必須性、地理的範囲、防御的条件に関する異議を防ぎません。商業的な状況は、宣言された各特許、メンバーのコミットメント、および二者間契約に依存します。

UEC は、Necessary Claims の公開記録を維持しています。調査時点では、Broadcom、Microsoft、Huawei、Qualcomm、AMD、HPE、Google、Marvell などに関連する宣言が表示され、将来のバージョン 1.1 作業に関連する提出も含まれていました。この記録は透明性を向上させます。なぜなら、実装者が製品を構築または出荷する前に知的財産をレビューする必要があるかもしれないことを明らかにするからです。

コンソーシアムは、宣言された特許が実際に有効、必須、侵害されているか、または特定の価格で利用可能かを判断しないと述べています。また、パテントプールを提供していません。小規模な実装者は、大企業がより容易に吸収できる法的および取引コストに直面する可能性があります。特許、シリコン、テストのクリアランスコストが高い場合、パブリック仕様が集中した実装市場を生み出す可能性があります。

IP フレームワークはガバナンスのインセンティブにも影響します。企業は、製品の広範な市場を創出するため、および自社の能力が共同設計に確実に反映されるようにするために、部分的に技術を提供します。特許宣言は、十分に早期かつ明確である場合にのみ、実装者を予期せぬ事態から保護します。また、採用が広がった後にライセンスが障壁となる可能性を排除するものではありません。

したがって、誠実な説明は「RAND コミットメント付きで公開されたマルチベンダー」であり、「普遍的にロイヤルティフリー」ではありません。調達チームは、技術プロファイルとライセンスパスの両方を必要とします。

製品とテストの最初の波

実装の証拠はバージョン 1.0 の前後に現れ始めましたが、例は成熟度が異なります。

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

Broadcom は 2025 年 6 月に、UEC ファブリックに関連する機能を備えた 102.4 Tbps スイッチ ASIC として Tomahawk 6 を発表しました。10 月には Thor Ultra 800G NIC を発表し、UEC 機能の完全な準拠を提供すると主張しました。これはベンダーによる重要な主張ですが、公開されている証拠がそれを独立したコンソーシアム認証に変換するわけではありません。サンプリング、ソフトウェアの成熟度、正確なプロファイルサポートを区別する必要があります。

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

他のメンバーは、UEC 対応のスイッチ、システム、ソフトウェア、テスト計画を説明しており、2026 年サミットでは製品化に重点が置かれました。証拠は実装への移行を裏付けていますが、出荷された UET カード、認定スイッチ、ライブクラウドリージョン、または完全なファブリックの正確な数を確立するものではありません。

この波の最も優れた解釈は、証拠の連鎖です。公開仕様が設計を可能にします。シリコンと NIC の発表は投資を示します。トラフィックデモは何らかの相互運用性を示します。コンプライアンスマトリックスは要件を整理します。オペレーターのレポートは運用価値を示すでしょう。独立したプラグフェストと本番結果は、依然として不足しているより広範な信頼を提供するでしょう。

RoCE、InfiniBand、Slingshot、UALink

UEC は、成熟した代替手段と隣接技術が存在する市場に参入します。その戦略的根拠は、Ethernet がこれまで RDMA を伝送したことがない、または特殊ファブリックが機能しないということではなく、現在の AI ワークロードの規模と同期性が、配信、パス使用、輻輳制御においてより柔軟な、新たなエンドツーエンド Ethernet アーキテクチャを正当化するというものです。

RoCEv2 は直接の前身であり、広く展開されている技術です。ルーティング可能な Ethernet 上に RDMA トラフィックを配置し、アプリケーションと製品で広範なサポートがあります。UEC は、一般的な RoCE の実装がフロー全体を単一のパスに固定し、Go-Back-N と受信側での再順序付けを使用し、困難な DCQCN チューニングを必要とし、多くの設計で Priority Flow Control に依存し、インキャストや一斉バーストでパフォーマンスが低下することを批判しています。これらはコンソーシアムの技術的立場であり、すべての RoCE ネットワークが劣っているという証拠ではありません。

比較は動的でもあります。ベンダーは、RoCE 互換性を維持しながら、プログラム可能な NIC にアダプティブルーティング、パケットスプレッディング、より優れた輻輳アルゴリズム、または UEC 類似の機能を追加できます。たとえば、AMD の Pollara メッセージングでは、プログラム可能なハードウェア上で RoCEv2 と UEC RDMA の両方をオプションとして提供しています。UEC はフルトランスポートとして RoCE と競合する一方で、将来の RoCE 製品の進化を形作る可能性もあります。

InfiniBand は、最も重要な特殊代替手段です。RDMA、輻輳、リンク信頼性、管理の統合エコシステムを提供し、HPC での長い歴史があります。InfiniBand Trade Association の 2.0 作業には、レーンあたり 200 Gbps の XDR 物理サポートと更新されたテレメトリが含まれています。UEC の最も強力な差別化要因は、InfiniBand にパフォーマンスが欠けていると言うことではなく、より広範な Ethernet サプライチェーン、標準 IP ルーティング、そしてより多くのベンダー選択肢を通じて IA/HPC の動作を実現できる可能性です。

HPE Slingshot は中間的な位置を占めています。これは、アダプティブルーティングと輻輳管理を備えた、Ethernet 互換の商用 HPC ファブリックであり、UET に重要な技術的先例を提供しました。これは、特殊な動作が Ethernet 上に構築できることを証明していますが、制御された商用プラットフォームと業界規模の仕様の違いも示しています。

UALink は直接の代替ではなく、補完的であることが多いです。現在の公開 200G 仕様は、ポッド内のアクセラレーター間の低レイテンシスケールアップ接続を対象としており、最大 1,024 個のアクセラレーターを備えたシステムを記述しています。UEC 1.0 は主に、スイッチを介してノードを接続するスケールアウトファブリックです。データセンターは、ポッド内にスケールアップリンクを使用し、ポッド間またはノード間に UEC を使用できます。スケールアップトランスポートとインネットワーク集団操作に関する将来の UEC 作業は、境界を近づけ、収束または競合を生み出す可能性があります。

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

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

573 ページの仕様は多くの要件を定義できますが、本番ファブリックには依然として運用モデルが必要です。UEC 1.0 は、重要な管理作業をコアの標準文書の外側または周辺に残しています。オペレーターは、プロファイル、トラフィッククラス、ECN しきい値、エントロピー セット、オプションのリンク機能、キー、ファームウェア、テレメトリ、障害ポリシーを、エンドポイントとスイッチ間で一貫して設定する必要があります。

混合トラフィックはこれをさらに困難にします。データセンター ファブリックは、UET、RoCE、TCP、ストレージ、管理、順序付けられた UET サービスと順序付けられていない UET サービスを伝送する可能性があります。各プロトコルを正しく実装するだけでは、キュー割り当てとそれらの間の公平性の問題は解決しません。輻輳アルゴリズムは単独ではうまく機能しても、異なる信号と前提を使用する別のコントローラーと競合すると、動作が悪くなる可能性があります。

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

オプション機能は、製品の差別化と断片化を同時に生み出します。あるベンダーは、基本的な ECMP と ECN を使用して AI Base に最適化されたエンドポイントを提供するかもしれません。別のベンダーは、AI Full、HPC、TSS、トリミング、LLR、CBFC をサポートするかもしれません。どちらも UEC エコシステム内にありますが、オペレーターは同じセマンティクス、パフォーマンス、セキュリティを想定できません。コンプライアンスマトリックスは、機能の運用マトリックスに変換される必要があります。

バージョンメンテナンスは継続的です。1.0.1 から 1.0.3 までのパッチは、輻輳、クレジット、リトライ、パケット動作に影響を与えました。大規模なクラスターには、異なる NIC ファームウェアバージョン、複数のスイッチバージョン、テストツールが含まれる可能性があります。残りの部分と調整せずに 1 つの層をアップグレードすると、コンソーシアムが回避しようとするクロスレイヤ相互作用が明らかになる可能性があります。

これが、外部関係が象徴的ではなく中心的である理由です。Open Compute Project は、トランスポートをシステムとオープンハードウェアに結びつけることができます。OpenFabrics Alliance と libfabric コミュニティは、アプリケーションを結びつけます。IEEE 802.3 は正式な Ethernet 作業を提供します。SNIA と NVM Express はストレージと管理の要件を追加します。IETF の技術は IP、ECN、および関連メカニズムを提供します。これらの団体は異なる意思決定プロセスとロードマップを持っています。調整は重複を減らしますが、同期された採用を保証するものではありません。

究極の運用テストは、動作するインフラストラクチャです。文書は動作を指定でき、ベンダーは製品を発表でき、コンソーシアムはサミットを開催できます。そのいずれも、独立したエンドポイントとスイッチが、輻輳、障害、アップグレードの下で実際のジョブを完了し、オペレーターが何が起こったかを説明できるクラスターの代替にはなりません。

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

2026 年 7 月までに、UEC は立ち上げ時には保証されていなかったことを達成しました。広範なコンソーシアムを構築し、完全な 5 層アーキテクチャを確立し、完全な 1.0 仕様をリリースし、パッチリリースでそれを維持し、200G レーンを追加し、特許宣言を公開し、製品発表とテストを引き寄せました。プロジェクトは活発であり、そのアジェンダは明らかに実装へと移行しています。

進歩は、以下の不確実性を重要性を低下させるのではなく、高めます。正確な現在のメンバー数と Steering 名簿は、単一の参照記録に表示されていません。公開メンバーシップページと運営文書は、アクセスを異なる方法で説明しています。TAC の現在の正式なリーダーシップは、サミットの役割と完全には一致していません。公式文書は 1.0.2 の日付が異なっており、コンプライアンススイートは古いプロファイル用語を使用しています。これらのどれもアーキテクチャを損なうものではありませんが、正確なバージョンに結果が依存するプロジェクトにおけるドキュメント管理と透明性の兆候です。

より重要なギャップは採用に関するものです。UEC は展開統計、独立して検証された製品記録、独立した予算や監査済みの会計を公開していません。コンソーシアムの最大規模の目標で完全に相互運用可能な UEC 1.0 ネットワークの公的な証拠はありません。ベンダーのデモと主張は価値がありますが、商業的利益を持つ当事者からのものです。現在の RoCE、InfiniBand、統合 Ethernet プラットフォームとの公平な比較は依然として限られています。

機会は依然として大きいです。Ethernet はデータセンターの共通分母であり、AI インフラストラクチャ市場は、新世代の NIC、スイッチ、光学系、ソフトウェアをサポートするのに十分な大きさです。オペレーターは、単一サプライヤーへの依存を減らし、アクセラレーターの利用率を向上させる強力なインセンティブを持っています。共有スタックは、これらのインセンティブを購買力に変換できます。

リスクは、「Ultra Ethernet」が互換性のない機能セットの傘となることです。ベーシックルーティングは機能しても、プロファイル、輻輳、セキュリティ、管理が異なる場合、ブランドは相互運用性よりも速く広がる可能性があります。RAND ライセンスが高価または不明瞭な場合、サプライヤー セットが狭まる可能性があります。RoCE 製品が新しいトランスポートなしで最も魅力的なアイデアを吸収する場合、UEC は支配的な名前になることなく市場に影響を与える可能性があります。

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