CUDAに挑むROCm：「一歩ずつ前進する」
(eetimes.com)- AMDはNvidia CUDAエコシステムに対抗するため、AIソフトウェアスタック ROCmを軸にデータセンターGPU戦略を強化している
- ROCmは初期の単純なファームウェアの寄せ集めから完全なソフトウェアプラットフォームへと進化し、6週間周期のリリース体制を導入して安定した使い勝手を確保しつつある
- OneROCmを通じてCPU、GPU、FPGA間のAIスタック統合と移植性の確保を推進し、Triton・MLIRベースのコード再利用で開発効率を高めている
- ROCmはファームウェアを除く全構成要素をオープンソース化し、コミュニティの革新スピードを取り込みつつ、Strix HaloノートPCとWindows版でも標準サポートされる
- AMDは開発者フィードバックへの対応とコミュニティの信頼回復を重視し、ROCmを今後10年間持続可能な開発者中心プラットフォームへ発展させることを目指している
AMD ROCmの進化とCUDA対抗戦略
- AMDはデータセンターGPU市場でNvidiaのCUDAエコシステムに対抗するため、AIソフトウェアスタック ROCmを中核戦略として推進している
- AIソフトウェア部門副社長 Anush Elangovanは、ROCm開発を「山を登るように一歩ずつ前進する過程」と表現し、継続的な改善と統合を強調した
- 彼はスタートアップ Nod.ai の買収を通じてAMDに加わり、NodチームはShark、Torch.MLIR、IREEなど主要なオープンソースプロジェクトへの貢献実績を持つ
- AMDはROCmを通じて**CPU、GPU、FPGA間のAIスタック統合（OneROCm）**を進め、ソフトウェア開発サイクルを6週間単位に短縮し、「ユーザーがバージョンを意識しなくてよい水準」を目標としている
- ROCmは現在、AI支援エンジニアリングへの転換を準備しており、オープンソースエコシステムと開発者コミュニティ中心の拡大を加速している
ROCmの発展とソフトウェア戦略
- ROCmは当初、複数のファームウェア断片を束ねた形だったが、2年半の投資を経て完全なソフトウェアプラットフォームへと発展した
- ElangovanはGoogle Chromeチームの開発文化をベンチマークし、定期的なリリース周期と安定したユーザー体験を目標とした
- ROCmは「ただ動く」ソフトウェアとして定着しつつあり、今後は6週間周期のリリース体制へ移行する予定である
- AMDはハードウェア中心企業からソフトウェア中心企業への転換を進めており、次の段階として**AI支援エンジニアリング（AI-assisted engineering）**を重要な転換点と位置づけている
AIスタック統合と移植性
- AMDはOneROCmを通じてCPU、GPU、FPGAなど多様なハードウェア間でのAIスタック統合を実現している
- 一部の構成要素は依然としてハードウェア依存だが、すべてのアクセラレーションはROCmスタックを通じて実行されるため、**移植性（portability）**を確保できる
- Tritonフレームワークの普及により、GPU間の互換性問題は緩和されている
- 以前はCUDAカーネルをHIPカーネルへ変換していたが、現在ではTritonカーネルを書けばAMDとNvidiaの両方で実行可能になっている
- AMDはTritonおよびMLIRコンパイラインフラに積極投資しており、Torch.MLIRの保守を通じて多様なハードウェアへのコード再ターゲティングを支援している
- 推論顧客の大半はvLLM、SGLangなどのLLMフレームワークを利用しており、CUDAコード変換の要望は減少している
- 新しいattentionアルゴリズムが登場しても、Tritonベースのカーネルを1〜2日で最適化できる
- HIPifyは依然としてHPC顧客向けに提供されており、新しいカーネル作成にはClaude AIを活用して検証とコード生成を行っている
オープンソース戦略
- ROCmはファームウェアを除く全構成要素を100%オープンソースで公開している
- オープンソース化により開発者コミュニティの検証を受けると同時に、AMDより速いコミュニティの革新スピードを活用できる
- 誰でもコンパイラ、ランタイムなど任意のレイヤーから参加でき、AMDの協業速度に縛られない
- AMDは開発者コミュニティの拡大を積極的に進めており、Strix Halo搭載ノートPCでROCmが標準サポートされる
- Instinctデータセンターハードウェアと同じ日にWindows版ROCmアップデートを配布している
開発者コミュニティとフィードバック文化
- Elangovanは開発者との直接的な対話を重視し、**X（Twitter）**を通じてリアルタイムでフィードバックを収集している
- 「ROCm」「ROCm sucks」「AMD software not working」などのキーワードを監視し、すべての投稿に直接対応している
- 問題の大半は教育とサポート不足に起因しており、匿名の開発者にも直接助言している
- AMDはGitHubでROCm関連の1,000件以上の不満を調査し、1年以内にすべて解決した
- 旧世代ハードウェアのサポート要望が多く、現在はAMDまたはコミュニティが保守している
- こうした対応により開発者の信頼は回復し、「AMDは問題を解決する」という認識が広がった
- ElangovanはMI450 GPU（2026年下半期発売予定）への期待を示し、ROCmを今後10年間持続可能なプラットフォームへ育てると強調した
- 新しいハードウェアが登場しても開発者が心配せずに済む安定したエコシステム構築を目指している
今後の方向性と哲学
- ElangovanはNod.ai時代の経験を踏まえ、コンパイラ技術がほぼすべてのアクセラレータ企業に採用された事例に言及した
- 彼は「確信を持って一歩ずつ前進しなければならない」と述べ、ROCmの発展を継続的な実行の結果と定義した
- AMDはCUDAを単に複製するのではなく、差別化されたROCm機能を開発しており、長期的には開発者中心プラットフォームとしての地位確立を目指している
2件のコメント
まずはドライバから……
Hacker News の意見
先週、TheRock を stagex に移植しながら、ROCm を musl/mimalloc ベースのツールチェーンでビルドしようとしていた
セキュリティとプライバシーが重要なワークロードでは、単一のコンパイラだけでビルドされたバイナリは信頼できないためだ
30 を超える依存関係とカスタム LLVM のパッケージ化に悪夢のような時間がかかったが、今朝ついにランタイムのビルドに成功した
AMD ハードウェアが完全にオープンな環境で動作するという点のおかげで、高セキュリティのワークロードに希望が見える
カスタム LLVM フォークや複数のパッケージは乗り越えたが、結局は時間の無駄だと思って諦めた
今は Vulkan 対応の llama.cpp を使っていて、十分満足している
もしビルドレシピを共有してくれるなら、Alpine への移植の最後の段階を越える助けになると思う
去年は AMD の約束を信じて株主キャンペーンを止めたが、今は本当に行動が必要だと感じている
unlockgpu.com/action-plan
こんな形であってはいけないし、この作業は明らかに 実用可能であるべきだ
Nvidia もオープンソースドライバを改善すると約束している
個人的には、Intel が 32GB VRAM を 1000 ドル程度で提供している点のほうが魅力的だ
異なるコンパイラで .o ファイルを混在させてリンクする方式なのだろうか？
もしかして Reflections on Trusting Trust の問題を実際に回避しようとしているワークロードなのか気になる
2 月から AMD に gfx1201 向けに最適化された Tensile カーネルを rcom-libs に入れてほしいと依頼しているが、誰も担当者を知らない
開発者向け Discord でも返答がなく、もどかしい。技術的な問題だけでなく、AMD の組織的なボトルネックが表れている例のようだ
zichguan-amd や harkgill-amd が関係する担当者かもしれない
AMD は ROCm に関して、まだ 数年分の差を埋めなければならない
AI 演算が可能な自社 GPU ですらすべてをサポートしているわけではなく、サポートされていてもバグが多い
Linux 向け AMDGPU ドライバは 6.6 以降ずっと不安定だ
AI が重要になることを見抜けなかったのは明らかな失策だ
AMD が競争力を持てば業界全体にとって良いことなのに、これは自業自得だ
昔の ATI 時代からバグの多いドライバで悪名高く、AMD に買収された後もその文化が変わっていないように見える
去年、AMD は GitHub で ROCm に関する不満を集め、1000 件すべて解決したと発表した
しかし実際には、旧ハードウェアのサポートはほとんど増えていない
ROCm がすべての AMD カードで発売と同時にサポートされる日が来て、初めて宣伝を信じられる気がする
以前、400 シリーズのような当時の最新カードすら切り捨てたのは大きな失敗だった
経営陣にはソフトウェアスタックにもっと投資してほしい
ROCm は RX 580 のような一般消費者向け GPU ではサポートされていない
その代わり Vulkan バックエンドはうまく動く
GCN アーキテクチャのサポート終了はもう当然だと思うが、RDNA 世代では依然としてサポート不足が問題だ
現在は RDNA3・RDNA4 のみ対応で、CUDA は今でも Turing までサポートしている
公式ドキュメント 参照
Vulkan バックエンドはうまく動くが、正式サポートまでに 1〜2 年かかった
ROCm スタックを**整理(clean-up)**してほしい
単に
git clone --recurse-submodules rocmのあと configure/make でビルドできて、不足している依存関係を明確に表示してほしい今は構造なしに複数のコンポーネントを放り込んだだけのようで、一貫したアーキテクチャが見えない
私は OpenVINO と SYCL で CUDA に対抗する側だ
Intel の iGPU・dGPU は最近、価格も妥当でソフトウェアサポートも良くなってきた
ゲーム用ではなく CV やデータサイエンスのワークロードではかなりうまくスケールする
AMD 経営陣に伝えたい ROCm についてのフィードバックだ
(1) サーバー向け GPU だけをサポートし、コンシューマー向け GPU/APU を無視したのは戦略的な失敗だ
開発者の大半はまず個人のノート PC で試し、その後サーバーへ拡張する
CUDA のように性能が低くても、コンシューマー向け GPU で動くようにすべきだ
(2) 2 世代しかサポートしない方針は顧客の立場から見て不合理だ
公式ドキュメント 参照
CUDA は強力な下位互換性を維持している
(3) Triton にばかり注力して HIP を二級扱いするのは間違った方向だ
依然として C/C++ ベースの HPC・シミュレーション・科学技術計算コードは多い
AMD GPU は FP64 性能が強みなのに、それを自ら捨てているようなものだ
(4) 最後にパッケージ品質を改善すべきだ
ディストリビューションのパッケージャと協力するのに大きなコストはかからず、Nvidia に対する競争優位にもなり得る
Python、Julia などさまざまな言語からカーネルを直接書けて、IDE・デバッガ・ライブラリ統合も素晴らしい
GPGPU エコシステム全体で見ると、AMD と Intel はまだ CUDA のエコシステム完成度に追いついていない
ほとんどの企業は
/opt/foo/のようなベンダーインストール方式を選ぶそうすればディストリビューション側が後から独自にパッケージ化しやすくなる
だがこれを理解するには、オープンソースのエコシステム経験がある人材が必要だ
高 VRAM のコンシューマー向け GPU の投入を遅らせ、サーバー市場に集中している
AMD がこの隙をうまく突ければチャンスになるかもしれない
たとえば 7900 XT でも問題なく動く
単に AMD がテストリソースを投じていないため、「公式サポート」と表示していないだけだ
以前 コンピュートシェーダを扱った経験では、CUDA、ROCm、OpenCV はどれもインストールが面倒すぎる
依存関係も大きく、CUDA は 11GB もある
ただ Vulkan を使うほうがいいと思う。プラットフォーム依存もなく、「ただ動く」
シェーダのコンパイルとリソース設定だけでも数百行必要で、GPU アドレスを扱うには拡張が必要になる
それが何時間もかかる作業なのかと思う
以前は NVIDIA でグラフィックスモードに切り替えると性能が 20% 向上するバグ（？）もあった