概要

  • 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 マシンでは、ネットワークは単一の同期計算の一部となります。何千ものアクセラレータが、集団演算中にモデルパラメータ、勾配、科学データを交換します。フェーズは、最も遅い参加者が必要なデータを受信するまで停滞する可能性があります。わずかな経路不均衡、輻輳エピソード、パケットロスが、ファブリックの平均使用率が許容範囲であっても、非常に高価なプロセッサを遊休させ得るのです。

最適化の基準が変わります。総合帯域幅は依然として重要ですが、それだけでは不十分です。オペレータは、ジョブ完了時間、テールレイテンシ、インキャスト、ロスからの回復、パラレル経路間のトラフィック分散、エンドポイントが保持しなければならない状態量も監視します。ほとんどのパケットを迅速に配信しても、わずかな割合が遅延するネットワークは、集団演算全体を遅らせる可能性があります。従来のトラフィックで許容される再送方式も、長いメッセージで1つのパケットが欠落した場合に時間を浪費しすぎる可能性があります。単一の ECMP 経路に固定されたフローは、トポロジ内の別の場所に空き容量があっても性能が低下する可能性があります。

UEC の創設時の前提は、これらの課題は単一のスイッチ機能や単一の輻輳アルゴリズムでは解決できないというものでした。通信パスはネットワークの上流、ソフトウェアライブラリとアプリケーションセマンティクスから始まります。メモリ登録、リモート操作、トランスポート状態、パケット配信、輻輳制御、IP ルーティング、Ethernet リンク、光学系、物理シグナリングを経由します。これらの層が個別に設計されると、局所的な最適化が単にボトルネックを移動させるか、他の場所で非互換な仮定を生む可能性があります。

UEC の回答は協調アーキテクチャです。オペレータが既に熟知しており、スイッチ、光学系、ケーブル、ネットワーク OS、テレメトリ、管理をめぐる巨大な産業チェーンが存在するため、Ethernet と IP を維持します。コンソーシアムが超大規模 AI および HPC ワークロードに不適切と判断した部分は置き換えるか拡張します。結果は「新しいロゴのついた普通の Ethernet」ではありません。これは、ソフトウェア API からレーンあたりのスループットまで動作が定義された特殊なトランスポートを、馴染み深いネットワークに担わせようとする試みです。

この違いが、デジタルインフラにとっての UEC の重要性を説明します。このプロジェクトは、アクセラレータ、工場、データセンター、クラウドリージョンを所有していません。UEC が定義するのは、メンバーや他の実装者がネットワークカード、スイッチ 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 は、法的枠組みと知的財産枠組みを備えた仕様開発コンソーシアムです。その公開文書は、複数企業間の実装契約となることを意図しています。

UEC は Ultra Ethernet Transport の同義語でもありません。UET は仕様の中核をなすトランスポートアーキテクチャです。コンソーシアムの作業範囲は、libfabric へのソフトウェアマッピング、メッセージとパケットのセマンティクス、ネットワーク前提、リンク層オプション、物理要件、管理、ストレージとの整合、性能とデバッグ、適合性とテストにまで及びます。プロジェクトを「新しい RDMA プロトコル」に矮小化すると、その層横断的な野心が見えなくなります。

UEC は IEEE 802.3 作業部会でもありません。IEEE 802.3 は、独自の正式なプロセスを通じて Ethernet MAC および物理層の標準を策定します。UEC はこのエコシステムに依存し、連絡を保ちますが、置き換えるものではありません。同じ制約は、UET を支える IETF メカニズム（IPv4、IPv6、Explicit Congestion Notification など）や、libfabric を保守する OpenFabrics エコシステム、ストレージ、オープンハードウェア、アクセラレータ相互接続の組織にも当てはまります。

プロジェクトのウェブサイトでは国際標準化団体のような表現が用いられていましたが、最も安全で裏付けのある説明は、JDF の下での国際的な仕様開発組織です。国際標準化機構（ISO）に属する、文書が ISO 標準である、または ISO 番号を持つといった主張の根拠はありません。この違いは表面的なものではなく、プロジェクトの権威がどこから来るか、参加がどのように機能するか、実装者にどのような法的義務が生じ得るかを理解する助けになります。

したがって、UEC はその実際の役割に基づいて評価されなければなりません。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 はスイッチ ASIC、ネットワークアダプタ、高速 SerDes を貢献しました。HPE と Eviden は HPC システムと特殊相互接続の歴史をもたらしました。Intel はプロセッサ、Ethernet、ソフトウェアで貢献しました。Meta と Microsoft は、大規模 AI クラスタの利用率向上と単一統合ベンダーへの依存低減に直接関心を持つハイパースケール事業者を代表しました。

この連合は競合する商業的利益も結集させました。参加企業はネットワークアダプタ、ASIC、システム、クラウド容量、光学系、ソフトウェア、サポートを販売しています。一部の企業は実装に不可欠となり得る特許ポートフォリオを保有しています。一部の企業は、差別化された独自機能で収益を上げながら、広範なマルチベンダー標準から利益を得ます。したがって、コンソーシアムは競争を排除するものではありません。競合企業が最低限のインタフェースに合意しつつ、実装品質、性能、統合、商業条件で差別化を続ける場を創出するものです。

HPE の Slingshot 相互接続は、技術的系譜の有益な例を提供します。Slingshot は、適応型ルーティングと輻輳管理機能を備えた Ethernet 互換の HPC ファブリックです。HPE 関係者のコメントは、「HPC Ethernet」仕様が UEC に貢献されたことを示唆し、UET の多くが Slingshot のトランスポート思想に由来する可能性を指摘しました。正確な割合は独自に検証されておらず、コンソーシアムの公式な集計として提示すべきではありません。より大きな点は十分に裏付けられています。UEC は白紙から始まったのではなく、HPC、クラウド、RDMA、Ethernet の本番経験を活用したのです。

この先行システムの混合は、「オープン」という言葉を正確に定義しなければならない理由も説明します。批准された仕様は公的にダウンロード可能であり、アーキテクチャはマルチベンダー実装を目指しています。しかし、このプロジェクトは同時に、メンバーが既存の知識、特許、製品ロードマップを持ち込む場でもあります。文書のオープン性は、技術に付随する経済的・法的条件を取り除くものではありません。

競合他社間の協業のために設計された法務シリーズ

Joint Development Foundation モデルは、UEC に正式な枠組みを与えつつ、通常の営利企業にはしません。プロジェクトには独自のアイデンティティ、範囲、会員区分、運営委員会、作業部会、知的財産義務があります。JDF の枠組みは非営利の法的基盤を提供し、プロジェクトの資産や契約を保有できます。このモデルはコンソーシアム設立のコストを削減し、競合他社に認知された協業プロセスを提供します。

運営委員会がプロジェクトを統治します。文書化された責務には、作業部会の調整、新会員の承認、資産と財務の管理、議長の任命または交代、進捗監視、プロジェクトの公開と商標の管理が含まれます。コンセンサスが優先されます。それが得られない場合、規約は出席要件を満たす適格参加者の4分の3以上の特別多数決を規定しています。書面による上訴は議長に提出できます。

初代議長は Meta の Brad Booth でした。現在の仕様 1.0.3 は、AMD の J Metz を議長、HPE の Barry Davis を副議長、Arista の Hugh Holbrook を技術諮問委員会（TAC）議長、Marvell の Puneet Agarwal を TAC 副議長として記載しています。Paul Congdon が仕様の編集者として挙げられています。文書はまた、物理、リンク、トランスポート、ソフトウェアの各作業の責任者と著者を特定しています。2026年サミットのアジェンダには他の運用責任者が記載されています。これらのサミット上の役割は仕様上の正式な肩書きを必ずしも置き換えるものではなく、公開文書は現在の完全な組織図を提供していません。

規約は Steering、General、Contributor の3つの区分を認めています。Steering 会員はガバナンスに参加し、通常は運営委員会に代表者を指名します。General 会員はすべての技術グループで作業できますが、委員会に参加しません。Contributor 会員は選択されたグループに参加し、特別多数決における議決権がありません。公開会員ページでは General と Contributor のレベルが年間2万ドルと5千ドル（Linux Foundation 会費は別）で販売されていますが、Steering レベルの現在の入会経路や価格は明確に説明されていません。

この公式な権力差は重要です。広範な会員基盤は専門知識と実装範囲を提供できますが、ガバナンスは均等に分配されていません。Steering ポジションを占め、複数のグループにエンジニアを配置し、特許と製品プログラムを維持できる大企業は、小規模な Contributor 会員よりも実質的な影響力を持ちます。非会員は最終仕様をダウンロードできますが、草案プロセス全体を見ることはできず、平等に参加することもできません。

内部情報は通常の企業秘密とは見なされませんが、会員は関連委員会の承認前に草案を公開できません。このルールは、市場への方向性を早期に示すことなく、競合他社間の議論を促進します。また、外部の観測者が拒否された提案、投票、暫定的な実装上の懸念、オプション機能につながった交渉を知ることを防ぎます。最終仕様はオープンですが、そこに至る道筋は部分的にしかオープンではありません。

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

2023年の初期の公開構造は、ソフトウェア、トランスポート、リンク、物理の4つの作業部会に基づいていました。この順序は、プロジェクトのエンドツーエンドの野心を反映していました。会員参加は無制限の公開メーリングリストとして開始されたわけではありません。200以上の組織が関心を示し、コンソーシアムはプロセスと独禁法に関する研修を要件としつつ、段階的に参加を受け入れました。この慎重さは理解できます。参加者は複数の市場で直接の競合他社であり、共通の製品およびプロトコル要件について議論しているためです。

2023年12月までに、UEC は約40社、300名以上を擁すると報告しました。技術諮問委員会（TAC）を設置し、構造を8つのグループに拡大しました。TAC はアーキテクチャの一貫性を確保する役割を担いました。あるトランスポートが、別のグループが合意していないスイッチ動作、シグナリング方法、API を前提とすることは許されなかったのです。2024年3月までに、コンソーシアムは55社、750名以上のアクティブ参加者を発表し、計画中のアーキテクチャについてより明確な説明を公開しました。

この3月のアップデートは、後に規範的仕様に含まれる主要なアイデアを導入しました。それは、libfabric をソフトウェア指向 API とすること、パケットスプレッディング、柔軟な順序付け、複数の配信モード、送信側・受信側輻輳制御、ECN、パケットトランケーション、Link Layer Retry、オプションのクレジットベースフロー制御、トランスポートセキュリティ、将来のイン・ネットワーク集団演算を含みます。また、UET は既存の Ethernet スイッチ上で動作可能であり、機能強化された装置は追加の性能を提供できることも確認しました。

制度的な範囲も並行して拡大しました。UEC は2024年7月にアクティブ参加者1,193名、8月に97の会員組織を宣言しました。これらは時点の数字であり、定義は完全には公開されていません。後の発表と機械的に合算すべきではありません。2025年には UEC は27社の新規参加を示唆しましたが、退会、合併、重複する参照期間のため、正確な現在の総数を推測することはできません。サイト自体が、すべての会員が表示されているわけではないと述べています。

Ultra Ethernet Specification バージョン 1.0 は2025年6月11日に公開されました。その時点から、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年会員サミットは、第二の転換点を示しました。そのアジェンダは、展開、製品化、適合性、管理、性能、デバッグ、ストレージ統合、スイッチとエンドポイント間のテストに焦点を当てていました。アーキテクチャ文書は存在します。プロジェクトの信頼性は、今後ますます、実装者が組織の境界を越えてスタックを構築、認定、運用、アップグレードできるかどうかにかかっています。

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または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、アクセラレータ通信ライブラリは、基礎となるベンダーが変わっても、馴染みのある抽象化を維持できます。原理的には、アプリケーションは、配信を担当するネットワークアダプタのブランドやパケットをスイッチするシリコンを知ることなく、操作を要求できます。これは、共通トランスポートが真のベンダー選択を生み出す主要なメカニズムの一つです。

抽象化は同等の実装を保証しません。ベンダーは、異なるインジェクションサイズ、スキャッターギャザー制限、エンドポイント数、アトミック操作、メモリ登録手法、完了動作、ハードウェアアクセラレーション、セキュリティ機能を提供できます。したがって、同じ API 向けにコンパイルされたライブラリでも、容量や性能の限界が異なる可能性があります。ソフトウェアの調達と認定には、「libfabric 対応」のチェックボックス以上のものが必要です。

ソフトウェア層はジョブと認可のセマンティクスも担います。AI および HPC システムは、共有インフラ上で多数のジョブを実行し、それぞれが独自のプロセス、メモリ領域、セキュリティ境界を持ちます。仕様は、どのエンドポイントがどのジョブに属し、どのバッファがアクセス可能で、リモート操作がどのように照合され、完了情報やエラー情報がソフトウェアにどう返されるかを特定しなければなりません。これらの決定は、高速ネットワークが、単にパケットベンチマークで印象的であるだけでなく、スケジューラ、ランタイム、アプリケーションによって実際に利用可能かどうかを左右します。

プロジェクトは libfabric を所有していないため、OpenFabrics エコシステムに依存しています。この関係は、より一般的な特性を示しています。UEC アーキテクチャは、他の場所で運営されているコンポーネントから組み立てられています。UEC は自身のトランスポートが libfabric にどうマッピングされるかを定義できますが、API の保守者や利用者と調整しなければなりません。同様の依存関係は、IEEE Ethernet、IETF のメカニズム、ストレージ組織、ベンダーのオペレーティングシステムにも存在します。

Fabric Endpoints と負荷プロファイル

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

このエンドポイント中心の設計により、スイッチは主に認識可能な Ethernet および IP 装置であり続けます。FEP はエントロピー値を選択し、パケットおよび輻輳状態を保持し、許可されたメモリにデータを配置し、ACK、トランケーション、その他のフィードバックを解釈します。これにより、スイッチ内の独自のルーティングインテリジェンスへの依存を低減できます。また、NIC シリコン、ファームウェア、ドライバ、ソフトウェアに複雑さを集中させます。

UEC は AI Base、AI Full、HPC の3つの実装プロファイルを定義しています。これらは異なるネットワークではなく、必須機能の集合です。AI Base は、より低いコストと状態量で一般的な AI 通信を対象とします。AI Full は特に遅延可能送信、完全一致、特定のアトミック読み取りまたは比較操作を追加します。HPC プロファイルは AI Full のほとんどの機能を継承し、遅延可能送信を除外し、順序付け、小メッセージ、HPC セマンティクスをより重視します。

プロファイルシステムは、すべての製品が最大セットを実装しなければならない事態を回避しようとします。大容量 AI カードは集団交換を優先する一方、HPC エンドポイントはより強い順序付けと多くのアトミック操作を要求する可能性があることを認識しています。ただし、プロファイルはオプションを排除しません。製品はプロファイル内でオプション機能を実装でき、同じラベルを持つ2つの製品でも、セキュリティ、リンク強化、容量、性能が異なる可能性があります。

既に用語が警告シグナルとなっています。権威ある仕様 1.0.3 は AI Base、AI Full、HPC を使用しています。2025年の適合性文書は AI Base、AI Extended、HPC を使用しています。最も確実な解釈は、「AI Full」が現在の名称であり、適合性文書が古いか不整合であることです。テストパッケージが修正されるまで、ベンダーと購入者は、主張の背後にある仕様バージョンと正確な用語を特定しなければなりません。

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

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

信頼性モードでは、エンドポイントは Packet Delivery Contexts（PDC）を確立します。PDC は、シーケンス番号、ACK、重複検出、順序付けモード、輻輳情報、リバース方向の状態、トラフィッククラスなどを保持します。PDC は配信モードとトラフィッククラスに対応し、同じ FEP 間に複数の PDC が存在できます。

この状態量は副次的ではありません。大規模クラスタは非常に多数の通信関係を生成する可能性があります。各関係が大きな宛先状態を要求すると、メモリとルックアップコストが制限要因になります。したがって、UEC はすべての操作を単一の接続モデルに押し込みません。契約の異なる4つのサービスを定義しています。

Reliable Unordered Delivery（RUD）は、順不同の到着を許容しながら、セマンティック層への正確に1回の配信を保証します。パケットスプレッディング、選択的再送、重複削除、データの直接配置をサポートします。宛先はトランスポートの並べ替えバッファを待つ代わりにオフセットに従ってデータを配置できるため、大規模な集団操作は、単一の欠落ユニットの後ろですべてのパケットをブロックすることなく、複数の経路を活用できます。

Reliable Ordered Delivery（ROD）は、正確に1回かつ順序通りの配信を保証します。単一経路と単一エントロピー値を使用し、順不同パケットをドロップし、最初の欠落番号からの Go-Back-N 回復に依存します。このモデルは RUD より高度でないように見えますが、厳密な順序付けを必要とする操作に必要なセマンティクスを保持します。UEC は順序付けをアプリケーションの要件として扱い、すべての転送に課されるコストとはしません。

Reliable Unordered Delivery for Idempotent Operations（RUDI）は別のトレードオフを行います。少なくとも1回の配信を保証し、重複を許容します。これにより、宛先での通常のシーケンスおよび ACK 状態が削減されます。これは、別個のバリアが後に続く特定のリモートメモリ移動に適合し得ます。誤って適用されると危険です。パケット層は操作がべき等かどうかを推論しません。ソフトウェアがそれを知らなければなりません。非べき等操作に 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）はソース主導です。送信側は輻輳ウィンドウを維持し、転送中のオクテットを推定し、ACK、NACK、タイムアウト、レイテンシ、ECN などのネットワーク信号に基づいてそのウィンドウを調整します。ウィンドウをパケットレベルのマルチパスと調整します。UEC は、パケットがネットワークから出なくなればウィンドウは自然にデータの受け入れを停止するのに対し、純粋にレートベースのコントローラは欠落したフィードバックを誤解する可能性があると主張します。

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

Receiver-credit Congestion Control（RCCC）はインキャストを対象とします。多数の送信側が同時に1つの宛先に送信する場合、コアは輻輳していなくても最終リンクがボトルネックになり得ます。受信側は需要を追跡し、クレジットを配布し、集約到着をペーシングし、競合に応じて各ソースの暗黙のウィンドウを調整します。RCCC は NSCC と併用できます。受信側の過負荷とコア輻輳は異なるためです。

Transport Flow Control（TFC）もクレジットを使用しますが、小さなバッファを持ち損失を許容しにくいポイントツーポイントサービス向けです。その目標は、直接的なオーバーフロー防止です。マルチパスありでもなしでも使用できます。すべてのクレジットメカニズムを混同すると、それらが制御する異なる故障ドメインが隠れます。

仕様はファブリック全体での ECN を期待し、入力時だけでなく出力時のマーキングなどの運用上の前提を置いています。エンドポイントは ECN を ACK、レイテンシ、トランケーションとともに解釈します。したがって、すべてのスイッチにわたる一貫した設定が不可欠です。トランスポートは正しく実装されていても、設定の誤ったファブリックでは不良な結果を生む可能性があります。

保守履歴は困難さを示しています。バージョン 1.0.1 は RCCC ソースアルゴリズムを修正しました。1.0.2 は輻輳管理のケースを修正しました。1.0.3 はクレジットと Link Layer Retry 間の相互作用を修正しました。これらの修正は生きた仕様としては正常ですが、クレジット、再送、経路が微妙に相互作用することの証明でもあります。オペレータは、初回の適合性だけでなく、バージョン管理の規律と回帰テストを維持する必要があります。

パケットトランケーションと損失後の正確な回復

トランケーションは、対応可能なスイッチがパケット全体を保持できない場合の動作を変えます。フレーム全体を情報なしに破棄する代わりに、ペイロードの一部または全部を取り除き、パケットを識別するのに十分なヘッダとメタデータを保持し、トランケートとしてマークし、この縮小通知を受信側に送信します。受信側は、欠落データを送信側に正確に通知できます。

この情報は ECN マーキングより豊富です。ECN は輻輳が発生したことを示します。トランケーションは、ペイロードが生き残らなかった特定のパケットを識別します。RUD と選択的再送により、タイムアウトを待ったり、1つの損失のために長いシーケンス全体を再送したりすることなく、回復を加速できます。

スイッチ機能はオプションですが、準拠エンドポイントは適用可能な要件に従ってトランケートパケットを受信し解釈しなければなりません。この非対称性は、従来のスイッチ上での展開を可能にしつつ、機能強化されたファブリックにはより正確なフィードバックを提供します。また、アップグレードの課題も生みます。部分的に近代化されたネットワークでは、すべての受信側が理解できるように、経路、プロファイル、トポロジごとにトランケーションを制限する必要が生じるかもしれません。

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

トランケーションは、プロジェクトの包括的な挑戦を例証します。プロトコルはワイヤ上の動作を定義できますが、結果はキュー、終端ロジック、テレメトリ、設定、故障処理に依存します。相互運用性は、単にパケット形式だけでなく、システムの特性なのです。

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

Link Layer Retry（LLR）は、エンドツーエンドのトランスポート反応が起こる前に、物理リンク上の破損を回復しようと試みます。ピアはシーケンス破損またはフレーム破損を検出し、リンク NACK を送り、ローカルバッファからのフレーム再読み出しを引き起こします。回復が迅速に成功すれば、トランスポートはより長い再送を回避できます。

潜在的な価値は、レーンあたりの速度とポート密度が上がるほど高まります。偶発的な光学的または電気的エラーは、そうでなければ同期ジョブに不釣り合いな遅延をもたらす可能性があります。しかし、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 から機能強化ファブリックへの軌跡を作り出しますが、マーケティング言語が隠蔽し得るマトリックスも生みます。あるスイッチはトランケーション、LLR、CBFC なしで UET を正しく転送できます。別のスイッチは特定のバージョンまたはポートモードでのみこれらをサポートするかもしれません。したがって、信頼できる展開提案は、単にコンソーシアム名を引用するのではなく、機能の正確なセットを記述しなければなりません。

100 および 200 Gbps/レーンの物理シグナリング

物理層は UEC をハードウェアロードマップに固定します。初期の 1.0 作業は 100 Gbps/レーンを中心としていました。バージョン 1.0.3 は 200 Gbps/レーンを追加しました。この進化は、より高密度なリンクの新世代と仕様を整合させますが、すべての UEC 製品がこの速度を直ちにサポートすることを証明するものではありません。

PHY 作業は、エラー訂正統計、訂正済みおよび訂正不可能なコードワードレート、制御順序セット、リンク品質報告、物理エラーと LLR の相互作用もカバーします。これらの詳細は、下位層が何を観測し報告できるかに回復決定が依存するために重要です。

高速化するほど、光学系、SerDes、FEC、ローカル回復、トランスポート再送の境界は経済的に重要になります。より強力な FEC は残余エラーを減らす代わりにレイテンシとエネルギーを要します。LLR はローカル破損をより高速に回復できますが、バッファと状態を要求します。エンドツーエンド回復はネットワーク内では単純ですが、より多くの時間を浪費し得ます。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 特許義務付きのオープン文書

仕様 1.0.3 は公的にダウンロード可能であり、Creative Commons Attribution-NoDerivatives 4.0 ライセンスの下で配布されています。このライセンスは、帰属表示を条件とする再配布を許可しますが、改変版の配布は許可しません。重要なことに、著作権上のアクセスと特許上のアクセスは別問題です。

作業部会の規約は通常、標準的な合理的かつ非差別的な（RAND）特許ライセンスモデルを使用しています。RAND は必ずしも無償を意味しません。この用語は統一価格を保証せず、交渉を排除せず、有効性、必須性、地理的範囲、防御的条件に関する紛争を防止しません。商業的立場は、宣言された各特許、会員のコミットメント、あらゆる二者間ライセンスに依存します。

UEC は Necessary Claims の宣言の公開記録を維持しています。調査時点では、Broadcom、Microsoft、Huawei、Qualcomm、AMD、HPE、Google、Marvell などに関連する宣言が、将来の 1.1 作業に関連する提出を含めて可視化されていました。この登録簿は透明性を向上させますが、実装者は製品を構築・販売する前に知的財産を調査する必要があるかもしれないことを示しています。

コンソーシアムは、宣言された特許が有効か、真に必須か、侵害されているか、所与の価格で利用可能かを判断しません。また、共通ライセンスを公開しません。したがって、小規模な実装者は、大規模会員がより容易に吸収する法的・取引コストを負担する可能性があります。公開仕様であっても、特許の明確化、シリコンコスト、テストが高ければ、集中した市場につながり得ます。

知的財産枠組みはガバナンスインセンティブにも影響します。企業は自社製品の市場を拡大するため、また既存の能力を共通設計に反映させるために技術を提供します。特許宣言は、早期かつ十分に明確であれば驚きを軽減しますが、アーキテクチャ採用後にライセンスが障壁となるリスクを排除するものではありません。

したがって、正直な説明は「RAND 特許コミットメントを伴う、公的に公開されたマルチベンダー仕様」であり、「普遍的にロイヤリティフリー」ではありません。購入者は技術プロファイルとライセンス経路の両方を必要とします。

最初の製品とテストの波

実装の証拠はバージョン 1.0 前後に可視化されましたが、成熟度のレベルは異なります。

AMD は2025年4月に Pollara 400 AI カードを利用可能にし、進化する UEC 機能を中心に設計されたと説明しました。Pollara は重要なプログラマブルプラットフォームであり、トランスポートが商用ハードウェアに到達したことを示しています。文言は依然として重要です。進化する UEC 機能向けに設計されたことは、すべての最終 1.0.3 要件の独立認証と等価ではありません。

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

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

他の会員は UEC 関連のスイッチ、システム、ソフトウェア、テスト計画を説明しており、2026年サミットは製品化に大きな焦点を当てました。利用可能な要素は、実装への移行の考えを支持します。出荷された UET カード、認証済みスイッチ、展開されたクラウドリージョン、完全なファブリックの正確な数を確立するには至りません。

この波の最良の読み取りは、証拠の連鎖です。仕様が設計を可能にします。シリコンとカードの発表が投資を示します。トラフィックデモが相互運用性の一部を示します。マトリックスが要件を整理します。オペレータの展開報告が運用価値を示すでしょう。独立したプラグフェストと本番結果が、依然として不足するより広範な信頼性をもたらすでしょう。

RoCE、InfiniBand、Slingshot、UALink

UEC は成熟した技術と隣接システムが存在する市場に参入します。その戦略的主張は、Ethernet がこれまで RDMA を運んだことがないとか、特殊ファブリックが機能しないということではありません。現在の AI ワークロードの規模と同期性が、配信、経路利用、輻輳においてより柔軟な、新しいエンドツーエンド Ethernet アーキテクチャを正当化するというものです。

RoCEv2 は直接の前身であり、広く設置された技術です。ルーティング可能な Ethernet 上で RDMA を伝送し、広範なアプリケーションおよび製品サポートを持ちます。UEC は、フロー全体の単一経路への固定、Go-Back-N 回復、受信側での並べ替え、DCQCN の調整困難、多くのアーキテクチャでの Priority Flow Control への依存、インキャストまたは集団バースト下での挙動について、一般的な展開を批判しています。これらは UEC の技術的立場であり、すべての RoCE ネットワークが劣るという証明ではありません。

比較は進化します。ベンダーは、RoCE 互換性を維持しながら、プログラマブルカードに適応ルーティング、パケットスプレッディング、改善された輻輳制御、その他の UEC アイデアを追加できます。AMD の Pollara に関するコミュニケーションは、既に RoCEv2 と UEC RDMA をプログラマブルハードウェア上の2つの選択肢として提示しています。したがって、UEC は完全なトランスポートとして RoCE と競合しつつ、その進化に影響を与える可能性があります。

InfiniBand は主要な特殊代替手段です。RDMA、輻輳、リンク信頼性、管理の統合エコシステムを提供し、長い HPC 経験を持ちます。InfiniBand Trade Association の 2.0 作業は 200 Gbps 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 と独自ファブリックは別のトレードオフを示します。統合スタックはハードウェア、ソフトウェア、サポートを迅速に最適化できますが、単一エコシステムへの依存を高めます。UEC は、統合の一部を共通インタフェースと選択の約束と交換します。トレードオフの価値は、性能、サポート、特許、相互運用性、総コストに依存し、スローガンとしての「オープン性」には依存しません。

運用上の問題はプロトコルを超える

573ページの仕様は多くの要件を定義できますが、本番ファブリックには依然として運用モデルが必要です。バージョン 1.0 は、規範的文書の周辺に重要な管理作業を残しています。オペレータは、プロファイル、トラフィッククラス、ECN 閾値、エントロピーセット、リンクオプション、キー、ファームウェア、テレメトリ、障害ポリシーを一貫して設定しなければなりません。

混合トラフィックはさらに複雑にします。ファブリックは UET、RoCE、TCP、ストレージ、管理、順序付き/なし UET サービスを伝送する可能性があります。キュー割り当てと公平性は、各プロトコルを個別に修正するだけでは解決されません。ある輻輳制御は単独では機能しても、異なる信号を使用する別の制御に対して不良に動作する可能性があります。

エンドポイントの複雑さは別の構造的リスクです。UET はマルチパス、直接データ配置、選択的再送、複数モード、ウィンドウおよびクレジット制御、トランケートパケット受信、セキュリティ、多くの状態をそこに配置します。これはシリコン面積、ファームウェアサイズ、検証努力、エネルギー、診断すべき故障数を増大させる可能性があります。終端のインテリジェンスは広範なサプライヤーチェーンを可能にしますが、すべてのサーバに存在するコンポーネントを複雑にもします。

オプション機能は差別化と断片化の両方を生みます。あるベンダーは従来の ECMP と ECN 向けに AI Base を最適化できます。別のベンダーは AI Full、TSS、トランケーション、LLR、CBFC をサポートできます。両者は同じエコシステムに参加しますが、同等の性能やセキュリティを保証しません。適合性マトリックスは運用能力マトリックスへと進化しなければなりません。

バージョン保守は継続的です。1.0.1 から 1.0.3 への修正は輻輳、クレジット、回復、パケットに触れました。大規模クラスタは、複数バージョンのカードファームウェア、スイッチソフトウェア、テストツールを抱える可能性があります。他と調整せずに1つの層をアップグレードすると、コンソーシアムがまさに回避しようとする層横断的な競合を露呈し得ます。

したがって、外部アライアンスが中心的重要性を持ちます。OCP はトランスポートをオープンハードウェアとシステムに接続します。OFA と libfabric はアプリケーションを接続します。IEEE 802.3 は正式な Ethernet プロセスをもたらします。SNIA と NVM Express はストレージと管理をもたらします。IETF メカニズムは IP、ECN、その他の基盤を提供します。これらの組織はプロセスとスケジュールが異なります。連絡は重複を減らしますが、同時採用を保証しません。

最終テストは稼働するインフラです。文書は動作を定義でき、ベンダーは製品を発表でき、コンソーシアムはサミットを開催できます。いずれも、独立したエンドポイントとスイッチが、輻輳、障害、アップグレード下で実際のジョブを完了し、オペレータが結果を説明できるクラスタの代わりにはなりません。

現在の妥当性：ドキュメント上の勝利から実装の信頼性へ

2026年7月までに、UEC は発足時には不確かだった複数の目標を達成しました。広範な連合を形成し、5層にわたる統合アーキテクチャを生み出し、完全な 1.0 仕様を公開し、保守し、200G レーンを追加し、特許宣言を開示し、製品およびテストの発表を引き出しました。プロジェクトは活動的であり、そのアジェンダは明らかに実装へと移行しました。

この進展は不確実性をより重要なものにします。現在の会員総数と運営委員会構成を公開する単一の登録簿は存在しません。会員ページと規約はアクセスについて異なる説明をしています。正式な TAC リーダーシップはサミットの役割と完全には調整されていません。1.0.2 の日付は公式文書間で異なります。適合性パッケージは時代遅れのプロファイル用語を使用しています。これらの問題はアーキテクチャを破壊しませんが、正確なバージョンが重要なプロジェクトにおける文書品質管理を示します。

最も重要なギャップは採用に関するものです。UEC は展開集計、独立した製品登録簿、独立した予算、監査済み財務諸表を公開していません。最大目標規模で完全に相互運用可能な 1.0 ネットワークを確立する公的証拠はありません。デモとベンダー主張は有用ですが、利害関係があります。RoCE、InfiniBand、統合 Ethernet プラットフォームとの公正な比較は依然として限られています。

機会は依然として莫大です。Ethernet はデータセンターの共通分母であり、AI 市場は新世代のカード、スイッチ、光学系、ソフトウェアを支えることができます。オペレータは、単一ベンダー依存を回避し、アクセラレータ利用率を向上させる強いインセンティブを持ちます。共通スタックはこれらのインセンティブを購買レバレッジに転換し得ます。

リスクは、「Ultra Ethernet」が互換性のないサブセットの傘になることです。基本転送は機能しても、プロファイル、輻輳、セキュリティ、管理が分岐すれば、ブランドは相互運用性より速く拡散するかもしれません。RAND ライセンスが高価か不確実であれば、サプライヤー数は減少し得ます。RoCE がトランスポートを変更せずに最も魅力的なアイデアを吸収すれば、UEC は市場に影響を与えつつも支配的なラベルにはならないかもしれません。

決定的な問いは、もはやコンソーシアムが洗練された仕様を公開できるかどうかではありません。それは成し遂げられました。問いは、独立した組織が同じ契約を実装し、必要なライセンスを確保し、ファブリックを大規模に運用し、進化の過程で互換性を維持できるかどうかです。UEC は、その主張が本番コードで耐えられる限りにおいてのみ、インフラとなるでしょう。