以前、RadeonでComfyUIを速くする4つの設定という記事を書いた。環境変数が2つ、起動オプションが1つ、そしてComfyUI本体のソースを書き換えるものが2つ。書き換えについては「ComfyUIをアップデートすると消える」と注意も書いた。
その後、ROCm 10 を入れて、同じ設定をまとめて有効にしたところ、3モデルとも速くなった。ここまでは前回の記事のとおりである。
問題は「4つのうち、どれが効いているのか」を分けていなかったことだ。
今回、条件ごとにComfyUIを起動し直して、1つずつ入れて測った。11条件、3モデル、各8ラン。結果を先に言うと、効いていたのは1つだけで、ソースの書き換え2つは逆に遅くしていた。
「更新で消える」と書いた改変は、消えたほうがよかった。
【結論】MIOpenを有効にする。それ以外は要らない
ROCm 10.0.0 / ComfyUI 0.35.0 / RX 9070 XT。数字は秒で、小さいほど速い。ベースは「何も指定しない」。11条件のうち主要な9つを載せる。
| 条件 | SD1.5（8枚） | SDXL（1枚） | FLUX.1（1枚） |
|---|---|---|---|
| 何も指定しない | 7.62 | 8.20 | 34.8 |
COMFYUI_ENABLE_MIOPEN=1 | 4.72（−38%） | 5.67（−31%） | 35.8（誤差） |
＋ MIOPEN_FIND_MODE=FAST | 4.72 | 5.66 | 36.1 |
--use-pytorch-cross-attention だけ | 7.57 | 7.90 | 36.8 |
VAE_KL_MEM_RATIO=2.0 だけ（ソース未改変） | 7.58 | 7.89 | 37.0 |
| MIOpen ＋ ソース改変①（VAE_KL） | 4.81 | 5.61 | 38.6（+7%） |
| MIOpen ＋ ソース改変②（VAEのpytorch attention） | 4.71 | 6.61（+17%） | 46.2（+28%） |
| MIOpen ＋ 改変①② | 4.81 | 6.65 | 49.2 |
MIOpen ＋ --preview-method auto | 4.73 | 5.67 | 38.7（+7%） |
- 効いているのは
COMFYUI_ENABLE_MIOPEN=1の1つだけ。これ1つで、全部入りと同じ数字になる MIOPEN_FIND_MODE=FASTは速度に寄与しない。初回の1枚が速くなるだけ（後述）--use-pytorch-cross-attentionは、ROCm 10 では書いても書かなくても同じ。既定で有効になっている- ソースの書き換え2つは、ROCm 10 では遅くなる。SDXL で +17%、FLUX.1 で +28%
- FLUX.1 には、速くする設定が1つも無い。改変なしの条件は 34.8〜37秒の中で、改変を当てると遅くなるだけ
そして、前回の記事で「MIOpenだけで15〜20%」と書いたが、ROCm 10 では31〜38%。効きは増えている。
【計測条件】条件ごとにComfyUIを起動し直した
前回の記事とROCm 10導入記事で使ったものと同じプロトコルである。
| GPU / CPU / メモリ | RX 9070 XT 16GB / Ryzen 9 7900X / DDR5 64GB |
| ComfyUI / PyTorch | 0.35.0 / 2.13.0+rocm10.0.0 |
| 計測 | 8ラン、初回と最大・最小を除いた5回平均。シード 1234567890 からインクリメント |
| SD1.5 | v1-5-pruned-emaonly-fp16 / 512×512 / Euler / 20step / バッチ8 |
| SDXL | juggernautXL_ragnarokBy / 1024×1024 / Euler / 30step / バッチ1 |
| FLUX.1 | FLUX.1 [dev]（T5はfp8） / 1024×1024 / Euler / 20step / バッチ1 |
今回はGUIを使っていない。条件ごとにComfyUIを起動し直し、APIにワークフローを投げ、ログの Prompt executed in の値を拾うスクリプトで回した。理由は3つある。
- 起動オプションや環境変数は起動時にしか効かないので、条件ごとに再起動するしかない。手でやると11回起動することになる
- GUIはプレビューの送信と描画が乗る。その分が「設定の効果」に混ざる
- 無人で回せる。今回は夜中に1回、昼に2回回した（2回目は筆者がYouTubeを見ていたので捨てた。後述）
ソースの書き換えは、条件に入るときだけ当てて、終わったら git checkout で戻している。当たっていることは、起動ログで確認した。
【本題1】MIOpenだけで全部だった
COMFYUI_ENABLE_MIOPEN=1 を入れると、起動ログから1行消える。
Set: torch.backends.cudnn.enabled = False for better AMD performance.何も指定しないと、ComfyUIはAMDでcuDNN（ROCmではMIOpen）を無効にする。畳み込みの最適化ライブラリを使わない状態がデフォルトである。環境変数はそれを戻すスイッチで、効果はこうだった。
| 項目 | 指定なし | MIOpen | 影響 |
|---|---|---|---|
| SD1.5 | 7.62 | 4.72 | −38% |
| SDXL | 8.20 | 5.67 | −31% |
| FLUX.1 | 34.8 | 35.8 | 誤差 |
畳み込み主体のSD1.5で最大、Transformer主体のFLUX.1で無効。MIOpenは畳み込みを速くするものなので、これは筋が通っている。
FIND_MODE=FAST は「初回」だけの話
MIOPEN_FIND_MODE=FAST を足しても、5回平均は 4.718 → 4.716 で変わらない。変わるのは初回の1枚である。
| 項目 | 初回（除外分） |
|---|---|
| MIOpen のみ | 42.2秒 |
| MIOpen ＋ FIND_MODE=FAST | 21.4秒 |
MIOpenは初回に最適なカーネルを探索する。FASTはその探索を短くする設定で、探索が終わった2回目以降には関係ない。前回の記事に「体感の差は測っていない」と書いたが、測ると「初回が半分になる」だった。入れておいて損は無いが、速くなる設定ではない。
【本題2】--use-pytorch-cross-attention は、もう既定になっていた
前回「まずこれ」と書いた起動オプションは、ROCm 10 では何もしていなかった。指定しても 7.57 / 7.90 で、指定なしの 7.62 / 8.20 と誤差の範囲である。
理由は ComfyUI のソースにある。comfy/model_management.py に、AMDのGPUに対してこういう分岐が入っている。
if rocm_version >= (7, 0): if any((a in arch) for a in ["gfx1200", "gfx1201"]): ENABLE_PYTORCH_ATTENTION = TrueROCm 7 以降で gfx1200 / gfx1201（RX 9060 / 9070 系）なら、pytorch attention は自動で有効になる。実際、11条件すべての起動ログに Using pytorch attention が出ていた。フラグは要らない。
前回の記事はROCm 7.1で書いたので、当時は意味があった可能性がある。今は書いても害は無いが、効果も無い。
【本題3】ソースの書き換え2つは、逆効果だった
ここが今回いちばん書きたかったところである。
前回の記事で、ComfyUI本体の2ファイルを書き換える手順を載せた。
- 改変①
comfy/sd.pyのVAE_KL_MEM_RATIOを環境変数で調整できるようにし、AMD既定の 2.73 を 2.0 に下げる - 改変②
comfy/model_management.pyで、AMDでは無効化されているVAEのpytorch attentionを有効にする
ROCm 10 の環境で、MIOpen有効を土台に、この2つを1つずつ当てた。
| モデル | MIOpenのみ | ＋改変① | ＋改変② | ＋①② |
|---|---|---|---|---|
| SD1.5 | 4.72 | 4.81（+2%） | 4.71（±0） | 4.81 |
| SDXL | 5.66 | 5.61（−1%） | 6.61（+17%） | 6.65 |
| FLUX.1 | 36.1 | 38.6（+7%） | 46.2（+28%） | 49.2 |
改変②：有効になっている。有効になった結果が遅い
まず、改変が当たっていることを確認した。改変②を当てた条件だけ、起動ログのVAEの行が変わる。
改変なし: Using split attention in VAE
改変あり: Using pytorch attention in VAE確かに切り替わっている。切り替わった結果、SDXLが17%、FLUX.1が28%遅くなった。
もう1つ気になるのが、FLUX.1の8ランのばらつきである。
MIOpenのみ: 35.3 36.3 36.0 36.6 36.4 36.4 35.5
改変②あり: 37.3 49.5 44.8 43.2 50.9 44.7 48.8MIOpenのみは36秒前後で揃うのに、改変②を当てると37〜51秒で揃わない。同じシード、同じ条件で、1枚ごとに10秒以上違う。VRAMに入りきらない分の退避が、毎回違う挙動をしているように見える。
ComfyUIがAMDでこれを無効化しているコメントは「高解像度でクラッシュする」である。クラッシュの手前の症状が、この遅さとばらつきなのだと思う。無効化には理由があった。
改変①：SD1.5とSDXLには無意味、FLUX.1では遅い
VAE_KL_MEM_RATIO は、VAEが使うVRAMの見積もりを決める係数である。AMDでは既定 2.73 と大きめに見積もられていて、前回の記事では「過剰なので 2.0 に下げると無駄な退避が減る」と書いた。
結果は SD1.5 +2%、SDXL −1%、FLUX.1 +7%。見積もりを下げると、VAEのために空けておくVRAMが減り、代わりにモデル本体の退避が増えたのだろう。FLUX.1の8ランは 38.2〜39.0 で揃って遅いので、こちらは「毎回同じだけ余計に退避している」形である。
当てる理由が無い。
1回目は「当たっていなかった」
実は、この2つは1回目の計測でも条件に入れていた。ところが結果は「効果ゼロ」で、そこで気づいた。ROCm 10 用に新しく作ったComfyUIには、ソースの改変を当てていなかった。VAE_KL_MEM_RATIO=2.0 を環境変数に書いても、sd.py が読みに行かなければ何も起きない。
つまり前回のROCm 10導入記事で「全部入り」として測った起動スクリプトも、VAE_KL_MEM_RATIO=2.0 の行は何もしていなかったことになる。あの記事の「オプションで14〜23%」は、実質「MIOpenで」だった。これは別途訂正する。
「更新で消える」と自分で書いた改変が、新しい環境に持ち込まれていなくて、持ち込まなかったほうが速かった。
【本題4】FLUX.1には、何をしても効かない
11条件のFLUX.1の数字を並べると、遅くする設定はあっても、速くする設定は1つも無い。
| 項目 | FLUX.1 |
|---|---|
| 指定なし〜MIOpen〜全部入り（改変なし） | 34.8〜37.0 |
| 改変①あり | 38.6 |
| preview auto | 38.7 |
| 改変②あり | 46.2〜49.2 |
MIOpenは畳み込み向けで、FLUX.1はTransformerなので効かない。VAE周りの改変は退避を増やすだけ。FLUX.1を速くしたければ、設定ではなくROCmのバージョンを上げるしかなく、それは前回の記事で3.23倍という形で出ている。
【計測衛生】プレビューとYouTube
設定の話ではないが、測っていて分かったことを2つ書く。
--preview-method auto はFLUX.1で7%
ステップごとにプレビューを描く設定である。SD1.5とSDXLでは +0.3% で無視できるが、FLUX.1では +7%（36.1 → 38.7秒）。TAESDを入れていないので Latent2RGB の軽い方式のはずだが、1024pxの20stepでこれだけ乗る。
普段使いで外す必要は無い。ベンチマークを取るときだけ外す。
YouTubeを見ていると、FLUX.1が5〜10%遅い
2回目の計測中、筆者はブラウザでYouTubeを見ていた。3回目をGPUを空けて取り直したところ、FLUX.1が条件によって2〜4秒縮んだ。動画のデコードは同じGPUで走る。
結論は変わらなかった（順序も差の向きも同じ）が、数字は3回目に置き換えた。ベンチ中はブラウザの動画も止める。
GUIはAPIより遅い
前回のROCm 10導入記事は、GUIで同じプロトコルを回した。あのときの「全部入り」は SD1.5 5.95秒 / SDXL 6.84秒。今回のAPI計測で相当する条件（MIOpen＋FAST＋preview）は 4.73 / 5.67 で、GUIのほうが1秒以上遅い。WebSocketでのプレビュー送信とブラウザ描画のぶんと思われるが、分離はしていない。GUIの数字とAPIの数字は混ぜないほうがいい。
【追記 2026-10-01】動画では逆になる。FLUX.1 は MIOpen で6割遅くなる
この記事を書いた2週間半後、画像だけでなく動画のモデルも足して測り直した。ComfyUI は v0.38.0、ROCm 10 の環境は同じである。
測り方も変えた。同じ晩に「MIOpenなし → あり → なし」と続けて測り、それを2周した。日をまたいで比べると、設定の効果と、測り直したときのぶれを取り違えるからだ。
| モデル | MIOpenなし（2周） | MIOpenあり（2周） | 効果 |
|---|---|---|---|
| LTX-Video 2B（動画） | 20.45 / 17.38 秒 | 10.09 / 8.80 秒 | 約2倍速い |
| SDXL（画像） | 8.71 / 8.24 秒 | 5.91 / 5.95 秒 | 30%速い |
| Qwen-Image 2.1（画像） | 17.49 / 16.83 秒 | 15.77 / 16.75 秒 | 差は無い |
| 初代 Qwen-Image（画像） | 47.77 / 46.85 秒 | 45.91 / 45.95 秒 | 差は無い |
| Wan2.2 5B（動画） | 69.88 / 63.75 秒 | 86.44 / 76.09 秒 | 遅くなる |
SDXL は前回（8.2秒 → 5.67秒）とほぼ同じ数字が出た。この記事の結論は、画像のモデルについては今も正しい。
動画では、MIOpen が足を引っ張ることがある
新しく足した動画モデルで、正反対の結果になった。
- LTX-Video 2B は、MIOpen を入れると約2倍速い。この記事で一番効きが大きい
- Wan2.2 5B は、MIOpen を入れると遅くなる。3周とも同じ向きで、62秒前後が78秒前後になる
同じ「動画」でも逆になる。MIOpen は畳み込みを速くするものなので、モデルの中で何が主役かで効きが変わる、という前回の説明どおりではある。ただし「入れておけば損はない」とまでは言えなくなった。
FLUX.1 の「誤差」は、誤差ではなかった
この記事の本文では、FLUX.1 について 34.8秒（指定なし）に対し 35.8秒（MIOpen）で誤差と書いた。測り直すと、そうではなかった。
最初に2周測ったところ、MIOpenなしの数字が 24.5秒の回と37.4秒の回に割れた。2回では決められないので、ComfyUI を毎回起動し直して、MIOpenなし・あり・あり・なし…の順に計16セッション、114回まで増やした。
| セッション数 | 24秒台で終わったセッション | 1回ごとに見て24秒台だった割合 | セッションごとの中央値 | |
|---|---|---|---|---|
| MIOpenなし | 7 | 6 | 81%（57回中46回） | 24.5秒 |
| MIOpenあり | 9 | 0 | 11%（57回中6回） | 38.6秒 |
MIOpen を入れると、FLUX.1 は約6割遅くなる。16セッションのうち、この向きが逆になったものは1つも無い。
ただし MIOpenなしも完璧ではない。7セッション中1つは、ほとんどの回が37秒台だった。1回ごとに見ても、5回に1回くらいは38秒前後かかる。この記事を書いた日は、たまたまその遅い回を引いていた。だから「34.8対35.8で誤差」に見えた。
「FLUX.1 には速くする設定が1つも無い」も訂正する。MIOpen を切るのが一番速い。
測り方について
1回や2回では、この割れ方は見えない。設定を比べるときは、同じ晩の中で続けて測って、それを2周する。 実際、筆者は別の記事で1周だけの数字を見て「効果があった」と書きかけ、2周目で消えて気づいた。ベンチの数字は、1回取っただけでは足りない。
まとめると
| 使うもの | MIOpen |
|---|---|
| SD1.5・SDXL | 入れる（30〜38%速い） |
| LTX-Video | 入れる（約2倍） |
| Qwen-Image（初代・2.1とも） | どちらでもいい |
| Wan2.2 5B | 切る（2割ほど速い） |
| FLUX.1 | 切る（約6割速い。ただし5回に1回は遅い回がある） |
画像を描くだけなら、この記事の結論（MIOpen を入れる）のままでいい。動画も回すなら、.bat を使い分ける。
【結局どうするか】.batはこれだけでいい
ROCm 10 の環境で、筆者がいま使っている起動バッチはこれである。
@echo off
set PYTHON="%~dp0/.venv/Scripts/python.exe"
set COMFYUI_ENABLE_MIOPEN=1
set MIOPEN_FIND_MODE=FAST
%PYTHON% main.py --cuda-device 1 --auto-launch --preview-method auto
pauseCOMFYUI_ENABLE_MIOPEN=1── これが本体。SD1.5/SDXLで3割速くなるMIOPEN_FIND_MODE=FAST── 初回の探索が半分になる。あってもなくても速度は同じ--cuda-device 1── Ryzenの内蔵GPUを掴まないため（導入記事参照）。内蔵GPUの無い環境では不要--use-pytorch-cross-attention── 書かない。既定で有効VAE_KL_MEM_RATIO── 書かない。ソースも書き換えない- ソースの書き換え ── しない
前回の記事の「4つの設定」のうち、生きているのはMIOpenの環境変数だけになった。
VRAMからの退避が話の中心になったので、この構成ならメインメモリには余裕を持たせたい。
ポチップ
【限界】この記事で測れていないこと
- ROCm 7.1 では測り直していない。前回の記事の改変2つは、当時の環境では正しかった可能性がある。「ROCm 10 では逆効果」までしか言えない
- 条件の順序効果。各条件は1セッション8ランで、「指定なし」は毎回最初に回っている。コールドキャッシュの分が乗っている可能性はあるが、同じ数字が3回の計測で再現した
- FLUX.1の改変②の条件はばらつきが大きい（37〜51秒）。平均より「揃わない」こと自体を結果として読んでいる
- 高解像度は測っていない。改変②は「大きい画像でのVRAM溢れを防ぐ」目的で入れたもので、1024pxまでの今回の条件ではその場面が来ていない
--highvram--fp16-vaeは今回の条件に入れていない。前回の記事にある残りの起動オプションは未検証
まとめ
- ROCm 10 で効くのは
COMFYUI_ENABLE_MIOPEN=1だけ。SD1.5 −38%、SDXL −31%。前回の「15〜20%」より効きが増えた MIOPEN_FIND_MODE=FASTは初回の探索を半分にするだけ。速度は変わらない--use-pytorch-cross-attentionは ROCm 7 以降の RX 9060/9070 では既定で有効。書かなくていい- ソースの書き換え2つは逆効果。VAEのpytorch attention有効化で SDXL +17%・FLUX.1 +28%、VAE_KL=2.0 で FLUX.1 +7%
- FLUX.1 には設定で速くする手が無い。上げるならROCmのバージョン
- プレビューは FLUX.1 で +7%、YouTube視聴で +5〜10%。ベンチのときは両方止める
- ROCmのバージョンが上がったら、前の版の最適化は測り直す。7.1の最適化が10では足を引っ張った
「アップデートで消える」と書いた改変は、消えたほうがよかった。設定は、環境が変わったら一度全部外して、1つずつ戻して測る。それを面倒にしないために、今回の計測はスクリプトにしてある。次のROCmが出たら、また同じものを回す。
コメント