Forge vs 通常WebUI:RTX 3060 12GB VRAM比較

Forge vs 通常WebUI:RTX 3060 12GB VRAM比較

※本記事にはプロモーション(広告・アフィリエイトリンク)を含みます。

RTX 3060 12GB で Stable Diffusion を動かすとき、通常の Automatic1111 WebUI(A1111)と Forge WebUI でどれだけ VRAM 消費が変わるのか——この記事では比較軸を先に定義し、モデル別の目安値を表にまとめたあと、状況別にどちらを選ぶべきかを書きます。

Forge WebUI とは何か

Forge WebUI(stable-diffusion-webui-forge)は、A1111 をベースに開発者 lllyasviel が公開した派生版です(執筆時点)。操作 UI と拡張機能の互換性を維持しながら、内部のメモリ管理と計算処理を大幅に再設計しています。

主な変更点は3つです。

  • Forge Attention:独自実装のアテンション機構。xformers より VRAM 使用量を削減できると開発者が説明しています。
  • ControlNet の最適化:複数枚同時使用時のメモリ確保ロジックを見直し、ピーク VRAM を下げると開発者は説明しています。
  • SDXL・FLUX 系対応の強化:大きなモデルを少ない VRAM で動かすためのバックエンド変更。

私が自宅サーバー(Linux、RTX 3060 12GB)で日常的に使っているのは A1111 の --api モードです。以下の Forge に関する VRAM 比較値は、開発者の GitHub(lllyasviel/stable-diffusion-webui-forge)に掲載された情報および一般に報告されている値を参照しています。自分で同条件を計測した数値ではないため、あくまで参考値として読んでください。

比較軸を整理する

何を基準に比べるかを先に固定します。「VRAM が足りるか」だけが判断軸ではないためです。

比較軸 A1111 Forge
VRAM 使用量(SD 1.5) 3〜5 GB 前後 2〜4 GB 前後
VRAM 使用量(SDXL) 8〜10 GB 前後 6〜8 GB 前後
FLUX.1 系モデル対応 標準版は未対応 対応
UI・拡張機能の互換性 基準 ほぼ同等
API(/sdapi/v1/)互換性 あり あり(同仕様)
セットアップ情報の豊富さ 多い A1111 経験者なら低コスト

VRAM 差が特に大きく出るのは SDXL 以上のモデルです。SD 1.5 の 512×512 生成であれば、12GB では A1111・Forge どちらも余裕があるため、VRAM 面での優劣はほぼ関係しません。

モデル別 VRAM 使用量の目安

以下は Forge 開発者の GitHub 情報および一般に報告されている数値をもとにした目安です。LoRA 枚数・ControlNet の有無・解像度・ドライババージョンによって実際の値は変わります(環境によって異なります)。

モデル 解像度 A1111 + xformers Forge 備考
SD 1.5 512×512 3〜4 GB 2〜3 GB 12 GB では余裕
SD 1.5 768×768 5〜6 GB 4〜5 GB 12 GB では余裕
SDXL 1.0 1024×1024 8〜10 GB 6〜8 GB A1111 でも動くが余裕が少ない
SDXL + ControlNet×2 1024×1024 OOM の可能性 9〜11 GB Forge で安定する場合あり
SDXL + Hires fix 〜2048px OOM または不安定 ギリギリ動く場合あり 解像度依存
FLUX.1 Schnell(fp8) 1024×1024 未対応(標準版) 8〜10 GB Forge のみ対応

SDXL + ControlNet 複数枚、または Hires fix を使うと、A1111 では 12GB を超えて OOM になるケースがあります。Forge ではこの上限が数 GB 下がるため、同じ操作が通るようになる可能性があります。

FLUX.1 Schnell を RTX 3060 12GB で動かすときの具体的な設定については、FLUX Dev 20ステップ vs Schnell 4ステップ — RTX 3060 12GBでの設定と選択基準にまとめています。

状況別:A1111 か Forge か

A1111 のままで十分な状況

  • SD 1.5 または SD 2.x を中心に生成している
  • --api で外部スクリプトから叩いており、API の仕様を変えたくない
  • 現状 OOM が出ておらず、他プロセスと VRAM を問題なく共有できている

筆者の自宅サーバーでは ComfyUI・A1111 WebUI・Ollama が同じ RTX 3060 12GB を共有しており、A1111 の --api モードで SD 1.5 の生成を行っています。SD 1.5 中心の構成では VRAM に余裕があるため、複数プロセスとの共存でも安定しやすいと考えられます。

Forge に乗り換える価値がある状況

  • SDXL を高解像度・ControlNet 付きで使っていて OOM が頻発している
  • FLUX.1 系モデルを WebUI から試したい
  • Hires fix やマルチ ControlNet など VRAM を大量に消費する処理を通したい

どちらでもほぼ変わらない状況

  • SD 1.5 の低解像度(512×512〜768×768)のみ
  • 生成速度の差を体感レベルで比べたい(改善はあるが、劇的な差が出ない場合も多いと考えられます)

Forge の導入手順(A1111 ユーザー向け)

A1111 と別ディレクトリに入れるのが安全です。既存環境をそのまま残して試せます。

git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git ~/forge-webui
cd ~/forge-webui
# 初回起動(Python 環境と依存関係を自動インストール)
./webui.sh

A1111 のモデルフォルダをシンボリックリンクで参照すると、.safetensors を二重に置かずに済みます。

ln -s ~/stable-diffusion-webui/models/Stable-diffusion ~/forge-webui/models/Stable-diffusion

--api モードと任意のポートで起動できます。A1111 と共存させるときはポートを変えてください。

./webui.sh --api --port 7861

APIエンドポイント(/sdapi/v1/txt2img など)は A1111 と共通仕様とされています。既存スクリプトの接続先 URL のポート番号だけ変えれば動作確認できます。

まとめ

状況 結論
SD 1.5 中心・--api 運用 A1111 のまま問題なし
SDXL 高解像度・ControlNet 複数枚 Forge で OOM 回避を試す価値あり
FLUX.1 系を使いたい Forge が必要
OOM で止まっている 別ディレクトリに Forge を入れて比べる

A1111 と Forge の最大の違いは、SDXL 以上のモデルで VRAM 上限が数 GB 下がるとされていること。SD 1.5 のみの運用なら RTX 3060 12GB でどちらも安定して動くため、急いで移行する必要はありません。

次の一手:今使っているモデルが SD 1.5 か SDXL かを確認してください。SDXL 以上であれば、A1111 を残したまま Forge を別ディレクトリに入れて比べてみるのが最もリスクの低い進め方です。

この記事で触れたもの

よくある質問

Forge WebUI をインストールしても A1111 の拡張機能はそのまま使えますか?

多くの拡張機能は Forge でもそのまま動作します。ただし一部はアップデートが必要な場合があるため、使いたい拡張の GitHub Issues を確認するのが確実です。

RTX 3060 12GB で SDXL は A1111 だけでも動きますか?

1024×1024 程度であれば A1111 + xformers でも動作します。ただし ControlNet を複数枚使ったり Hires fix をかけると OOM になる場合があります。Forge に切り替えることで余裕が生まれる可能性があります。

Forge と A1111 は同じ PC に共存できますか?

別ディレクトリにインストールしてポートを変えれば共存できます(例:A1111 は 7860、Forge は 7861)。モデルはシンボリックリンクで共有すれば容量の重複を避けられます。

Forge の API エンドポイントは A1111 と互換性がありますか?

/sdapi/v1/txt2img など主要エンドポイントは A1111 と同じ仕様です。既存スクリプトの接続先 URL のポート番号だけ変えれば、コードを書き直さずに動作確認できます。