AMDは、GPUソフトウェアの性能調整を専門家の手作業からエージェントの反復作業へ移そうとしている。2026年7月23日に発表した「ROCm.AI」は、ROCmのランタイムや数値計算ライブラリを置き換える新SDKではない。既存のROCm Core SDKの上に、エージェント用の知識、再現可能なコマンド、システム監視、自律最適化を重ねる開発体験である。

狙いは明快だ。AMD製GPUでAIモデルを動かすまでに必要な環境構築と、動いた後の性能調整を同じ導線へまとめる。公開されたコードを見ると、その構想はすでに動き始めている。一方で、製品ページがInstinctからRadeon、Ryzen AIまでを描くのに対し、自動最適化を担うHyperloomの検証範囲はInstinctの3製品に限られる。ROCm.AIの価値を測るには、広い製品構想と初期実装を分けて見る必要がある。

AD

ROCm本体を置き換えず、開発体験を上に重ねる

ROCmの基盤側では、ROCm Core SDK 7.14.0が7月15日に公開された。この版はビルド・リリース基盤をTheRockへ移し、コアをランタイムやコンパイラなどの基本部品へ絞った。AI、データサイエンス、HPC向けの機能は用途別SDKとして切り離し、必要な部品だけを導入できる構成へ変えている。

ROCm.AIは、このモジュール化された基盤のさらに上で開発作業をまとめる。AMDが公開した構成は、役割と成熟度が異なる4要素から成る。

要素 担う仕事 公開時点の状態
ROCm Core SDK ランタイム、コンパイラ、数値計算・通信ライブラリ 7.14.0を7月15日に公開
AMD Skills コーディングエージェントへAMD検証済みの手順を渡す カタログ全体がTech Preview
ROCm CLI／Console 導入、環境確認、モデル配信、更新、診断、監視 Tech Preview、nightlyビルドのみ
ROCm Hyperloom 推論ワークロードを測定し、設定やコードを変更して再検証 公開Quickstartは1.0.0a1

この分業によって、自然言語の指示を受けるエージェントと、決められたコマンドをスクリプトからも実行できるCLIを切り離せる。エージェントが直接シェルを組み立て続けるのではなく、Skillsが意図をAMDの推奨手順へ落とし、CLIが実行する設計だ。CI/CDや複数人の開発環境では、作業を再現しやすくなる。

CLIとSkillsが狙う「最初の一歩」の短縮

ROCm CLIはLinuxとWindows向けの単一バイナリとして開発され、既存のROCmやPython環境を前提としない。rocm install sdkはTheRock版のROCm wheelと対応するPyTorchを管理環境へ導入し、既存のROCm環境とは分けて保持する。rocm examineでGPUと実行環境を調べ、rocm serveでOpenAI互換のモデルサーバーを起動する。推論エンジンはRadeon／Ryzen向けのLemonadeと、Instinct向けのvLLMを使い分ける。

AMD Skillsは、そのCLIや既存ツールをClaude、Cursor、Codexなどから呼ぶための作業手順だ。現在のカタログには、Instinct上でvLLMを配信するスキル、PyTorchのプロファイラートレースを解析するTraceLens、ローカルAIをアプリへ組み込む手順などが並ぶ。ドキュメントを検索してコマンドをつなぐ負担を、AMD側が保守する実行可能な知識へ移す発想である。

ただし、発表で前面に出た機能の一部はまだ計画段階だ。ROCm、PyTorch、llama.cppの設定不良を診断するrocm-doctorや、カーネル最適化を呼び出すhyperloom-kernel-optimizerは、公式カタログでplannedまたはcoming soonとされている。ROCm CLIも安定性を保証しないTech Previewで、公開ビルドはnightlyだけだ。現在使える部品はあるが、ROCm.AIという一続きの製品体験は完成していない。

AD

Hyperloomは性能調整を測定と検証の反復へ変える

Hyperloomは、動いている推論ワークロードを速くする作業を自律的なループへ組み替える。まず基準性能を測り、Magpieで収集したトレースをTraceLensが解析する。見つかったボトルネックに応じて配信設定やホスト側コードを直し、Arborが最適化の探索範囲を広げ、GEAKが負荷の高いGPUカーネルを調整する。その後に再びベンチマークを実行し、性能と正しさを検証して変更案を報告する。

これはコード補完とは異なる。Hyperloomは「測る、変える、もう一度測る」を長時間回し、変更ごとに結果を比較する。人がボトルネックを読み解いて設定値やカーネルを書き直してきた工程を、プロファイラーと複数のエージェントへ分配する仕組みだ。ただし、正しさの検証は用意されたテストとワークロードの範囲に限られ、任意のコードに対する保証にはならない。

現行版の適用範囲は狭い。Hyperloom 1.0.0a1の互換表が挙げるGPUはInstinct MI300X、MI325X、MI355Xで、OSはUbuntu 22.04または24.04、ROCmは7.2.xである。SGLang 0.5.12以上かvLLM 0.21.0以上も必要になる。最新のROCm Core SDKは7.14.0であり、Hyperloomとの組み合わせは公開互換表で検証済みとされていない。製品ページに載るRadeon、Ryzen AI、最新のInstinct MI455Xも、現時点のHyperloom検証表にはない。

運用時には上流LLMも必要だ。QuickstartはAnthropicへのアクセスを前提とし、認証文書はAnthropicとOpenAIのAPIを分けて接続する方法や、自社のLiteLLM互換ゲートウェイを使う方法を示している。したがって、Consoleのテレメトリーが手元に残ることと、最適化処理が完全にオフラインで閉じることは同義ではない。企業は、外部モデルがどのコードやトレースへアクセスできる構成なのかを確認し、利用規約と併せて管理する必要がある。

勝負はモデル性能より、再現できる運用になる

ROCm.AIが埋めようとしているのは、GPUの演算性能そのものより、ハードウェアを使える状態へ持っていくまでの距離だ。ROCm 7.14.0はPyTorch 2.12.0、JAX 0.10.0、vLLM 0.23.0、SGLang 0.5.13、TensorFlow 2.21を対応対象に加えた。しかし、対応表に載ることと、個々のGPUで適切な版を選び、モデルを配信し、期待した性能まで調整できることの間には作業が残る。

SkillsとCLIは、その作業をAMDが検証する定型手順へ変える。Hyperloomは、配信後の性能調整まで同じ考え方を延ばす。ここが定着すれば、開発者はROCmの全コンポーネントを覚える前に、AMD GPU上で検証を始められる。MLOpsチームにとっても、担当者の経験に依存していた設定と診断を、バージョン管理できるスキルとコマンドへ移せる。

もっとも、AMD自身も性能向上率はワークロードやモデルで変わると注記している。GPUとソフトウェア環境、開始時点も結果を左右する。現段階で一般的な倍率を置くことはできない。採用判断を動かすのは、CLIの安定版、計画中のSkills、Hyperloomの新GPU・新ROCm対応が同じ検証済み構成で揃い、実案件のコードで再現可能な改善を示せるかどうかである