Advancing AI 2026を、IT技術者が「ラック・ネットワーク・運用」の変化として読む

AIインフラの競争は、もはや「最も速いGPUを選ぶ」だけでは語れない。

生成AIの利用が、単発のチャットから、複数のモデル、データ、API、実行環境をまたいで仕事を進めるエージェント型AIへ広がると、詰まりやすい場所はGPU演算だけではなくなる。GPUメモリ、GPU間通信、ラック間ネットワーク、CPUによるツール実行、認証・監査、推論ソフトウェアまでが、業務の完了時間とコストを左右する。

AMDが2026年7月に示したのは、この変化に対する明確な答えだ。同社はMI455X GPU、EPYC 9006シリーズCPU、Pensandoネットワーク、ROCm.AIを、個別製品ではなくラック単位のAI基盤「Helios」として提示した。AMDの狙いは、GPUの代替候補にとどまらず、クラウドから企業システム、PC、エッジまでのAI実行基盤を、オープンなエコシステムで押さえることにある。 AMDの発表

この記事では、発表された製品名を追うのではなく、AIインフラのトレンドと、IT技術者が設計・調達・運用で見るべきポイントからAMDの戦略を読み解く。

AI需要の中心は「学習」だけでなく、反復する推論へ移っている

従来の生成AIは、利用者の質問にモデルが一度答える構造だった。

利用者の質問をモデルが一度推論して回答する、比較的単純な流れである。

一方、エージェント型AIでは、一つの依頼を完了するまでに推論が何度も走る。情報を検索し、計画を立て、コードや業務ツールを使い、結果を検証し、必要ならやり直すからだ。

![エージェント型AIは、タスク分解、検索、推論、ツール実行、検証を反復する](

この構造では、GPUだけを増やしても処理全体が速くなるとは限らない。たとえば、次の箇所がボトルネックになる。

処理	主な制約	影響
長い入力の読込み	GPU演算、メモリ帯域	応答開始までの遅延
1トークンずつの生成	HBM容量・帯域、KVキャッシュ	同時利用者数、応答速度
複数GPUの協調	GPU間通信	大規模モデルの学習・推論効率
ツール実行・隔離環境	CPU、メモリ、コンテナ密度	エージェントの並列実行数
API呼出し・データ取得	ネットワーク、認証、業務システム	業務完了までの時間と障害範囲

つまり、実効性能は「GPUのピーク性能」ではなく、GPU、CPU、メモリ、ネットワーク、ソフトウェアを通過して業務を完了できる能力で決まる。AMDはここを主戦場にしようとしている。

AMD Heliosの本体は、GPUサーバーではなく「ラックを一台のコンピューターとして扱う」発想

Heliosは、GPUを搭載したサーバー製品というより、計算、メモリ、通信、制御をラック単位で協調させるための設計である。AMDの発表によれば、1ラックに72基のInstinct MI455X GPUと18基の第6世代EPYC「Venice」CPUを置き、フロントエンド、スケールアップ、スケールアウトのネットワークをPensando製品群で接続し、ROCmソフトウェアで最適化する。 Heliosの構成

層	主な構成	役割
AI計算	Instinct MI455X	学習、推論、ファインチューニング
ホスト・実行基盤	EPYC 9006	GPUへのデータ供給、エージェント実行、I/O制御
スケールアップ	UALoE	ラック内のGPU群を高速に協調させる
スケールアウト	Vulcano AI NIC	ラック・データセンター間へ処理を広げる
フロントエンド	Salina DPU	エージェント型AIの接続・制御を支える
ソフトウェア	ROCm / ROCm.AI	フレームワーク、ランタイム、最適化、検証

ここで重要なのは、AMDが「GPU数」ではなく、ラック全体でのトークン生成、ジョブ完了時間、保守性を価値として前面に出していることだ。AMDはHeliosについて、競合構成比で1ドル当たり最大30%多い推論トークンを生成すると主張している。ただしこれはAMDが定めた比較条件での最大値であり、導入判断では自社のモデル、精度、入力長、出力長、同時実行数、電力単価を使った再測定が必要になる。 MI455Xの製品仕様

このラックスケール化は、NVIDIAのような垂直統合型のAI基盤に対し、AMDがオープンな標準とパートナー網で対抗する構図でもある。AMDはネットワークを、フロントエンド、ラック内、ラック間の三層として設計し、オープンなEthernet系エコシステムとUALink系技術を組み合わせる方針を示している。 AMDのネットワーク戦略

MI455Xで重要なのは、演算性能よりも「モデルとKVキャッシュをどこまで載せられるか」

MI455XはAMD CDNA 5アーキテクチャを採用し、432GBのHBM4と23.3TB/sのメモリ帯域を備える。ピーク性能はOCP MXFP4で40.3PFLOPS、MXFP8で20.1PFLOPSである。 AMD公式仕様

これらの数字を読むときは、FLOPSだけで評価しないことが重要だ。

LLMの推論は大きく二つに分かれる。

段階	内容	主に効く要素
Prefill	入力文書や会話履歴をまとめて処理する	演算性能、メモリ帯域
Decode	出力を1トークンずつ生成する	メモリ帯域、KVキャッシュ、通信、スケジューリング

企業利用では、長い会話履歴、社内検索の結果、複数ツールの中間結果を抱えたまま推論する場面が増える。ここで効くのが、GPUに載せられるメモリ容量と、そのメモリを読み書きする帯域である。

AMDがMI455XでHBM4の432GBと23.3TB/sを強調するのは、巨大なモデルを載せるためだけではない。より多くの同時セッションとKVキャッシュを保持し、モデルの重みや中間状態をGPU間・CPU間へ退避させる回数を減らすためだ。これは、対話型AIの待ち時間と、1ラック当たりの処理件数を左右する。

AMDはMI355Xとの比較で、MI455Xのトークンスループットが最大34倍になると発表している。この種の「最大」性能は、モデル、精度、バッチサイズ、ソフトウェア版、GPU数に依存する。ベンチマーク値を調達の結論にせず、業務SLOで検証する必要がある。 AMDの性能主張と前提

CPUはAI時代に脇役ではなくなる

AIサーバーではGPUに目が向きがちだが、エージェント型AIが増えるほどCPUの仕事は増える。

APIを呼び出す
ファイルを展開し、変換し、検索する
コンテナや仮想環境を起動する
複数エージェントの処理を調整する
業務データベースや認証基盤と連携する
ログを集約し、監査・再実行・復旧を行う

GPUは推論そのものを高速化するが、エージェントが業務を完了するための周辺処理はCPU、メモリ、ネットワーク、ストレージに広がる。AMDはEPYC 9006を、GPUホスト、エージェントのサンドボックス、汎用サーバーという異なる層で使うCPUとして位置付けている。 AMDのEPYC 9006発表

そのため、容量計画を次のように分けるとよい。

領域	測る指標
GPU	tokens/sec、GPUメモリ使用率、待ち行列、同時セッション数
CPU	エージェント数、コンテナ密度、API処理時間、CPU待ち時間
メモリ	KVキャッシュ、コンテナ、検索・変換処理の使用量
ネットワーク	GPU通信、API遅延、再送、輻輳、帯域使用量
ストレージ	モデル配布、ナレッジ更新、ログ・成果物の保持量
業務システム	API呼出し数、DB負荷、認証失敗、レート制限

「GPUを何台買うか」だけで容量を決めると、CPUサンドボックスや業務APIが先に飽和し、AIを増やしても業務完了件数が伸びない。

ROCm.AIは、CUDA互換の話ではなく「導入と最適化の作業を短くする」戦略である

GPUを導入しても、モデルが期待どおり動くとは限らない。フレームワーク、推論エンジン、カーネル、通信ライブラリ、量子化、メモリ管理を合わせ込んで初めて、実務に必要なスループットと安定性が出る。

ROCm.AIは、AI支援による開発、デプロイ、性能最適化を一つの開発体験にまとめるとするAMDの取り組みである。環境確認、モデルの提供、問題診断、AMDで検証済みの手順、ボトルネック検出と正しさの確認までを対象にしている。 ROCm.AIの説明

AMDにとってソフトウェアは、ハードウェア性能を後から補う付属品ではない。モデル事業者と共同で最適化し、開発者が比較的少ない手順で本番ワークロードへ到達できるようにすることが、採用を左右する競争領域になる。

利用側も、ソフトウェア更新を単なる保守作業として扱わないほうがよい。更新のたびに、少なくとも次を同じ条件で測る。

正確性：出力品質、ツール呼出しの成功率、回帰がないか
性能：P50/P95遅延、tokens/sec、キュー待ち時間
コスト：1件当たりのGPU時間、トークン数、電力・クラウド費用
運用性：失敗時の再試行、ロールバック、監視・ログの欠落がないか

この評価を持たないままランタイムやモデルを更新すると、「ベンチマークは速くなったが、実業務は遅くなった」「精度は保ったが、コストが急増した」といった事態を見落としやすい。

パートナー戦略は、採用実績の飾りではなく共同設計の入口である

AMDは、OpenAI、Anthropic、Meta、Microsoft、Oracle、Cerebrasなどとの協業を発表している。これは単に有名企業のロゴを並べる話ではない。

モデルは、MoE、長いコンテキスト、マルチモーダル、エージェント処理のように変化し続ける。チップを完成させてからソフトウェア側が対応するだけでは、実サービスの性能を出しにくい。モデルの演算パターン、通信、メモリ利用、推論ランタイムを、早い段階から共同で調整する必要がある。

AMDは、OpenAIとシリコンからソフトウェアまでの最適化を進め、Metaとは大規模導入に向けた共同設計を進めると説明している。またCerebrasとは、Heliosの高スループットとCerebrasの低遅延計算を組み合わせる推論基盤を目指す。主要パートナーとの協業

とくにCerebrasとの協業は、推論を一つのGPUクラスタで完結させない考え方を示している。

用途ごとに得意な基盤を分ける「分離推論」は、今後の大規模推論で検討すべき設計選択肢になる。ただし基盤を分けるほど、KVキャッシュ転送、可観測性、障害時の切替、コスト配賦も難しくなる。高速化だけを目的に採用してはいけない。

AMDの「AI Everywhere」は、クラウド一極化ではない

AMDの製品群は、データセンターだけで完結していない。サーバーCPU・GPU、AI PC向けプロセッサ、組込み向けプロセッサ、Kria AI SOM、ロボティクス向け開発基盤までを並べている。 AMDのフィジカルAI関連発表

これは、AI処理の配置を次のように使い分ける市場を見ているからだ。

配置場所	向く処理	設計上の優先事項
クラウド	大規模学習、全社横断の推論	弾力性、コスト、データ移動
企業データセンター	機密データ、既存システム連携	権限、監査、ネットワーク、保守
PC	個人支援、ローカル要約、開発支援	プライバシー、端末管理、ユーザー体験
エッジ・機器	低遅延判定、現場制御、通信断対応	応答時間、安全、電力、長期供給

特にロボットや設備にAIを適用する場合、LLMへ直接モーター制御を任せる設計は危険である。AIは状況認識や高位の計画を担当し、リアルタイム制御と緊急停止は決定論的な安全系へ分離する必要がある。

AMDの狙いは、クラウドGPUだけでなく、こうした処理配置の選択肢を一社の製品群とパートナー網で提供することにある。

IT技術者が先に設計すべきなのは、性能より「実行の境界」である

エージェント型AIは、回答を生成するだけでなく、データを読み、APIを呼び、ファイルや業務レコードを変更しうる。インフラの性能を上げるほど、誤操作や過剰実行も速く、大きくなる。

必要なのは、GPUの選定と同時に、実行の境界を設計することだ。

制御対象	最低限の設計
エージェント	所有者、目的、利用期限、版を台帳で管理する
データ	検索権限、出典、更新日、持出し可否を確認する
ツール	読取りと書込みを分け、許可リストとスコープを持たせる
実行環境	サンドボックス、ネットワーク制限、時間・回数上限を置く
コスト	トークン、GPU時間、API呼出し、並列数の上限を定める
高リスク操作	金額・対象・影響に応じて人間承認を必須にする
運用	入出力、ツール呼出し、承認、変更結果を追跡可能にする

以下のような制御フローを、モデルや基盤を変えても維持できる状態が望ましい。

AI基盤は、速いほどよいわけではない。誰が、どのデータとツールを、どの上限で使えるのかを限定し、問題が起きたときに止め、原因を追い、戻せることが、本番利用の前提になる。

AMDを評価するときの調達・検証チェックリスト

AMDの今回の発表は、AI基盤がGPU単体の比較から、ラック、ネットワーク、ソフトウェア、パートナー連携を含むシステム競争へ移ったことをよく表している。ただし、発表のピーク性能やコスト性能は、どのベンダーのものであっても、自社条件で検証しなければならない。

導入検討では、次の順で確認するとよい。

業務単位を定義する：GPU利用率ではなく、「問い合わせ1件を正しく完了する時間とコスト」で測る。
推論を分ける：対話、バッチ、長文、低遅延、機密データの処理を同一基盤に詰め込まない。
CPU・ネットワークも負荷試験する：GPUを増やす前に、ツール実行、API、DB、認証、サンドボックスの飽和点を測る。
ソフトウェアの再現性を確保する：ROCm、フレームワーク、推論エンジン、モデル、量子化設定を固定し、更新前後で比較する。
障害と復旧を試験する：GPU、ネットワーク、外部APIが落ちたときの縮退、再試行、停止、ロールバックを確認する。
権限とコスト上限を先に実装する：高性能な基盤を本番へつなぐ前に、エージェント単位の最小権限と監査を整える。

AMDが目指すのは、GPUを売る企業から、オープンなパートナーエコシステムでAI基盤全体を提供する企業への拡張である。IT技術者にとっての本質的な変化も同じだ。

これから問われるのは「高性能GPUを何台導入するか」ではない。どの処理を、どこで、どのモデルと基盤に載せ、誰の権限で、どのコストと安全条件の下に動かすかを一貫して設計できるかである。

作成日：2026年7月25日