AMD Helionエージェント型AIラック、スケールに向けたオープンな道筋
AMDは、インフラ競争に対する異なる答えとしてAMD Helionエージェント型AIラックを発表した。すべてのAIタスクがGPU上で動くべきとは限らない、という考え方だ。同社の新しいブループリントでは、1ラックに最大32,768個のCPUコアを搭載できる。別の構成ではCPUとGPUを組み合わせ、エージェント実行とモデル推論を単一システムで行いたい企業を対象とする。
この違いは重要だ。AIエージェントはトークンを生成するだけではない。レコードを取得し、ツールを呼び出し、コードを実行し、データベースを照会し、状態を管理し、ワークフローを調整する。モデル推論は依然として重要だが、こうした連鎖の一部に過ぎない。AMDは、高密度で構成可能なCPU能力には、専用のラックスケール・アーキテクチャが必要だと賭けている。
Nvidiaとの比較は避けられない。NvidiaのVera Rubinプラットフォームは、CPU、GPU、ネットワーキング、ストレージ、ソフトウェアを緊密に連携するAIファクトリーに統合する。一方でHelionは、オープン標準とワークロード別のコンポーネントを重視する。エージェント導入が本番環境へ移行する中、顧客がAMDのモジュール性とNvidiaの統合性のどちらを選ぶかが中心的な問いとなる。
AMD Helionエージェント型AIラック、実行と推論を分離
Helionは、AIモデルを取り巻く処理を第一級のインフラ課題として扱う。
AMDは2026年10月12日、エージェント型AI向けのオープンなラック・ブループリントとしてHelionを発表した。この設計はOpen Compute Projectの標準と、AMDのプロセッサ、アクセラレータ、ネットワーキング、ソフトウェアを採用する。エコシステムパートナーは仕様に基づくシステムを開発しており、2026年11月の提供開始が予定されている。
AMD Helionの発表では、主に2つの構成が説明されている。CPUのみのバージョンは、ハイパースケーラー、ネオクラウド、ソブリンAI事業者を対象とする。エンタープライズ向けバージョンは、CPU、GPU、ストレージ、データベース、テクニカルコンピューティングのノードを1ラックに統合する。
CPUのみの構成には、第6世代AMD EPYC 9006 Seriesプロセッサのコアを最大32,768個搭載できる。AMDはこれらのコアを、最大級モデルのホスティングではなく、エージェント実行のための能力として位置付ける。このラックは、モデル推論を担う別個のアクセラレータシステムに接続できる。
この分離型設計では、異なる種類の処理を専門化されたインフラに分ける。分離とは、実行と推論を不可分な1つのコンピューティングブロックとして扱うのではなく、別々のシステムに配置することを意味する。大規模事業者は、Helion CPUラックをAMD Heliosシステムを含む既存GPUクラスターと組み合わせられる。
AMDのエンタープライズ構成は別の道筋を取る。EPYC CPUブレードと、最大16基のAMD Instinct MI350P GPUを組み合わせる。これらのアクセラレータは、ラック全体で単一のスケールアップ領域を構成するのではなく、独立した2台の8-GPUサーバーに搭載される。
この違いが製品への期待値を定める。Helionは、最先端モデルの学習クラスターに代わるものではない。エージェントの実行、リクエストのルーティング、一部モデルの提供、そしてエージェントが利用するデータベースの支援を目的とする。
このラックには、ストレージ、データサービス、テクニカルコンピューティング向けの汎用ブレードも搭載できる。本番運用のエージェントは、モデル呼び出しだけで稼働することはほとんどないため、こうした補助システムは重要だ。権限を読み取り、メモリーを維持し、企業データを検索し、アクションを記録しなければならない。
AMDは、この設計で最大毎秒102テラビットのネットワーク帯域幅を掲げる。顧客は構成に応じて、空冷または直接液冷を選択できる。物理システムには、44 Open Rackユニットを備えた21インチORv3ラックを使用する。
Helionには統合トークンルーターも含まれる。トークンルーターは、モデルリクエストを適切な推論エンドポイントへ振り分ける。そのエンドポイントはクラウド上の最先端モデルである場合も、ラック内で稼働するオープンモデルである場合もある。
このルーターは、AMDのモジュール型という主張をソフトウェアにも広げるものだ。企業は高価なモデルを難しいリクエストに限定し、予測可能な処理をローカルモデルへ送ることができる。この構想は魅力的だが、AMDはルーターのコスト、レイテンシ、品質への影響を示す本番ベンチマークを公表していない。
したがってHelionは、競争の単位を変える。AMDは単体のサーバープロセッサやアクセラレータを提示しているのではない。CPU、GPU、ネットワーキング、補助サービスを、エージェントタスクの完全なライフサイクルを中心に編成している。
エージェント型AIが新たなCPU市場を生む理由
モデル推論はワークフロー全体を実行するものではないため、エージェント向けインフラの競争はGPUの枠を超えて拡大している。
チャットボットは、多くの場合、モデルへ1回のリクエストを送り、1つの応答を返す。エージェントは計画を生成し、複数のシステムを検索し、外部ツールを呼び出し、結果を評価し、アプローチを見直すことができる。1つのユーザーリクエストが、多数の個別処理を引き起こす可能性がある。
こうした処理がCPU需要を生む。ツールコンテナを起動し、アプリケーションロジックを実行し、データベースがクエリに応答しなければならない。セキュリティポリシーもプロセス全体で検査される必要がある。モデルアクセラレータはトークンを高速に生成できるが、周辺機能を置き換えるものではない。
コードエージェントは有用な例を示す。モデルが変更案を提案しても、別のシステムがリポジトリをチェックアウトし、依存関係をインストールする。ソフトウェアのコンパイル、テストの実行、ログの確認、修正されたプロンプトの送信も行うかもしれない。これらのステップには、汎用コンピュート、メモリー、ストレージ、ネットワークアクセスが求められる。
カスタマーサービス用エージェントも同様のパターンを生む。アカウント記録を取得し、在庫を確認し、サポートチケットを更新し、機密性の高いアクションについて承認を求めることができる。言語モデルが対話を導く一方、実際の処理の多くは従来型システムが担う。
AMDはエージェントのワークロードを、パーソナル、エンタープライズ、テクニカルの各カテゴリーに分類する。パーソナルエージェントは、ワット当たりのエージェント数を優先する。エンタープライズ導入では、多数の同時ユーザーに対するバランスの取れた性能が必要だ。テクニカルエージェントでは、コンパイルやシミュレーションなどの処理に高速なコアが求められる。
HelionのCPUブレードの選択肢は、これらの違いを反映している。高密度ブレードは、400ワットに設定された256コアプロセッサを使用する。バランス型システムも256コアを提供し、動作電力は600ワットとなる。性能重視ブレードは、5.0 GHzに達する高周波数の96コアを使用する。
これらは構成上の目標であり、アプリケーション性能の証明ではない。コア数だけでは、エージェントがタスクをどれだけ速く完了するかは予測できない。ソフトウェア設計、メモリーアクセス、ツールのレイテンシ、モデル応答時間、ネットワーク競合が結果を左右する可能性がある。
それでも、このアーキテクチャは市場のより広い変化を反映している。Nvidiaは、エージェント型ワークロード向けに256プロセッサを搭載する単体のVera CPUラックを発表した。同社によれば、そのCPUは環境、強化学習、データ処理、その他GPU推論を取り巻くタスクを支援する。
Intelもこのカテゴリーを狙っている。同社の2026年ラックスケール戦略は、XeonプロセッサとSambaNovaアクセラレータを組み合わせ、推論とエージェントのワークロードに対応する。Intelは別途、異なるアクセラレータタイプを使用できる分離型システムも推進している。
こうした競争活動はAMDの前提を裏付ける。エージェント型AIは、アクセラレータラックの先にあるインフラ市場を生み出している。意見が分かれるのは、顧客がそれらのコンポーネントをどこまで密接に結び付けるべきかという点だ。
CPUの機会はGPUの重要性を低下させるものではない。むしろGPUの利用拡大に伴うものだ。モデル呼び出しが増えれば、その周囲のオーケストレーション、データ移動、アプリケーション実行も増加する。
AMDにとって、これはAIデータセンターへ進出する別の道筋となる。NvidiaはGPUハードウェアとCUDAソフトウェアを通じて、アクセラレータ市場の大部分を支配してきた。AMDはアクセラレータで競争しながら、エンタープライズシステム全体にすでに存在するx86サーバーの基盤も守ることができる。
Helionは、この既存基盤の優位性をラックレベルの提案としてパッケージ化する。顧客は周辺ワークフローのより多くをEPYCプロセッサ上で実行できる。そのうえで、モデル呼び出しをAMD GPU、別のローカルアクセラレータ、または外部サービスへ振り向けられる。
ビジネスケースは依然としてワークロードに依存する。単純な検索支援アシスタントを運用する企業には、専用ラックは不要かもしれない。一方で、数千の同時エージェントを運用するハイパースケーラーでは、計算が異なる。Helionは、こうしたバックグラウンド処理が容量計画の問題となる局面を対象とする。
AMDのオープンなブループリント、Nvidiaの統合型AIファクトリーに挑む
主な競争は、1つのベンチマークにおけるAMD対Nvidiaではない。モジュール型インフラと、垂直統合的に連携するプラットフォームとの競争である。
NvidiaのVera Rubinプラットフォームは、複数の専用システムを組み合わせる。そのポートフォリオには、Rubin GPUラック、Vera CPUラック、ネットワーキング、データ処理ユニット、ストレージインフラが含まれる。Nvidiaは、これらの要素が大規模なAIファクトリーとして連携するよう設計している。
この統合は性能エンジニアリングを簡素化し得る。サプライヤーは、プロセッサ、インターコネクト、システムアーキテクチャ、ソフトウェアの大部分を管理する。顧客は明確な導入経路と、コンポーネント間で最適化された通信を得られる。
同じアプローチはプラットフォームへの依存も高める。設計全体がNvidiaのハードウェアとソフトウェアを前提とする場合、1つのレイヤーを置き換えることは難しくなる。購入者が既存インフラと複数ベンダーのコンポーネントを組み合わせる余地も小さくなる。
AMD Helionは反対の約束を掲げる。Open Compute Projectのラック形式を採用し、メーカーが適応できるブループリントとして提示する。AMDは、コミュニティ開発のために仕様を同団体へ寄与する予定だ。
Open Rackプロジェクトは、データセンター機器向けの共通の機械・電力仕様を提供する。Helionは、さまざまなレイヤーでORv3、DC-MHS、DC-SCM、HPRv2、OCP NIC 3.0、Caliptraを採用している。これらの標準は、ラック寸法、モジュラー型ホスト、管理、電力、ネットワーキング、ハードウェアセキュリティなどを対象とする。
このレベルの準拠は、キャビネットにオープンというラベルを付けること以上の意味を持つ。標準化されたインターフェースにより、メーカーは互換性のあるブレード、電力システム、管理コンポーネントを構築できる。また、特定顧客向けにラックを適応させる際に必要なエンジニアリング作業を減らすこともできる。
AMDは大規模な製造パートナー群を集めている。発表された支援企業には、Dell、Foxconn、HPE、Lenovo、QCT、Supermicro、Wiwynnが含まれる。Ciscoも、より広範なインフラアプローチを支援している。
パートナーの広がりは、Helionをブループリントとして信頼できるものに見せる助けになる。ただし、それだけで顧客需要が立証されるわけではない。同じメーカーの多くはNvidiaシステムも製造しており、公表された支持表明からは確約済みの導入規模は分からない。
Nvidiaも、MGXを大規模な製造ネットワークが支えるオープンなシステムアーキテクチャとして説明している。そのため、AMDはオープンでNvidiaはクローズドというほど選択は単純ではない。両社とも機器メーカーを通じてリファレンス設計を配布している。
違いは、各プラットフォームがどこに制御を集中させるかにある。Nvidiaはアクセラレータファブリック、ネットワーキングスタック、プロセッサ、ソフトウェア環境を中心に構築する。AMDは交換可能な構成と、確立されたOCPインターフェースをより重視する。
HelionのCPUのみの選択肢は、この違いを特に明確に示す。ハイパースケーラーは、エージェント実行能力を推論フリートとは別に導入できる。アクセラレータフリートが同じラックを占有したり、同じ更新サイクルを使用したりする必要はない。
この分離は運用上の柔軟性をもたらす。ツール実行がボトルネックになればCPU能力を増やせる。モデルトラフィックが増加すればGPU能力を拡張できる。各プールは、それぞれの経済性に従って選択・置換できる。
それは調整作業も生み出す。運用者は、別々のシステムにまたがるネットワーク、配置、スケジューリング、可観測性、障害対応を管理しなければならない。オープンな設計図は選択肢を増やす一方で、統合に関する責任をより顧客側へ移す可能性がある。
エンタープライズ構成は、CPUとMI350P GPUを同じ場所に配置することで、その負担を軽減する。ただし、2台のGPUノードは独立して動作する。Helionには、最大規模のモデル向けに設計されたシステムで用いられるラック全体のスケールアップ・ファブリックはない。
AMDによれば、これはラックがフロンティアモデルのトレーニングではなく、エンタープライズ向けエージェントを対象としているため意図的な設計だという。この説明はアーキテクチャと整合している。同時に、購入者が理解しておくべき制約も明確にしている。
Helionはオープンモデルをローカルで実行できるが、16基のGPUを1つの巨大なアクセラレータに変えるようには設計されていない。統一されたGPUドメインを必要とするワークロードは、AMD HeliosやNvidiaのGPUラックのようなインフラに適している。Helionの役割は、調整、実行、そして選択的な推論である。
したがって、AMD Helionのエージェント型AIラックは、購入者にある種のトレードオフを求める。モジュール性と複数の導入経路を得る代わりに、どのワークロードを各コンポーネントに割り当てるかを判断し、それらの境界を管理しなければならない。
AMD Helionが異なるエージェント・ワークロードを振り分ける仕組み
Helionの中核となる仕組みはワークロード配置であり、エージェントタスクの各段階を適切なコンピューティングリソースに対応付ける。
ある企業のリサーチエージェントが、サプライヤーを評価するよう求められたケースを考えてみよう。エージェントはまず要求を解釈し、計画を立てる。次に社内文書を検索し、業務システムに照会し、外部ソースを読み、リスク指標を計算する。
初期の計画段階はクラウドモデルが担える。機密情報を含む取得済み文書の分類はローカルモデルが担える。CPUノードでは、検索、データベース、解析、計算のサービスを実行できる。ストレージシステムは、プロセス全体で使われる記録を提供する。
トークンルーターは、個々のモデル要求をこれらの宛先に振り分けられる。これは推論向けのトラフィック制御装置に似ているが、その判断は単純な負荷分散より重い意味を持つ。モデルごとに、品質、レイテンシー、プライバシー、コンテキスト容量、運用コストが異なるためだ。
例えば、定型的な抽出タスクはラック内のコンパクトなモデルに送ることができる。難度の高い推論要求はフロンティアサービスに送られる可能性がある。ローカルモデルのほうが時間を要しても、機密データはローカルにとどめられる。
AMDは、こうしたルーティング判断を評価するのに十分な詳細を開示していない。この発表では、経路選択の精度やオーバーヘッドに関する公開測定値は示されていない。また、複数のモデル間を移動する要求を管理者がどのように監査するかも説明されていない。
こうした問いは、規制のある環境で重要になる。ルーティング層は、データの保存場所、アクセス権、承認済みモデルのポリシーを尊重する必要がある。また、各要求をどのエンドポイントが処理したかを説明する記録も生成しなければならない。
モデルルーティングは、スケジューリング層の一つにすぎない。プラットフォームは、エージェントが起動する非モデルタスクについても配置を決める必要がある。一部のジョブは多数の効率的なコアを好む一方、技術的なタスクには、より高いシングルスレッド性能を持つ少数のコアが必要になる。
AMDの3つのプロセッサプロファイルは、この違いに対応する。高密度ブレードは同時処理能力を最大化する。バランス型ブレードは、同じコア数により多くの電力を供給する。高周波数ブレードは、レイテンシーに敏感なコードとテクニカルコンピューティングを対象とする。
エンタープライズラックは、こうしたCPUオプションに加えてMI350P推論ノードを備える。そのため、すべてのモデル要求をシステム外へ送ることなくワークフローを支援できる。この設計は、データガバナンスやレイテンシー要件を持つ組織にとって魅力的になり得る。
汎用ブレードがアーキテクチャを完成させる。これらは、エージェントが依存するデータベース、ストレージサービス、技術アプリケーションを支える。これは、エージェントプラットフォームがモデルだけでなくエンタープライズシステムにも依存するという、実践的な認識である。
知識集約型のワークフローは、そのつながりを示している。作業者は、エージェントに行動を依頼する前に、personal knowledge baseを用いて関連するコンテキストを見つけるかもしれない。組織規模では、同じパターンにアイデンティティ制御、検索サービス、データベース、追跡可能なアクションが必要となる。
開発者は、インフラが弱いエージェント設計を修復すると考えるべきではない。コア数を増やしても、不明確な権限、不安定なツール、不十分に評価されたモデル挙動は解決できない。Helionは容量を提供できるが、アプリケーションには依然として制限と復旧経路が必要だ。
購入者は、代わりにワークフロー全体をマッピングすべきである。モデル推論、ツール実行、検索、待機、検証に費やされる時間を測定する必要がある。こうした測定により、CPU中心のラック、混成システム、既存サーバーのどれが適切かが決まる。
ここでAMDの主張は検証可能になる。本番エージェントがモデル推論以外に相当な時間を費やすなら、Helionはその作業を独立して拡張する手段を顧客に提供する。推論が支配的なら、アクセラレータ中心のシステムのほうが引き続き説得力を持つ。
仕様が証明していないこと
Helionは開発中のリファレンスデザインであり、その最大値は検証済みの本番成果ではなく容量を示している。
32,768コアという見出しの数値は理解しやすい。しかし、これはエージェント性能の指標ではない。顧客が知る必要があるのは、ワット当たりの完了タスク数、ワークフロー当たりの所要時間、モデルレイテンシー、障害率、実トラフィック下での利用率である。
AMDの製品資料では、ワット当たりのエージェント数とエージェント当たりの性能の最大化が語られている。しかし、これらの指標に関する標準化された結果はまだ提供されていない。ワークロードの定義がなければ、「エージェント」という言葉は一貫したベンチマーク単位として機能しない。
あるエージェントは短いメールを分類するかもしれない。別のエージェントは30分間のソフトウェアテストスイートを実行するかもしれない。3つ目は数百回のツール呼び出しと複数のモデルを調整するかもしれない。これらをすべて1エージェントとして数えれば、作業量の大きな違いが隠れてしまう。
AMDは、Helionと従来型のサーバー列を比較した完全なデータも公開していない。ラック密度は必要な床面積を削減できるが、電力、冷却、ネットワーク要件を集中させる。運用者は施設全体への影響を評価しなければならない。
102Tbpsというネットワーク数値にも同様の文脈が必要だ。ファブリック全体の容量は、アプリケーションスループットを明らかにしない。トラフィックパターン、スイッチ構成、プロトコルのオーバーヘッド、ストレージアクセス、外部モデル呼び出しはすべて、観測される性能に影響する。
可用性も未解決の問題である。AMDによると、パートナー構成は開発中であり、2026年11月を予定している。つまり発表から想定される投入までの期間は短い。具体的なモデル、地域別の提供状況、認定スケジュール、顧客導入については依然として不明確だ。
Tom’s Hardwareが報じた日程修正は、その流動性を示している。同メディアは当初2027年を示す案内を受け取ったが、その後AMDが提供時期を2026年11月へ改定したことを受け、scheduleを更新した。購入者は、納入時期をシステムパートナーに直接確認すべきである。
ソフトウェアの成熟度も別のリスクとなる。ハードウェアのオープン性が、メーカー間で一貫した運用体験を自動的に生み出すわけではない。ファームウェア、オーケストレーションツール、可観測性、セキュリティ制御、サポート慣行は、実装によって異なり得る。
トークンルーターには特に厳しい検証が必要だ。クラウドモデルとローカルモデルの間のルーティングはリソース利用を改善できるが、誤りは品質やデータガバナンスに影響し得る。情報に保存場所や機密性の制限がある場合、企業には自動判断を上書きするポリシーが必要である。
組織が、すべてのエージェントサービス向けに1つの混成エンタープライズラックを望むという公開された証拠も、まだ存在しない。一部の購入者はすでに共有GPUクラスターと広範なx86フリートを運用している。専用のHelion導入より、既存プールを横断するソフトウェアオーケストレーションを好む可能性がある。
Nvidiaは別の方向から競争圧力を生み出している。Vera RubinはHelionの発表前に量産へ入った。Nvidiaによれば、そのプラットフォームは、専用設計のCPU、GPU、ストレージ、ネットワークのラックを、一つの協調システム内で接続する。
これらはNvidia自身による性能と導入に関する主張であり、比較には独立して再現されたテストが必要である。それでも、製品の可用性とソフトウェア統合は、アーキテクチャの柔軟性を上回ることがある。顧客は、抽象的な品質としてのオープン性を導入することはできない。
IntelはAMDにさらなる不確実性をもたらす。Xeonはすでにデータセンターで広く普及しており、同社は複数のアクセラレータを備えたエージェント型ラックソリューションを推進している。したがってHelionは、既存のx86インフラだけでなく、Nvidiaの統合プラットフォームとも競わなければならない。
AMDの主張で最も強い形は、普遍的な優位性を訴えることに依存しない。分離された実行能力から利益を得る、測定可能なエージェント・ワークロードの分類が存在することを示す点に依存する。最大コア数よりも、公開される顧客成果のほうが重要になる。
AMDの戦略が機能するかを示す3つのシグナル
Helionの成功は、提供されたシステム、再現可能なワークロード結果、そして顧客が実際にそのモジュラー設計を活用するかに左右される。
第1のシグナルは11月の提供開始である。Dell、HPE、Lenovo、Supermicro、QCT、Foxconn、Wiwynnは、支援表明を注文可能な構成へと変える必要がある。購入者は、完全な仕様、提供地域、サービス条件、認定ガイダンスに注目すべきだ。
予定どおりのシステム提供は、OCPベースの協業が設計図から製品までの道のりを短縮できるというAMDの主張を強化する。遅延や限定的な提供状況は、この発表がエコシステムの準備が整う前に行われたことを示唆するだろう。
第2のシグナルは、アプリケーションレベルのベンチマークである。AMDとそのパートナーは、現実的なワークフロー全体で、完了したエージェントタスク、レイテンシー分布、消費電力、利用率を報告する必要がある。テストでは、モデル時間をCPU実行、検索、ストレージ、ネットワークから切り分けるべきである。
最も有用な比較には、従来型サーバー、HelionのCPU専用ラック、混成エンタープライズ構成が含まれる。また、すべてのワークフローを明確に定義すべきだ。タスクの複雑性や品質管理がなければ、一般的な「ワット当たりのエージェント数」という結果の価値は小さい。
独立したテストは、こうした結果をより強固にする。また、購入者がHelionをNvidia Vera CPUラック、Intel Xeon導入環境、すでに本番稼働しているソフトウェアオーケストレーション型インフラと比較する助けにもなる。
第3のシグナルは、顧客がディスアグリゲーションをどのように利用するかである。Helionを複数のアクセラレータプラットフォームと組み合わせるハイパースケーラーは、AMDの中心的な主張を裏付けることになる。それは、エージェント実行が独立して拡張可能なインフラ層になり得ることを示すだろう。
エンタープライズでの導入は、別の前提を検証する。購入者は、1つのラック内にCPU実行と限定的なGPU推論を組み合わせることで導入が簡素化されることを実証しなければならない。Helionが高密度の汎用コンピューティングとしてのみ使われるなら、エージェント特化という位置付けの独自性は薄れる。
AMD Helionのエージェント型AIラックは、信頼できるアーキテクチャ上の着想を持って市場に参入する。エージェントのワークフローはモデル推論だけで構成されず、その周辺の運用には相当なインフラが必要だ。AMDはその観察を軸にラックを設計した。
しかし、この設計図は始まりにすぎない。その価値は、パートナーがコンポーネントをどれだけうまく統合するか、そして顧客が成果をどれだけ明確に測定するかによって決まる。オープン標準は選択肢を広げられるが、信頼性の高いエージェントプラットフォームを構築する作業をなくすものではない。
開発者とエンタープライズの購買担当者にとって、直ちに取るべき行動は明快です。ハードウェアを選定する前に、ワークフロー全体をプロファイリングしてください。エージェントがどこで時間を費やしているのか、どのデータをローカルに保持する必要があるのか、そしてどこで障害が発生するのかを測定します。その上で、これらの要件に照らしてHelionのモジュール型アプローチを統合型の代替案と比較してください。11月に、透明性の高いベンチマークと実際の導入事例を伴うシステムが登場すれば、エージェント型コンピューティングには独自のラックスケール層が必要であることを、AMDは実証できるでしょう。
