UALink Consortiumは、AIアクセラレータを接続するオープン規格「UALink 2.0」を公表した。今回の更新では、UALink 1.0で示された低遅延、高帯域のアクセラレータ間接続を土台に、In-Network Collectives、マルチテナント環境を意識したセキュリティ、障害耐性、管理性が拡張された。支持表明では、初の管理仕様とチップレット仕様にも触れられている。
現時点で、価格や2.0対応シリコンの出荷時期は公表されていない。一方、UALink 1.0のホワイトペーパーでは、1.0系エコシステムについて評価ハードウェアを2026年中に見込むとしていた。UALink 2.0は、転送性能そのものの更新というより、大規模AIクラスタを実際に構築、共有、監視する際に必要になる要件を仕様の中へ取り込んだ改訂と言えそうだ。
2.0で拡張された範囲
UALink 1.0は、200G/laneの物理層を前提に、最大1,024のアクセラレータを1つのPod内で接続するスケールアップ相互接続として設計されていた。2.0では、その上に集団通信、共有基盤での分離、障害回復、管理プレーンに関する要素が加わっている。
| 項目 | UALink 1.0で確認できる土台 | UALink 2.0で追加・拡張された内容 |
|---|---|---|
| 基本アーキテクチャ | メモリセマンティクス、スイッチベース構成、Ethernet PHYとの整合 | 1.0の土台を維持しつつ、AI運用向けの機能を追加 |
| 集団通信 | ソフトウェアがP2Pメッセージを組み合わせて処理 | In-Network Collectivesにより、スイッチがbroadcast、reduce、all-reduce、reduce-scatterに参加 |
| セキュリティ | リンクレベルの暗号化と認証 | 仮想Pod単位の鍵管理、鍵導出・ローテーション、任意の完全性保護とリプレイ保護 |
| 障害耐性 | 1.0では基礎仕様が中心 | マルチパス、障害分離と回復、link folding、collective障害時の制御を強化 |
| 管理性 | 1.0時点では基盤機能が中心 | Pod controllerの役割を明確化し、管理仕様を追加。Google CloudはgNMIとRedfishに言及 |
| チップレット | 1.0で独立した仕様の言及は確認しにくい | 支持表明で初のチップレット仕様に言及 |
この表から読み取れるのは、2.0の中心が単純な帯域増強ではないという点だ。AIクラスタを多ノード、共有前提で運用する際に問題になりやすい処理を、仕様の射程に入れ始めたことが今回の特徴である。特に管理仕様とチップレット仕様が同じタイミングで前面に出てきたことで、UALinkは相互接続だけではなく、運用や実装の周辺まで含む議論に進んでいる。
In-Network Collectivesで集団通信の扱いが変わる
Synopsysの解説によると、UALink 2.0の中核機能はIn-Network Collectives（INC）である。AI学習では、勾配交換や同期処理のために多数のアクセラレータ間で集団通信が発生する。UALink 1.0では、これをソフトウェアが多数のポイントツーポイント通信に分解して処理していたが、2.0ではスイッチ自体が集団通信を理解し、データの複製、集約、分配に関与する。
| 集団通信の種類 | 2.0で想定される役割 |
|---|---|
| Broadcast | 1つのアクセラレータのデータを他ノードへ配布する |
| Reduce | 複数ノードの値を集約し、1つの宛先へ送る |
| All-reduce | 集約結果を全ノードへ再配布し、学習状態をそろえる |
| Reduce-scatter | 集約しつつ結果を分割し、各ノードへ返す |
この仕組みが意味を持つのは、集団通信がAI学習時のトラフィックの大きな割合を占めるためだ。スイッチがcollective処理に参加すれば、不要な往復や重複転送を減らしやすい。Synopsysは、スイッチが必要最小限の状態だけを持ちながら集団処理に加わることで、レイテンシ低減とトラフィック増幅の抑制を狙うとしている。ノード数が増えるほど、ここは補助的な改良では済まず、システム全体の効率を左右する部分になる。
セキュリティと障害耐性は共有クラスタ運用を前提に広がった
セキュリティ面では、1.0がリンクレベルの暗号化と認証を備えていたのに対し、2.0は仮想Pod単位のセキュリティ文脈を導入する。各仮想Podに固有の鍵、認証状態、鍵導出、鍵ローテーションを持たせ、リクエスト、レスポンス、集団通信を通じて保護する構成である。さらに、集団通信に参加するスイッチを信頼計算基盤の一部として扱い、必要に応じて暗号化データを復号、処理、再暗号化する流れも定義する。
この設計は、単一テナントの専有クラスタよりも、複数ワークロードが共存するクラウドや共有AI基盤で重みを持つ。Google Cloudが支持表明で「UALink Manageability」をgNMIとRedfishで支える点を挙げたのも、性能に加えて、異機種混在環境を一貫して発見、設定、監視できる運用性が重要になっているためだろう。
障害耐性も2.0の大きな更新点である。Synopsysは、マルチパスルーティング、障害分離と回復、collective処理の障害認識、link foldingによる段階的な性能低下運用、Pod単位の協調回復を挙げている。AIクラスタが大規模化すると、リンク断や部分故障をゼロにはできない。2.0は、障害が起きないことを前提にするというより、障害が起きた状態でもPod全体を止めずに運用を続けるための枠組みを整えている。
1.0で示された基礎仕様は引き続き土台になる
2.0の位置付けを理解するには、1.0で何が定義されていたかも重要だ。UALink 1.0ホワイトペーパーでは、200G/laneを基本に、1、2、4レーン構成を採用し、4レーンのStationで送受信それぞれ最大800Gbpsの帯域を持つとしている。ケーブル長は4m未満、要求から応答までの往復時間は1マイクロ秒未満を目標に掲げ、1Podあたり最大1,024アクセラレータを想定していた。
| UALink 1.0の基礎仕様 | 内容 |
|---|---|
| レーン当たり速度 | 200 GT/s per lane |
| シリアル速度 | 212.5G |
| レーン構成 | x1 / x2 / x4 |
| x4 Station帯域 | 送信800Gbps、受信800Gbps |
| Pod規模 | 最大1,024アクセラレータ |
| 目標往復遅延 | 1マイクロ秒未満 |
| 想定ケーブル長 | 4m未満 |
| 帯域効率目標 | 93% effective bandwidth |
今回の2.0は、こうした基礎仕様を別の数値で置き換える更新というより、既存のスケールアップ基盤にAI向けの集団処理、共有利用向けの隔離、標準化された管理、パッケージ分割を重ねる流れにある。Synopsysも、2.0はメモリセマンティクス、スイッチベース構成、Ethernet物理層との整合といった1.0の強みを維持すると説明している。
開示された内容と、なお見えていない条件
今回確認できる情報を整理すると、仕様の拡張内容に比べて商用条件の開示はまだ限られている。
| 項目 | 現時点で確認できる内容 |
|---|---|
| 2.0仕様 | 公表済み。INC、セキュリティ、障害耐性、管理性の拡張が中心 |
| 管理仕様 | 初の管理仕様が加わり、gNMIやRedfishとの連携が言及された |
| チップレット仕様 | 初のチップレット仕様が支持表明で言及された |
| 1.0系ハードウェア | 2026年中に評価ハードウェアを見込むという説明がある |
| 価格 | 公表なし |
| 2.0対応シリコンの出荷時期 | 公表なし |
| 商用製品の正式投入時期 | 公表なし |
この開示状況を見る限り、UALink 2.0は即時の製品投入を告げる発表というより、複数ベンダーが共通の実装前提と運用モデルを共有するための仕様更新と受け止めるのが自然だ。AMDは支持表明で、INCに加えて管理仕様とチップレット仕様を基盤整備として評価した。Astera Labsは、INC、標準化チップレット、既存基盤へ統合しやすい管理ツールを新仕様の要素として挙げている。Google CloudはgNMIとRedfishを伴う管理性を重視し、UnifabriXはメモリ中心のスケールアップを支える相互運用性に言及した。
UALink Consortiumは、オープン規格によるAI相互接続を掲げてきた。2.0では、その論点がリンク性能だけにとどまらず、共有運用、障害対応、管理、自動化、チップレット統合へと広がっている。価格や製品投入時期はまだ見えていないが、AIクラスタの実運用で問題になりやすい要素を規格の中へ取り込もうとしている点が垣間見える。
Sources
