ハクソク

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

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

27日前原文(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年）にも少しサポートがあるよ。

└

Vulkanバックエンドは問題なく動くよ。ただし、C++、Fortran、PythonのJITカーネルに対するファーストクラスのサポートがないVulkan開発者体験に制約されることを望むならね。IDE統合、グラフィカルデバッグ、ライブラリも含めて。

ずいぶん前にコンピュートシェーダーをいじってた経験から言うと、cudaやrocm、opencvをセットアップするのはめっちゃ面倒くさい。ツールキットやSDKを動かすのに数時間かかるし、そもそも動かせるかどうかも怪しい。依存関係も大きすぎるし、cudaは11GBもあるの？とにかく、Vulkanを使った方がいいよ。Vulkanは「そのまま動く」し、NvidiaやAMDに縛られないからね。

└

Vulkanも別の理由で面倒くさい。インストールは簡単だけど、シェーダーのコンパイルやリソースの設定には数百行のコードが必要だし、CUDAみたいにGPUアドレスを扱うための拡張も必要になる。

└

ハハ。もうみんなが言ってるけど、Vulkanって実際にはすごく複雑な低レベルAPIで、最もシンプルなことを動かすために200行以上のコードを書く必要があるんだ。NVIDIAでVulkanを使って計算するのも、仕様をそのまま信じるなら楽しいけど、信じないなら純粋な計算パイプラインをグラフィカルモードに切り替えてウィンドウとスワップチェーンを使うだけで、パフォーマンスが約20%上がるんだよ。これがバグなのか意図された動作なのかは分からないけど（CUDAを守るためかも）、数年前はこんな感じだった。

AMDはROCmで自社のデバイスがちゃんと動くようにするために、何年も追いつかなきゃいけない。AIができる自社のグラフィックカードを全部サポートしてるわけじゃないし、サポートされてもバグが多い。Linux用のAMDGPUグラフィックドライバーは6.6以降ずっと不安定だし、なんでもっと優秀なソフトウェアエンジニアを雇えないのか理解できない。

└

彼らがそれにお金を払う気がないから？

└

年数が経っても。彼らはROCmをずっと無視してたよ。5年以上前にそこで働いてた友達が、ROCmにもっと投資するように経営陣を必死に説得しようとしたけど、失敗したんだ。AIが重要なワークロードになっているのを見えないようにするには、かなり深く砂に頭を突っ込んでないと無理だよ。AMDには競争力を持ってほしいな。NVIDIAがあまり支配的でない方が、業界全体が良くなると思う。でも、これはAMD自身が招いたことだよ。100%そうだね。

└

どうして彼らがもっと優秀なソフトウェアエンジニアを雇えないのか理解できない。世界で最も価値のある企業と人材を争っている上に、「会社を賭ける」レベルの財政的苦境からまだ10年も経ってないのに？

私は「OpenVINOでCUDAに挑戦するチーム」だよ（SYCL*もね）。最近、IntelはiGPUとdGPUの性能をかなり上げてきてるし、価格もまともでソフトウェアサポートやAPIも結構良い感じ。ゲーム用のCUDAじゃなくて、CVやデータサイエンスのワークロードはArcでうまくスケールするし、Core Ultra 2/3のEdgeでもちゃんと動くよ。

現在のROCmの状況についてAMDの経営陣にちょっとフィードバックを。 (1) - サーバーグレードのハードウェアだけをサポートして、ノートPCやコンシューマーグレードのGPU/APUを無視するのは、戦略的に大きなミスだよ。多くの開発者はまず個人のノートPCで実験して、後で高価なプロフェッショナルグレードのハードウェアにスケールするんだから。さらに、サーバーグレードのハードウェアを買うお金がない開発者もいる。ROCmをサーバーグレードのGPUだけに制限することで、OSS ROCmエコシステムへの貢献者のリストを大きなAIユーザーやいくつかのHPCセンターに制限しちゃってる…つまり、実質的に誰もいないってこと。もっと賢い戦略は、コンシューマーGPU上でROCmのパフォーマンスを落とすことを提供することだよ。これがNvidiaのCUDAがやってることだし。これは変わりつつあるけど、はっきりしたメッセージを送る必要がある。新しくリリースされたデバイスはすべてROCmにしっかりサポートされるべきだ。 - (2) - たった2世代のアーキテクチャだけをサポートするのは、顧客が望んでいることじゃない。 https://rocm.docs.amd.com/projects/install-on-linux/en/docs-... 既存のGPUコードベースを持っている人は、ROCmをサポートするためにかなりの努力を投資している。エコシステムがまだ不安定なときに「ごめん、もう更新できないよ！」って言うのは受け入れられない。CUDAは後方互換性に優れている。これを完全に無視するのはマイナスだよ。 (3) - Tritonに専念して、HIPを二級市民扱いするのはナンセンスだ。AIが今は注目を集めてお金も集まっているのは分かる。表面的にはPythonベースのAIに焦点を当てるのは理にかなっているように見えるけど、C++やCに依存しているコードが膨大にあって（HPC、シミュレーション、科学、画像処理など）、それは今後数十年にわたって残るんだ。これを無視するのは、再びCUDAに顧客を奪われることになる。AMDのGPUがFP64で非常に競争力があることを考えると、こういう動きは皮肉だよ。自分たちの競争優位性を捨ててるようなもんだ… (4) - 最後に、ソフトウェアソリューションのパッケージングにも少し注力してほしい。これについては過去5年間不満が出ていて、あまり変わってない。ディストリビューションのパッケージャーと連携して統合するのはそれほどコストがかからないはず…これが現在、Nvidiaに対する競争優位性を与えることになる。

└

追加のポイントとして、CUDAはポリグロットで、C++やC、Fortran以外の言語でカーネルを書くことを気にする人もいるんだ。コード生成を経ずにね。NVIDIAはPythonの採用を認めていて、cuTileやMLIRのPythonサポートを提供しているから、C++と同じ柔軟性を持たせている。カーネルでもPythonを直接使えるようにしてるみたいだ。Juliaにも同様の機能を持たせることを支持しているようだし。IDEやグラフィカルデバッガーの統合、ライブラリエコシステムも、今ではPythonのバリエーションが出てきている。グラフィックスプログラミングに興味がある私にとって、AMDやIntelがCUDA、エコシステム全体が実際に何を意味しているのかを理解できていないのは難しい。ランダムなGTCカンファレンスのスケジュールを見て、今のoneAPIやROCmでどれだけ再現できるか考えてみて。

└

実際、ロックは全くないよ。新しい、公式にサポートされていないROCmのバージョンを使って、7900 XTで動かすことができるし、公式にサポートされていないカードでもちゃんと動くんだ。ただ、AMDは自分たちのテストスイートを私のカードに対して実行して、公式にサポートされる必要があるとは思ってないみたい。もしPyTorch以外のことをやってたらバグに遭遇するかもしれないけど、これは怠慢であって悪意ではないよ。

└

サーバーグレードのハードウェアだけをサポートして、ノートパソコンやコンシューマーグレードのGPU/APUを無視するのは、戦略的に大きなミスだよね。多くの開発者はまず自分のノートパソコンで実験して、後から高価なプロフェッショナルグレードのハードウェアにスケールアップするんだから。NVIDIAも今、サーバー市場に焦点を当てるために高VRAMのコンシューマーグレードGPUのリリースを後回しにして同じ間違いを犯してる。彼らはすでに大きな優位性を持ってるから、そんなに痛手ではないけど、AMDにとってはチャンスだと思う。

ROCmがCUDAと同じようにリリース時にすべてのAMDカードをサポートする日が来たら、初めてこのマーケティングの誇大広告を信じるよ。ここで本当に失敗してるし、最近リリースされた400シリーズのようなカードを見捨てたのもダメだね。経営陣が自分たちの頭を冷やして、ソフトウェアスタックにもっと投資してくれることを願ってる。

昨年、AMDはROCmに関する不満のためにGitHubでアンケートを実施し、1,000件以上の回答を得たんだって。多くは古いハードウェアのサポートに関するもので、今はAMDかコミュニティがサポートしてるけど、1年経って、1,000件の不満はすべて解決されたってエランゴヴァンが言ってた。1000人の不満を持ってる人が年を取って死ぬのを待ってたんじゃないかと思うけど、どの古いハードウェアにサポートを追加したのか全然わからないよ。

└

もし、たくさんある矛盾したウィキの中から情報を見つけて、自分のカードを特定のROCmバージョンにハックする方法を見つけられたら、それはカウントされるんじゃないかな。

2月からずっと、AMDにgfx1201用のチューニングされたTensileカーネルをrcom-libsに出荷してもらうように頼んでるんだけど、Ollamaが使ってるのに、開発者Discordの誰もそれを担当してる人を知らないんだ。かなりイライラしてるし、AMDには技術的な問題に加えて、組織的な問題を克服する必要があるってことがわかるよ。

ROCmは本当にイライラする（バグが多いし、依存関係が面倒だし、ハードウェアサポートが限られてる）。TinyGradはハードウェアに直接ターゲットを絞った独自のコンパイラとツールチェーンを作ったんだ。しかも、ROCmよりも広いデバイスサポートがあるみたいで、ROCmは主にデータセンターのGPUに焦点を当ててる感じだね。