VultrのAMD Helios発注、HPEにNvidiaへの対抗策となる12億ドル規模の足掛かり
VultrはHPEのAMD Heliosシステムを12億ドル分発注し、72基のGPUを搭載するこのプラットフォームにHPEとして初の顧客をもたらした。VultrによるAMD Heliosの発注は、このアーキテクチャを公開ロードマップの段階から、米国のデータセンターにおける商用導入へと移行させる。
この取引は、単なるAIアクセラレーターの追加購入ではない。HPEは、AMDのコンピュート、オープンソフトウェア、Ethernetベースのスケールアップネットワーク、液冷、導入サービスを組み合わせた統合ラックを供給する。この取り決めは、代替ベンダーの連合が完全なシステムレベルでNvidiaと競争できるかを試すものだ。
Nvidiaが基準点であり続けるのは、Vera Rubin NVL72も72基のGPUを1つのラックスケールのコンピューティングドメインとして接続するためだ。ただしNvidiaは、NVLinkのような独自技術を通じてスタックのより多くを管理している。AMD、HPE、Juniper、Broadcomは、標準ベースのEthernetをよりオープンな道筋として提示している。
この違いは、個別のピーク性能の主張よりも重要だ。ラックスケールAIシステムは、アクセラレーター、メモリー、ネットワーク、冷却、オーケストレーション、ソフトウェア全体で一貫した結果を提供しなければならない。Vultrは現在、このオープンなアプローチが本番クラウドで機能することを示すために多額の資本を投じている。
VultrによるAMD Helios発注、HPEを本番環境へ押し上げる
この発注は、これまで主に仕様と提携発表によって定義されてきたシステムに対し、HPEにとって初の商用検証をもたらす。
HPEは2026年9月30日にこの契約を発表した。同社の発注発表によると、Vultrは米国のクラウドデータセンター全体で、HPEによるAMD Helios AI Rackシステムを導入する。
同社はこの取引を、統合Heliosプラットフォームに対する初の受注と説明した。HPEは9月30日付のSEC提出書類でもこの進展を報告しており、発表を正式な投資家向け開示の一部に位置付けている。
各ラックには72基のAMD Instinct MI455X GPUが搭載される。また、VeniceというコードネームのAMD EPYCプロセッサーと、AMD Pensando Vulcano AIネットワークインターフェースカードも含まれる。
GPUコンピューティング向けAMDのオープンソフトウェアプラットフォームであるROCmが、プログラミング環境を提供する。HPEはラックエンジニアリング、直接液冷、導入サービス、そしてラックあたり6基のJuniper QFX5252スケールアップスイッチトレイを担う。
スケールアップネットワークは、1つのコンピューティングドメイン内でアクセラレーターを接続する。多数のGPUが、互いを待つ時間を過度に費やすことなく共有モデル上で動作できるだけの速さでデータを移動させなければならない。
HPEのスイッチは、一般にUALoEと略されるEthernet上のUALinkを使用する。このアーキテクチャは、垂直統合されたインターコネクトに依存するのではなく、Ethernetベースのネットワークを通じてUALinkトラフィックを伝送する。
HPEによれば、6基のスイッチトレイは高帯域幅・低レイテンシーのリンクで全GPUを接続する。この主張には、本番環境での検証が必要になる。ネットワーク性能はワークロード構造、通信パターン、ソフトウェア構成によって変化するためだ。
両社はVultrが発注したラック数を明らかにしていない。また、完全な納入スケジュールも、コンピュート、ネットワーク、冷却、ソフトウェア、サービスの各構成要素の内訳も示していない。
こうした非開示により、GPUまたはラックあたりのコストを単純に計算することは難しい。また、契約のどの程度がハードウェアで、どの程度が長期的な運用支援なのかを外部の観測者が推定することも妨げられる。
それでも、この取引は実在する顧客と意味のある導入目標を確立した。これが本質的な変化だ。HPEはもはや、Heliosがいずれ買い手を引き付けると主張する必要がない。
Vultrは、企業向けおよびAIワークロード向けのクラウドインフラをすでに運用している。専門的なデータセンターを所有せずに、モデル学習、ファインチューニング、大規模推論を必要とする顧客へシステムを提供できる。
HPEは、AMDアクセラレーターを理解する顧客も得ることになる。Vultrは以前からAMD Instinctシステムを採用しており、新たなAMD世代を追加する際の組織的な摩擦を抑えられる。
したがってこの発注は、実験室ベンチマークやリファレンスデザイン以上の重みを持つ。Heliosを商用クラウドに投入し、その成否を稼働率、可用性、顧客需要が決めることになる。
HPEに必要なのはGPU販売だけではない
HPEはAMD Helios AIラックを、単なるサーバーシャーシではなく、アクセラレーターを取り巻くインフラストラクチャを巡って競争するために活用している。
AIインフラ市場では、部品の寄せ集めではなく、機能するラックを提供できるサプライヤーがますます有利になっている。高密度アクセラレータークラスターには、電力、冷却、ネットワーク、ファームウェア、ソフトウェア、監視、保守の連携が求められる。
顧客は高性能チップを購入しても、クラスターの利用率が低いという問題に直面し得る。遅延はしばしば、ネットワーク混雑、不安定なソフトウェア、熱的制約、あるいは診断に時間がかかる障害から生じる。
HPEの役割は、Vultrが繰り返し導入できるシステムとして、これらの要素をパッケージ化することだ。これにより同社は、従来であれば個別のサーバー、スイッチ、冷却、統合ベンダーに流れていた支出を獲得する機会を得る。
ネットワークコンポーネントは特に重要だ。HPEは2025年にJuniper Networksの買収を完了し、スイッチング技術とエンジニアリング人材をインフラポートフォリオに加えた。
Heliosは、この統合戦略にとって初期の試金石となる。各HPEシステムには6基のJuniperスイッチトレイが収められ、ネットワークはラックの中核設計の一部となっている。
HPEの投資家向けイベントでの説明では、この取引は標準ベースのEthernetがスケールアップ層へ進出する例として紹介された。同じネットワーク分析では、HPEが契約に占めるネットワークの比率を開示していないことも指摘された。
HPEは投資家に対し、今後2年間でHelios関連ネットワークに10億ドル超の機会があると見込んでいると述べた。また、ネットワークトレイの受注はすでに2億ドルを超えたとしている。
これらの数値は会社予測であり、完了済みの顧客導入を示す証拠ではない。それでも、HPEがHeliosを追加的なサーバー製品以上のものとして扱う理由を明確にしている。
同社は、ラック内のアクセラレーター間トラフィックを自社のネットワーク機器で処理したい考えだ。分散AIジョブは多数のデバイス間で大容量テンソルを交換するため、これは要求の厳しいワークロードである。
この層でのレイテンシーや混雑は、高価なアクセラレーターを遊休状態にしてしまう可能性がある。脆弱なファブリックは、より高速なGPUや大容量メモリープールが約束する利点を失わせかねない。
したがってVultrの導入は、AMDのシリコンと同程度にHPEの統合能力を試すことになる。HPEは、スイッチ、冷却システム、サービス、ラック設計が1つの信頼できる製品として機能することを示さなければならない。
また、そのシステムを複数のクラウド施設にわたって管理可能にする必要もある。大規模に構成を繰り返すには、一貫した設置、テレメトリー、障害対応、スペアパーツの手順が必要だ。
直接液冷は、さらに別の運用要件を加える。この技術は高電力部品の近くで冷却液を通じて熱を移動させ、従来の空冷では支えにくい密度を可能にする。
ただし、液冷は施設設計と保守にも影響する。運用者には、対応する配管、排熱設備、漏れ管理、訓練を受けた技術者、部品交換の手順が必要となる。
HPEは、自社のサービス組織がこうした導入・運用リスクを低減するとしている。Vultrの実際の展開は、その約束が異なる施設や本番スケジュールの現実に耐えられるかを示すだろう。
HPEにとって成功は、コンピュートとJuniperネットワークを組み合わせる論理を裏付けることになる。失敗すれば、ネットワーク資産の取得が自動的に競争力のあるラックスケールAIプラットフォームを生み出すわけではないことを示唆する。
オープンEthernetこそNvidiaに対する真の賭け
主な競争は、オープンでマルチベンダーのEthernetスタックと、Nvidiaが緊密に統合したラックスケールアーキテクチャの間で行われる。
Nvidiaは、アクセラレーター性能だけでAIインフラの地位を築いたわけではない。CUDAソフトウェア、NVLinkインターコネクト、ネットワーク製品、リファレンスデザイン、開発者の習熟度は、相互に強化し合っている。
Vera Rubin NVL72は、このモデルを72 GPUラックへと拡張する。Nvidiaが公開したNVL72の仕様は、72基のRubin GPU、36基のVera CPU、第6世代NVLinkを組み合わせている。
AMD Heliosは、異なるサプライヤー構成で同じラックスケールのカテゴリーを狙う。AMDはアクセラレーター、ホストプロセッサー、ネットワークインターフェース技術、ROCmを提供する。HPEは統合、サービス、冷却、Juniperスイッチングを供給する。
Broadcomは、HPEのスケールアップ設計で使用されるスイッチ技術を提供する。Open Compute Projectのラック仕様、UALink、Ethernet標準は、追加のベンダーが採用できるインターフェースを生み出す。
ここでの主張は、Heliosに統合性が欠けているというものではない。統合には、1社のベンダーがあらゆる重要レイヤーを支配する必要はない、ということだ。
AMDが公開したHeliosの仕様には、72基のMI455X GPU、31テラバイトのHBM4メモリー、毎秒260テラバイトの総スケールアップ帯域幅が記載されている。HBM4は、モデルデータへ高速にアクセスするためGPU近くに配置される高帯域幅メモリーだ。
AMDはまた、FP4でピーク時2.9エクサフロップス、FP8で1.4エクサフロップスの性能を掲げている。FP4とFP8は、少ないメモリーとエネルギーでAIスループットを高めるために設計された低精度数値フォーマットだ。
ピーク値はアプリケーション性能に直接変換されるものではない。ベンダーごとに、異なるデータ形式、スパース性の前提、ソフトウェア設定、ワークロード条件を用いる可能性がある。
そのため、MI455XとVera Rubinの比較は、2つの数値を照合するほど単純ではない。購入者には、実際のモデル、バッチサイズ、コンテキスト長、ネットワークパターン、サービスレベル要件に基づく結果が必要となる。
メモリー容量は、AMDに明確なマーケティング上の訴求点を与える。Heliosは、ラックレベルで31テラバイトのHBM4を備えるよう設計されており、データを過度に分割せずに大規模モデルと長文コンテキスト推論を支援する。
Nvidiaは、ソフトウェアの成熟度と統合ネットワークで対抗する。同社のCUDAエコシステムは、AIフレームワーク、最適化ライブラリー、デプロイメントシステム、エンジニアリング慣行に深く浸透している。
ROCmは大きく改善してきたが、採用は単にモデルをコンパイルするだけでは済まない。本番チームには、安定したカーネル、監視、オーケストレーション、セキュリティ制御、頻繁なフレームワーク更新をまたぐ予測可能な性能が必要だ。
ここでVultrは戦略的に有用な存在となる。クラウドプロバイダーは統合の複雑さの一部を引き受け、顧客に生のコンポーネントではなく管理されたインフラを提供できる。
Vultrが信頼できるインスタンスやリザーブドクラスターを提供すれば、顧客は基盤となるファブリックをそれほど意識しないかもしれない。このアプローチは、ROCmや分散システムの専門家を欠くチームにもAMDハードウェアを利用しやすくできる。
ただし、クラウドで利用可能になるだけでソフトウェア上の差異が解消されるわけではない。顧客は引き続き、モデル互換性、開発者の工数、コスト当たりの性能、安定した本番運用に至るまでの時間を比較することになる。
VultrによるAMD Helios発注は、このオープンなアプローチを評価するための本格的な舞台を与える。システムが導入され、測定される前に勝者を決めるものではない。
仕様だけではMI455X対Vera Rubinの優劣は決まらない
両社は印象的なピーク性能の数値を示しているが、クラウドの購入者が最終的に支払うのは、完了したワークロード、実用可能な容量、そして予測可能な運用に対してである。
AMDは、Heliosが兆パラメータ規模の学習と大量推論をサポートするとしている。その設計は、メモリ容量、オープン標準、ラック内およびラック間のEthernetベースの接続性を重視している。
NvidiaはVera Rubinを、エージェント型推論、学習効率、トークン処理能力を中心に位置付けている。同社によれば、このプラットフォームはCPU、GPU、DPU、ネットワークインターフェース、スイッチングを、一体設計された単一のシステムとして組み合わせる。
これらの主張は、ベンダーが選定したワークロードと手法に基づくものだ。製品の優先事項を理解するうえでは有用だが、独立したベンチマークの代わりにはならない。
独立系の技術レビューは、MI455XをNvidiaに対するAMDの最も信頼性の高いラックスケールの対抗策と評した。また、Heliosが72基のGPUを一つの一貫したドメインに統合する重要性も強調している。
この比較には依然として大きな未知数がある。その一つが実現利用率であり、アプリケーションがシステムの理論上の計算能力をどれだけ一貫して活用できるかを測る指標だ。
もう一つは、集合通信の性能である。学習ジョブではGPU間で部分的な結果を頻繁に交換するため、同期が遅いとクラスター全体の出力を低下させる可能性がある。
推論では異なる負荷が生じる。長いコンテキスト、大規模なmixture-of-expertsモデル、多数の同時リクエストは、メモリ容量、メモリ帯域幅、ルーティング、スケジューリングに負荷をかける。
三つ目の未知数は、ソフトウェア移行に必要な作業量だ。Nvidiaシステム上で開発されたモデルは、CUDA固有のライブラリ、カーネル、運用ツールに依存している場合がある。
ROCmはPyTorch、TensorFlow、JAXを含む主要フレームワークをサポートしている。フレームワークレベルでの互換性は、最適化された本番パイプラインのすべてで同一の挙動を保証するものではない。
開発者はカーネルの変更、通信設定の調整、依存関係の置き換えを必要とする可能性がある。チームが厳しい導入期限に直面している場合、こうしたコストはハードウェアの節約分を上回り得る。
Vultrは、検証済み構成、最適化済みコンテナ、モデルレシピ、実測性能を公開することで、その負担を軽減できる。また、ラックを直接運用することで得た知見に基づく技術サポートも提供できる。
クラウドプロバイダーには、その作業を行う動機がある。実用的なアクセラレータ供給を拡大すれば、特定ベンダーへの依存を減らし、顧客に追加の容量選択肢を提供できる。
ただし、容量は予定どおりに提供されなければならない。HPEとVultrは詳細な導入スケジュールを開示していない一方、AMDはHeliosの出荷が2026年後半から2027年にかけて拡大すると説明している。
大規模な発注には、購入コミットメント、納入期間、サービス、将来の容量が含まれ得る。見出しに示された金額は、すべてのハードウェアがすでに設置済み、または顧客に提供可能であることを証明するものではない。
製造と導入のリスクは依然として大きい。MI455Xアクセラレータには先進パッケージングとHBM4が必要となる。Heliosラックもまた、新しいCPU、ネットワーク部品、スイッチトレイ、冷却設備、施設側の準備に依存している。
重要な部品のいずれかが遅延すれば、システム全体の展開が遅れる可能性がある。ラックスケール製品では、購入者が必要とするのは代替部品ではなく統合構成であるため、依存関係が集中する。
電力供給も別の制約となる。高密度AIラックには大規模な電力・冷却インフラが必要であり、既存データセンターに常に迅速に追加できるとは限らない。
したがって、MI455X対Vera Rubinの実際の結果は、発表スライドではなく導入実績から明らかになる。有用な比較には、同等条件下での稼働率、消費電力、モデル処理能力、レイテンシー、総運用コストを報告する必要がある。
Vultrは容量だけでなく交渉力も獲得している
Vultrのコミットメントにより、同社は新たなアクセラレータプラットフォームを得ると同時に、チップベンダーとエンタープライズAI顧客の間における立場を強化する。
クラウドプロバイダーは難しい均衡に直面している。希少なハードウェアを早期に確保しなければならない一方、顧客需要が予測可能になる前にシステムへ資本を固定するリスクも負う。
Vultrの発注は、顧客が学習と推論でAMDの容量を利用するという確信を示している。同社は、高性能AIインフラへの需要が引き続き利用可能な供給を上回っているとしている。
この発言はVultrの商業的な見解を反映したものであり、開示された利用率データによる独立検証は行われていない。同社は、顧客別またはワークロード別の将来のHelios需要を測定できるほど十分な詳細を公開していない。
それでも、戦略的な論理は明確だ。NvidiaとAMDの双方をサポートすれば、Vultrは一つのアクセラレータファミリーを中心に構築されたクラウドよりも多くの選択肢を提供できる。
この柔軟性は、ハードウェアの可用性、サプライヤーの集中、ソフトウェアの可搬性を懸念する企業に訴求し得る。また、より大きなメモリプールの恩恵を受けるワークロードを持つチームも引き付けられる可能性がある。
複数のアクセラレータプラットフォームが顧客ニーズに対応できれば、Vultrは交渉力を得る。同社は、単一サプライヤーの生産スケジュールや商業条件への依存を減らせる。
AMDはMI455Xの目立つクラウドチャネルを得る。HPEは初の統合Helios顧客を得る。Juniperの機器はアクセラレータ規模のネットワーク内で役割を得る。
この取り決めはVultrに差別化された製品ももたらす。より大規模なハイパースケーラーは幅広いポートフォリオを提供するが、独立系AIクラウドは、早期のハードウェアアクセス、重点的なサポート、地理的な選択肢を通じて競争できる。
その機会には集中リスクも伴う。この発注は多くの民間クラウドインフラ取引と比べて大規模であり、Vultrは導入済みハードウェアを持続的な顧客利用へ転換しなければならない。
予約容量のコミットメントがあれば、その根拠は強まる。顧客がNvidiaシステムから大規模モデルをHeliosへ、長期の再開発なしに移行したことを示す公開事例も同様だ。
低利用率は逆の結果を生む。高価なラックは、顧客ジョブによって十分に稼働していなくても資本を消費する。
Vultrは、性能可搬性に関する顧客の期待も管理しなければならない。両プラットフォームで正しく動作するモデルでも、処理能力、レイテンシー、コストの特性は異なり得る。
クラウドプロバイダーは、ワークロード固有の証拠を示すことで支援できる。汎用的なアクセラレータ比較よりも、モデル学習、長コンテキスト推論、ファインチューニング、エージェント型ワークロードに関する測定結果の方が有用だ。
顧客はサービスの可用性にも注目すべきだ。一部の施設に限定された少数の専門クラスターは、Vultrのクラウド全体に標準化されたHelios容量が提供される場合より、競争上の重みが小さい。
エンタープライズの購入者は、レイテンシー、データレジデンシー、災害復旧、保存済みデータセットへの近接性を考慮するため、地理的な展開は重要となる。HPEは、システムが米国内の拠点に導入されると述べたにとどまる。
この発表では契約構造も不明確なままだ。両社は、納入マイルストーン、解約条項、最低購入量、サービスに紐づく部分を開示していない。
こうした詳細は、各当事者がどれほどのリスクを負うかに影響する。確定したハードウェア購入は、将来の容量要件に左右される複数年の枠組み契約とは異なる。
したがって、VultrによるAMD Heliosの発注は強い需要シグナルではあるが、導入完了と同義ではない。顧客が大規模にシステムへアクセスできるようになるまで、この区別は明確にしておくべきだ。
Heliosが市場に浸透できるかを示す三つのシグナル
この発注が競争市場を変えるかどうかは、導入時期、本番ワークロードの結果、より広範な顧客採用によって決まる。
第一のシグナルは物理的な導入だ。HPEとVultrは、Helios容量がいつ稼働可能になるのか、顧客がどこで利用できるのかを明らかにする必要がある。
本番環境への展開が確認されれば、AMDとHPEが新しいラックスケールプラットフォームを予定どおりに製造、統合、設置できるという主張を強化する。度重なる遅延はその主張を弱めるだろう。
可用性はプレスリリースだけにとどまるべきではない。Vultrは、対象顧客向けにサービス提供地域、予約オプション、構成の詳細、見込まれる容量を公開すべきだ。
第二のシグナルはワークロードの証拠である。独立した、または顧客により検証されたベンチマークは、同一条件下でHeliosを関連するNvidiaシステムと比較する必要がある。
有用な結果には、毎秒トークン数、学習完了時間、消費電力、モデルサイズ、コンテキスト長、バッチサイズ、ソフトウェアバージョンが含まれる。また、チューニングに必要な作業も報告すべきだ。
この証拠は、学習と推論の両方を対象にする必要がある。あるプラットフォームは一方の分野では優れた性能を示す一方、別の分野では通信、レイテンシー、ソフトウェアサポートに苦戦する可能性がある。
運用データも重要だ。顧客には、稼働率、コンポーネント障害からの復旧、クラスターのスケジューリング、保守が性能に与える影響についての情報が必要である。
強い結果は、オープン標準が競争力のあるラックスケール性能を実現できるというAMDの立場を支持する。弱い結果、または限定的に選ばれた結果であれば、Nvidiaの統合面での優位性が維持される。
第三のシグナルは後続の採用だ。HPEには追加のHelios顧客が必要であり、AMDには既にコミットしたパートナーを超える導入実績が必要となる。
他のクラウドプロバイダー、企業、研究機関、国家計算プログラムからの発注は、このアーキテクチャが複数の購入者タイプに訴求することを示すだろう。
Vultrからの追加購入はさらに示唆的だ。本番利用後の二度目の拡張は、顧客需要と運用経済性が期待に応えたことを示す可能性がある。
Nvidiaの対応にも注目すべきだ。同社は、Rubinの導入加速、ソフトウェアの改善、積極的なクラウド提携、より強力なEthernet提供を通じて自社の立場を守ることができる。
HPEとAMDがHeliosを正当化するために、市場全体でNvidiaを置き換える必要はない。オープン性、メモリ、可用性、サプライヤーの多様性に十分な価値があるワークロードに対し、信頼できる代替手段を確立する必要がある。
開発者とエンタープライズの購入者にとって、直近の行動は、ピーク仕様を購入判断とみなさないことだ。意図するモデルと運用環境に合致する測定結果をプロバイダーに求めるべきである。
ソフトウェア移行、検証済みフレームワーク、クラスターの可用性、サービスコミットメント、障害復旧に関する詳細を要求する。本番稼働に到達するために必要なエンジニアリング作業を、アクセラレータの処理能力だけでなく比較するべきだ。
VultrによるAMD Heliosの発注は、信頼できる商業的テストを生み出した。今、業界に必要なのは、野心的なアーキテクチャと信頼できるクラウドプラットフォームを切り分ける導入の証拠である。
