公式ドキュメントを開くと ROCm 7.14.0 と書いてある。ところが自分のWindows環境に入っているのは 7.2.1 だ。
「Windowsは置いていかれているのか」「7.14を入れたほうが速いのか」と思うところだが、結論から言うとその比較自体が成立していない。 7.2.1と7.14.0は、そもそも別の系統の番号だからだ。
この記事では、ややこしくなっている番号体系を整理して、自分がどれを入れるべきかを判断できるところまで持っていく。あわせて、最近よく名前を見る TheRock が何なのかにも触れる。
【結論】番号の大小ではなく「系統」で選ぶ
先に答えを出す。ROCmの7.x系には2つの系統があり、番号を見れば見分けがつく。
| 本番系統（production） | 技術プレビュー系統 | |
|---|---|---|
| 番号 | 7.0 〜 7.8 | 7.9.0 以降 |
| 最新（2026年8月時点） | 7.2.4（2026-05-29） | 7.14.0（2026-07-15） |
| ビルドシステム | 従来のもの | TheRock |
| 位置づけ | 常用向け | 評価・先取り向け |
| Windowsの安定配布 | 7.2.1（repo.radeon.com） | ナイトリーのwheelで入る |
AMDの公式ドキュメントには、はっきりこう書かれている。
Versions 7.0 through 7.8 are reserved for production stream ROCm releases, while versions 7.9.0 and later listed on this page represent the technology preview release stream.
つまり 7.9以降の番号は、全部プレビュー系統である。 7.9.0、7.10.0、7.11.0、7.12.0、7.13.0、そして7.14.0。これらは本番系統の続きではない。
だから「7.2.1より7.14.0のほうが新しい」という読み方が、そもそも間違っている。 系統が違うものの番号を大小で比べていることになる。
迷ったときの判断
- 常用したい → 本番系統。WindowsならROCm 7.2.1
- とにかく速さを試したい → プレビュー系統。ただし後述の実測を読んでから
【なぜ紛らわしいのか】公式の「latest」がプレビューを指している
そもそも、なぜこんなに分かりにくいのか。原因は公式ドキュメントの導線にある。
rocm.docs.amd.com/en/latest/ を開くと、表示されるのは 7.14.0 のドキュメントである。「latest」を見に行った人は、そのままプレビュー系統に着地する。
さらに厄介なことに、そのページのリリース一覧は本番とプレビューを混ぜて並べている。
| バージョン | リリース日 | 系統 |
|---|---|---|
| 7.14.0 | 2026-07-15 | プレビュー |
| 7.2.4 | 2026-05-29 | 本番 |
| 7.2.3 | 2026-05-04 | 本番 |
| 7.2.2 | 2026-04-14 | 本番 |
| 7.2.1 | 2026-03-25 | 本番 |
| 7.2.0 | 2026-01-21 | 本番 |
| 7.1.1 | 2025-11-26 | 本番 |
| 7.1.0 | 2025-10-30 | 本番 |
一覧に「これはプレビューです」という印は付いていない。 上から順に読めば、7.2.4の次が7.14.0に見える。番号が7.3〜7.13まで飛んでいるように見えるのもこのためだ。
飛んでいるように見える番号は、実際にはプレビュー系統として存在している。
| プレビュー版 | リリース日 |
|---|---|
| 7.14.0 | 2026-07-15 |
| 7.13.0 | 2026-05-15 |
| 7.12.0 | 2026-03-26 |
| 7.11.0 | 2026-02-11 |
| 7.10.0 | 2025-12-11 |
| 7.9.0 | 2025-10-20 |
「7.15」や「7.2.5」を探しても見つからないのは、まだ存在しないからである。プレビュー系統は7.14.0が現行で、本番系統は7.2.4が最新だ。7.2.5で検索している人は、1つ先を打っている。
【ROCmとTheRockの違い】製品とビルドシステム
プレビュー系統の説明に必ず出てくるのが TheRock である。ROCmの後継や別製品だと思われがちだが、そうではない。
- ROCm … AMDのGPUコンピューティング用ソフトウェアスタックそのもの（製品）
- TheRock … そのROCmをビルドして配布するための仕組み（ビルドシステム）
正式名称は The HIP Environment and ROCm Kit。公式リポジトリでは「a lightweight open source build system for HIP and ROCm」と説明されている。
つまり両者は対立する概念ではなく、「作られるもの」と「作る道具」の関係にある。
なぜ作り直しているのか
従来のROCmはモノリシックなビルドで、AMDは次の点を改善するとしている。
| 従来 | TheRock |
|---|---|
| ビルドが遅く、失敗しやすい | より速く確実なコンパイル |
| Linuxディストリビューションごとにビルドが必要 | ManyLinux_2_28準拠で1ビルドから複数ディストロへ |
| パッケージが大きい | アーキテクチャ別のPythonパッケージで容量を削減 |
そして重要なのは、中身のコードは2系統でほぼ共通だという点である。違うのはビルド方式・パッケージング・ドライバ統合であって、機能が大きく別物になっているわけではない。
2つを並走させているのは、利用者が新しいビルド方式へ移行する時間を確保するためだと説明されている。
The technology preview stream is planned to continue through mid-2026, after which it will replace the current production stream.
予定では2026年半ばにプレビューが本番系統を置き換えるはずだった。 だが2026年8月末の現在、両方の系統がまだ並走している。移行は予定より後ろにずれているとみてよい。
【Windowsでの入手経路】実は4つある
「WindowsのROCm」と一口に言っても、入手経路は1つではない。ここが最も混乱しやすいところで、それぞれ番号が違う。
| 経路 | バージョン | 性格 |
|---|---|---|
| 1. PyTorch on Windows（repo.radeon.com） | 7.2.1 | AMD公式の安定版。ドライバ要件あり |
| 2. HIP SDK for Windows | 7.2.0（2026-07-31） | 開発ツール一式。別配布・別番号 |
| 3. プレビュー系統のナイトリーwheel | 7.9以降（7.11 / 7.14 など） | TheRockビルド。Windows向けも配布されている |
| 4. TheRockをソースからビルド | 任意 | MSVCが必要。公式が「まだ成熟していない」と明言 |
経路1：安定版はrepo.radeon.comで止まっている
repo.radeon.com/rocm/windows/ に実際に置かれているのは、この4つだけである。
rocm-rel-6.4.4 2025-09-23
rocm-rel-7.1.1 2025-11-25
rocm-rel-7.2 2026-01-20
rocm-rel-7.2.1 2026-03-187.2.1が置かれたのが3月18日で、それ以降5か月以上、ここは動いていない。 Windows向けの環境構築記事が7.1.1と7.2の2本しか無いのは、単に3本目が存在しないからだ。
なお公式は次のように明記している。
Pytorch on Windows includes ROCm 7.2.1 components; however, the entire ROCm stack is not yet supported on Windows.
Windowsで動くのはROCmの一部であって、全部ではない。
経路2：HIP SDKは別番号で動いている
HIP SDK for Windowsは、上とは別の配布物で、番号も別に振られている。最新は7.2.0で、リリースは2026年7月31日。
ここがややこしい。日付は経路1の7.2.1（3月）より新しいのに、番号は小さい。 番号だけで新旧を判断すると必ず間違える。
経路3：プレビュー版もWindowsに入る
TheRockは LinuxとWindowsの両方にPyTorchのナイトリーパッケージを提供している。 つまり7.11や7.14といったプレビュー系統も、Windowsで動かせる。
「7.14はLinux専用」という話ではない。入るが、安定版とは配布経路もサポート水準も違うというだけである。
経路4：ソースビルドはまだ厳しい
TheRockを自分でビルドする道もあるが、公式の現状認識はこうだ。
While Windows source builds of TheRock (including PyTorch!) are working for some expert developers, this support is relatively new and is not yet mature.
コンパイラ一式やmath系ライブラリ、MIOpenは動く。一方でプロファイラやRCCL、そして rocminfo などのコアユーティリティは未対応である。
この rocminfo が未対応という点は覚えておいたほうがいい。 「ROCmのバージョン確認は rocminfo で」と書いてある解説は多いが、プレビュー系統では通用しない。
【対応GPU】RX 9070 XTはgfx1201
ROCm関連のドキュメントは製品名ではなく gfx番号 で書かれていることが多い。自分のGPUがどれなのかを先に押さえておくと読み違えない。
| gfx | 製品 |
|---|---|
| gfx1201 | RX 9070 XT / RX 9070 / RX 9070 GRE / AI PRO R9700S / R9700 / R9600D |
| gfx1200 | RX 9060 XT LP / RX 9060 XT / RX 9060 |
当ブログで使っている RX 9070 XT は gfx1201 である。
ポチップ
対応リストに入っていないGPUを使っている場合、Windowsネイティブでの環境構築は現状かなり厳しい。PCごと組み替えるならBTO、そもそもローカルで持たずに済ませたいならブラウザで動くサービスという選択肢もある。
Windows（ROCm 7.2.1）の対応環境
| 項目 | 内容 |
|---|---|
| 対応アーキテクチャ | gfx1201 / gfx1200 / gfx1100 / gfx1101 |
| 対応GPU | RX 9070 / RX 9070 XT / AI PRO R9700 / RX 9060 XT / RX 7900 XTX / PRO W7900 / PRO W7900 Dual Slot / RX 7700 |
| OS | Windows 11 |
| Python | 3.12 |
| PyTorch | 2.9 系 |
| グラフィックスドライバ | 26.2.2 以上 |
注意すべきはドライバである。 7.2.1を使うには 26.2.2 が要る。ROCmのバージョンだけ上げてもドライバが古いままなら動かないので、先に確認しておきたい。
そして RX 9060 XT が対応リストに入っている。 9070系より手頃なカードでも、公式サポートの範囲で画像生成環境を組める。
【確認方法】自分が何を使っているのか調べる
前述のとおり rocminfo はプレビュー系統では使えない。PyTorch側から確認するのが確実である。
python -c "import torch" 2>nul && echo Success || echo Failure
python -c "import torch; print(torch.cuda.is_available())"
python -c "import torch; print(f'device name [0]:', torch.cuda.get_device_name(0))"
python -m torch.utils.collect_env本命は最後の python -m torch.utils.collect_env で、PyTorchのバージョン、ビルドに使われたROCmのバージョン、HIPランタイム、GPUのgfx番号までまとめて出る。
以下は公式ドキュメントに載っている出力例である（筆者の環境ではない点に注意）。
PyTorch version 2.9.1+rocm7.2.1
ROCm version 7.2.53211-158bd99533
HIP runtime version 7.2.53211
GPU AMD Radeon AI PRO R9700 (gfx1201)2.9.1+rocm7.2.1 のように、PyTorchのバージョン文字列にROCmの番号が入る。 ここを見れば、自分がどちらの系統を使っているのか一発で分かる。
【実測】プレビュー版を入れると、速くなるのか
ここまでは仕組みの話である。実際のところ、プレビュー系統を入れると速くなるのか。
当ブログでは以前、RX 9070 XT環境で ROCm 6.4 / 7.1 / 7.11（ナイトリー） の3つを比較している。この7.11こそ、プレビュー系統をWindowsに入れたものだ。
結果は次のとおりだった。
| モデル | 6.4 | 7.1 | 7.11（プレビュー） |
|---|---|---|---|
| SD1.5（512×512・8枚） | 15.57秒 | 6秒台 | 6.75秒（7.1と誤差） |
| SDXL（1024×1024・1枚） | 23.35秒 | 8秒台 | 8.90秒（7.1よりわずかに遅い） |
| FLUX.1 | 188.94秒 | — | 133.59秒（20%高速） |
SD1.5とSDXLでは、プレビュー版を入れる意味がほとんどない。 7.1との差は誤差の範囲で、SDXLに至ってはわずかに遅かった。
一方でFLUX.1だけは明確に差が出た。 6.4と比べて55秒以上短縮され、7.1と比べても20%速い。高負荷時のメモリ管理まわりの改善が効いている可能性が高い。
詳細な条件と全データは元記事にある。
なお、6.4系を使い続けている場合は話が別だ。 SDXLで23秒が9秒になるので、バージョンを上げる効果は系統の議論より遥かに大きい。 まずここを済ませたい。
【結局どうするか】3パターンで答える
これから入れる人 → 7.2.1
repo.radeon.com/rocm/windows/ の rocm-rel-7.2.1 を使う。ドライバを26.2.2以上に上げてから取りかかること。Pythonは3.12を用意する。
手順は別記事にまとめてある。
7.1.1で動いている人 → 急いで上げなくてよい
7.1.1と7.2.1の間で、生成速度が劇的に変わるという結果は出ていない。動いている環境を壊してまで上げる理由は薄い。 ドライバ更新のタイミングで一緒に、くらいでよい。
ただし 6.4系の人は上げるべきである。ここは速度が明確に違う。
7.14を見て混乱した人 → それはプレビュー系統
Windowsが遅れているわけではない。 本番系統の最新は7.2.4で、Windowsには7.2.1が来ている。7.14.0はTheRockで作られたプレビュー系統の番号であり、比較する相手が違う。
FLUX.1をメインで使っていて、20%の差に価値を感じるなら、ナイトリーのwheelを試す意味はある。それ以外の用途なら、安定版で困らない。
バージョンの組み合わせを追いかけるのが面倒になったら、環境ごと用意されているサービスに逃がすのも手ではある。
まとめ
- ROCmの7.x系は 本番系統（7.0〜7.8）とプレビュー系統（7.9以降） に分かれている
- TheRock はROCmの後継ではなく、ROCmをビルドして配布する仕組み
- Windowsの安定版は 7.2.1 で、2026年3月から更新が止まっている
- プレビュー系統もWindowsに入る。ただし配布経路もサポート水準も違う
- 7.2.1にはドライバ26.2.2とPython 3.12が要る
- 実測では SD1.5・SDXLで差は出ず、FLUX.1でのみ20%速かった
番号が大きいほうが新しい、という直感が通じないのが今のROCmである。迷ったら、まず自分が使っているのがどちらの系統かを collect_env で確認するところから始めたい。
RadeonでのAI系まとめはこちら。
参考文献
コメント