先日、ROCm6.0版のマルチWebUIセットアップスクリプトを出しましたが、皆さん、うまく活用しておられますでしょうか。
今日はStable Diffusion WebUIのパフォーマンスチューニングを行いたいと思います。
「いやいや、管理人さん、そんなのほかのサイトでももう何度もやっているじゃないですか」という声が聞こえてきそうですが、今回はROCm、RX7900XTXという条件でパフォーマンスチューニングを行っていきましょう。
わたくしの知る限りではこのような条件でパフォーマンスチューニングを公開している事例はないはずです。
検証環境
- CPU：Intel Core i7-13700K
- CPUクーラー：サイズ Big shuriken3 RGB
- マザーボード：Asrock Z690M-ITX/ax
- SSD:M2_2(チップセット側) Moment MT34 NVMe Gen3 SSD 256GB
- M2_1(CPU側) 未装着
- 電源：Corsair SFX 750W電源 SF-750
- メモリ：G Skill Trident Z DDR4-3600 OCメモリ16GB*2=32GB
- ケース：QDIY 0040-*PCJMK6-ITX(テストベンチ)
- OS：Lubuntu 22.04LTS(jammy-jellyfishベース)
- GPU Sapphire Pulse Radeon RX7900XTX 24GB
いつもの環境になります。
参考にしたページ
最適化にあたっては、github.comのAutomatic1111のOptimizationのページを参考にいたしました。
有名ですから、すでにご存じの方も多いと思います。
| コマンドライン引数 | 説 明 |
| --opt-sdp-attention | 一部のシステムでは xFormer を使用するよりも高速になる可能性がありますが、 より多くの VRAM が必要になります。 (非決定的) |
| --opt-sdp-no-mem -attention | 一部のシステムでは xFormer を使用するよりも高速になる可能性がありますが、 より多くの VRAM が必要になります。 (決定的で、--opt-sdp-attention よりもわずかに遅く、より多くの VRAM を使用 します) |
| --opt-split-attention | クロス アテンション レイヤーの最適化により、ほとんどコストをかけずに メモリ使用量が大幅に削減されます (これによりパフォーマンスが向上したと報告する人もいます)。 黒魔術。 torch.cuda ではデフォルトでオンになっており、これには NVidia カードと AMD カードの両方が含まれます。 |
| --disable-opt-split -attention | 上記の最適化を無効にします。 |
| --opt-sub-quad -attention | サブ二次関数的アテンション。メモリ効率の高いクロス アテンション レイヤー の最適化により、必要なメモリを大幅に削減できますが、場合によってはわずか なパフォーマンス コストがかかります。 xFormers が機能しないハードウェア/ソフトウェア構成でパフォーマンスが低下 したり、生成に失敗したりする場合に推奨されます。 macOS では、より大きな画像の生成も可能になります。 |
| --opt-split -attention-v1 | メモリをそれほど消費しない、上記の最適化の古いバージョンを使用します (使用する VRAM は少なくなりますが、作成できる画像の最大サイズがより 制限されます)。 |
| --medvram | Stable Diffusionモデルを、cond（テキストを数値表現に変換）、first_stage （画像を潜在空間に変換して戻す）、unet（潜在空間の実際のノイズ除去）の 3つの部分に分割し、常に1つだけがVRAMにあり、他はCPU RAMに送るように することで、VRAMの消費を少なくします。 ライブプレビューが有効になっている場合を除き、パフォーマンスは低下します が、ほんの少しです。 |
| --lowvram | 上記をさらに徹底的に最適化したもので、unetを多くのモジュールに分割し、 VRAMには1つのモジュールしか保持しない。パフォーマンスは壊滅的だ。 |
| *do-not-batch-cond -uncond | 1.6.0以前のみ: サンプリング中の肯定的および否定的なプロンプトのバッチ処理 を防止。パフォーマンスを低下させる。コマンドラインオプションではなく、 -medvramまたは-lowvramを使用することで暗黙的に有効になる最適化。 1.6.0では、この最適化はコマンドラインフラグでは有効になっておらず、 代わりにデフォルトで有効になっている。設定の最適化カテゴリのバッチ cond/uncondオプションで無効にできる。 |
| --always-batch -cond-uncond | 1.6.0以前のみ：上記の最適化を無効にします。medvramまたは-lowvramと 併用する場合にのみ意味がある。 1.6.0では、このコマンドラインフラグは何もしません。 |
| --opt-channelslast | チャンネルへの安定した拡散のために、トーチメモリのタイプを最後に変更 する。効果は詳しく研究されていない。 |
| --upcast-sampling | NvidiaとAMDのカードは、通常—no-halfで動作することを余儀なくされるが、 生成速度が向上するはずだ。 |
上のページで解説されているコマンドライン引数のうち、Rdeonに関係ありそうなものを引用しています。
xformersはRadeonでは使えませんので、関連のオプションは一切載せていません。
また、古い情報ですが、RadeonではFP32演算オプションを指定すると速くなるという情報がありましたので、上のほかに以下のオプションも含めて調査することにしました。
--no-half --precision full・・・このオプションを指定すると強制的にFP32を使用します。--upcast-samplingとの違いは判りませんでしたので今回のテストで比較してその違いを見てみることにします。
使うところまで持っていくだけで大変なRadeon界隈において、わたくしが調べたところによるとおそらく、パフォーマンスチューニングまで試みた事例は海外を含めてネットでは皆無であり、本記事が世界初だと思います。
※ もちろんGeforceなら山ほどあります。
テスト方法とテストの結果
テストに用いたソフトウェアのバージョン
- ROCm6.0.2
- torchとtorchvisionのバージョン・・・torch2.3.0、torchvision0.18.0
テスト方法
- ハローアスカベンチマークを3回実行(512*512、28steps、10枚生成)し、生成時間とit/sの平均値で比較
- ハローアスカベンチマーク768を3回実行(768*768、28steps、10枚生成)し、生成時間とit/sの平均値で比較
テストの結果
| 512*512(秒) | 512*512(it/s) | 768*768(秒) | 768*768(it/s) | ||
| 1 | --autolaunch --opt-sdp-attention | 16.6 | 18.61 | 51.9 | 5.86 |
| 2 | --autolaunch --opt-sdp-attention --disable-opt-split-attention --opt-sub-quad-attention | 22.3 | 13.55 | 80.0 | 3.69 |
| 3 | --autolaunch --opt-sdp-attention --opt-sub-quad-attention | 16.6 | 18.66 | 51.8 | 5.88 |
| 4 | --autolaunch --opt-sdp-attention --opt-sub-quad-attention --upcast-sampling | 16.8 | 18.47 | 52.0 | 5.86 |
| 5 | --autolaunch --opt-sdp-attention --opt-sub-quad-attention --no-half --precision full | 29.7 | 10.03 | 94.6 | 3.10 |
| 6 | --autolaunch --opt-sdp-attention --opt-sub-quad-attention --opt-channelslast | 17.6 | 17.48 | 52.8 | 5.76 |
| 7 | --autolaunch --opt-sdp-attention --opt-sub-quad-attention --opt-channelslast (Tensor演算) | 17.7 | 17.48 | 52.8 | 5.76 |
※ Tensor演算とは、「.\modules\sd_hijack.py」の31行目に「torch.backends.cuda.matmul.allow_tf32 = True」を付け加えること。ネット情報による。
結果は上のようになった。
一番性能が良くなったのは3の「--autolaunch --opt-sdp-attention --opt-sub-quad-attention」だった。
ただし、Hires.FixやControlnetを使うとエラーで落ちるので、そういった作業には「Stable Diffusion WebUI Forge」を使わざるを得ないだろう。
Geforceではこういう変な落ち方はしなかったので、Radeon、ROCm特有の現象だろう。
非常に残念ながら、Geforceと全く同じ使い勝手というわけにはいかないようだ。
オプションで印象的だったのは32bitを演算を使用する「--upcast-sampling」や「--no-half --precision full」の効果が薄かったことだ。
「--no-half --precision full」はかなり遅くなった。
また、「--upcast-sampling」はRadeonだと定番のようなオプションらしいが、特に早くならずに、逆に少し遅くなったのが印象的だった。
xformersが使えないRadeonは有効そうなオプションの選択肢があまり多くなく、「--autolaunch --opt-sdp-attention --opt-sub-quad-attention」が一番有効だろう。
できるだけ本家版の「Stable Diffusion WebUI」使いたいと思うならば、メモリエラー対策でメモリの節約オプションを付けざるを得ないだろう。
export COMMANDLINE_ARGS="--autolaunch --opt-sdp-attention --opt-sub-quad-attention --opt-channelslast --medvream"
export PYTORCH_CUDA_ALLOC_CONF=garbage_collection_threshold:0.8,max_split_size_mb:128
具体的には実使用では上の2行のようにしてメモリ関連のエラーを対策せざるを得ないだろう。
最速のオプションはベンチマーク上だけの話であり、RadeonでイラストAIを使う場合は、実使用では今のところ全力が出せないということになる。
ROCm側の問題なのかWebUI側の問題なのか不明だが、今後のバージョンアップで解決することを祈るしかないだろう。
※ X(旧ツイッター)で報告いただきました。
ROCmはSettingのOptimizationよりCross attention optimizationをInvokeAIに変えるとメモリ効率が良くなります
さっき検証で気づきました
712×712をHires.Fixで2.5倍いけました— れーじちゃん (@eYLOGaAwgLhIF8w) March 4, 2024
Settings(設定) - Optimization - Corss AttentionでInvoke AIを選択するとメモリ効率が良くなるという情報をいただきましたので参考にしてください。
Geforceとの比較
先日の記事でOS間の性能を比較した記事のデータを利用してGeforceと比較してみよう。
※ 数字が小さいほうが性能が良い
※ 数字が大きいほうが性能が良い
※ 数字が小さいほうが性能が良い
※ 数字が大きいほうが性能が良い
※ 数字が大きいほうが性能が良い
Stable Diffusion WebUI Forgeの結果を加えて比較したグラフが上になる。
RX7900XTXの結果は良くてWindows版のRTX4070Tiと同程度だが、768*768のように処理が大きくなると差が開いていく。
ForgeはGeforceでは本家より高速になるがROCmにおいては全くそのようなことはなく、逆に遅くなった。
こちらもROCm側の問題なのかForgeの問題なのかははっきりしないが、今後の改善に期待したいところだ。
学習においては、RTX4070TiのLinuxには明確に及ばないもののWindowsには勝っているのは印象的だ。
結論
結果を見てみると、非常に厳しい数字が並んでいる。
512*512においてはRTX4070Tiと並ぶ結果もあるものの、768*768のように処理が重くなると明確に差がついていく。
RX7900XTXの画像生成AIにおける処理性能は、価格では3-4クラス下のGeforceと同程度と考えてよいと思います。
ROCm側の問題なのか、生成AIのプログラム側の問題なのかははっきりしないが、どちらのソフトウェアもバージョンアップがかなり速いので、今後改善される可能性は十分にあるだろう。
嘘を書くのは嫌いなので非常に辛い結論をはっきり書く。
RX7900XTXの売りはメモリの搭載量ではあるが、メモリの使用効率においてGeforceと同等のレベルとはいいがたく、性能もかなり落ちてしまうので生成AI用途において、RDNA3、RX7900XTXを選ぶ意味は現時点では全くない。
この傾向が機械学習・推論のすべての用途で、すべてのRadeonアーキテクチャーに及ぶのかどうかまでははっきりしないが、AMDにとっても大問題のはずであるので、今後の改善に期待したいところだ。
速度は脚光を浴びることが比較的多いが、メモリの使用効率が取りざたされることはあまりないので、せめて処理中に落ちない程度にはメモリの使用効率は改善してほしいところだ。
少なくともRDNA3では同クラスのAda Lovelaceには敵わない。
AI/ML用途においてはかなり性能が下になると考えてよい。
おそらく、ROCmを使ってこれほど用途をはっきりと固定して、これだけ明確にデータを出したテストというのはほかにはないと思う。