HeliosがNvidiaに挑む中、AMDとGoogle Cloudの競争が激化

AMDは初の完全なラックスケールAIプラットフォームを発表し、AMDとGoogleをめぐる議論を、データセンターアーキテクチャの主導権を誰が握るかという直接対決へと変えた。

Heliosシステムは、72基のInstinct MI455Xアクセラレータ、18基のEPYCプロセッサ、Pensandoネットワーキング、AMDのROCmソフトウェア環境を組み合わせる。AMDは2026年7月23日、Advancing AIイベントでこの量産設計を披露した。

この発表は、AMDの市場における立ち位置を変える。同社はもはや、顧客が他社のネットワーキングやソフトウェアを中心に組み立てなければならないコンポーネント群をハイパースケーラーに提供するだけではない。Heliosは、NvidiaのNVL72システムや、Googleのtensor processing unitsを支える垂直統合型インフラと競合する、統合されたラックをAMDにもたらす。

主要な仕様は大規模だ。Heliosラックは、アクセラレータ全体で約31テラバイトのHBM4、すなわち第4世代の広帯域メモリを搭載する。AMDは、AI推論で一般的に用いられる低精度形式であるFP4で、ピーク時2.9エクサフロップスの演算性能を掲げている。

ただし、これらの数値だけで競争の行方が決まるわけではない。Nvidiaは依然として、より強力な開発者環境、より大きな導入基盤、確立されたラックスケール導入モデルを持つ。Googleは自社モデル、クラウドプラットフォーム、ネットワーキング、独自TPUロードマップを管理している。

AMDの方向転換は、より具体的だ。同社は代替アクセラレータの販売から、代替となるデータセンター設計の提案へと進んだ。顧客は今、オープンでマルチベンダーなラックが、厳格に管理されたプラットフォームの運用上の利点を上回るかどうかを判断する必要がある。

AMDとGoogle Cloudの競争は個別チップの先へ進む

Heliosの発表により、個別アクセラレータではなく完全なラックが、AMDにとって競争の主要単位となった。

現代のAIクラスターは、高速GPUを従来型サーバーに搭載するだけでは実用的な性能を発揮できない。数百から数千のアクセラレータが、モデルパラメータ、アクティベーション、キャッシュ済みデータを一貫して低いレイテンシーで交換する必要がある。

ラックスケールアーキテクチャは、キャビネット全体を1つの連携したコンピューティングシステムとして扱う。コンピュートトレイ、ホストプロセッサ、メモリ、冷却、配電、スイッチ、ソフトウェアが一体で設計される。

AMDのHelios platformは、Ethernet経由のUALinkで接続された72基のInstinct MI455X GPUを採用する。UALinkは、複数ベンダーのアクセラレータ間に高速通信を提供することを目的とした、業界支援のインターコネクトだ。

AMDが公表した仕様によると、各MI455Xには432 GBのHBM4と、最大毎秒23.3テラバイトのメモリ帯域幅が搭載される。HBMはスタックされたメモリをプロセッサの近くに配置し、モデルデータ移動に伴う遅延を抑える。

ラックには18基のEPYC「Venice」CPUとPensando Vulcanoネットワークインターフェースも含まれる。外部へのスケールアウトネットワーキングには、大規模なAIおよびハイパフォーマンスコンピューティングクラスター向けに設計されたオープン仕様、Ultra Ethernetを用いる。

こうした詳細が重要なのは、データ移動がAIの実効性能をますます左右しているためだ。プロセッサは莫大なピークスループットをうたえても、稼働時間の一部をメモリや別のアクセラレータ待ちに費やす可能性がある。

より大きなメモリプールにより、システムはより多くのモデル重みとキー・バリューキャッシュデータをプロセッサ近くに保持できる。キー・バリューキャッシュは推論中に生成された情報を保存し、モデルがトークンごとに会話全体を再計算しないようにする。

この機能は、長いプロンプト、コーディングエージェント、リサーチシステム、回答を返す前に複数の候補を生成するモデルで重要になる。こうしたワークロードは、基盤となるモデルが変わらなくても、急速にメモリを消費しうる。

したがって、AMDとGoogleの比較はGPU性能だけにとどまらない。GoogleのTPUシステムは、Googleのクラウドおよびモデル開発環境に最適化されたカスタムアクセラレータ、独自インターコネクト、ソフトウェアを使用する。

Googleはそれらを管理しているため、各層を一体で最適化できる。一方AMDは、顧客がサーバーメーカー、ネットワーキングサプライヤー、クラウドプラットフォーム、ソフトウェアフレームワークの選択肢を維持しながら、同等のシステム連携を得られると主張する。

Google Cloudは、Heliosを中核アクセラレータプラットフォームとして発表していない。同社の2026 infrastructure roadmapは、Google TPU、Nvidiaシステム、AMDおよびIntel CPUを使用する汎用仮想マシンを強調している。

この区別は明確にしておくべきだ。GoogleはAMDのより広範なインフラ環境に参加しているが、Heliosは現時点でGoogle CloudのAIアクセラレータ戦略の基盤ではない。

関連する圧力は、顧客の期待から生じる。AMDがオープンなラックスケールシステムを効率的に運用できると証明すれば、購入者はあらゆるクラウドプロバイダーに同様の柔軟性を求めるかもしれない。

AMD Heliosの解説を探す開発者にとって、最も簡潔な答えは、AMDがキャビネット、ネットワーク、プロセッサ、ソフトウェアを導入可能な1つの設計にまとめたということだ。より難しい問いは、事業者が慎重に選ばれたデモンストレーションの外でも、約束された性能を実現できるかどうかである。

HeliosはAMDをシステム競争の担い手へ変える

AMDにとって最も重要な変化は組織面にある。同社はもはや競争力あるシリコンだけでなく、AIインフラ向けの完全な運用システムを提供しなければならない。

AMDは主にEPYCサーバープロセッサを通じて、データセンターでの地位を築いてきた。その後、InstinctアクセラレータがクラウドプロバイダーにAIコンピューティングの第二の供給源を提供した。特に、需要が利用可能なNvidiaの供給能力を上回った局面でそうだった。

HeliosはAMDをスタックのさらに上位へ押し上げる。AMDは、プロセッサ設計、アクセラレータパッケージング、ネットワーキング、ファームウェア、コンパイラ、ライブラリ、クラスター管理、冷却、保守性を調整しなければならない。

このモデルは、NvidiaがDGXおよびNVLラックシステムで採った手法に似ている。NvidiaはGPUをNVLink、ネットワーキング、CUDAライブラリ、リファレンスシステム、導入ガイダンスと組み合わせることで、チップサプライヤーからデータセンタープラットフォーム企業へと変貌した。

AMDは異なるガバナンスを通じて同じ成果を追求している。同社はROCmをオープンなソフトウェア環境として推進し、HeliosをOpen Compute Projectのハードウェア仕様に基づいて構築している。

Open Compute Projectは、メーカーや事業者が適応できるデータセンター設計を公開している。このアプローチは1社のサプライヤーへの依存を減らしうるが、「オープン」が自動的に互換性や運用の容易さを意味するわけではない。

AMDは、ほかのチップおよび機器企業が支援するネットワーキング規格も使用する。これにより、OEMは市販スイッチや自社の管理ツールを組み込む余地を得る。

実務上の利点は交渉力だ。クラウドプロバイダーは、周辺のすべての層をAMDに委ねることなく、AMDアクセラレータを採用できる。

それに対応する負担は統合にある。独自システムが故障した場合、問題の診断責任はプラットフォーム所有者により明確にある。オープンなシステムでは、その責任がアクセラレータベンダー、スイッチサプライヤー、サーバーメーカー、ソフトウェアチーム、クラウド事業者に分散する可能性がある。

AMDは、試験導入を超える顧客コミットメントによってこの懸念に対応している。Metaは、複数のハードウェア世代にわたり最大6ギガワットのAMD Instinct容量を導入することに合意した。

AMDのMeta deploymentによると、Metaの最初の1ギガワットを支える出荷は2026年後半に始まる予定だった。初期導入では、カスタマイズされたMI450ファミリーのアクセラレータ、Venice CPU、Heliosアーキテクチャ、ROCmソフトウェアを使用する。

Anthropicは別途、HeliosシステムにMI450シリーズGPUを最大2ギガワット導入することを約束している。最初の1ギガワットは2027年前半に導入を開始する予定だ。

このAnthropic agreementは、Anthropicが最先端モデルを訓練・提供している点で特に意味がある。そのワークロードは、メモリ管理、集団通信、コンパイラの挙動、大規模クラスターの信頼性における弱点を明らかにするはずだ。

MicrosoftもAzureを通じてHeliosを導入すると述べている。Cerebrasは、Heliosシステムを自社データセンターに配置し、ウェハースケール推論技術と組み合わせる計画だ。

これらのコミットメントは、AMD Helios解説をめぐる1つの疑問に答えている。Heliosは、顧客を待つだけのリファレンス図ではない。複数の大規模事業者が、これに導入計画を結び付けている。

ただし、それらの導入が予定どおりのスケジュール、稼働率、経済性に到達するかどうかには答えていない。ギガワット単位のコミットメントは、提供可能性のあるインフラ規模を示すものであり、実際に提供された演算能力ではない。

大規模AIクラスターの構築には、電力供給、冷却設備、建設、ネットワーキング、メモリ供給、動作するソフトウェアが必要となる。1つの部品の遅延だけでも、名目上利用可能なアクセラレータが課金可能なトークンを生み出せない事態につながりうる。

その結果、AMDはより要求の厳しい事業に参入した。同社の成功は、個別チップの出荷ではなく、完全なクラスターの提供とワークロード性能にかかっている。

AMD対NvidiaのAI競争はラックレベルの戦いになった

Heliosは、Nvidia最大の強みであるアクセラレーテッドコンピューティングスタック全体への支配力を直接攻撃するため、Nvidiaが依然として最大の対抗相手である。

Nvidiaの優位性は、GPUコンピューティング向けプログラミングプラットフォームであるCUDAから始まる。CUDAには、開発者が長年使用してきたコンパイラ、ライブラリ、デバッグツール、最適化カーネルが含まれる。

その結果生まれたソフトウェア基盤は、乗り換えコストを生む。一般的なフレームワークで書かれたモデルは技術的には異なるアクセラレータで動作するかもしれないが、カスタム操作や導入ツールは依然としてNvidiaのソフトウェアに依存しうる。

ROCmは主要なAIフレームワークをサポートし、連続するリリースで改善されてきた。AMDは、トレーニング、推論、通信、モデル提供向けの移行ツールや最適化ライブラリも公開している。

ソフトウェアの同等性は、依然としてワークロードごとに異なる。標準ベンチマークでは良好に動作しても、社内の本番モデルでは、未対応の操作、不安定なカーネル、より遅いコンパイルに遭遇する可能性がある。

だからこそ、AMD対NvidiaのAI論争は1つのピーク性能値だけでは決着しない。購入者には、モデル精度、トークンスループット、レイテンシー、消費電力、運用者の工数、クラスター可用性を網羅する測定が必要だ。

Heliosはいくつかの物理的な側面で競争力を示している。72基のMI455Xアクセラレータは約31 TBのHBM4を提供し、ラックに大規模なローカルメモリプールを与える。

AMDは、MI455Xがデバイスあたりピーク40.3ペタフロップスのFP4性能を実現すると主張している。この数値を72基のアクセラレータに掛け合わせると、Heliosでうたわれる2.9エクサフロップスとなる。

Nvidiaは、72 GPU構成のVera Rubin NVL72について、より高いラックレベルFP4性能値を公表している。これらの主張を独自に検証した結果、ベンダーが公表した測定値では、AMDのGPU単位での優位性はより高いラック合計には結び付かなかった。

このrack comparisonは、繰り返し見られるベンチマーク上の問題を示している。ベンダーは、デバイスレベルまたはシステムレベルの分母、異なる数値形式、都合のよいワークロード前提を選べる。

ピーク理論演算性能には、通信の停止時間やソフトウェアのオーバーヘッドも含まれない。公称の演算性能が低いシステムでも、ソフトウェアとネットワークによってより多くのプロセッサを稼働させ続けられれば、モデル実行をより早く完了できる。

したがって、Nvidiaの優位性は生のスループットにとどまらない。同社のシステムは、確立された導入パターン、経験豊富な運用担当者、商用AIソフトウェアにおける広範なサポートを備えて提供される。

AMDの反論は、メモリ、標準、そして顧客のコントロールに焦点を置く。Heliosは、あらゆるインターフェースを単一の独自サプライヤーに依存させることなく、統合システムを購入者に提供する。

これは説得力のある違いだが、無償で得られる利点ではない。オープン標準では、多くの場合、複数のベンダーが足並みをそろえて互換製品を投入する必要がある。

Nvidiaは、プロセッサ、リンク、スイッチ、ソフトウェアライブラリを単一のロードマップの一部として変更できる。AMDはUALink、Ultra Ethernet、サーバーメーカー、スイッチベンダー、メモリサプライヤー、クラウド事業者を調整しなければならない。

AMDとNvidiaのAI競争は、実行面での規律によっても決まる。AMDには、パートナーが仕様を再現可能な導入環境へと落とし込むことが必要であり、Nvidiaには、統合アプローチがより強いプラットフォーム統制を正当化することを示す必要がある。

Googleは別の競争経路を加える。同社のTPUインフラは、あらゆるクラウドが導入できる商用GPUプラットフォームの構築を目指してはいない。Googleは主として、自社クラウドサービスと社内AIワークロード向けにカスタムシステムを構築している。

これによりGoogleは、モデル研究者、コンパイラチーム、チップ設計者、データセンター技術者の間に、極めて直接的なフィードバックループを持つ。提供を見込むワークロードパターンに合わせてハードウェアを最適化できる。

ただし、TPUを選ぶ顧客はGoogle Cloudとのより密接な関係を受け入れることになる。同じワークロードを別の場所へ移すには、異なるハードウェア前提、ソフトウェアチューニング、運用慣行が必要になる可能性がある。

したがってAMDとGoogleをめぐる論点は、単にどのプロセッサが速いかではない。購入者が、クラウド固有の垂直統合スタックを好むのか、それともオープンなインターフェースを中心に構築された移植可能なインフラを好むのかを問うものだ。

Nvidiaは第三の立場を占める。同社は複数のクラウドにまたがる高度統合プラットフォームを販売し、アクセラレータ環境をNvidiaに密接に結び付けたまま、CUDAをプロバイダー間で移植可能にしている。

AMDはこの三方向の課題を打開しなければならない。Nvidiaのように動作するだけの統合性、Nvidiaとの差別化に足るオープン性、そしてGoogleのインフラ到達範囲と競争できるだけのクラウド提供体制が求められる。

仕様にはなお量産での実証が必要

HeliosはAMDにとってこれまでで最も強力なデータセンター設計だが、その決定的な主張の多くは、持続的な量産結果ではなく、依然としてエンジニアリング上の予測にとどまる。

AMDの製品ページは、MI455Xをピーク理論スループットと社内エンジニアリング推定値で説明している。これらの数値は有用な上限を示すが、顧客が大規模モデルをその上限で運用することはほとんどない。

本番システムでは、電力制約、ネットワーク混雑、コンポーネント故障、チェックポイント作成、ソフトウェア更新、不均一なリクエストパターンに直面する。こうした要因が、購入した演算能力のうちどれだけが有効な仕事に変わるかを左右する。

Heliosは直接液冷にも依存する。液冷は従来の空冷システムより効率的に熱を除去するが、互換性のある設備、分配ユニット、監視、保守手順を必要とする。

多くの大規模事業者は、すでに高密度AIクラスターに液冷を採用している。一方、従来型のサーバールームを持つ企業は、より大規模なインフラ変更に直面する可能性がある。

保守性も別の試験となる。Heliosの設計では72基のアクセラレータを再現可能な4 GPUトレイに分割しており、技術者はラック全体を再構築せずにコンポーネントを交換できるはずだ。

実際の修理時間は、障害の切り分けと予備部品の入手性に左右される。運用者には、性能低下がGPU、ケーブル、スイッチ、ファームウェア層、あるいは集団通信ライブラリのどこに起因するかを特定できるテレメトリーが必要だ。

メモリ供給も不確実性を加える。Heliosの各ラックには31 TBのHBM4が搭載され、ハイパースケール事業者のコミットメントは、大量の先進メモリとパッケージングへの需要を示唆する。

AMDは外部の製造・メモリパートナーに依存している。パッケージング歩留まりやHBM出荷が完成システムを制約すれば、優れたアクセラレータ設計でも導入目標を達成できない。

同社の主要顧客との契約には、将来を見据えたスケジュールも含まれる。Metaの最初の導入は2026年後半に始まり、Anthropicの導入は2027年前半に開始する。

こうした予定は、現時点で公開されている量産実績を限られたものにする。顧客は、発表済み容量、設置済み容量、受け入れ済みシステム、実トラフィックを処理するアクセラレータを区別すべきだ。

ベンチマークの開示も同様に重要となる。AMDは、定義された条件下でトレーニングと推論を測定する業界ベンチマークスイート、MLPerfに参加している。

今後のMI455Xの結果には、サーバー構成、ソフトウェアバージョン、電力設定、精度目標、可用性クラスを含めるべきだ。単独の企業チャートよりも、比較可能な提出結果のほうが重要である。

標準化されたベンチマークであっても、すべての本番ワークロードを再現することはできない。長いコンテキストでの推論、スパースなMixture-of-Expertsモデル、強化学習、エージェント型システムでは、通信・メモリのパターンが異なる。

Mixture-of-Expertsモデルは、すべてのパラメータを使用するのではなく、各入力に対して選択されたパラメータ群を活性化する。これにより演算要件を減らせる一方で、ルーティングと通信の複雑さは増す可能性がある。

AMDは以前、こうしたモデルでMI400ファミリーのシステムが大幅な性能向上を実現すると予測していた。購入者は、独立したテストで再現されるまでは、その向上をワークロード依存のものとして扱うべきだ。

ROCmはもう一つの中心的な不確実性を示す。企業はカスタムカーネルや社内デプロイメントシステムを維持していることが多いため、ソフトウェアの成熟度をサポート対象フレームワークの数だけで要約することはできない。

移行コストには、コード変更、検証、監視の更新、スタッフ研修、移行中の並行稼働容量が含まれる。エンジニアリングチームが本番パイプラインの修復に数カ月を費やせば、低いハードウェアコストの利点は失われかねない。

そのため、AMD Heliosの説明資料を評価する開発者は、アクセラレータ仕様だけでなくソフトウェア部品表も確認すべきだ。必要なのは、対応フレームワークのバージョン、カーネルのカバレッジ、通信ライブラリ、可観測性ツール、エスカレーション手順である。

GoogleとNvidiaはいずれも成熟した運用ループの恩恵を受けている。Googleは社内サービスに照らしてインフラを調整し、Nvidiaは大規模な開発者基盤とクラウドパートナーからフィードバックを得る。

AMDはいま、同様のループを構築するのに必要な顧客を得ている。Meta、Microsoft、Anthropic、Oracle、Cerebrasは、それぞれ異なるワークロードを代表し、異なるプラットフォームの弱点を明らかにできる。

最も強いシグナルは、別のパートナーシップ発表ではない。これらの顧客が最初のシステムを運用した後に導入を拡大したという証拠である。

この区別は分析を現実に即したものに保つ。Heliosは、AMDが本格的なラックスケールの競合製品を設計できることを示している。しかし、同社がそれらのラックを同等の量産効率で提供・サポートできることは、まだ示されていない。

AMDとGoogleの競争が次に明らかにすること

Heliosが持続的なプラットフォームになるのか、それとも選ばれた顧客にとって有用な第2調達先にとどまるのかは、短期的な3つのシグナルによって決まる。

第1のシグナルは、2026年後半における初期量産の立ち上がりだ。AMDとそのパートナーは、完成システムを出荷し、準備済みの施設に設置し、顧客ワークロードをテスト段階から先へ進める必要がある。

数量は重要だが、受け入れはより重要である。ステージング環境に置かれたラックは、性能、信頼性、運用準備の妥当性を証明しない。

MetaとMicrosoftが持続的な本番ワークロードを実行している証拠は、AMDの主張を強めるだろう。ハードウェア納入から有用な導入までに遅れがあれば、統合面または設備面の制約が明らかになる。

投資家と購入者は、AMDの報告表現を注意深く見るべきだ。製品出荷、顧客受け入れ、売上認識、設置済み容量、稼働中ワークロードへの言及は、それぞれ異なる段階を示している。

第2のシグナルは、独立して比較可能なMI455Xの性能である。公開結果では、複数のモデルタイプにわたり、トレーニングと推論の両方をテストすべきだ。

有用な比較では、システムレベルでスループット、レイテンシー、エネルギー消費、メモリ挙動を報告する。デバイス単位の主張は、72アクセラレータラックの測定の代わりにはならない。

このシグナルは、AMD対NvidiaのAI競争に関する見方を迅速に強めることも弱めることもある。競争力のあるワークロード結果は、Heliosのメモリとインターコネクト設計が実用的な性能へ転換されることを示すだろう。

ピーク性能の主張と測定出力の間に大きな隔たりがあれば、Nvidiaのソフトウェアおよび統合面の優位性を補強する。フレームワーク間で結果に一貫性がなければ、ROCmの最適化不足を示すことになる。

第3のシグナルは、継続購入である。Meta、Anthropic、Microsoft、その他の初期顧客は、すでに相当規模の需要コミットメントを示している。

第2段階の導入は、プラットフォームが運用面・経済面の目標を満たしたことを示す。一方、計画容量が目立たない形で縮小されれば、逆の意味を持つ。

Google Cloudの対応にも注目すべきだ。AMDの見通しに影響を与えるために、GoogleがHeliosを採用する必要はない。

TPUの提供範囲を拡大し、一般的なAIフレームワークとの互換性を改善し、あるいはNvidiaや他のプロセッサへのより柔軟なアクセスを提供できる。こうした動きは、ラックインフラを管理せずに代替手段を求める顧客にとって、Google Cloudをより強い選択肢にする。

逆に、GoogleがAMDアクセラレータをより広くサポートすれば、クラウドの移植性が高まり、ROCmへのコミットメントに伴うリスクは低下する。両社が発表するまでは、Heliosのそのような導入を想定すべきではない。

したがって、AMDとGoogleの競争は、インフラ購入におけるより大きな変化を映し出す。顧客はもはや単独のアクセラレータ仕様を比較しているのではない。演算資源のガバナンスモデルを選んでいる。

Googleは垂直統合されたクラウドとカスタムアクセラレータの道筋を提供する。Nvidiaは、多数のクラウドやシステムベンダーを通じて利用できる統合商用プラットフォームを提供する。AMDは、パートナーが適応できるオープンなラックアーキテクチャを提案している。

各モデルは、ある形のコントロールを別の形のコントロールと引き換えにする。垂直統合は最適化を簡素化できる一方、プラットフォーム依存を強める可能性がある。オープンインターフェースは選択肢を維持できる一方、調整コストを増大させる可能性がある。

開発者にとって、当面の意味合いは実務的だ。ハードウェアの多様化により、移植性、プロファイリング、ワークロード固有のベンチマークの価値は高まる。

チームは可能な場合、モデルロジックをベンダー固有のカーネルから分離すべきだ。また、移行を精度およびサービスレベル要件に照らして測定できるよう、再現可能な評価セットを維持すべきである。

インフラ購入者は、クラスター全体のレベルで本番運用の証拠を求めるべきだ。プロセッサのベンチマークだけでは、ネットワークのオーバーサブスクリプション、冷却の限界、復旧時の挙動、運用者の負担を明らかにできない。

また、システムレベルの問題を誰が担当するのかを明確にすべきだ。オープンアーキテクチャが役立つのは、サポート契約と診断責任が明確に保たれる場合に限られる。

ナレッジワーカーは、この競争を間接的に体験することになる。インフラの選択肢が増えれば、モデルの利用可能性が拡大し、単一の容量プロバイダーへの依存を減らせる可能性がある。

ただし、その結果が自動的に低レイテンシーや幅広いアクセスにつながるわけではない。プロバイダーはハードウェア容量を信頼できるサービスへと転換する必要があり、アプリケーションはその容量を効率的に利用しなければならない。

増え続ける仕様、ベンチマークの条件、導入発表を追跡することは難しくなり得る。検索可能な技術ナレッジベースは、インフラ判断の根拠となる証拠をエンジニアリングチームが保持する助けとなる。

Heliosは、すでに競争の構図を変えた。AMDは今や、NvidiaのラックシステムやGoogleの垂直統合型AIインフラに対抗する、一貫性のあるラック構成を提示できる。

次の段階は、より地道なものになる。顧客は機器を導入し、ソフトウェアを移行し、モデルを稼働させ、障害を修復し、追加発注の可否を判断しなければならない。

読者が注視すべきなのは、この試練だ。実際に受け入れられた本番環境の処理能力、比較可能なシステムベンチマーク、そして繰り返される導入事例を追うべきである。これらのシグナルを合わせて見れば、AMDが新たなアクセラレータの選択肢を生み出しただけなのか、それとも持続的な代替データセンタープラットフォームを築いたのかが分かる。

AMDとGoogleの競争が進展するなか、新たな主張が現れた際には、シンプルな問いを投げかけてほしい。これは仕様を述べているのか、出荷を示しているのか、それとも本番ワークロードを指しているのか。この違いが、実際に優位を広げているのが誰なのかを明らかにする。