AMDは2026年10月12日、AIエージェント向けのラック設計「Helion」を発表した。第6世代EPYCを使うCPU専用構成は最大32,768コアに対応し、企業向けにはCPUとInstinct MI350P GPUを同じラックへ組み込む構成を用意する。既に大規模モデルの学習・推論向けに「Helios」を展開するAMDが、エージェントによるコード実行や業務処理を支える側にも、ラック単位の設計を広げた。Helionは、エージェントを動かす処理とモデルに回答を生成させる処理を、顧客の設備と用途に合わせて配置する提案である。

AD

エージェントを動かすCPUと、モデルを動かすGPU

HelionのCPU専用ラックは、別に設けたモデル推論基盤へ接続する設計だ。AMDの発表は、CPU側にエージェントの実行を担わせ、推論側との接続を提供すると説明している。既にGPUなどの推論設備を運用する大規模事業者なら、その設備を使いながらエージェントを実行するCPU側を増設できる。ラック内にGPUを置かない構成でも、モデルを呼び出す工程は残る。

モデルがコードや次の操作を生成した後には、実際にプログラムを走らせ、結果を受け取り、次の処理へ進む仕事がある。AMDは7月23日のEPYC 9006の技術説明で、エージェントが生成するコードとタスクの隔離実行、状態やメモリの保持をCPUの役割として挙げていた。さらに、GPUへデータを供給するホストと、エージェントが利用する業務サービスも分けている。Helionは、そこで示した用途別のCPU選択をラックの組み方に落とし込んだものと読める。

例えば、コーディングエージェントが修正案を生成しても、コンパイルやテストが詰まれば仕事は完了しない。モデルの応答が速いことと、エージェントが短時間で仕事を終えることは別の指標になる。CPU側の実行環境をどれだけ用意し、推論設備とどう組み合わせるかが、運用上の選択になるわけだ。

競合も同じ工程を狙っている。NVIDIAは5月31日のVera発表で、Pythonの実行環境や隔離環境でのコード実行を用途に挙げ、CPU単独のサーバーと高密度ラックを示した。GPUが生成するトークンの量に加え、その前後のCPU処理をどう速くするかという競争が進んでいる。Helionの位置付けは、この流れの中で捉えると明確になる。

256コアの密度と96コアの速さ

Helionでは、エージェント用CPUブレードを用途に応じて混在させられる。AMDの製品資料が示すEPYC 9006の選択肢は、高密度向けの256コア・400W、バランス型の256コア・600W、高性能向けの96コア・5.0GHzである。ここで400Wや600WはCPUの提示値であり、ラック全体の消費電力ではない。

CPUブレードの選択肢 公表されたCPU仕様 AMDが対応させるエージェントの用途
高密度型 256コア、400W 多数の個人向けエージェントを電力当たり多く動かす
バランス型 256コア、600W 企業向けエージェントの処理を支える
高性能型 96コア、5.0GHz 応答の速さを求める技術計算エージェント

この表はAMDの構成例を用途別に並べたもので、処理速度の実測比較ではない。同時に多くの仕事を走らせるならコア密度が効きやすく、一つの仕事のCPU処理を短くしたいならコア当たりの性能が問われる。両者を同じラックに混ぜられる点が、CPUコア数の最大値だけでは見えない設計上の選択肢だ。

ただし、コアやスレッドの数を、そのまま実用上のエージェント数として読むことはできない。AMDが7月に示した「エージェント数／CPU電力」の比較も、技術説明の脚注では公開コア数とCPU電力に基づく推計とされている。これは実際のエージェントが業務を完了する回数を測った値とは異なる。処理するコード、必要なメモリ、モデルの応答待ちが変われば、同じCPU構成でも得られる結果は変わる。

AD

GPUを16基積んでも、Heliosと同じ接続にはならない

企業向けHelionのGPU推論ブレードは、5UサーバーにInstinct MI350Pを8基載せる構成である。AMDのFAQによれば、ラックにはこのサーバーを最大2台収容でき、合計16基になる。一方、両ノードは独立して動き、ノード間にはGPU群を一体化する接続がない。制約が示されているのは2ノードの間であり、ノード内のGPU接続について述べたものではない。

HelionのCPU専用構成は別系統の推論基盤に接続し、企業向け構成は8 GPUの独立ノードを最大2台載せる。

ラック設計 エージェント実行と推論の配置 GPU接続と主な用途
Helion CPU専用 ラック内のCPUでエージェントを実行し、モデル推論は別基盤へ接続 既存の推論設備を持つ大規模事業者向け
Helion企業向け CPU実行、MI350Pによる推論、業務用の汎用計算を同じラックに配置 最大8 GPU×2ノード。両ノードは独立し、ノード間にGPUを一体化する接続はない
Helios MI455X、EPYC、ネットワークをラック全体で統合 72 GPUを使う大規模推論・最先端モデルの学習向けで、GPUを一体化する接続を備える

2026年10月13日までのAMDの公表設計を、推論の配置とGPU接続の役割で比較した。Helionの構成・FAQと7月23日のHelios発表に基づき、性能や価格の優劣は付けていない。Helionの最大CPUコア数と最大GPU数が、同じ構成で同時に達成されることを示す表でもない。

Heliosは、複数GPUを連携させて大きなモデルを扱うための設計だ。対して企業向けHelionは、エージェントのCPU実行とGPU推論を一つのラックに収める。GPUの数が増えても、独立したノードを追加することと、一つのGPU計算領域を広げることは同じではない。導入先が求めるモデルの大きさと同時処理量に照らし、ノード単位で扱える構成を確認する必要がある。

AMDはネットワーク帯域の最大値として102Tbpsも掲げるが、製品資料には集計方法や通信遅延の条件が示されていない。帯域の数字だけでは、ノード間のGPU接続やエージェントの応答時間を判断できない。

モデルの振り分けとOCP規格で変わる導入条件

企業向けHelionは、ラック内で動かすオープンソースモデルと、クラウド上の最先端大規模モデルへ推論要求を振り分ける。AMDは、こうした振り分けを担う「トークンルーター」をHelionに組み込む。CPUでエージェントを実行する場所と、そのエージェントが呼び出すモデルの場所を、同じラック内に固定しない設計である。

この構成なら、社内に推論GPUを置きながら外部モデルも使う運用を組める。ただし、今回の発表と製品資料には、モデルを選ぶ規則や個々の対応モデル、振り分けによる性能・費用の測定結果までは示されていない。企業が選ぶべきCPU/GPUの比率は、どの仕事を社内のモデルで処理し、どの仕事を外部へ回すかと合わせて決まる。ハードウェアの最大構成だけで必要量を見積もるのは難しい。

ハードウェア側では、21インチのORv3ラックを採用し、直接液冷と空冷の選択肢を持つ。AMDが挙げるOCP関連仕様はラックの形状に限らず、電源供給用のバスバー、ホストモジュール、管理・セキュリティにも及ぶ。パートナーが計算ノードや管理系を組み合わせるための共通の設計基盤になる。

もっとも、共通仕様を使うことと、既設設備へそのまま収まることは別の確認だ。OCPのRack & Powerプロジェクトも、ラック規格に加え、施設とIT機器の間の電源変換・制御を対象にしている。空冷を選べる場合でも、受電容量やラックへの給電方式を含め、導入する構成が施設に合うかを詰める必要がある。

AMDはHelionの仕様をOCPへ寄贈する計画も示した。公表時点では計画であり、寄贈済みの仕様として扱うことはできない。現在どの規格を採用しているかと、Helion全体の仕様を今後コミュニティへ提供することは、分けて捉えるべきだ。

AD

11月に見るべきは、コア数より仕事の完了

Helionのラック構成はパートナーと開発中で、AMDは2026年11月の提供を予定する。発表にはDell TechnologiesやHPE、Lenovoが支持を表明し、製造・統合側ではFoxconn、QCT、Supermicroなども加わる。これは個々の構成が全社から同じ日に出荷されるという約束ではなく、製品ごとの仕様と提供条件は各パートナーの具体化を待つ段階だ。

今回の発表と製品資料では、ラック価格、ラック全体の消費電力、エージェントが仕事を完了する速度の実測値は示されていない。製品が出てきたときには、同じモデルと業務、同じ完了基準を使い、成功した仕事の数と応答時間を比べたい。電力当たりの効率を測るならCPUだけでなくラック全体を対象にし、外部モデルを使う構成ではその利用料金も加える。この評価なら、CPU密度の向上が実際の仕事にどれだけ効いたかを確かめられる。

企業がHelionに求める価値は、自社の処理に合わせてCPUの実行環境とモデル推論を配置できることだ。パートナー製品がその組み合わせを実際の業務で検証し、設備条件と総費用まで示せれば、企業はエージェントの処理が滞る工程を見極めて、必要な計算資源を増やせるようになる。