ハクソク

世界を動かす技術を、日本語で。

CUDAに挑むROCm: 一歩ずつ前進

2026年4月13日原文(eetimes.com)

概要

  • AMDはAIソフトウェアスタックROCmを強化し、NvidiaのCUDAに挑戦中
  • Nod.ai買収によりAIコンパイラ技術を獲得し、AIスタックの統合を推進
  • TritonやMLIRなど、オープンソース技術でGPU間のポータビリティを向上
  • 開発者コミュニティとの直接的な対話を重視し、迅速なフィードバック対応を実施
  • 今後10年使えるプラットフォームを目指し、ROCmの差別化機能も検討中

AMD、ROCmでCUDAに挑む ― 一歩一歩の前進

  • AMD はデータセンター向けGPU市場でNvidiaからシェアを獲得するため、 AIソフトウェアスタックROCm の成功に注力
  • Nvidia CUDA の巨大な普及基盤が最大の障壁となる現状
  • AMD VP AIソフトウェア のAnush Elangovanは「山を登るように、一歩一歩進む」と語る
    • ElangovanはスタートアップNod.aiの買収でAMDに参加
    • Nod.aiはAIコンパイラ分野で多数のオープンソースプロジェクトに貢献

ROCmの進化と開発体制

  • 買収以降2年半にわたり ROCmへ継続的投資 を実施
    • 当初は部品の寄せ集め状態だったが、現在は統一されたAIスタックへ進化
  • Google Chrome開発チームの運用手法を手本に、 6週間ごとのリリース体制 を目指す
  • ソフトウェア企業のようなスピード感と品質管理を実現

ポータビリティとオープンソース戦略

  • OneROCm 構想により、AMDのCPU・GPU・FPGA間でAIスタックを統合
    • すべてのアクセラレーションはROCmスタック経由で実行
  • Triton や MLIR などオープンソース技術を活用し、クロスGPU対応を推進
    • TritonカーネルによりAMD/Nvidia両GPUで同一コードの実行が可能
    • Torch.MLIRで異なるハードウェアへのコード最適化を実現
  • かつて主流だったCUDAからHIPへの変換は減少傾向
    • 現在はvLLMやSGLangなどLLM推論フレームワークの最適化が主流

開発者コミュニティとの連携強化

  • ROCmは100%オープンソース （ファームウェアを除く）で、コミュニティ主導のイノベーションを促進
  • 開発者コミュニティへの積極的なアウトリーチ を展開
    • Strix Halo搭載ノートPC対応で開発者の裾野拡大を狙う
    • Windowsノート向けROCmアップデートもデータセンター向けと同時リリース
  • Elangovan自身がX（旧Twitter）で「ROCm sucks」などのキーワードを監視し、直接的なサポートを実施
    • GitHubでの苦情1,000件にも1年で全対応
    • 迅速な対応がコミュニティの信頼獲得と利用拡大につながる

今後の展望と差別化

  • 2026年後半に MI450 の出荷を予定し、さらなる性能向上を図る
  • ROCmを「今後10年使える開発基盤」として進化させる方針
    • 新ハードウェア登場時も心配不要なプラットフォーム設計
  • CUDAと差別化できる独自機能の検討も本格化

まとめ

  • ROCm はAI時代のオープンなGPUソフトウェア基盤として着実に進化
  • AMD は開発者との対話とオープンソース戦略でNvidiaに挑戦
  • 「一歩一歩」の着実な前進で、次世代AIエコシステムのリーダーを目指す

Hackerたちの意見

最近の1週間くらい、TheRockをstagexに移植する作業をしてたんだけど、ROCmをネイティブのmusl/mimallocツールチェーンでビルドして、高セキュリティやプライバシーのワークロードに対応できるようにするためなんだ。バイナリが単一のコンパイラだけでビルドされるのを信頼できないからね。ちょっと悪夢みたいな作業で、30以上の依存関係とカスタマイズされたLLVMをパッケージしなきゃならなかったけど、今朝やっとランタイムがビルドできたよ。AMDハードウェアでの高セキュリティワークロードにとって明るい未来が見えてきたけど、どんなに混乱しててもオープンに動いてるからね。

└

https://github.com/ROCm/TheRock/issues/3477 は、いろんな理由でちょっと悲しい。こんなのはおかしいよ。この作業はちゃんと使えるべきなんだから。

└

私もmuslでROCmをパッケージしようとしたんだけど、特にAlpine Linux用にね。全体をビルドするのは本当に悪夢だったよ。カスタムLLVMフォークや他の十数個のパッケージはなんとかクリアしたけど、結局は時間の無駄だと思ってやめちゃった。今はvulkanサポートのあるllama.cppを使ってるけど、私の用途には十分だよ。Vulkanはもうそこにあって、普通に動くしね。多分、あなたのホストにも入ってると思うよ、他の多くのものがそれに依存してるから。そう言えば、あなたのビルドレシピを見てみたいな。もしかしたら、Alpineポートの最後の部分を乗り越えるのに役立つかも。

└

え、Nvidiaを信じてないの？ドライバーがクローズドソースだから？Nvidiaはオープンソースドライバーを改善して、プロプライエタリなものに近づけるって約束してると思うよ。Intelが追いついてくれるといいな。32GBのVRAMが約1000ドルで手に入るのはすごくアクセスしやすいし。

└

先週くらいずっと、TheRockをstagexに移植してたんだけど、ROCmをネイティブのmusl/mimallocツールチェーンでビルドして、高セキュリティやプライバシーのワークロードに対応できるようにしてるんだ。バイナリが一つのコンパイラだけでビルドされるのを信頼できないからさ。…あんた、答えられないかもしれないけど…何それ？「信頼の信頼を疑うべき」みたいなワークロードって何やってるの？「一つのコンパイラだけでビルドされたバイナリ」ってどういう意味？具体的にはどうやって動くの？コンパイラ特有のサフィックスをつけて.oファイルをコンパイルして、苦労してリンクして異なる.oを組み合わせたライブラリ/ELFを作るの？二つの異なるCコンパイラを混ぜるってこと？同じコンパイラで二つの異なるブートストラップ？レギュラー/クロスミックス？詳細を聞きすぎてたらごめんだけど、実際にコンパイラやユーザースペースをソースからブートストラップしたことがあるから、あんたのユースケースには興味があるんだ。

└

何度もこういうのを見るのは悲しいね。昨年、これを変えるために株主キャンペーンをやろうと思ったけど、AMDの約束を受けて一旦中止した。でも、やっぱりこれを実行する必要があるかもね。: https://unlockgpu.com/action-plan/

ROCmは、RX 580みたいな一般的なコンシューマGPUではサポートされてないんだ。Vulkanのバックエンドは問題なく動くけどね。

└

RX 580はGCN 4のGPUだよ。ROCmの最低要件はGCN 5（Vega）以上だと思う。

└

以前は違ったのかな？数年前、RX580でhashcatを使うためにROCmのドライバーやライブラリを使った気がするけど、今はもう古いの？

└

私もRX 5700で同じ経験をしたよ。サポートされているROCmのバージョンが古すぎてOllamaが動かないんだ。OllamaのVulkanバックエンドは私には問題なく動くけど、公式にサポートされるまでに1年か2年かかったよ。

└

私は2018年初めにRX 580を購入して、2024年末まで使ってた。AMDがRNDA1やRDNA2に基づく全てのGPUを完全にサポートしていないことには批判的だよ。後方互換性は消費者にとって常に良いけど、RX 580は2016年に出たRX 480の軽微なアップデート版だったからね。確かにROCmも2016年に出たけど、GCNアーキテクチャをサポートするのはRDNA/CDNA世代をサポートするのとは全然違うって認めてもいいと思ってる（Vegaはまるで独自の島にいるみたいで、何を言えばいいのかもわからない）。RX 580を再利用できるのはクールだけど、2026年にGCN GPUが新しいライブラリバージョンでサポートされないのは全く驚かないよ。もしRDNA1 GPUやサポートが悪いRDNA2 GPUを持ってたら、もっとイライラしてたと思う。

└

ROCmは通常、消費者向けGPUの2世代しかサポートしてなくて、最新世代のサポートが遅れることもあるよ。現在サポートされているのはRDNA 3とRDNA 4（RX 7000と9000）だけだよ。https://rocm.docs.amd.com/projects/install-on-linux/en/lates... これは理想的じゃないね。比較のために言うと、CUDAはまだTuring（RDNA 2より2年古い）をサポートしてるし、CUDA 12にダウングレードするとMaxwell（約2014年）にも少しサポートがあるよ。

Hacker Newsで議論の続きを見る