前回の記事で、ROCm 10 は「Windows対応と書いてあるが、配布物がまだ無い」と書いた。そして「配布されたら測って追記する」とも書いた。
その前提が間違っていた。配布は既に始まっていた。探す場所が変わっていただけである。
この記事では、Windows の RX 9070 XT に ROCm 10 を実際に入れて、当ブログで以前測った ROCm 6.4 / 7.1 / 7.11 と同じ条件でベンチマークを取った結果をまとめる。
結論を先に言うと、速くなるかどうかはモデルによって逆になる。
【結論】上げるべきかは、動かすモデルで決まる
| モデル | ROCm 7.11 | ROCm 10.0.0 | |
|---|---|---|---|
| SD1.5（512×512・8枚） | 6.75秒 | 7.72秒 | 14%遅い |
| SDXL（1024×1024・1枚） | 8.90秒 | 8.27秒 | 7%速い |
| FLUX.1（1024×1024・1枚） | 133.59秒 | 41.33秒 | 3.23倍速い |
- FLUX.1を回すなら、上げる価値がある。133秒が41秒になる
- SD1.5しか使わないなら、上げないほうがいいかもしれない。実測で遅くなった
- SDXLは誤差の範囲。急いで上げる理由はない
そして、この記事でいちばん言いたいのはここである。
- バージョンより起動オプションのほうが効く。ただし効くのはMIOpenだけで、SD1.5/SDXLで31〜38%。FLUX.1には効かない（09-12 訂正。詳細は後述）
【入手先】「まだ無い」のではなく、置き場所が変わっていた
前回、筆者は repo.radeon.com/rocm/windows/ を見て「Radeon向けの配布物はまだ無い」と判断した。
この場所については、いまも正しい。
| ディレクトリ | 日付 |
|---|---|
| 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-18（最新） |
rocm-rel-10.0/ を直接叩くと 404 が返る。ここだけ見れば「無い」で正しい。
だが ROCm 10 は別のホストで配られていた。
| 置き場所 | Windows向けの中身 |
|---|---|
repo.radeon.com/rocm/windows/ | 7.2.1（2026年3月から更新なし） |
repo.amd.com/rocm/whl-multi-arch/ | 7.13 / 7.14 / 7.14.1 |
stable.repo.amd.com/rocm/whl-next/ | 10.0.0 |
ROCm 10 は TheRock ベースになり、配布が pip のインデックス形式へ移った。インストーラは今も無い。公式のリリース情報にも「native packages は planned」と書かれている。
「Windows版がまだ無い」ではなく、「インストーラが無く、pipのwheelだけがある」が正確な現状である。
RX 9070 XT 向けのランタイムは、tarballでも落とせる。
therock-dist-windows-gfx120X-all-10.0.0.tar.gz
2,282,922,923 バイト（約2.28GB）/ 2026-08-26gfx120X は gfx1200 / gfx1201、つまり RX 9060 XT と RX 9070 / 9070 XT のことだ。
【導入】pipのコマンド2行で入る
7.2.1 までは、wheelのURLを4本直接pipに渡す形だった。ROCm 10 はインデックスを指定するだけになった。
事前にやること
- AMD Software: Adrenalin Edition を最新に
- 既存の HIP SDK for Windows をアンインストール
- WDAG（Windows Defender Application Guard）を無効化
- SAC（Smart App Control）を無効化
SACの無効化は慎重に判断してほしい。この機能は以前、一度オフにするとクリーンインストールしないと戻せなかった。2026年3月26日の KB5079391 で再インストール不要になったが、段階的な展開なので端末によっては旧仕様のままである。
オフにする前に、設定 → Windows Update → 更新の履歴でこの更新が入っているか確認しておきたい。
仮想環境を作る
Python は 3.11 / 3.12 / 3.13 / 3.14 に対応している。
py -3.14 -m venv .venv
.venv\Scripts\activate
python -m pip install --upgrade pip7.2.1 のwheelは cp312 固定だった。「ROCmを使うにはPythonを3.12に落とせ」という手順が各所に書かれているが、ROCm 10 ではその制約が無くなっている。筆者は 3.14.4 でそのまま入った。
ただし ComfyUI 側が新しいPythonに対応しているかは別問題なので、迷うなら 3.12 が無難だ。
ROCm本体を入れる
python -m pip install --index-url https://stable.repo.amd.com/rocm/whl-next/ "rocm[libraries,device-gfx1201]==10.0.0"device-gfx1201 が RX 9070 / 9070 XT を指す。RX 9060 / 9060 XT なら device-gfx1200 になる。公式は全GPU向けの device-all を例示しているが、そちらは無駄に大きい。
PyTorchを入れる
python -m pip install --index-url https://stable.repo.amd.com/rocm/whl-next/ "torch[device-gfx1201]" "torchvision[device-gfx1201]" torchaudio確認する
python -c "import torch; print(torch.__version__)"
python -c "import torch; print(torch.cuda.is_available())"
python -c "import torch; print(torch.cuda.get_device_name(0))"【要注意】True と出ても、掴んでいるのはRyzenの内蔵GPUだった
ここで筆者は引っかかった。確認コマンドは全部通ったのに、実際に動いていたのは別のGPUだった。
python -c "import torch; print(torch.cuda.is_available())"
→ True
python -c "import torch; print(torch.cuda.get_device_name(0))"
→ AMD Radeon(TM) Graphics「AMD Radeon(TM) Graphics」は RX 9070 XT ではない。collect_env を見ると正体が分かる。
GPU models and configuration: AMD Radeon(TM) Graphics (gfx1036)gfx1036 は Ryzen 9 7900X の内蔵GPUである。Ryzen 7000/9000シリーズのデスクトップCPUには小さなGPUが載っていて、それが0番として先に列挙されていた。
エラーは一切出ない。そのまま画像生成を始めれば、ただ異常に遅いだけである。
2台列挙されている
python -c "import torch; n=torch.cuda.device_count(); print(n)"2
0 AMD Radeon(TM) Graphics gfx1036
1 AMD Radeon RX 9070 XT gfx1201ComfyUIでは起動オプションで指定する
環境変数 HIP_VISIBLE_DEVICES を設定する手もあるが、ComfyUIでは効かない場面がある。起動ログにこう出る。
[WARNING] On windows we are currently forcing single GPU mode in ComfyUI
due to a Nvidia related issue, if you want to disable this use: --cuda-device allComfyUIはWindowsで強制的にシングルGPUモードになり、0番＝内蔵GPUを選ぶ。フラグで指定するのが確実だ。
python main.py --cuda-device 1環境変数と併用してはいけない。HIP_VISIBLE_DEVICES=1 を残したままだと1台しか見えなくなり、--cuda-device 1 が範囲外になる。
内蔵GPUで動いていると、何が起きるか
実際に両方で起動して比べた。
| gfx1036（内蔵GPU） | gfx1201（RX 9070 XT） | |
|---|---|---|
| ComfyUIのVRAM表示 | 36,674 MB | 16,304 MB |
| flash attention | エラーで無効化 | 正常 |
| hipバックエンドのカーネル数 | 31個 | 36個 |
VRAMが36GBと出たら、それは内蔵GPUがシステムメモリを見ている。RX 9070 XT なら 16,304 MB である。ここがいちばん分かりやすい判別点になる。
そして内蔵GPUのときは、こんな警告が出ていた。
[WARNING] Could not run flash attention, disabling it:
CUDA error: device kernel image is invalid (hipErrorInvalidImage)これを見て「ROCm 10 では flash attention が使えない」と結論づけてはいけない。device kernel image is invalid は「別のアーキテクチャ向けにビルドされたカーネルを読もうとした」という意味で、gfx1201用のカーネルを gfx1036 に載せようとして失敗しているだけだ。GPUを正しく指定したら、この警告は消えた。
内蔵GPU側では int8_linear na3d sol_attn など5つのカーネルも欠けていた。速度以前に、使える機能が減る。
【制約】tritonのWindows版は無い
起動ログにはっきり出る。
[INFO] Found comfy_kitchen backend triton:
available: False / unavailable_reason: ImportError: No module named triton配布インデックスを直接確認しても、tritonだけ win_amd64 のwheelが存在しない（Linux版はある）。triton前提の高速化は、現時点のWindowsでは使えない。
ただし「何もできない」わけではない。hipバックエンドは有効で、量子化やRoPE系を中心に36個のカーネルが使える。
【計測条件】以前の記事と1文字も変えていない
当ブログでは以前、同じRX 9070 XT環境で ROCm 6.4 / 7.1 / 7.11 を比較している。そのときのルールをそのまま使った。
- バッチカウントで8回測定し、初回と最大値、最小値を除いた5回の平均値をとる
- シード値は「1234567890」からインクリメント
| モデル | モデル名 | 解像度 | サンプラー | ステップ | バッチサイズ |
|---|---|---|---|---|---|
| SD1.5 | v1-5-pruned-emaonly-fp16 | 512×512 | Euler | 20 | 8 |
| SDXL | juggernautXL_ragnarokBy | 1024×1024 | Euler | 30 | 1 |
| FLUX.1 | FLUX.1 [dev] | 1024×1024 | Euler | 20 | 1 |
今回の環境
| 項目 | 値 |
|---|---|
| GPU | Radeon RX 9070 XT 16GB |
| CPU | Ryzen 9 7900X |
| RAM | DDR5 64GB |
| OS | Windows 11 Home 26200 |
| PyTorch | 2.13.0+rocm10.0.0 |
| Python | 3.14.4 |
| ComfyUI | 0.35.0 |
そして、起動オプションを変えて2回測った。
- 最小:
--cuda-device 1のみ - 最適化: MIOpen有効・
MIOPEN_FIND_MODE=FAST・--use-pytorch-cross-attentionほか
【結果】モデルによって、向きが逆になる
| SD1.5（8枚） | SDXL（1枚） | FLUX.1（1枚） | |
|---|---|---|---|
| ROCm 6.4 | 15.57秒 | 23.35秒 | 188.94秒 |
| ROCm 7.1 | 6.85秒 | 8.72秒 | 169.36秒 |
| ROCm 7.11 | 6.75秒 | 8.90秒 | 133.59秒 |
| ROCm 10（最小） | 7.72秒 | 8.27秒 | 41.33秒 |
| ROCm 10（最適化） | 5.95秒 | 6.84秒 | 35.35秒 |
| 7.11との差（最小） | 14%遅い | 7%速い | 3.23倍速い |
| オプションの効果（GUI計測・後日訂正） | −23% | −17% | −14.5% |
※ オプションの効果は後日 API で1つずつ測り直した。効いていたのはMIOpenだけで、FLUX.1 の −14.5% は再現しなかった。詳しくは【本題】の追記。
FLUX.1は本当に速くなった
133.59秒 → 41.33秒。3.23倍である。しかもこれは最適化オプションを一切使わない状態の数字だ。
以前の記事では、6.4 → 7.1 で10%、7.1 → 7.11 でさらに20%縮んで133.59秒になったと書いた。今回はその上でさらに3.2倍縮んでいる。FLUX.1を回している人にとっては、上げる理由がはっきりある。
SD1.5は遅くなった
6.75秒 → 7.72秒。14%の後退である。
ROCm 7.1 の時点で 6.85秒まで来ていて、7.11 でも 6.75秒とほぼ変わらなかった。そこから初めて明確に遅くなった。
SDXLはほぼ変わらない
8.90秒 → 8.27秒。7%速いが、7.1 の 8.72秒と比べれば5%で、誤差と呼んでいい範囲だ。
なぜ逆になるのか
3モデルを並べると、傾向が見える。
| モデル | 性質 | ROCm 10 の効き |
|---|---|---|
| SD1.5 | 小さい・畳み込み主体・バッチ8 | 遅くなる |
| SDXL | 中間 | ほぼ変わらない |
| FLUX.1 | 大きい・transformer（DiT） | 3.23倍 |
ROCm 10 の改善が、畳み込みではなく attention や行列積の側に寄っていると考えると筋が通る。ただし筆者はそこまで測っていないので、これは推測である。
【本題】バージョンより、起動オプションのほうが効いた
この記事でいちばん実用的なのはここだと思う。
| オプションの効果 | |
|---|---|
| SD1.5 | −23%（7.72 → 5.95秒） |
| SDXL | −17%（8.27 → 6.84秒） |
| FLUX.1 | −14.5%（41.33 → 35.35秒） |
3モデルすべてで14〜23%縮んだ、というのがこの記事を書いた時点の結論だった。この数字は後日訂正している（この章の末尾）。SD1.5でバージョンアップで失った14%を取り返して、なお速いという結論は変わらない。むしろ効きは大きかった。
使ったのはこれだ。
set COMFYUI_ENABLE_MIOPEN=1
set MIOPEN_FIND_MODE=FAST
set COMMANDLINE_ARGS=--use-pytorch-cross-attention --auto-launch --preview-method auto※ 公開時は set VAE_KL_MEM_RATIO=2.0 も入れていたが、この環境では sd.py を書き換えていないので、この行は何もしていなかった。削除した（09-12）。
MIOpenを有効にすると、ComfyUIの挙動が変わる。最小オプションのときだけ、起動ログにこの行が出た。
[INFO] Set: torch.backends.cudnn.enabled = False for better AMD performance.MIOpenを有効にした場合、この行は出ない。畳み込み主体のSD1.5で効果が最大（−23%）だったのは、ここが素直に効いているのだろう。
4つのうちどれが効いたかは、この時点では分離できていなかった。後日、条件ごとにComfyUIを起動し直して1つずつ測った結果がこれである（API計測・GPU空き・8ラン5回平均）。
| モデル | 指定なし | MIOpenのみ | 全部入り |
|---|---|---|---|
| SD1.5 | 7.62秒 | 4.72秒（−38%） | 4.72秒 |
| SDXL | 8.20秒 | 5.67秒（−31%） | 5.66秒 |
| FLUX.1 | 34.8秒 | 35.8秒 | 35.6秒 |
- 効いていたのは
COMFYUI_ENABLE_MIOPEN=1だけ。これ1つで全部入りと同じ --use-pytorch-cross-attentionは ROCm 10 + gfx1201 では既定で有効。書いても変わらない- FLUX.1 の −14.5% は再現しなかった。上の表の 41.33秒 と 35.35秒 は GUI で別セッションに測ったもので、差はオプションではなく計測条件のぶんだった
- 本文の「−23% / −17%」は GUI とプレビュー描画込みの数字で、API で測ると効きはもっと大きい（−38% / −31%）
11条件の全データと、前回の高速化記事のソース改変が ROCm 10 では逆効果だった話は、こちらにまとめた。
なお、この構成を組むならGPUはここを参考にしてほしい。
ポチップ
FLUX.1は22.7GBをステージングする。16GBのVRAMには収まらないので、メインメモリにも余裕が要る。
ポチップ
【限界】この記事で測れていないこと
数字を出しておいて言うのも何だが、この比較には揃っていない条件がある。先に書いておく。
- 以前の記事に起動オプションの記載が無い。6.4 / 7.1 / 7.11 を測ったときが既定だったという保証はない
- ComfyUIのバージョンが 0.7.0 から 0.35.0 に上がっている。ROCmだけの差ではない
- FLUX.1の3.23倍の原因を分けられていない。22.7GBを16GBに載せている以上、計算が速くなったのか、メモリ管理が改善したのかは判別できない。実際、初回のランだけサンプリングが1.4〜1.6倍速いという妙な挙動も出ている
- 4つの起動オプションのうち、どれが効いたか分離していない
したがって「ROCm 10 で3.23倍速くなった」とは書けない。書けるのは「この環境で、この条件で、3.23倍だった」までである。
まとめ
- ROCm 10 の Windows 版は「まだ無い」のではなく、置き場所が
stable.repo.amd.comへ移っていた - インストーラは今も無い。pipのwheelだけで、公式にも native packages は planned とある
- pipのコマンド2行で入る。7.2.1 のようにwheelのURLを並べる必要は無くなった
- Pythonの3.12固定が解けた。3.11〜3.14に対応している
- True と出ても内蔵GPUを掴んでいることがある。Ryzenのデスクトップは要注意。VRAMが36GBと出たら疑う
- ComfyUIはWindowsで強制シングルGPU。
--cuda-device 1で指定する hipErrorInvalidImageは「GPUを間違えている」サイン。flash attentionが壊れているのではない- tritonのWindows版は無い。ただしhipバックエンドは36カーネル使える
- FLUX.1は133.59秒→41.33秒（3.23倍）。SD1.5は6.75秒→7.72秒（14%後退）
- バージョンより起動オプションのほうが効く。ただし効くのはMIOpenだけ（SD1.5/SDXLで31〜38%）。FLUX.1には効かない（09-12 訂正）
「最新に上げれば速くなる」という話ではなかった。自分が何を動かしているかで、答えが変わる。FLUX.1を回すなら上げたほうがいい。SD1.5だけなら、上げる理由は無い。
そして、上げる前に起動オプションを見直したほうが早い。
参考文献
コメント