SD用快速webUI「Forge」公開！A1111版とどこが違う？導入と実践 (Pixiv Fanbox)

こんにちは、スタジオ真榊です。支援者の皆様には連日、プロンプト超辞典の枝記事が生成されるたびに更新通知が行ってしまっているのではないかと思います。ご迷惑をおかけしておりますが、あと3分の1ほどで終わりますのでどうかご容赦ください。

さて、今日はControlnetの開発者lllyasviel（イリヤスフィール）氏が公開した、StableDiffusion用の快速webUI「forge」のレビュー記事です。8GB程度のVRAMなら約30～45%の高速化が見込める上、CUDA out of memoryエラーを起こさずに２～３倍サイズの画像を生成できるようになるとされています。

使い勝手はほぼAutomatic1111版のSDwebUIと変わらないようですが、RTX4080でもしっかり高速化の恩恵を得ることができるのか、さっそく試していきたいと思います。

新webUI「Forge」とは

「Forge」を発表したのは、Controlnet開発者として世界的に有名なAI研究者、「lllyasviel」ことチャン・リュミンさん。同氏については、新清士さんのこちらの記事に詳しいです。

2024年2月5日に発表されたこの新webUIは、automatic1111版SDwebUIをベースに開発されており、マインクラフトに対する「Minecraft Forge」（Modを導入できるようになるローダー）のように、「SD WebUIにとってのForgeになることを目指している」としています。

▲Forgeの基本画面（公式GitHubより引用）

使用画面を見ればわかるとおり、基本的にはA1111SDwebUIとほとんど変わらない見た目ですね。

SDwebUIより快速性を誇る高機能UIとしては「ComfyUI」が人気ですが、ワークフローの管理が複雑だったり、A1111版との違いがありすぎて使い勝手が飲み込みにくかったりするのが難点でした。「Forge」がSDwebUIの正統進化版のように使えるものかどうか、まず気になるところです。

どのくらい早くなる？

最大の利点である高速化については、公式で下記のように紹介されています（自動翻訳）。ざっくり言うと、グラボ性能が低いほど効果が大きく、一般的なGPUでは30~45%の高速化とOut of memoryにならずに生成できる最大解像度が２～３倍になるとしています。

また、もう一つの目玉が開発者向けの「Unet Patcher」。拡張機能の開発や連携が非常に簡単になるものだそうで、これによりA1111版では不可能だったさまざまな拡張機能が「競合の心配なく、100行程度のコードで」実現できるようになったとしています。

スタジオ真榊ではRTX4080を使用していますが、こちらはVRAM16GB搭載。この表には8GB以上24GB未満のグラボでどれくらい効果があるのか書かれていないので、さっそく実験していきましょう。

Forge導入方法

まずは導入方法を簡単に。

【StabilityMatrixを使って導入】★オススメ

StabilityMatrixが既にForgeにも対応しています。A1111版をStabilityMatrixで導入した方は簡単に導入でき、CheckpointやLoRA共有も容易なのでこちらがおすすめです。詳しくは個別記事に掲載しておきました。

画像生成AIは「StabilityMatrix」で超簡単インストール！a1111版、Forge、ComfyUIを一発導入・一括管理

こんばんは、スタジオ真榊です。こちらは「StabilityMatrix」という便利なアプリケーションを使って、Automatic1111版のStableDiffusionWebUI（以下SDwebUI）やForge、ComfyUIといったローカル生成環境を一発導入・一括管理する方法についてまとめたHowto記事です。 AIイラストの初心者向け解説については「AIイラストが...

【GitでSDwebUIを導入した方】

任意の場所でGit Bash Hereして「git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git」を入力すればOK。下記のようなメッセージが出てインストール終了ですので、あとはA1111版と同様に「webui-user.bat」を実行すればOKです。

【Gitがよくわからない方向け】

GitやPythonを避けて通りたい方で、StabilityMatrixもちょっと…という方向け。

こちらの公式GitHubへアクセス。下図の「>>> Click Here to Download One-Click Package<<<」から必要なワンクリックパッケージ（1.7GB）をDLしましょう。任意の場所にDLしたら、7zファイルを解凍します。同梱されている「update.bat」と「run.bat」を順に実行すればOKです。

Forgeを実行しよう

実行ファイルを起動するとこのように環境構築が行われます。数GB程度のダウンロードも行われるので、気長に待ちましょう。

A1111版では「medvram」や「no half」といったコマンドライン引数を指定するのが一般的でしたが、Forgeではこうしたコマンドを必要としないのが特徴の一つ。従来の引数を追加してもエラーは発生しないようですが、効果もないとのことですので、とりあえずbatファイルは何もいじらず、そのまま起動してみました。

こちらが「Forge」の初期画面。

ほぼというかなんというか、A1111SDwebUIですねこれは…。デフォルトでControlnetやFreeUなどがインストールされている点が違いといえば違い。それと、初回起動時はDLを伴ったため分からなかったのですが、webUIが立ち上がるまでの起動速度自体もA1111版に比べて半分くらいに感じました。使い勝手がそのままなのに時間だけ短くなるので、とても快適です。

日本語化の方法

アップデートや拡張機能のインストールなど、基本的な使い勝手は完全にA1111版と変わりませんので、とりあえず日本語化したい方は、A1111版と同じ要領で行いましょう。ここをお読みの皆様には今更ですが、一応書いておきます。

①画面上部の「Extension」タブをクリックし、「Installed」「Avaliable」「Install from URL」とある中の「Avaliable」をクリック

②「localization」の左に入っているチェックを外し、「Load from:」ボタンをクリック

③しばらく待つとExtensionリストがずらっと表示されます。Ctrl+Fなどで「ja_JP Localization」を見つけ、右端にある「Install」ボタンをクリックすれば拡張機能がインストールされます。

④この時点では、まだ機能がインストールされただけで、日本語化は実行されていません。翻訳機能を有効にするため、画面上部メニューの「Settings」タブをクリックし、画面左の一覧から「User Interface」をクリックします。

⑤下の方にある「Localization (requires restart)」の「None」を「ja_JP」に変更。画面上部の「Apply settings」を押します。

⑥「settings changed: localization」と表示されたら成功です。画面上部の「Reload UI」を押すことで、UIがリロードされ日本語機能が有効化されます。（画面最下部の『Reload UI』を押しても同じです）

A1111のCheckpointやLoRAを持ってこよう

さて、生成の準備が整いましたが、StabilityMatrixを使っていない場合は肝心のCheckpointやLoRAフォルダが空っぽです。「stable-diffusion-webui-forge\models\Stable-diffusion」内にA1111版と全く同じフォルダ構成がありますので、普段使用しているものをそちらにコピーすれば問題なく利用することができますし、いちいちコピペしなくても下記の方法で直接A1111のフォルダから読み込ませることができます。

※デフォルトではCheckpointを1.5系からXL系に変えると、表示されるLoRAが対応するものだけに切り替わってくれるのですが、この方法を取ると切り替えが生じません。面倒な方はLoRAだけコピペすることをおすすめします。

・「stable-diffusion-webui-forge」フォルダ内の「webui-user.bat」をテキストエディタで開く。

・9行目の「@REM set A1111_HOME=Your A1111 checkout dir」となっている部分の@REMを削除。A=1111_HOME=以下を、A1111のインストールフォルダのフルパスに変更する

※A1111のインストールフォルダのフルパスは、A1111の該当フォルダを開いて、アドレス部分を右クリックから「アドレスをテキストとしてコピー」するのが手っ取り早いです。別ストレージだと読み込みに時間がかかってしまうので、A1111とForgeは同じストレージに置いておくことをおすすめします。

・12～16行目の@REMをすべて削除する。（前述の理由でLoRAは参照したくない場合、@REM --lora-dir %A1111_HOME%/models/Loraの@REMだけ残そう）

Checkpointとembeddings、hypernetworks、LoRAがA1111フォルダのものと共有されます。11行目の@REMを削除すると、venv環境も共有されます（分かる方向け）ただ、ForgeのControlnet絡みはフォルダ構成が変更されているので、単純に持ってくることができません。素直にコピペした方が早いです。

さっそく生成してみよう

今回はAnimagineXL3.0（AXL3）を使って生成実験を行います。AXL3についてはこちらの記事を参照のこと。現在編纂中のプロンプト超辞典もこのモデルで生成実験を行っています。

AnimagineXL3.0でSDXLデビュー！導入法からおすすめ設定、サンプラー選びまで

設定は下記の通り。

PP:best quality,amazing quality,highres,4K,extreme detailed CG,(rating: general:1.2),1girl

NP：hair over eyes,blush,nsfw,lowres, bad anatomy, bad hands, text, error, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, normal quality, jpeg artifacts, signature, watermark, username, blurry, artist name

Steps: 28, Sampler: Euler a, CFG scale: 7, Seed: 123456, Size: 1024x1024, Model: animagine-xl-3.0, Clip skip: 2

【実験１】1枚生成

まずはさきほどの設定でそのまま１枚生成してみました。生成されたのはこちらの画像。

Forgeでは8.2秒で生成できました。

これをA1111版の「PNG内の情報を表示」でそのまま読み込んで、完全に同じ設定で生成したところ、生成終了まで11.2秒掛かりました。1枚あたり約3秒（約27%）程度の生成時間削減効果が得られています。グラボ性能が高いほど効果は限定的になっていくと思っていたので、生成時間の4分の1を超える削減がいきなり出るとは驚きました。

ちなみにこちらがA1111産の1girl。さきほどのForge版とよく見くらべると、背景などがわずかに変化していることが分かります。A1111版はXformersを導入しているので、そのせいかもしれません。

ちなみに、その後も何度か1枚生成を行いましたが、Seed値によってはなぜか逆にA1111版のほうが早く生成できてしまうこともありました。ただ、基本的にはしっかりForgeの方が早く感じられましたし、VRAM消費量も圧倒的に少ないです。実際にもう少し重めな生成をさせて比べてみましょう。

【実験2】Hires2倍（Latent）

今度はhiresあり（高解像度補助、Latent0.7でサイズ2倍）で行ってみました。

Forge：経過時間55.6 sec.　A: 8.69 GB, R: 12.71 GB, Sys: 15.2/15.9922 GB (94.8%)

A1111：経過時間1 min. 7.1 sec.　A: 8.69 GB, R: 21.61 GB, Sys: 16.0/15.9922 GB (100.0%)

こちらでもちゃんとForgeの高速化効果を味わうことができました。VRAM消費量についても大きな差が出ています。Latent0.7で雑にアップスケールしたせいで画像はひどい感じですが…まあ実験ということで。

【実験3】8枚同時生成

今度は8枚同時生成で試しました。

生成結果がこちら。

【Forge】経過時間1 min. 5.0 sec.A: 7.20 GB, R: 8.22 GB, Sys: 9.6/15.9922 GB (60.0%)

【A1111】経過時間1 min. 14.6 sec.A: 7.60 GB, R: 11.78 GB, Sys: 16.0/15.9922 GB (100.0%)

こちらも9秒の差が出ました。生成されたグリッド画像をGIF比較してみると、意外と結構変化があることが分かります。どちらが低劣かと言われると印象の差かもしれませんが、細かなつぶれなどはA1111よりもForgeの方がみられたので、多少「早かろう安かろう」な面はあるのかもしれません。

拡張機能について

A1111版の拡張機能は結構そのまま使えるものも多いようですが、特にUnetに関わる拡張は現時点で互換していないものがあるようです。LoRA Block Weightやnegpipなど、早速forge対応が報告されている拡張もありました。

また、forgeではcontolnetとTiledVAEが統合された関係で、「sd-webui-controlnet」と「multidiffusion-upscaler-for-automatic1111」の二つはA1111版から流用できず、新規インストールした場合はアンインストールする必要があるようです。

Controlnet用の学習済みモデルについても、Checkpointなどと同じように該当フォルダにコピーすれば普段通り利用できます。

▼SD1.5用Controlnetモデル

▼SDXL用Controlnetモデル

また、A1111版にはない機能として、前述した「Unet Patcher」の恩恵で、「Controlnetのマスク機能」「IP-Adapterのマスク機能」「新CN：Photomaker」といった新機能が実装されています。

Controlnetのマスク機能

Controlnetを使った生成の際に、影響範囲をマスクする機能が新設されています。例えば２つの画像を入力して、次のようなことができるようになります。

①画像A（軍人）を一つ目のCNで読み込み、「UseMask」をオンにして上半分を雑に塗りつぶします。

②画像B（猫娘）を二つ目のCNで読み込み、UseMaskで今度は下半分を塗りつぶします。

③生成すると、軍人キャラの上半身と猫娘キャラの下半身をCannyした結果が得られます。

他にもさまざまなCNモデルで同様のマスク適用を行うことができ、例えば公式では人物写真Aと人物写真BをそれぞれIPAdapterで顔認識させ、横長画像の左側と右側にABそれぞれの人物を呼び出すようなこともできていました。

たださきほどのCannyの実験、SD1.5系モデルでは成功したのですが、SDXL用の「kohya_controllllite_xl_canny」では下図のようになってしまい、成功しませんでした。CNモデル側の理由かどうかわかりませんが、もう少し検証が必要なようです。

▲死んだにゃ…

また、こうしたバグ報告（▼）もSNS上でちらほら見かけます。

なにしろ昨日公表されたばかりですから、こうした細かなバグは今後パッチが当たっていくと思いますが、むしろ（A1111版に準拠しているとは言え）最初からこの完成度でリリースされたのは素晴らしいと感じました。起動時間もA1111版に比べて早く、操作感は同じでたいていの機能は互換が効きそうとなれば、目立ったバグがない限りは乗り換えの選択肢になりそうですね。

新サンプラー

また、DDPM、DDPM Karras、DPM++ 2M Turbo、DPM++ 2M SDE Turbo、LCM Karras、Euler A Turboといった新たなサンプラーも導入されています。

まとめ

駆け足で見てきましたが、Forgeの第一印象としては「早い！軽い！操作感そのまんま！」という小学生みたいな感想となりました。

A1111版に慣れてずっと使ってきた私としては、ちょっとくらい便利になっても使い勝手が変わるのは大きなマイナスポイントになってしまうのですが、Forgeは今回ご紹介したようにUIもフォルダ構成もボタンの位置も「基本そのまんま」なwebUIですので、問題なく使用することができました。あとは未知のバグ等や今後のアップデート、拡張機能の互換などがA1111と比べてどうかというところですが、特にVRAM8GB～12GBのグラボを使用している方にとってはより大きな速度改善が見込めるということですので、試して損はないのではないかと思います。

速度については、小さいサイズではさほど差が感じられなかったのですが、バッチ数や生成サイズを上げるほどにしっかりと感じられました。速度もそうですが、VRAM使用率の低さが優秀です。これまでCUDA out of memoryを起こしていたサイズにもアップスケールできるようになりそうですので、いろいろさらに検証を進めたいと思います。（新たに分かったことがあればこちらの記事に追記していくつもりです）

そんなわけで、今日はこのへんで。明日からはプロンプト超辞典の検証も、試しにForgeを使って進めてみたいと思います。