WebUI ForgeとRestore facesその後｜Stable Diffusion｜Blog

Stable Diffusion 2024.02.26

アップデートで解決したみたいです

色々やったけど効果がなかった

　WebUI ForgeでRestore facesありで画像を生成すると動作が遅くなる現象ですが，venvの仮想環境を確認して入っていなかったGFPGANをインストールするなど，これでうまくいくかなという部分を見つけてはチャレンジしていました。しかしながら画像を生成するとファンが大きな音を立てて回り始める現象は改善しませんでした。

アップデートしたら改善した

　2/26の夜にアップデートを試みたところ，いつもより多めのメッセージが出ました。その中にface restration関連のファイル名があったのでもしかしたらと思い，チェックしてみました。

先日の画像チェックと同じような設定でテストしたところ，以下のようになりました。

LCM LoRAあり，Restore facesあり…17.1秒（4.82it/s）
- 【前回】56.8秒（1.42it/s）【Restore facesなし】14.4秒（5.72it/s）
LCM LoRAなし，Restore facesあり…36.8秒（6.99it/s）
- 【前回】75.2秒（3.34it/s）【Restore facesなし】34.0秒（7.56it/s）

どちらもかなり速くなりました。Restore facesなし+2.7秒くらいとほぼ変わらない感じです。今までのようにファンが回り始めることもなく，CPUの使用率も30%台まで下がっていました。おそらくアップデートで最適化されたのではないかと思います。

これでRestore facesありの状態でWebUI Forgeを常用することができそうです。

起動時にヒントが出ていました

　起動時のコマンドプロンプトの画面を見ると，何とヒントが表示されていました。

Hint: your device supports --pin-shared-memory for potential speed improvements.

Hint: your device supports --cuda-malloc for potential speed improvements.

Hint: your device supports --cuda-stream for potential speed improvements.

あなたのデバイスはこれらの速度改善につながるオプションに対応しているよという意味のようだったので調べてみることにしました。

githubのWebUI Forgeのリポジトリにアクセスすると，これらのオプションの説明がありました。

日本語に機械翻訳するとこんな感じでした。

まだ注目すべきいくつかのフラグ:

always-offload-from-vram(このフラグにより処理は遅くなりますが、リスクは低くなります)。このオプションにより、Forge は常にモデルを VRAM からアンロードできるようになります。これは、複数のソフトウェアを一緒に使用し、Forge の VRAM 使用量を減らして他のソフトウェアに VRAM を割り当てたい場合、または Forge と VRAM と競合する古い拡張機能を使用している場合、または (非常にまれに) OOM が発生した場合に便利です。

cuda-malloc(このフラグは処理を高速化しますが、リスクも高くなります)。これは、pytorch にテンソル malloc にcudaMallocAsyncを使用するように要求します。一部のプロファイラーではミリ秒レベルでパフォーマンスの向上が観察できますが、ほとんどのデバイスでは実際の速度向上は気づかれないことがよくあります (画像あたり約 0.1 秒以下)。非同期 malloc によってプログラムがクラッシュするという問題が多くのユーザーから報告されているため、これをデフォルトとして設定することはできません。ユーザーは、自己の責任でこの cmd フラグを有効にする必要があります。

cuda-stream(このフラグは処理を高速化しますが、リスクも高くなります)。これは、pytorch CUDA ストリーム (GPU 上の特別なタイプのスレッド) を使用して、モデルの移動とテンソルの計算を同時に行います。これにより、すべてのモデルの移動時間がほぼなくなり、小さな VRAM を搭載した 30XX/40XX デバイス (RTX 4050 6GB、RTX 3060 Laptop 6GB など) の SDXL が約 15% ～ 25% 高速化されます。ただし、2060 では純粋な黒画像 (Nan 出力) の可能性が高く、1080 と 2060 では OOM の可能性が高いことが観察されているため、残念ながらこれをデフォルトとして設定することはできません。解像度が大きい場合、計算時間が長くなる可能性があります。 1 つのアテンションレイヤーは、モデル全体を GPU に移動する時間よりも長くなります。これが発生すると、GPU がモデル全体でいっぱいになり、別のアテンションレイヤーを計算するための残りのスペースがなくなるため、次のアテンションレイヤーが OOM になります。ほとんどのオーバーヘッド検出方法は、古いデバイスで信頼できるほど堅牢ではありません (私のテストでは)。ユーザーは、自己の責任でこの cmd フラグを有効にする必要があります。

pin-shared-memory(このフラグは処理を高速化しますが、リスクも高くなります)。と併用した場合のみ有効ですcuda-stream。これにより、モデルをオフロードするときに、システム RAM ではなく共有 GPU メモリにモジュールがオフロードされます。小さな VRAM を搭載した一部の 30XX/40XX デバイス (RTX 4050 6GB、RTX 3060 Laptop 6GB など) では、SDXL の大幅な (少なくとも 20%) 速度向上が観察できます。ただし、共有 GPU メモリの OOM は一般的な GPU メモリの OOM よりもはるかに深刻な問題であるため、残念ながらこれをデフォルトとして設定することはできません。Pytorch は、共有 GPU メモリをアンロードまたは検出するための堅牢な方法を提供しません。共有 GPU メモリが OOM になると、プログラム全体がクラッシュします (GTX 1060/1050/1066 上の SDXL で確認)。クラッシュを防止したり、クラッシュから回復したりする動的な方法はありません。ユーザーは、自己の責任でこの cmd フラグを有効にする必要があります。