Schneider ElectricがHeliosの導入を可能にし、AMD Googleインフラ競争が変化

Schneider ElectricとAMDは、246キロワットのラックと最大10.4メガワットのIT負荷を持つクラスタをサポートする、Helios向け初のインフラ設計を公開した。これは、amd googleのインフラ競争を実務面から変える動きだ。AMDには今、アクセラレータ仕様から実際に稼働する高密度データセンターへ至る文書化された道筋がある。

この発表によって、AMDがGoogle、Nvidia、あるいは他のプラットフォーム提供企業に対して突如として性能上の勝利を得るわけではない。むしろ、異なる競争上の弱点に対処している。各ラックに専用の配電、液冷、制御、施設レベルのモデリングが必要となる場合、アクセラレータの購入は始まりにすぎない。

Googleは、機械学習ワークロード向けに最適化されたプロセッサであるTensor Processing Units（TPU）を中心に、こうしたシステムを長年かけて開発してきた。Nvidiaもまた、自社のアクセラレーテッドシステム向けの物理インフラでSchneider Electricと協業している。AMDは、運用事業者に対し、支援設備を一から考案させることなく、Heliosを運用可能なクラスタにできると納得させなければならない。

だからこそ、このリファレンス設計は重要だ。Schneider Electricを単なる機器サプライヤー以上の存在へと変える。同社は、垂直統合されたAIインフラに対するAMDの回答の一部となる。

Heliosの設計図はチップを10.4MWの施設へとつなぐ

AMDとSchneider Electricは、単にラック内のプロセッサ配置ではなく、Heliosを取り囲む物理システムを定義した。

両社は、2026年7月23日にサンフランシスコで共同開発した設計を発表した。Helios blueprintによると、IT容量10.4メガワットに達するモジュール型AIクラスタをサポートする。

高密度ラック1台あたり、最大246キロワットが必要となる。このレベルのラックは、多くの従来型エンタープライズ設備に関連する電力の数倍を消費する。また、その電力入力のほぼすべてを、継続的に除去しなければならない熱として集中させる。

Heliosは、AMD Instinct MI455Xアクセラレータ、第6世代EPYCプロセッサ、Pensando Vulcanoネットワークインターフェースカード、そしてROCmソフトウェア環境を組み合わせる。ROCmは、AMDのアクセラレータをプログラミングし運用するためのオープンソフトウェアスタックだ。

これらのコンピューティングコンポーネントは、あくまで1つの層にすぎない。リファレンス設計は、施設電力、施設冷却、ITスペース、ライフサイクルソフトウェアを対象とする。これらの層をHeliosの要件に沿ってどのように連携させるべきかを規定している。

Schneider Electricによると、同社のMotivair冷却システムは、液体ベースおよび空気・液体ハイブリッド方式により、熱の最大84％を除去できる。Coolant distribution units（CDU）は、ラック側のループと建物の冷却システムの間で熱を移動させる。

この設計では、EcoStruxure IT Designを通じてETAPの電気モデリングと数値流体力学も活用する。数値流体力学は、機器が現場に到着する前に、気流と温度の挙動をシミュレーションする。

運用事業者は、電気デジタルツインを用いてインフラの挙動をモデル化できる。AVEVAのUnified Operations Centerは、導入後の監視と運用上の可視性を追加する。これらのツールは、建設プロセスの早い段階で電気的または熱的な競合を明らかにすることを目的としている。

Schneider Electricによると、完成した構成はフル負荷時に約1.12の電力使用効率（PUE）を達成できる。PUEは、施設全体のエネルギー使用量とコンピューティング機器に供給されるエネルギーを比較する指標だ。1に近いほどオーバーヘッドが少ないことを示すが、実際の結果は気候、稼働率、運用上の選択に左右される。

初期設計は、米国での導入に向けてAmerican National Standards Instituteの要件に従う。Schneider Electricは、他市場向けにInternational Electrotechnical Commission規格に適合するバージョンを開発する計画だ。

この地理的な制約は重要である。この発表は、地域の電気法規や電力会社の条件を回避できる汎用設計ではなく、検証済みの出発点を提供するものだ。顧客にはなお、現場に応じたエンジニアリング作業が必要となる。

independent reportingによると、この設計図は顧客による別途の料金負担なしで利用できる。その真の価値は、文書の取得コストではなく、統合に伴う不確実性を回避できる点にある。

リファレンス設計が電力を供給したり、送電網への接続を確保したりするわけではない。コンクリートを打設することも、水利権を取得することも、地域の許認可を解決することもできない。適切な用地が存在した後、未解決のエンジニアリング課題の範囲を狭めることはできる。

この違いが、記事の中心的な緊張関係を示している。AMDは競争力のあるプロセッサとラックスケールのアーキテクチャを生み出した。今必要なのは、現実の物理的制約の下で建設される施設の内部に、そのアーキテクチャを繰り返し導入する方法だ。

AMD Google競争がチップを超えて進む理由

高密度AIシステムは、電気、熱、ネットワーク、ソフトウェアを含む完全なプラットフォームとして競争するため、amd googleの比較はますます施設エンジニアリングに左右される。

Googleは、およそ10年にわたりカスタムAIインフラを運用してきた。同社はTPU、ポッド規模のネットワーク、冷却システム、ソフトウェアフレームワーク、そして多くのデータセンター支援コンポーネントを1つの組織内で設計している。

その経験は、単純なアクセラレータ仕様では捉えられない優位性を生む。Googleは、プロセッサのロードマップを、それらのプロセッサを収容する建物と連携させられる。また、Google Cloudを通じて容量を提供する前に、大規模な社内フリート全体でインフラの変更を試験できる。

Googleは、7年間で2,000超のTPUポッドにわたり、ギガワット規模で液冷を導入したと報告している。また、これらの冷却導入では約99.999％の稼働率を達成したとも報告した。同社は、1メガワットラック設計を紹介する中で、その経験について説明している。

これらはAMD Heliosとの独立した比較ではなく、企業が報告した数値である。それでも、競合するインフラプラットフォームが対応しなければならない運用上の成熟度を示している。

Googleは、空冷施設内の液冷ハードウェア向けに、ラックマウント型の液体・空気間冷却システムであるBrazosも開発した。Brazos systemは、密閉された液体ループで熱を回収し、既存のホットアイルへ放出する。

BrazosとSchneider ElectricのHelios設計は、異なる導入状況に対応する。しかし、両者はいずれも同じ業界圧力を反映している。対象となる建物が必要な液体ループ、電力供給、または排熱能力を提供できない場合、AIハードウェアの導入は停滞する。

AMDはGoogleに匹敵するハイパースケールデータセンターフリートを所有していない。したがって、顧客にとって同等の道筋をつくるには、インフラパートナー、サーバーメーカー、クラウドプロバイダー、ネットワークサプライヤーが必要となる。

Schneider Electricは、そのギャップの重要な部分を埋める。同社は、配電、冷却機器、モデリングソフトウェア、施設エンジニアリングをAMDのラックスケールプログラムにもたらす。HPEは、Heliosを商用システムへ組み込むことで、別の経路を提供する。

このパートナーシップモデルは柔軟性を提供できる。顧客は、単一のクラウド事業者のプロセッサや施設アーキテクチャに限定されない。運用事業者は、コロケーション、プライベートクラウド、ソブリンAI、専門的なコンピューティングプロジェクトにまたがってオープン設計を適応できる。

しかし、パートナー主導モデルは調整リスクも生む。アクセラレータ、スイッチ、CDU、電気バス、ソフトウェアリリースの変更は、複数の企業に影響し得る。検証は、主要コンポーネントのあらゆるロードマップに追随しなければならない。

Googleの統合モデルは、こうした組織間の距離の一部を縮める。同社は、TPU、ネットワーク、ソフトウェア、施設の各チームを社内計画を通じて連携させられる。また、自社の経済性に適したワークロードのためにインフラを確保することもできる。

その代償は顧客のコントロールにある。Google Cloudの顧客は、主としてマネージドサービスとしてこのプラットフォームを利用する。Heliosの購入者は、コンピューティング環境、施設設計、運用モデルをより直接的に制御できる。

これは、すべての調達においてAMDとGoogleが直接の代替手段になることを意味しない。Googleはクラウドサービスを販売しカスタムシリコンを使用する一方、AMDは業界ネットワークを通じてプロセッサとプラットフォーム技術を販売している。

それでも、エンタープライズの購入者は結果として得られる容量を比較する。導入時間、モデル互換性、利用可能なリージョン、運用管理、性能、エネルギー使用量を検討する。競争単位は、個々のチップではなく、稼働するAIクラスタになりつつある。

Nvidiaは依然として、この市場における最大の参照点だ。Schneider Electricは2024年、高密度アクセラレータクラスタ向けの大電力配電と液冷に焦点を当て、Nvidiaとのインフラ協業を発表した。この先行するNvidia collaborationは、Schneiderが1つのアクセラレータプラットフォームを選んでいるわけではないことを示している。

その代わり、Schneider Electricは複数のアーキテクチャが新たな施設設計を求めることで利益を得る。AMDにとって、この関係はインフラに関する信頼性をもたらす。顧客にとっては、クラウドネイティブのTPUやNvidia中心のシステムに並ぶ、もう1つのエンジニアリング済みの選択肢となる。

電力と冷却が競争の仕組みを定義する

246キロワットのラックは、調達用スプレッドシートを変えるよりも速く施設を変えるため、Schneider Electricの貢献は重要だ。

従来のサーバー計画では、データセンターは安定した容器として扱われることが多かった。購入者はサーバーを選び、ラック位置を割り当て、既存の電力・冷却容量が十分かどうかを確認した。

高密度AIはその順序を逆転させる。いまやワークロードとアクセラレータのロードマップが、電気トポロジー、配管、フロア配置、冗長化モデル、建設スケジュールを形づくる。昨日のサーバー向けに設計された建物が、明日のラックを自動的に受け入れられるわけではない。

246キロワットでは、Heliosラックはコンピューティング機器と施設システムの直接的な連携を必要とする。電気設計は、定常負荷、過渡的な挙動、保護設定、保守状態、障害シナリオを扱わなければならない。

冷却設計は、すべてのコールドプレートに十分な液体を供給しなければならない。また、許容できない温度変化や流量の不均衡を生じさせずに、CDUと施設ループを通じて熱を移動させる必要がある。

一部のコンポーネントや周辺機器は依然として室内に熱を放出するため、空冷も設計の一部として残る。そのためSchneider Electricは、液冷が空気側の要件をすべて不要にすると主張するのではなく、ハイブリッドアプローチを説明している。

同社のリファレンス設計ライブラリは、モデリングが電気的挙動、気流、液体の流れを網羅する必要がある理由を示している。各モデルは異なる種類の障害を捉える。それらを組み合わせることで、運用事業者がクラスタに通電する前に相互作用を特定できる。

部分的な冷却障害を考えてみよう。残りの機器が追加の熱を吸収するか、コンピューティング負荷を迅速に下げる必要がある。この事象は、施設制御、クラスタスケジューリング、そして場合によってはモデル学習の進捗にも影響する。

電力の中断は、もう一つのクロスレイヤー問題を生む。バックアップシステムは想定する運用状態を支え、ソフトウェア環境は中断されたジョブを処理しなければならない。施設のレジリエンスとコンピューティングのレジリエンスを、別々に計画することはできない。

これがHelios提携の仕組みである。AMDはコンピューティングプラットフォームの動作と要件を定義する。Schneider Electricはそれらの要件を、プロジェクトチームが評価できるインフラ構成へと落とし込む。

モジュール式の10.4メガワット・クラスター設計は、さらに一層を加える。事業者は、配備ごとにゼロから設計するのではなく、再利用可能な単位で容量を計画できる。標準化は調達を簡素化し、エンジニア、請負業者、技術ベンダー間の見解の相違を減らせる可能性がある。

反復可能性は、サプライヤーによる機器需要の予測にも役立つ。CDU、スイッチギア、監視システム、プレハブモジュールは、既知のクラスター構成を基準に計画できる。ただし、繰り返し使えるモジュールであっても、現場レベルでの統合は必要となる。

電力会社が供給できる容量は、依然として最も難しい制約である。洗練された設計でも、電力会社が希望するスケジュールで追加の10.4メガワットを供給できる保証にはならない。系統連系の待機列や変電所工事は、コンピューティングハードウェアの導入スケジュールより長引く可能性がある。

水と排熱の処理も、場所によって異なる。施設では、気候や地域の規制に応じて、チラー、ドライクーラー、冷却塔、あるいは別の構成が必要になる場合がある。リファレンス設計によって、こうした環境差がなくなるわけではない。

約1.12とされるPUEについても、同様の文脈が必要だ。PUEは、稼働率、天候、冗長性、冷却方式、測定範囲によって変動する。モデル上の全負荷時の値を、年間を通じた保証値として扱うべきではない。

事業者はまた、保守や障害に備えてどれだけの容量を確保するかを選ばなければならない。冗長インフラを追加のコンピューティングに使えば、通常運用時の利用率は向上し得る。一方で、機器が停止した際に利用できる余裕は減少する。

Schneider Electricは、この選択を追加のコンピューティング出力と当初の冗長性戦略との競争として説明している。未使用のバックアップ容量は、自動的に無料の生産容量になるわけではないため、この判断は明示的に行うべきだ。

Googleも、統合型モデルであっても同じ物理的制約に直面する。同社の液冷への取り組みは、カスタムシリコンが施設エンジニアリングを不要にするわけではないことを示している。むしろ、組織はコンピューティングの世代ごとに、冷却・電力システムを並行して開発しなければならない。

したがってamd googleの競争は、同じ仕組みに対する二つのアプローチを浮き彫りにする。Googleはスタックの大部分を社内で調整する。AMDはHeliosを中心にオープンなパートナーネットワークを構築し、Schneider Electricが重要な施設レイヤーを担う。

検証済みの設計は、検証済みの導入ではない

最大の不確実性は、顧客が実際のサイト、ワークロード、サプライヤー、運用条件にわたって、設計図でモデル化された結果を再現できるかどうかにある。

Schneider ElectricとAMDは、この設計が共同で開発・検証されたものだと説明している。この検証は、コンポーネントとエンジニアリング上の前提がまとめて評価されたことを示す。ただし、大規模な導入基盤全体での実地性能を確立するものではない。

7月の発表には、公開された顧客導入の結果は添えられていなかった。両社は、新設計のもとでラック当たり246キロワットを連続運転する完成済みHelios施設を公表していない。

この隔たりは、新たに発表されたアーキテクチャとしては通常のことである。それでも、購入者が試運転期間、障害時の挙動、コンポーネントの入手性、長期保守について推測できる範囲を制限する。

Heliosプラットフォームは、ハードウェアが計画どおりに投入されることにも依存する。設計にはMI455Xアクセラレーター、第6世代EPYCプロセッサー、Vulcanoネットワークインターフェースが含まれる。遅延や仕様変更があれば、別の検証サイクルを強いられる可能性がある。

ネットワークは特有のリスクをもたらす。Heliosは、Nvidiaの緊密に統合されたNVLink環境の代替を提供することを目指した、オープンでEthernet志向のアプローチを採用する。これにより購入者はサプライヤーの選択肢を広げられるが、発展途上のパートナーエコシステムの重要性も高まる。

HPEはHeliosベースのシステムを提供する計画を発表しており、AMDにとって大きな商業的ルートとなる。同社の実装では、高帯域幅のアクセラレーターファブリックと専用設計のスイッチを用いる。

詳細なHeliosシステム分析では、MI455Xアクセラレーター72基を含む計画構成が説明されている。報告では、AMDの目標として、ラック当たり31テラバイトのHBM4メモリーと2.9エクサFLOPSのFP4演算性能も示された。

これらの数値は将来のハードウェアに紐づく目標であり、独立して検証された本番結果ではない。FP4は、一部のAI推論タスクで使われる低精度の数値形式である。あらゆるトレーニングや科学計算のワークロードと直接比較すべきではない。

ソフトウェアも依然として変数である。ROCmはフレームワークとモデルの対応を拡大してきたが、ハードウェアが利用可能であることだけで同等のアプリケーション性能が保証されるわけではない。購入者は実際のモデル、演算子、コンパイラー、分散トレーニングの挙動をテストする必要がある。

Googleは、JAX、XLA、社内ソフトウェア環境を通じて、TPU向けに重要なワークロードを最適化できる。Nvidiaには長年確立されたCUDA開発者基盤がある。AMDは、顧客に過度な統合作業を移すことなく、オープンスタックが依存関係を減らせることを証明しなければならない。

リファレンス設計は施設の設計図を解決できても、アプリケーション移行の問題を未解決のまま残す可能性がある。この境界は、アクセラレータープラットフォーム切り替えの総コストを評価するエンタープライズチームにとって重要である。

保守もまた一つの試金石となる。液体ループは、高価なコンピューティング機器の近くに、ポンプ、接続部、センサー、マニホールド、保守手順を追加する。事業者には、漏れ、ろ過、冷却液の品質、コンポーネント交換、スタッフ教育に関する証拠が必要だ。

84パーセントという熱除去の数値にも、慎重な解釈が必要である。Schneider Electricは、提案する冷却方式が、その割合の熱を液体によって除去できるとしている。残る熱負荷と運用条件は、依然として室内レベルの冷却要件を左右する。

導入速度にも同じ注意が当てはまる。事前設計された構成は、計画期間を短縮し、重複作業を減らすことができる。しかし、変圧器、スイッチギア、チラー、アクセラレーター、電力系統の増強が制約されたままであれば、より速い建設を保証することはできない。

商業面での問題もある。購入者は、アーキテクチャ上の選択肢の増加が、より分散したサプライヤー関係を運用することを正当化するか判断しなければならない。施設をAPIの下に隠すクラウドサービスを好む企業もあるだろう。

一方で、直接的な管理、地域内でのデータ保管、あるいは単一クラウドプラットフォームからの独立性を重視する企業もある。ソブリンAIプロジェクトと専門クラウドプロバイダーは、特にこの選択肢を検討する可能性が高い。

この緊張関係により、AMDの戦略は信頼に足るものではあるが、未完成でもある。Schneider Electricは不確実性の一分類を減らした。今後は顧客導入が、組み合わされたシステムがモデル環境の外でも一貫して機能するかを示さなければならない。

AMDがインフラギャップを埋められるかを示す三つのシグナル

次の段階は、もう一度のアーキテクチャ上の主張ではなく、運用上の証拠、パートナーによる提供、反復可能な顧客導入にかかっている。

第一のシグナルは、Schneider Electricの設計を用いた顧客導入の完了である。最も強い証拠には、現実的なワークロード変動下で測定されたラック密度、試運転期間、冷却性能、可用性、PUEが含まれるだろう。

一つのパイロット導入は、設計図が設計環境の外へ出られることを確認する。異なる気候や施設タイプにまたがる複数の導入は、反復可能性についてより強い結論を支えることになる。

公表された全負荷時PUE 1.12に近い結果は、両社の効率性に関する主張を強める。これを大きく上回る結果でも、設計が自動的に無効になるわけではないが、サイト条件の重要性を浮き彫りにする。

購入者は、事業者が障害と保守をどう扱うかも注視すべきだ。高密度クラスターは、CDU、ポンプ、電気コンポーネント、コンピューティングトレイのいずれかに対応が必要になったときも、保守可能な状態を維持しなければならない。

第二のシグナルは、AMDのハードウェア・ネットワーキングパートナーによる協調した提供である。MI455Xアクセラレーター、新しいEPYCプロセッサー、Vulcanoインターフェース、スイッチ、サーバー、施設機器は、互換性のあるスケジュールでプロジェクトに届く必要がある。

不可欠な一つのコンポーネントが長期の遅延を生むなら、リファレンスアーキテクチャの価値は失われる。逆に、提供時期が同期すれば、AMDのパートナーモデルが一貫したプラットフォームのように機能できることを示すだろう。

相互運用性テストは特に重要になる。顧客には、サーバー、スイッチ、ソフトウェア、電力、冷却の変更が、繰り返しの再設計サイクルを招かないという証拠が必要だ。

HPEの商用Heliosシステムは、初期の試験となる。同じラックレベルの前提を採用する追加のサーバーメーカーやクラウド事業者が現れれば、標準化はさらに強まる。

第三のシグナルは、Google TPUおよびNvidiaシステムに対抗するワークロードの採用である。AMDは、すべての購入者にそれらのプラットフォームを置き換えさせる必要はない。Heliosを信頼できる代替案として確立するのに十分な本番ワークロードを得る必要がある。

その証拠には、ピークベンチマークの結果だけでなく、トレーニングと推論のアプリケーションも含まれるべきだ。事業者は、実用的な性能、ソフトウェアへの労力、クラスターの可用性、エネルギー消費量、容量拡張の速度を検討する。

Google自身によるインフラ開発は、有用な参照例となる。同社の長い液冷の歴史は、運用上の知見がハードウェア世代をまたいで蓄積されることを示している。AMDとSchneider Electricは、顧客とパートナーを通じて、これに匹敵する実績の構築を始めなければならない。

両社が市場で占める位置は異なるため、amd googleの比較は不完全なままである。Googleは統合されたクラウドとカスタムシリコンのプラットフォームを運用する。AMDは、他社が導入するオープンアーキテクチャを提供する。

しかし、この対照こそが新設計を重要にする理由である。これは購入者に、統合プラットフォームを利用するか、自らの管理下で検証済みのパートナーベースシステムを構築するかという選択肢を与える。

Nvidiaも結果を左右する。同社のラックスケールシステム、ソフトウェア基盤、インフラパートナーシップは、導入成熟度の基準を定めている。Nvidiaがより速く進展すれば、AMDのオープンアーキテクチャは柔軟性、可用性、またはワークロードの経済性でそれを補う必要がある。

Schneider Electricには、主要な各プラットフォームを支援する動機がある。この中立的な立場は、一つのアクセラレーターロードマップを恒久的なものと見なすことなく、顧客が施設要件を比較する助けとなり得る。

技術チームと調達チームにとって、直近の行動は具体的である。まず想定するワークロードをモデル化し、その後、選定したサイトが電力、熱、ネットワーク、レジリエンスの要件を満たせるかを検証するべきだ。

大規模なインフラ発表を評価するチームには、エンジニアリング上の前提と後続の運用証拠を結び付ける、持続可能な方法も必要となる。検索可能な技術ナレッジベースは、プロジェクトの変化に応じて、設計文書、テスト結果、サプライヤーに関する意思決定へアクセスしやすい状態を維持できる。

Schneider Electricの設計は、アクセラレーター競争に決着をつけるものではない。AMDを、ラック仕様が電力系統の制約、建設スケジュール、冷却障害、本番ワークロードに耐えなければならない、より難しい段階へと進めるものだ。

Heliosの顧客は設計図に一致する測定結果を公表するのか。そしてパートナーは、すべてのレイヤーを予定どおりに提供できるのか。今重要なのは、これらの試験である。AMD Googleインフラ競争の勝者を宣言する前に、最初の稼働サイト、協調されたハードウェア供給、ワークロードの採用を注視すべきだ。