Stable-Diffusion-WebUI-Forgeが速かった！

Stable Diffusionで画像を生成していて、大量のガチャをしたり、プロンプトをアレコレやりくりして希望の画像を作り出したい場合、やはりGeForce GTX 3050ではちょっとツライ。

しかもそれがSDXLともなると、1536x1024で生成開始から完了まで1枚1分以上かかるので、なかなか厳しいところ。

…という悩みを抱えつつ、かといってグラボを新しくするほど画像生成に本腰を入れる訳でもないし…と思っていたら、Stable-Diffusion-WebUI-Forgeというものを発見。

コレ、ウチのようなVRAMが8GBでも、3割以上の高速化が期待できるんですってよ。

ということで、さっそく使ってみることにしたので、インストール手順やAutomatic1111との比較などをメモメモ。

インストール

インストールしたいフォルダでコマンドプロンプト（cmd）を起動して、Stable-Diffusion-WebUI-Forgeをダウンロードします。

git clone https://github.com/lllyasviel/stable-diffusion-webui-forge

環境を新規に作成する場合は、これだけでOK。ダウンロードが終わったら、webui-user.batを実行すれば、勝手に環境を作成してくれます。

既存WebUI-A1111を引き継ぐ

既にAutomatic1111を使用している場合は、モデルやLoRA、VAEなどをそのまま引き継いで使用できます。初回起動する前に、下記設定をしておけば起動時間短縮にも。

webui-user.batを開くと、最初は以下のようになっていると思います。（f0.0.12-1.7.0の場合）

@echo off

set PYTHON=
set GIT=
set VENV_DIR=
set COMMANDLINE_ARGS=

@REM Uncomment following code to reference an existing A1111 checkout.
@REM set A1111_HOME=Your A1111 checkout dir
@REM
@REM set VENV_DIR=%A1111_HOME%/venv
@REM set COMMANDLINE_ARGS=%COMMANDLINE_ARGS% ^
@REM  --ckpt-dir %A1111_HOME%/models/Stable-diffusion ^
@REM  --hypernetwork-dir %A1111_HOME%/models/hypernetworks ^
@REM  --embeddings-dir %A1111_HOME%/embeddings ^
@REM  --lora-dir %A1111_HOME%/models/Lora

call webui.bat

これを、自分の環境に合わせて書き換えます。例えば、A1111をF:¥stable-diffusion-webuiにインストールしてある場合、

@echo off

set PYTHON=
set GIT=
set VENV_DIR=
set COMMANDLINE_ARGS=--xformers --opt-channelslast

@REM Uncomment following code to reference an existing A1111 checkout.
set A1111_HOME=F:/stable-diffusion-webui
set VENV_DIR=%A1111_HOME%/venv
set COMMANDLINE_ARGS=%COMMANDLINE_ARGS% ^
  --ckpt-dir %A1111_HOME%/models/Stable-diffusion ^
  --hypernetwork-dir %A1111_HOME%/models/hypernetworks ^
  --embeddings-dir %A1111_HOME%/embeddings ^
  --vae-dir %A1111_HOME%/models/VAE ^
  --lora-dir %A1111_HOME%/models/Lora

call webui.bat

このように書き換えると、venvとモデルデータ、HyperNetwork、Embeddings、VAE、LoRAのデータを、A1111環境から読み込みます。

全てを共有したくない場合は、不要なものはコメントアウト（@REM）しておけばOK。

あ、ついでにxformersなども書き足しています。

速度差

起動パラメータを同一にし、A1111 v1.6.0環境で10枚生成したときの生成時間と、Forge f0.0.12-1.7.0環境で10枚生成したときの生成時間を比較してみました。

条件は以下の通り。

モデル	AsyncsMIX_XL_v20
VAE	sdxl_vae
プロンプト	cat
ネガティブ	なし
ClipSkip	2
Method	Euler a
Steps	25
Width	1536
Height	1024
CFG	6

起動直後の1回目の画像生成は時間がかかることがあるので、起動後に1枚画像を生成した後の10回分を集計してみました。

結果は以下の通り。

	A1111	Forge
1回目	00:44	00:40
3回目	00:44	00:40
5回目	00:44	00:39
7回目	00:44	00:39
9回目	00:44	00:39
総時間	13:07	07:12

1枚あたりの実生成時間は1割ほど速くなっているようですが、総時間を見ると、なんと10枚で6分近い差が！

なぜこんな差が出たのかというと…Forgeでは、1枚の画像生成が終わった後、次の画像を生成し始めるまでの時間が大幅に短縮されていることが大きな理由でした。

ということはつまり、大量に画像を生成すればするほど、特に時間短縮が感じられる、ということですね。

あとは、上記計測時間には含まれていないのですが、モデルデータを変更したときの読み込み時間も短縮されていました。

これについては、読み込み時間短縮だけでなく、WebUI上でモデルデータを切り替えたタイミングで読み込むのではなく、実際に画像生成を始める段階で読み込む、という変更もあるようです。

さいごに

ということで、Stable-Diffusion-WebUI-Forgeを使ってみたらA1111より速いと感じたけど、具体的にどれくらい速いのかを軽く計ってみたところ、10枚生成時で6分近く短縮できてしまった、ということがわかりました。

3割どころではない高速化になりましたね！

Forgeは、VRAMが少ない環境ほど高速化が期待できるようですので、自分のような8GB環境でSDXLを扱う場合は、A1111よりForgeの方が良さそうなことがわかりました。

それでは、今日はここまで。お疲れ様でした！