【StableDiffusion】VRAM8GBのSDXLは--medvramを入れるだけで生成18分が1分未満に｜起動オプション3つを比べた

VRAM 8GB のグラボ(RTX 2080 SUPER)で、Stable Diffusion web UI(AUTOMATIC1111 版。以下 A1111)を使って SDXL 系のモデルで画像を作っている。起動オプションには --xformers --medvram --no-half-vae を付けているが、それぞれがどれくらい効いているのか確かめたことがなかった。

そこで、3つを1つずつ外して、同じ条件で1枚ずつ生成して比べた。結論は「3つとも付けたままがよい」。中でも --medvram を外すと、エラーは出ないまま生成に18分かかった。

できた画像は、どの設定でも見た目では違いが分からなかった。差が出たのは生成時間だけだ。

VRAM 8GB で SDXL 系のモデルを使うなら、webui-user.bat の COMMANDLINE_ARGS の行に、少なくともこの3つを入れておけばよい。

set COMMANDLINE_ARGS=--xformers --medvram --no-half-vae

私の環境では、ほかに --listen --port 7861 --enable-insecure-extension-access も付けている(同じ家のネットワークの別の PC から使うためと、拡張機能を入れるため)。比べた3つとは関係ないので、以下では説明を省く。

試した環境と条件

• GPU: NVIDIA GeForce RTX 2080 SUPER(VRAM 8192MiB)、ドライバー 610.88
• A1111: v1.10.1(Python 3.10.6)
• モデル: songmix_v22(SDXL 系、6.62GB。起動時のログで sd_xl_base.yaml が使われている)
• サイズ: 768 x 1344
• サンプラー: DPM++ 2M、Schedule type: Simple、ステップ数 25、CFG スケール 6
• シード: 12345(毎回同じ画像になるように固定)
• Hires. fix: オフ、バッチ回数・バッチサイズ: 1
• プロンプト: すべて同じ

起動オプションを変えるたびに、WebUI を起動し直した。始める前に、元に戻せるよう webui-user.bat をコピーしておいた。

cd "D:\Program Files\Stable\stable-diffusion-webui"
Copy-Item webui-user.bat webui-user.bat.bak

終わったら、Copy-Item webui-user.bat.bak webui-user.bat -Force で元に戻せる。

いつもの設定(3つとも付ける)

まず基準として、いつもの設定で生成した。画像の下に出る「経過時間(Time taken)」が生成時間だ。

1回目は40.1秒だった。1回目は準備で遅いことがあるので、同じ条件でもう1回生成すると36.1秒だった。

--no-half-vae を外す: NaN が出て、やり直す分だけ遅くなる

--no-half-vae は、VAE(生成の最後に、計算結果を画像に変換する部分)を16ビットに切り替えずに動かすオプションだ。これを外して生成すると、画像は出たが、黒い画面(コンソール)に次のメッセージが出ていた。

A tensor with all NaNs was produced in VAE.
Web UI will now convert VAE into 32-bit float and retry.
To disable this behavior, disable the 'Automatically revert VAE to 32-bit floats' setting.
To always start with 32-bit VAE, use --no-half-vae commandline flag.

訳すと、「VAE で計算結果が壊れた(NaN になった)ので、VAE を32ビットにしてやり直す。最初から32ビットで動かすなら --no-half-vae を付けること」という内容だ。A1111 が自動でやり直してくれたので画像は普通に出たが、生成時間は1分0.1秒で、いつもの設定より20秒ほど長くなった。

メッセージにある「Automatically revert VAE to 32-bit floats」の設定をオフにしていると、自動でのやり直しはされない。その場合にどうなるか(エラーで止まるのか、真っ黒な画像になるのか)は、私は試していない。

--medvram を外す: エラーは出ずに18分かかる

--medvram は、少し速さを犠牲にして VRAM の使用量を減らすオプションだ。これを外すと、生成に18分28.2秒かかった。

コンソールを見ると、1ステップに約40秒(39.80s/it)かかっていた。--medvram を付けていた手順(--no-half-vae だけを外した回)では1秒あたり1.70ステップ(1.70it/s)だったので、ステップ1回あたりの時間は60倍以上になっている。

VRAM が足りなければ「CUDA out of memory」のエラーで止まると思っていたが、エラーは出なかった。エラーにならずにただ遅くなるので、--medvram を付け忘れていても原因に気付きにくい。生成が急に何分もかかるようになったら、まず起動オプションを確かめるとよい。

画像の下の「A: 9.68 GB」(計算のデータが実際に使ったメモリの最大値。詳しくは後で説明する)は、VRAM 8GB のカードなのに8GBを超えている。NVIDIA のドライバーには、VRAM が足りないときにメインメモリを代わりに使う仕組み(NVIDIA コントロールパネルの「CUDA - Sysmem Fallback Policy」)があり、これで足りない分を補っていたため、エラーにならずに遅くなったのだと思う。ただし、この設定は私は確かめていない。

--xformers を外す: 2〜3割遅くなる

--xformers は、画像を作る計算の一部(cross attention)を xformers というライブラリで行うオプションだ。外して起動すると、コンソールに「No module 'xformers'. Proceeding without it.」と出て、代わりに Doggettx という方式が使われた。

生成時間は47.9秒だった。いつもの設定の2回目(36.1秒)と比べると、2割から3割ほど遅い。

VRAM の使用量について

画像の下には、生成時間の右に「A: 〇GB, R: 〇GB, Sys: 〇/8 GB」と VRAM 関係の数字も出る。それぞれの意味は、文字にマウスのカーソルを合わせると出る説明(A1111 のソースコードに書かれている)によると次のとおりだ。

• A(Active): 生成中に、計算のデータが実際に使った VRAM の最大値。キャッシュは含まない
• R(Reserved): PyTorch(A1111 が使っている計算ライブラリ)が確保した VRAM の最大値。使い終わった後も再利用のために取っておく分(キャッシュ)を含む
• Sys(System): A1111 以外も含めて、PC 全体で使われた VRAM の最大値と、カードの総容量

A と R の最大値は、生成のたびに測り直される。今回の値は次のとおりだった。

Sys はどの設定でも100%で、カードの VRAM はいつも使い切っていた。そのため、Sys では設定ごとの違いは比べられなかった。

R はどの設定でも8GBを超えている。PyTorch はカードに載っている8GBより多くのメモリを確保していたことになり、足りない分は NVIDIA のドライバーがメインメモリで補っていたのだと思う(確かめてはいない)。

一方、A が8GBを超えたのは --medvram を外した回だけだ(9.68GB)。--medvram を付けた回は5.2〜5.7GBで、8GBに収まっていた。計算のデータそのものが VRAM に入りきらず、メインメモリとの間のやり取りが毎ステップ起きたため、18分もかかったと考えると説明がつく。これも私の推測だ。

まとめ

VRAM 8GB で SDXL 系のモデルを使うなら、--xformers --medvram --no-half-vae の3つは付けたままにしておく。どれを外しても画像は出たが、速くなるものは1つもなかった。特に --medvram は、外すとエラーにならないまま18分かかるので、生成が急に遅くなったときは真っ先に疑うとよい。

関連記事

同じ VRAM 8GB のグラボで、ComfyUI を使った動画生成の環境を作った話はこちら。

• 【ClaudeCode】VRAM8GBのグラボでローカルAI動画生成環境を丸ごと作ってもらった話

参考

• Command Line Arguments and Settings(stable-diffusion-webui の Wiki)