要約

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

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

Ultra Ethernet Consortium は、コンピューティングの経済性が変化したことを背景に設立されました。通常のエンタープライズネットワークでは、ファブリックは多数の独立したフローを許容可能なスループットと可用性で移動させることが期待されます。大規模な人工知能トレーニングシステムや高性能コンピューティングマシンでは、ネットワークは同期された一つの計算の一部になります。数千のアクセラレータが集合通信においてモデルパラメータ、勾配、科学的データを交換することがあります。あるフェーズは、最も遅い参加者が必要な情報を受け取るまで進めません。したがって、わずかな経路不均衡、輻輳、またはパケットロスが、ファブリックの平均利用率が健全に見えていても、高価なプロセッサを待機させる可能性があります。

これにより、オペレータが最適化する対象が変わります。総帯域幅は依然として重要ですが、それだけでは不十分です。ジョブ完了時間、テールレイテンシ、インキャスト、ロスからの回復、平行経路へのトラフィック分散、エンドポイントが維持しなければならない状態の量も気にします。大部分のパケットを迅速に配信しつつ、ごく一部を遅延させるネットワークは、コレクティブ全体を停止させる可能性があります。従来のトラフィックでは許容可能な再送方式も、長いメッセージが1パケットをロスした場合には時間を浪費しすぎます。1つの等コストパスに固定されたフローは、トポロジの他の場所に余剰容量があるにもかかわらず、パフォーマンスを低下させる可能性があります。

UEC の設立趣旨は、これらの問題が一つの新しいスイッチ機能や一つの改訂輻輳アルゴリズムでは解決できないという点にありました。通信経路はネットワークの上流、ソフトウェアライブラリやアプリケーションセマンティクスから始まり、メモリ登録、リモート操作、トランスポート状態、パケット配信、輻輳制御、IP 転送、イーサネットリンク、光学、物理シグナリングを経由します。これらの層が独立して設計されると、ある場所での最適化が単にボトルネックを移動させるか、他の場所で矛盾した前提を生み出す可能性があります。

UEC の答えは、調整されたアーキテクチャです。オペレータが既に理解しており、スイッチ、光学、ケーブル、ネットワーク OS、テレメトリ、管理の周辺に巨大なサプライチェーンが存在するため、イーサネットと IP を保持します。大規模な AI や HPC ワークロードに不適合とみなされる部分を変更または拡張します。その結果は「新しいロゴのついた普通のイーサネット」ではありません。ソフトウェア 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 はしばしば不正確に企業、アライアンス、標準化団体と表現されるためです。株主、自己資本、評価額、独立した財務諸表を持つ営利企業ではありません。イーサネット製品を販売したり、公衆ネットワークを運営したり、メンバーが推進するハードウェアを所有したりしません。法的および知的財産の枠組みを持つ仕様策定コンソーシアムです。公開文書は複数企業間の実装契約となることを意図しています。

また、UEC は Ultra Ethernet Transport と同一ではありません。UET は仕様の中心にあるトランスポートアーキテクチャです。コンソーシアムの作業はより広範で、libfabric へのソフトウェアマッピング、パケットとメッセージのセマンティクス、ネットワークの前提、リンク層オプション、物理層要件、管理、ストレージ連携、パフォーマンスとデバッグ、適合性、テストを含みます。このプロジェクトを「新しい RDMA プロトコル」と縮小することは、野心的かつ困難なクロスレイヤ設計を隠してしまいます。

UEC は IEEE 802.3 Working Group でもありません。IEEE 802.3は、自身の正式プロセスを通じてコアイーサネット MAC および物理層標準を策定します。UEC はそのエコシステムに依存し、リエゾンを維持しますが、置き換えるわけではありません。この境界は、UET の下位にある IPv4、IPv6、Explicit Congestion Notification などの IETF メカニズム、libfabric を維持する OpenFabrics エコシステム、ストレージ、オープンハードウェア、アクセラレータ相互接続に取り組む組織についても同様です。

プロジェクトの Web サイトは、国際標準化団体としての地位を示唆する表現を用いています。より安全で確かな記述は、UEC が JDF フレームワークに基づく国際的な仕様策定組織であるというものです。国際標準化機構の一部であること、文書が ISO 標準であること、ISO 標準番号を持つことの証拠はありません。この区別は用語以上のものであり、権威の源、参加の仕組み、実装者が直面し得る法的コミットメントを特定します。

したがって、UEC は実際に果たす役割によって判断されるべきです。競合他社や事業者を共通の技術設計の周りに調整し、仕様を公開し、ワーキンググループと宣言された特許義務を管理し、適合性資料と隣接組織との関係を発展させます。宣言だけで製品を相互運用可能にしたり、市場にアーキテクチャを採用させたりすることはできません。

9社の設立連合

コンソーシアムは2023年7月19日、AI および HPC サプライチェーンの異なる層に位置する9組織によって発表されました：AMD、Arista Networks、Broadcom、Cisco、当時 Atos と関連していた Eviden、Hewlett Packard Enterprise、Intel、Meta、Microsoft です。この広がりは当初から戦略的資産でした。スイッチベンダーのみが開発したトランスポートは、アプリケーションやエンドポイントの制約を無視するかもしれません。アクセラレータサプライヤーのみが主導する設計は、一つのハードウェアエコシステムに過度に最適化されるかもしれません。クラウドのみのプロジェクトは、アーキテクチャを製品に変えるために必要なシリコン、光学、システムの専門知識を欠くかもしれません。

AMD はプロセッサ、アクセラレータ、エンドポイントネットワーキングをもたらしました。Arista と Cisco は大規模イーサネットスイッチングと運用経験をもたらしました。Broadcom はスイッチングシリコン、NIC、高速 SerDes を提供しました。HPE と Eviden は HPC システムと特殊相互接続の歴史を持ち寄りました。Intel はプロセッサ、イーサネット、ソフトウェアの専門知識を提供しました。Meta と Microsoft は、大規模 AI クラスタの利用率向上と単一の統合サプライヤーへの依存低減に直接的なインセンティブを持つハイパースケール事業者を代表しました。

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

HPE の Slingshot インターコネクトは、技術的系譜の有益な例です。Slingshot は適応ルーティングと輻輳管理機能を持つイーサネット互換の HPC ファブリックです。HPE 関連のコメントは、HPC イーサネット仕様が UEC に寄贈され、UET の大部分が Slingshot トランスポートのアイデアに由来すると推定しています。正確な割合は独自に検証されておらず、コンソーシアム会計として扱うべきではありません。より広範なポイントは十分に裏付けられています：UEC は白紙から始まったのではなく、HPC、クラウドネットワーキング、RDMA、イーサネットにおける実運用経験を活用しました。

この既存システムの混在が、「オープン」という言葉に正確さが必要な理由の一つです。UEC の承認された仕様は公開ダウンロード可能です。アーキテクチャは複数ベンダーによる実装を意図しています。しかし、プロジェクトはメンバーが既存の知識、特許、製品ロードマップを提供する場でもあります。文書のオープン性は、技術を巡る経済的または法的条件を取り除くものではありません。

競合他社が協調するために構築された法的シリーズ

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年のサミットアジェンダは追加の運営リーダーを指名しています。これらのサミット役職は必ずしも仕様内の正式な役職を置き換えるものではなく、公開資料は完全な現在の組織図を提供していません。

チャーターには3つのメンバーシップクラスが登場します：Steering、General、Contributor です。Steering メンバーはガバナンスに参加し、通常 Steering Committee 代表を指名します。General メンバーは技術グループ全体で作業できますが、Steering Committee には参加しません。Contributor メンバーは選ばれたグループに参加し、特別多数決権を持ちません。現在の公開メンバーシップページは General および Contributor レベルを案内し、年間プロジェクト価格はそれぞれ20,000米ドルと5,000米ドル、加えて Linux Foundation メンバーシップが必要です。Steering ステータスの加入経路や現在の価格は明確に説明されていません。

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

内部プロジェクト情報は通常の企業機密データとしては扱われませんが、メンバーは関連委員会が公開を承認するまでドラフト資料の開示を制限されます。この取り決めは、競合他社が時期尚早な市場シグナリングなしに未完成のアイデアを議論するのに役立ちます。また、外部の者が却下された提案、投票記録、中間的な実装上の懸念、オプション機能を生み出した交渉を見ることができないことも意味します。最終仕様はオープンですが、そこに至る道筋は部分的にしか見えません。

4グループの立ち上げから573ページの仕様へ

2023年の UEC の最初の公開構造は、ソフトウェア、トランスポート、リンク、物理の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 は既存のイーサネットスイッチを通じて動作可能であり、強化されたスイッチが追加パフォーマンスを提供できることも強調されました。

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

コンソーシアムは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 パーレーンシグナリングとブール交渉機能のサポートを追加します。リリースノートでは、パケット配信、輻輳クレジット、Link Layer Retry、物理層制御オーダードセットに関する必要な修正も特定しており、トランスポートセキュリティ、アトミック、トリムパケットに関する明確化も含まれています。必要な修正と編集上の明確化の区別は重要です。一部の変更は適合動作に影響し、したがって実装のメンテナンスに影響します。

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

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

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

最上位では、AI フレームワーク、MPI、SHMEM、集合通信ライブラリが OpenFabrics Interfaces、特に libfabric を通じて相互作用します。UET Semantic Services Sublayer がアプリケーション操作をトランスポートトランザクションに変換します。Packet Delivery Sublayer は、メッセージがどのようにパケット化、順序付け、確認応答、回復されるかを決定します。輻輳管理はファブリックに入るデータ量とトラフィックの経路間分散を制御します。オプションのトランスポートセキュリティがエンドポイント間トラフィックを保護します。標準の IPv4 または IPv6 がネットワーク層転送を提供します。イーサネットはリンクを提供し、オプションのパケットトリミング、Link Layer Retry、Credit-Based Flow Control、機能ネゴシエーションが付随します。物理層は100または200 Gb/s パーレーンでの統計とシグナリング要件を定義します。

この構造は、既存ネットワークの重要な部分を保持します。UEC は IP ルーティングの代替を定義しません。従来の等コストマルチパス転送と ECN 対応スイッチを期待します。インテリジェンスの多くは Fabric Endpoints に留まり、エントロピーの操作、トランスポート状態の追跡、データ配置、輻輳信号への応答を行います。強化されたスイッチは機能を追加できますが、UET トラフィックが通過する前に全ファブリックを交換する必要は設計上ありません。

これにより移行の利点と分類の問題が生じます。ある展開では、ECMP と ECN による従来のイーサネット上で 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 イーサネット、IETF ネットワーキング、ストレージ組織、ベンダーのオペレーティングシステムにも同様の依存関係が存在します。

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

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

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

UEC は3つの実装プロファイルを定義します：AI Base、AI Full、HPC です。これらは別個のネットワークタイプではなく、実装がどの機能をサポートしなければならないかを指定するバンドルです。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 がアプリケーションの意図を運びます。メッセージ識別、バッファアドレッシング、タグ付きおよびタグなし操作、リモートメモリアクセス、アトミック、完了動作、ジョブ識別子、バッファ認可、応答、エラーを定義します。Packet Delivery Sublayer が、その意図がどのようにパケットになり、それらのパケットが別のエンドポイントに到達するかを決定します。

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

この状態は小さな実装詳細ではありません。大規模クラスタでは莫大な数の通信関係が生じることがあります。各関係が広範なターゲット状態を必要とすると、エンドポイントメモリと検索コストが制限要因になり得ます。したがって UEC は、すべての操作を1つのコネクションモデルに強制しません。異なる信頼性と順序付け契約を持つ4つの配信サービスを定義します。

Reliable Unordered Delivery（RUD）は、パケットが順不同で到着することを許容しつつ、セマンティック層への正確に一度だけのパケット配信を提供します。複数経路へのパケットスプレー、選択的再送、重複抑制、直接データ配置をサポートします。宛先はトランスポートレベルの並べ替えバッファを待たずにオフセットに従ってデータを配置できるため、長いコレクティブは1つの欠落ユニットの後ろに全パケットを直列化することなく、複数経路を活用できます。

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 の中心的哲学を明らかにします：ネットワークはいくつかのメカニズムを露出すべきであり、ソフトウェアがトランスポートのコストを操作のセマンティクスに一致させられるようにします。利点は効率性です。コストは、より大きな実装とテストの表面積であり、プロバイダ、アプリケーション、オペレータが互換性のない組み合わせを選択する機会が増えます。

パケットスプレー：1つの幸運な経路ではなくファブリックを活用

従来の等コストマルチパス転送はしばしば、フロー全体を1つの経路にハッシュします。広い Clos ファブリックでは、これは宝くじを生じさせます。複数の大きなフローが同じリンクで衝突する一方で、同等の容量が他の場所で未使用のままになることがあります。長い AI 転送は、全生涯にわたって1つの不運なハッシュによって制限される可能性があります。

UET は、パケット粒度でエントロピーを変更することでこれに対処します。送信者は数十から数百のエントロピー値を使用し、スイッチの既存の ECMP メカニズムがパケットを多数の経路に分散できるようにします。Packet Delivery Sublayer がシーケンス情報を提供し、Congestion Management Sublayer がエントロピーまたは経路を選択し、スイッチが通常のハッシュを実行し、フィードバックが送信者にどのエントロピー値が輻輳しているように見えるかを通知します。

パケットスプレーが実用的なのは、設計の他の部分がそれをサポートしているからに他なりません。パケットは順不同で到着することがあります。RUD は完全なトランスポートの並べ替えを待たずにデータを直接配置できます。選択的再送はロストしたものだけを回復できます。輻輳フィードバックは問題のある経路の使用を減らすことができます。したがって、このメカニズムは独立した負荷分散トリックではなく、経路多様性を中心に構築されたトランスポートモデルの一部です。

UEC はすべてのスイッチが独自の適応ルーティングアルゴリズムを実行することを要求しません。基本的な実装は、標準 ECMP 上でラウンドロビンまたは疑似ランダムエントロピーを使用できます。より高度なエンドポイントは、ECN、レイテンシ、トリミング信号を特定のエントロピー値と関連付け、輻輳しているように見える経路を回避するかもしれません。ベンダー固有の適応転送は UET と共存できますが、経路認識の唯一の源ではありません。

約束はより良いファブリック利用率とより低いテールレイテンシです。未解決の疑問は、異なるエンドポイントがフィードバックをどれだけ一貫して解釈するか、そしてパケットスプレーがスイッチバッファ、並べ替え、障害、混合トラフィックとどのように相互作用するかです。均質なラボでうまく機能するアルゴリズムが、複数のスイッチ世代とトラフィッククラスを持つ大規模ファブリックでは異なる挙動を示すかもしれません。独立したマルチベンダーの証拠は依然として限られています。

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

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

Network-signal Congestion Control（NSCC）は送信側駆動です。送信者は輻輳ウィンドウを維持し、転送中のバイト数を推定し、確認応答、否定確認応答、タイムアウト、レイテンシ、ECN などのネットワーク信号を用いてウィンドウを調整します。パケットレベルマルチパスとウィンドウ動作を調整します。UEC は、ウィンドウがパケットがネットワークから出られなくなったときに自然にデータの受け入れを停止するのに対し、純粋にレートベースのコントローラは不在のフィードバックを誤って解釈する可能性があると主張します。

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

Receiver-credit Congestion Control（RCCC）はインキャストを対象とします。多数の送信者が同時に1つの宛先に送信する場合、ネットワークコアが輻輳していなくても最後のリンクがボトルネックになり得ます。受信側は需要を追跡し、クレジットを送信者に分配し、総到着をペーシングし、競合に応じて各送信者の実効ウィンドウを変動させます。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 と選択的再送と組み合わせることで、タイムアウトを待ったり、1つのロス後に大きなシーケンスを再送したりすることなく、回復を加速できます。

このスイッチ機能はオプションですが、適合エンドポイントは該当要件の下でトリミングされたパケットを受信し解釈しなければなりません。この非対称性は、従来のスイッチ上での展開をサポートしつつ、強化されたファブリックがより豊富なロス情報を提供できるようにします。また、アップグレードの問題も生じます。部分的に強化されたネットワークでは、すべての受信側エンドポイントが正しく処理するように、トリミングを経路、プロファイル、トポロジによって制約する必要があるかもしれません。

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

パケットトリミングは、プロジェクトのより広範な実装課題を例示しています。プロトコルはワイヤ動作を定義できますが、運用結果はスイッチキューイング、エンドポイントロジック、テレメトリ、設定、障害処理に依存します。相互運用性はしたがって、パケット形式のプロパティではなく、システムのプロパティです。

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

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

潜在的な価値は、レーン速度とポート密度が上昇するにつれて増大します。時折の光学的または電気的エラーは、緊密に同期されたジョブに不釣り合いな遅延を生じさせ得ます。しかし LLR は、シーケンス状態、再送バッファ、制御メッセージ、破棄ウィンドウ、新しい障害モードを追加します。クレジット更新やリンクリセットとも共存しなければなりません。バージョン1.0.3は、CBFC クレジット情報と LLR が関与する競合を含む、いくつかのエッジケースを修正しました。

Credit-Based Flow Control（CBFC）は、リンクレベルで仮想チャネルごとに動作します。受信側にどれだけの受信容量が残っているかを送信側に伝え、広範な優先度ポーズよりもきめ細かな制御を提供できます。UEC は、グローバルにロスレスであることを要求することなく、制御されたロスレス動作をサポートする方法として提示します。CBFC はオプションであり、UET はベストエフォートネットワーク上で動作するよう設計されています。

CBFC を Priority Flow Control の別名として扱うべきではありません。メカニズムは、バッファオーバーフローを防止しようとする点では共通していますが、シグナリングと粒度が異なります。CBFC も依然として一貫した設定と、それ自身の制御フレームの正確な配信を必要とします。ローカルクレジットはまた、エンドツーエンドウィンドウや受信側クレジットと相互作用し、複数の入れ子になった制御ループを生み出します。

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

これらのオプションは、ベーシックから強化されたイーサネットへの経路を提供します。また、調達文言が隠蔽し得るマトリックスも生み出します。あるスイッチは UET を完全に転送しても、トリミング、LLR、CBFC を欠くかもしれません。別のスイッチは、特定のソフトウェアリリースやポートモードでのみ機能をサポートするかもしれません。信用できる展開記録には、単にコンソーシアム名だけでなく、正確な機能セットが必要です。

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

物理層は UEC をハードウェアロードマップに固定します。初期の1.0作業は100 Gb/s パーレーンシグナリングを中心に書かれました。バージョン1.0.3は200 Gb/s パーレーンのサポートを追加しました。この変更は、仕様をより高密度のリンクとシステムの世代に合わせますが、これは仕様上の能力であり、すべての UEC 製品が直ちにそのレートをサポートする証明ではありません。

UEC の PHY 作業はまた、前方誤り訂正（FEC）の統計、訂正可能および訂正不能符号語比率、制御オーダードセット、リンク品質報告、物理エラーと LLR の間の相互作用にも取り組みます。これらの詳細は、トランスポートの回復決定が下位層が観察し報告できるものに依存するため重要です。

より高いシグナリングレートでは、光学、SerDes、FEC、リンク再試行、トランスポート回復の間の境界が経済的に重要になります。より強力な FEC はレイテンシと電力のコストで残余エラーを低減するかもしれません。リンク再試行はローカルな破損をより迅速に回復するかもしれませんが、バッファと状態を必要とします。エンドツーエンド再送はネットワーク全体でより単純ですが、より多くの時間を浪費し得ます。UEC は、各ベンダーが孤立して最適化させるのではなく、これらの層がどのように協調するかを定義しようと試みます。

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

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

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

この設計は、メンバーが暗号コンテキストを共有するセキュアドメインを使用します。識別子、関連付け番号、エポック、セキュアソース識別、鍵導出は、すべてのエンドポイントペアに対して独立したセッションを確立することを超えてスケールすることを意図しています。これは、アクセラレータの数やジョブメンバーシップが急速に変化する場合に必要です。

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

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

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

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

UEC はバージョン1.0と共に適合性資料の公開を開始しましたが、公開システムは成熟した独立認証制度ではありません。利用可能なパッケージは主に実装者の自己証明用に設計されています。マトリックスは仕様要件をプロファイルにマッピングし、テストベッドガイダンスは推奨されるエンドポイントとスイッチ構成を記述します。独立した権威が完全な UEC プログラムに合格または不合格となった製品を記録する包括的な公開データベースは特定されていません。

この区別は、市場で異なる主張がいくつか流通しているため極めて重要です。製品は発展中の UEC 機能を中心に設計されているかもしれません。選択されたワイヤ機能を実装するかもしれません。特定のソフトウェアリリースで1つのプロファイル、またはその一部をサポートするかもしれません。ベンダーは完全に機能準拠していると述べるかもしれません。テストラボはスイッチを通じて UET トラフィックを生成するかもしれません。これらのいずれも、独立したマルチベンダー、エンドツーエンドの認証と自動的に等価ではありません。

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

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

信頼できる次の段階には、正確な仕様バージョンに結びついた公開テスト定義、マルチベンダープラグフェスト、独立して管理された結果、ネガティブ結果と成功の両方、そしてエンドポイント、スイッチ、ソフトウェア、完全システムを区別するレジストリが含まれるでしょう。それまでは、「UEC 準拠」は完全な保証ではなく、出発点の質問です。

RAND 特許義務付きのオープン文書

Ultra Ethernet Specification 1.0.3は公開ダウンロード可能であり、Creative Commons Attribution-NoDerivatives 4.0の下で配布されています。これにより帰属表示付きの再配布が許可されますが、ライセンスの下で修正版の配布は許可されません。より重要なことに、著作権アクセスと特許アクセスは別個のものです。

文書化されたワーキンググループチャーターは一般に、合理的かつ非差別的な特許ライセンスを伴う伝統的な仕様策定モデルを使用します。RAND は必ずしもロイヤリティフリーを意味しません。1つの普遍的価格を保証せず、交渉を排除せず、有効性、必須性、地理、防衛的条件に関する紛争を防ぎません。実際の商業的地位は、宣言された各特許、メンバーのコミットメント、および任意の二者間ライセンスに依存します。

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

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

知的財産フレームワークはガバナンスのインセンティブも形成します。企業は、自社製品のための広範な市場を創出するためと、自社の既存能力が共通設計に反映されることを確実にするために、部分的に技術を提供します。特許宣言は、タイムリーで十分に明確である場合にのみ、実装者を不意打ちから保護できます。それらはアーキテクチャが採用された後にライセンスが障壁となる可能性を排除しません。

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

最初の製品とテストの波

実装の証拠は1.0リリースの頃に可視化されましたが、例は異なる成熟段階を占めています。

AMD は2025年4月に Pollara 400 AI NIC を商業的に利用可能にし、発展中の 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データセンタースイッチファミリーを800ギガビットイーサネットで横断するエンドツーエンド UET トラフィックデモンストレーションを発表しました。Keysight がトラフィック生成と検証を提供しました。このテストは、UET トラフィックが商用スイッチングシステムを通過でき、テスト機器サポートが発展していることを示します。完全なマルチベンダーエンドポイントプロファイル、本番規模、またはすべてのオプション機能の独立認証を確立するものではありません。

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

製品の波を読む最も有用な方法は、証拠の連鎖としてです。公開仕様が設計を可能にします。シリコンと NIC の発表が投資を示します。トラフィックデモンストレーションが何らかの相互運用性を示します。適合性マトリックスが要件を組織化します。事業者展開報告が運用価値を示すでしょう。独立したプラグフェストと本番結果が、現在の記録がまだ欠いているより広範な信頼性を確立するでしょう。

RoCE、InfiniBand、Slingshot、UALink

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

RoCEv2 は直接の先行技術であり、主要な導入技術です。ルーティング可能なイーサネット上に RDMA トラフィックを配置し、幅広いアプリケーションと製品のサポートがあります。UEC は一般的な RoCE 展開を、フロー全体の経路固定、Go-Back-N 回復、受信側再順序付け、困難な DCQCN チューニング、多くの設計での Priority Flow Control への依存、インキャストやコレクティブバースト下での弱い動作について批判します。これらは UEC の技術的立場であり、すべての RoCE ネットワークが低パフォーマンスである証拠ではありません。

比較はまた動的です。ベンダーは RoCE 互換性を維持しながら、プログラマブル NIC に適応ルーティング、パケットスプレー、より良い輻輳アルゴリズム、その他の UEC 類似機能を追加できます。例えば AMD の Pollara に関するメッセージングは、RoCEv2 と UEC RDMA をプログラマブルハードウェア上の選択肢として提示しています。UEC はしたがって、完全なトランスポートとして RoCE と競争すると同時に、将来の RoCE 製品がどのように進化するかにも影響を与える可能性があります。

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

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

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、トリミング、LLR、CBFC をサポートするかもしれません。両者とも UEC エコシステムに参加できますが、オペレータは同じセマンティクス、パフォーマンス、セキュリティを想定できません。適合性マトリックスは運用能力マトリックスになる必要があります。

バージョンメンテナンスは継続的です。1.0.1から1.0.3までの修正は輻輳、クレジット、再試行、パケット動作に影響しました。大規模クラスタは複数の NIC ファームウェアバージョン、スイッチリリース、テストツールを含む可能性があります。他の層と調整せずに1つの層をアップグレードすると、コンソーシアムが回避しようとしているまさにクロスレイヤの競合を露呈させる可能性があります。

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

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

現在の妥当性：仕様の勝利から実装の信頼性へ

2026年7月までに、UEC は立ち上げ時に不確かだったいくつかのことを達成しました。幅広い連合を形成し、統合された5層アーキテクチャを生み出し、完全な1.0仕様をリリースし、修正リリースを通じて維持し、200G パーレーンサポートを追加し、特許宣言を開示し、製品およびテストの発表を引き付けました。プロジェクトは活発であり、アジェンダは断固として実装へと移行しています。

この進展により、次の不確実性がより重要になります。正確な現在のメンバーシップと Steering 名簿は、1つの信頼できる登録簿に公開されていません。公開メンバーシップページとチャーターはアクセスを異なって記述しています。現在の正式な TAC リーダーシップはサミットの役割と完全には整合していません。1.0.2リリース日は公式文書間で矛盾しています。適合性パッケージは古いプロファイル用語を使用しています。これらの問題はいずれもアーキテクチャを破壊しませんが、正確なバージョンが重要なプロジェクトにおける文書管理と透明性についての信号です。

より重大なギャップは導入に関するものです。UEC は展開調査、独立して検証された製品登録簿、独立した予算、または監査済みの会計を公開していません。コンソーシアムの最大規模ターゲットで完全に相互運用可能な UEC 1.0ネットワークを確立する公開証拠はありません。ベンダーのデモンストレーションと主張は価値がありますが、商業的に利害関係があります。現在の RoCE、InfiniBand、統合イーサネットプラットフォームとの中立的なパフォーマンス比較は依然として限られています。

コンソーシアムの機会は依然として大きいです。イーサネットはデータセンター全体の共通分母であり、AI インフラ市場は新たな NIC、スイッチ、光学、ソフトウェアの世代をサポートするのに十分な大きさです。事業者は単一ベンダー依存を回避し、アクセラレータ利用率を改善する強力なインセンティブを持っています。共通スタックはこれらのインセンティブを購買力に変え得ます。

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

決定的な問いはもはや、コンソーシアムが洗練された仕様を公開できるかどうかではありません。それは達成されました。問いは、独立した組織が同じ契約を実装し、必要な技術をライセンスし、ファブリックを大規模に運用し、仕様が進化する中で互換性を維持できるかどうかです。UEC は、これらの主張が稼働コードとの接触を生き延びる範囲でのみインフラになるでしょう。