powered by TechFeed
表示モード
Deep Dive

AIデータセンターの「銅配線=スケールアップ」という常識が崩れ始めた — GoogleはJupiterネットワークへのOCS導入でスループット30%向上・消費電力40%削減を達成(2022年論文)

8月13日、Semiconductor Engineeringが「Copper's Grip On AI Scaling Is Starting To Slip」と題した記事を公開した。この記事では、AIクラスタの大規模化に伴い銅配線の物理的限界が露わになりつつあり、光インターコネクトへの移行がデータセンターのネットワーク設計を根本から変えようとしている状況について詳しく紹介されている。

8月13日、Semiconductor Engineeringが「Copper's Grip On AI Scaling Is Starting To Slip」と題した記事を公開した。この記事では、AIクラスタの大規模化に伴い銅配線の物理的限界が露わになりつつあり、光インターコネクトへの移行がデータセンターのネットワーク設計を根本から変えようとしている状況について詳しく紹介されている。


「スケールアップ=銅配線」という前提が崩れ始めた

従来のAIデータセンターでは、スケールアップ(ラック内のGPU間通信)は銅配線、スケールアウト(ラック間通信)は光インターコネクト、という役割分担が常識だった。だがその境界線が今、急速に曖昧になっている。

Rambusのフェロー兼ディスティングイッシュド・インベンターであるSteven Wooは「スケールアップは銅、スケールアウトは光という従来の定義が崩れ始めている。ラック内のデータレートが上昇するにつれ、銅配線は損失・到達距離・消費電力の面で物理的な限界に突き当たっている」と述べている。

この変化の根本的な動因はレイテンシだ。Omnitronの共同創業者兼CEOであるEric Aguilarは「GPUがデータ待ちで止まっているせいで、稼働効率が25%程度にとどまるという報告が多数出ている」と指摘する。

では、どこから光に切り替わるのか。Ayar Labsのプロダクトマネジメント責任者Vishal Chandrasekharは具体的な目安を示している。「200Gbpsのシグナリングレートを前提にすると、銅が有効なのは5〜7メートルまで。10メートルを超えたら光一択だ。隣接ラックなら銅でギリギリ届くが、それ以上離れると光に移行することになる」。


スケーリング用語の再整理

記事では、AIデータセンターのスケーリング階層が以下のように整理されている。

  • Scale-in:単一サーバーボード内のプロセッサ間。元記事によれば比較的新しく定着してきた用語とされている。
  • Scale-up:ラック内〜隣接ラック間。従来は「銅配線+メモリセマンティクス」で定義されていたが、今や光が侵食しつつある。
  • Scale-out:ラック間。Ethernet RDMAセマンティクスを使用。光インターコネクトが主流。
  • Scale-across:データセンターキャンパス間。光ファイバーを使用。

スケールアップの残る定義要素はメモリセマンティクス(プロセッサが単一メモリ空間を扱う)のみになりつつある。SynopsysのPriyank Shuklaは「ソフトウェア側はスケールアップを『1つのOSドメインで1つのメモリを持つ』と定義している。プロセッサはメモリの物理的な場所を意識せず任意のアドレスに書き込める」と説明する。

UALink(AMDやIntelなどが推進するスケールアップ向けインターコネクト規格)では、この1ホップ原則が仕様として担保されている。「UALinkのスケールアップファブリックは、アクセラレータ間の通信が常に1スイッチホップで完結するよう設計されている。ラックをまたいでも、スイッチ間トポロジは増えない」(Shukla)。


Googleが先行実装した「光回線交換(OCS)」

ここが記事の核心だ。パケット交換ネットワークでは、光信号はルーターを通過するたびに電気信号へ変換され、パケットヘッダを読んで次のホップを決定し、再び光に戻される。このOEO(光-電気-光)変換がレイテンシと消費電力の大きな原因になっている。

Googleは約10年前、この問題に対してMEMS(微小電気機械システム)ベースの光回線交換(OCS: Optical Circuit Switching)を実用化した。OCSでは、各ルーターノードにMEMSミラーを置き、入力ファイバーからの光をそのまま目的地ファイバーへ反射させる。OEO変換は発生せず、データは光のまま端点まで届く。

GoogleのJupiterネットワーク(Googleのデータセンターネットワークのコードネーム)へのOCS導入成果については、2022年にGoogleのシニアバイスプレジデントであるAmin Vahdatらが発表した論文で報告されている。同論文によると、以下の成果が得られたとされている。

  • フロー完了時間を10%削減
  • スループットを30%向上
  • 消費電力を40%削減
  • コストを30%削減
  • ダウンタイムをベスト比で50倍削減

Aguilarは電力削減の内訳を「トランシーバを半数省略でき、液冷設備とASICも削減できる。それらを光学ソリューションで置き換えた効果だ」と説明する。

OCSの弱点は、フローを開始する前にミラーの経路設定(コントロールプレーン処理)が必要な点だ。短時間・小規模なパケットであるマイスフロー(mice flow)には向かず、大容量の持続的なデータ転送であるエレファントフロー(elephant flow)に適している。Aguilarは「LLMの学習と推論はまさにOCSが有効なユースケースだ」と述べている。


パケット交換とOCSの混在アーキテクチャ

現在多くのデータセンターで使われるリーフ・スパイン(Clos)構成にOCSを適用する検討も進んでいる。想定されるのは、リーフ・スパインの上位ティアにOCSを置き、ソース・デスティネーションのルーターが複数パケットをまとめて光で転送し、受信側で再分解する構成だ。「OCSは最終的にスイッチへ終端し、そこから先は電気」(Shukla)。

一方、Googleのトーラス型ネットワーク(各TPUが上下・右の隣接TPUと接続するメッシュ状トポロジ)ではリーフ・スパインより多くのホップが発生するが、その分だけOCSによる電力削減効果も大きくなる。トレードオフはワークロードとトポロジの組み合わせ次第であり、一つの正解はない。


詳細はCopper's Grip On AI Scaling Is Starting To Slipを参照していただきたい。