AMD ROCmのCUDA追い上げはどこまで来たか

EE Timesが2026年4月15日に公開したAMDのAnush Elangovan氏（AI Software VP）へのインタビューを読んだ。
ROCmがCUDAにどこまで迫れるかという話で、自分もStrix HaloでROCm環境を使っている。
正確に言うと「使おうとして何度も壊れる環境と格闘してきた」立場で、記事の内容に実体験を加えて整理する。

そもそもなぜGPU推論なのか

GPUは複雑な計算が苦手なデバイスだ。
CPUのように条件分岐を高速に処理したり、異なるタスクを柔軟に切り替えたりはできない。
じゃあなんでAI推論にGPUが使われるのか。

答えは単純で、AI推論の計算がGPUの得意な形をしているから。

CPUは少数の高性能コア（数個〜数十個）で、複雑な命令を順番にこなす。
分岐予測、アウトオブオーダー実行、大容量キャッシュといった、汎用的な処理を速くするための仕組みが詰まっている。
一方GPUは数千〜数万の小さなコアで、同じ計算を大量のデータに対して一斉に実行する。
1つ1つのコアは単純だが、並列度が桁違いに高い。

AI推論の正体は行列演算の塊。
大規模言語モデルが1トークン生成するたびに、数十億パラメータの重み行列に対して積和演算を繰り返す。
「同じ単純な計算を、膨大なデータに対して並列に実行する」、まさにGPUのために存在するような計算パターンだ。

特性	CPU	GPU
コア数	数個〜数十個	数千〜数万
1コアの能力	高い（複雑な命令を処理）	低い（単純な演算のみ）
得意な処理	分岐が多い逐次処理	同じ計算の大量並列実行
AI推論との相性	悪い（並列度が足りない）	良い（行列演算の並列処理）

ただし、GPUは生のハードウェアだけでは何もできない。
「PyTorchのモデル定義」を「GPU上で動く並列カーネル」に変換するソフトウェア層が必要になる。
行列演算の分割方法、メモリの配置、カーネルのスケジューリング。
この変換を担うのがCUDAやROCm、Metalといった計算基盤。

つまり、GPUの性能を引き出せるかどうかは上で動くソフトウェアスタックの質で決まる。
ハードウェアの演算能力がどれだけ高くても、ソフトウェアが変換をミスれば性能は出ないし、そもそも動かない。
ROCmで「ゴミトークンが出る」のも、Metal経由で「BF16が遅い」のも、GPUハードウェアの問題ではなくソフトウェアスタックの問題。

この前提があると、CUDAが強い理由もROCmが苦しい理由も、ハードの性能勝負ではないことが見えてくる。

CUDAが強すぎる理由

GPU計算基盤の話になると「GPUの性能が〜」みたいな話になりがちだが、本質はそこじゃない。
CUDAが圧倒的なのはソフトウェアエコシステムの厚みによるもの。

CUDAは2006年のリリースから約20年かけて以下を積み上げてきた。

開発ツール（Nsight、cuda-gdb、nvprof）
ライブラリ（cuDNN、cuBLAS、NCCL、TensorRT）
ドキュメントとサンプルコード
CUDA経験者の人材プール
フレームワーク側の最適化（PyTorch、TensorFlow、JAX）

AI開発は事実上CUDA前提で動いている。
PyTorchのコードをGitHubで検索すると.cuda()の呼び出しがハードコードされている例が大量に見つかる。
OSSのREADMEに「Requirements: NVIDIA GPU」と書いてあるのが当たり前の状態。

これはロックイン（囲い込み）ではあるが、使う側からすると「全部揃ってる」環境は圧倒的に楽。
動かないモデルに遭遇する頻度が段違いに低い。

ROCmの公式戦略

インタビューでElangovan氏が語っていた内容を整理する。

Nod.ai買収によるコンパイラ基盤強化

AMDは2024年にAIコンパイラ企業Nod.aiを買収した。
モデルの最適化と異なるハードウェアへの移植性向上が目的で、ROCmのソフトウェアスタックで最も弱かったコンパイラ層を補強する動き。

Elangovan氏はROCmを「ASICファームウェアの提供を通じて支えられるエコシステム」と表現しており、異なるAMD GPU世代間で反復的に改善を積み重ねる方針を示している。

OneROCmイニシアチブ

AMDハードウェアのバリアント間で統一的なアクセラレーションを実現する「OneROCm」構想。
MI300XとRadeon RX 9070とStrix Haloで同じROCmコードが動く世界を目指している。

ただしNVIDIA GPUからAMD GPUへの移植性には依然として課題がある。
CUDAコードの変換はHIPIFYツールがあるものの、多くの開発者にとって非自明な作業。
実際には直接変換より、vLLMやSGLangなどの上位フレームワーク経由で最適化するアプローチが実用的。

オープンソース戦略

ROCmはオープンソース寄りの路線を取っている。
CUDAのような囲い込みではなく、コミュニティからの貢献を歓迎する姿勢。
OpenAIのTritonフレームワークを使ったクロスプラットフォームカーネル開発など、コミュニティ主導の解決策も模索されている。

戦略としては正しい方向を向いていると思う。
ただ、自分の環境で起きたことを振り返ると、戦略と現実の間にはまだかなりの距離がある。

Strix HaloでROCmが4回壊れた話

ここからは、自分がEVO-X2（Ryzen AI Max+ 395 / Radeon 8060S）でROCm環境を使ってきた実体験の話。
EE Timesの記事で語られている「ROCmの進歩」は事実だが、実際のユーザー体験はもっと泥臭い。

第1幕: ROCmが動かない

EVO-X2でローカルLLM環境を構築したとき、最初に直面したのがROCmの非対応だった。
OllamaはデフォルトでROCmバックエンドを優先するが、Strix Halo（gfx1151）は対応GPU一覧に入っていない。
ロードの時点でクラッシュするか、CPUフォールバックになる。

結局LM StudioのVulkanバックエンドに切り替えて、ようやくGPU推論が動いた。
AMDのGPUを使っているのにAMD公式のROCmが動かず、いきなりVulkan経由という回り道を強いられた。

第2幕: Qwen 3.5全滅事件

Qwen 3.5をOllamaで動かそうとしたときは、もっとひどかった。

バックエンド	結果
ROCm（Ollama）	ロードできるがゴミトークン無限ループ
Vulkan（Ollama）	ロードすらできずクラッシュ
Vulkan（LM Studio）	ロードできるが推論開始でクラッシュ
Metal（Mac）	正常動作

ROCmでは「associates传递更多信息ivitprest」という意味不明なトークン列が延々ループ。
最初はabliterationが重みを壊したと思ったが、公式版でも同じゴミが出る。
同じモデルをMacのMetalバックエンドで動かしたら一発で動いた。
モデルは壊れていない。ROCmのgfx1151向けカーネルがQwen 3.5のアーキテクチャに対応できていなかっただけ。

全バックエンド全滅で、Windows上ではQwen 3.5を動かす手段がなかった。

第3幕: ドライバ更新で一括解決

ドライバを26.2.2に更新したら、別世界になった。
Vulkan経由でQwen 3.5が34〜54 t/s出るようになり、VRAMの共有メモリ優先問題も解消。やっとEVO-X2のGPUがまともに使えるようになった、と思った。

第4幕: ドライバ26.3.1でまた壊れた

AMD Software 26.3.1に更新したら、また壊れた。
症状は多岐にわたった。

Vulkan経由でモデルをロードすると成功扱いだが、実際はCPUフォールバック（54 t/s → 9.5 t/s）
空きVRAMが54GBあるのに ErrorOutOfDeviceMemory でロード失敗
mmap=true でモデルの出力が壊れる（中国語・日本語・英語が混ざった意味不明な文字列）
Vulkanのロード失敗を繰り返すとデバイスメモリがリークし、PC再起動まで回復しない

最終的にBIOSのVRAM配分を48GB/16GBから32GB/32GBに変更することで解決した。
VRAMを減らしたら逆にQ6_K（26.8GB）が載るようになるという直感に反する結果。
ドライバがモデルロード時にシステムRAMを転送バッファとして使うため、システム側の空きが足りないとVRAMに余裕があっても失敗する。

これで4回目のトラブルシュート。
ドライバ更新のたびにBIOSのVRAM配分の最適解が変わるのがStrix Haloの現状だ。

壊れ方の共通パターン

4回の格闘で見えてきたパターンがある:

ドライバ更新 → 何かが壊れる
原因切り分けに数時間〜数日（ドライバ？llama.cpp？モデル？BIOS設定？）
回避策を見つける（BIOS変更、--no-mmap、バックエンド切り替えなど）
次のドライバ更新まで安定稼働
1に戻る

CUDAなら5分で終わる作業に何時間もかかるのは本当で、しかも原因がドライバなのかアプリなのかハード構成なのか、切り分け自体が難しい。

Apple Siliconは安定しているが速度は出ない

EVO-X2と並行してMac（M1 Max 64GB）も使っている。
こちらはROCmの阿鼻叫喚とは無縁で、Metalバックエンドは安定して動く。
ただし、最初からすごい速度なんか出ない。

実測データ

用途	環境	結果
Qwen 72B推論	Ollama / Metal	5.3 t/s
動画生成（Wan 2.2、2秒）	ComfyUI / MPS	82分
Qwen Image Edit（4step）	ComfyUI / MPS	80秒→アプデ後10分に劣化
BF16 matmul	PyTorch / MPS	FP16の2倍遅い（M1〜M3はBF16ハードウェア非対応）

Mac（Apple Silicon）は「安定して動くが遅い」のが特徴。
CUDAのH100が2秒で終わる動画生成に82分かかる。
ハードウェアの方向性が違うので仕方ない。
Unified Memoryはローカル推論のVRAM制約を回避できる利点があるが、演算性能自体はNVIDIA GPUに遠く及ばない。

MLXという光明

Apple専用フレームワークのMLXは方向性が正しい。
PyTorch MPS経由の問題（BF16の遅さ、FP16 Attentionバグ）を回避でき、ComfyUIの検証ではmflux + MLX + Lightning LoRAでPyTorch MPS経路と同等の速度を黒画像リスクなしで達成した。

ただしMLXのエコシステムはまだ限定的で、対応モデルも少ない。
ローカル推論に特化した独自路線としては最強だが、CUDAの代替にはならない。

GPU計算基盤の全体構図

ハードとソフトの階層を整理すると、勝負がハードウェアではなくソフトウェアスタックの厚みで決まることがわかる。

レイヤー	NVIDIA	AMD	Apple
ハードウェア	H100 / B200	MI300X / MI350	M4 Ultra
低レイヤAPI	CUDA	ROCm (HIP)	Metal
AI特化ライブラリ	cuDNN, TensorRT	MIOpen	MLX
フレームワーク対応	PyTorch (ネイティブ)	PyTorch (ROCm)	PyTorch (MPS/MLX)
エコシステム成熟度	圧倒的	追い上げ中	限定的
推論サーバー	TensorRT-LLM, vLLM	vLLM (ROCm)	mlx-lm

NVIDIAは全レイヤーで自社完結しているのに対し、AMDはフレームワーク層以上をコミュニティに依存している。
Appleはローカル推論に特化した独自路線。

graph TD
    A[AIアプリケーション] --> B[推論フレームワーク<br/>vLLM / SGLang / mlx-lm]
    B --> C[AIフレームワーク<br/>PyTorch / JAX]
    C --> D1[CUDA + cuDNN]
    C --> D2[ROCm + MIOpen]
    C --> D3[Metal + MLX]
    D1 --> E1[NVIDIA GPU<br/>H100 / B200]
    D2 --> E2[AMD GPU<br/>MI300X / Radeon]
    D3 --> E3[Apple Silicon<br/>M4 Ultra]

    style D1 fill:#76b900,color:#fff
    style D2 fill:#ed1c24,color:#fff
    style D3 fill:#555,color:#fff

実務での使い分け

CUDA（NVIDIA）を選ぶべきケース

本番AIサービスの運用
大規模モデルの学習
OSSをそのまま動かしたい
トラブルを最小限に抑えたい

ほぼ全てのAIコードがCUDA前提。
バグに遭遇する確率が圧倒的に低い。
迷ったらCUDA。これは今も変わらない。

ROCm（AMD）を選ぶべきケース

GPUコストを下げたい（MI300XはH100より安価なケースが多い）
ベンダーロックインを避けたい
OSSコードを多少いじれるエンジニアがいる
トラブルシューティングに時間を使える覚悟がある

メリットはコストとオープン性。
ただし自分の経験を正直に書くと、「動かないモデルが普通にある」「ドライバ更新で壊れる」「壊れたときの原因切り分けが困難」が現実。
LLM-jp-4のROCmベンチマークでは62.9 t/sが出ていて性能自体は高い。
LemonadeのようなAMD公式ツールも改善が進んでいる。
ただしGPUの価格差で浮いたコストが人件費で消える可能性は本当にある。
Strix Haloの場合、VRAM配分の最適化からドライバのリグレッション対応まで、GPU以外の要素に時間を取られる。

MLX（Apple Silicon）を選ぶべきケース

ローカル推論（速度より安定性重視）
エージェント運用（軽量モデル）
開発・検証環境

Macで完結し、Unified MemoryによるKVキャッシュ効率が強い。
ただし学習はほぼ無理で、OSS対応もまだ限定的。
速度はNVIDIAの桁違いに遅いが、「動く」という安心感はある。
ROCmのように「ドライバ更新したら壊れた」が起きないのは大きい。

選定フローチャート

graph TD
    Q1{本番サービス?} -->|YES| A1[CUDA一択]
    Q1 -->|NO| Q2{大規模学習?}
    Q2 -->|YES| A2[CUDA推奨]
    Q2 -->|NO| Q3{コスト最優先?}
    Q3 -->|YES| A3[ROCm検討<br/>トラブル対応力が必要]
    Q3 -->|NO| Q4{ローカル開発?}
    Q4 -->|YES| A4[MLX / ROCm]
    Q4 -->|NO| A5[CUDA]

    style A1 fill:#76b900,color:#fff
    style A2 fill:#76b900,color:#fff
    style A3 fill:#ed1c24,color:#fff
    style A4 fill:#555,color:#fff
    style A5 fill:#76b900,color:#fff

ROCmが「使える」ラインはどこか

自分がStrix HaloでROCmとVulkanを使ってきた経験も踏まえて、現実的な境界線を整理する。

使えるライン

PyTorch公式サポート範囲内の操作（学習・推論）
HuggingFaceの主要モデル（Llama系、Qwen系、Mistral系）
llama.cppのROCmバックエンド（hipBLAS）。ただしGPUターゲット（gfxXXXX）が対応済みの場合
vLLMのROCm対応（MI300X以上が現実的）
llama.cppのVulkanバックエンド。ROCmが使えない場合の現実的な逃げ道

ただし「使える」と「安定して使える」は別物。
Lemonade検証でもVulkanの共有メモリ漏れとROCmの安定性の差が見えた。
動くことは動くが、CUDAと同じ信頼性で動くかというと、まだそこには達していない。

まだ厳しいライン

カスタムCUDAカーネルを含むOSSプロジェクト（手動移植が必要）
TensorRTに依存する推論パイプライン
マルチGPUの分散学習（NVLink相当のインターコネクトがない環境）
CUDAのエコシステムツール（Nsight等）に代わるデバッグ環境
新しいGPUターゲット（gfx1151のようなRDNA 3.5以降）での安定動作

最後の項目は自分の経験そのもの。
gfx1151はllama.cppのROCmカーネルもVulkanドライバも成熟しておらず、Qwen 3.5が全滅したのもドライバ更新でVulkanが壊れたのも、新しいGPUターゲットゆえの問題だった。

CUDAから移行する現実的な条件

移行対象のコードがPyTorchの標準APIに収まっていること
カスタムCUDAカーネルを使っていないこと
ROCmのバグを踏んだときに自力で調査できるエンジニアがいること
「動くまでに時間がかかる」ことを許容できるスケジュールであること
ドライバ更新で壊れたときに自力で回避策を見つけられること

条件3〜5が実質的に同じことを言っている。
「ROCmの問題を自力で解決できるか」が移行可否の最大の分水嶺。

今後の見通し

短期的にはCUDA優位が揺るがない。
中期的にはROCmが「代替手段」として存在感を強める。
OpenAI TritonやApache TVM（機械学習コンパイラ）のような中間層が成熟すれば、長期的にはマルチバックエンド化が進む可能性もある。

EE Timesのインタビューは前編（Part 1）で、後編にはさらに踏み込んだ話が出てくるかもしれない。公開されたら追記する。

自分はStrix HaloでROCmとMLXの両方を使い続けているが、CUDAなら5分で終わる作業に何時間もかかることがまだある。
初期セットアップからVRAM配分攻略、Ollama全滅、ドライバで解決、ドライバでまた壊れたと、もう何回壊れて何回直したかわからない。
それでもAMDの方向性は正しいと思うし、LemonadeやLLM-jp-4のROCmベンチマークのように、ローカル環境ではROCmの実用性が着実に上がっている。
ただ、AMDが語る「未来」と、ユーザーが体験する「今日」の間には、まだドライバ1回分のリグレッションが埋まっている。