Stable DiffusionのVRAM不足は、設定で改善できることがある。急に遅くなったなら、まずNVIDIAの「Sysmem Fallback」（VRAMが足りないときにメインメモリを使う仕組み）を疑う。止めると速度が安定する代わりに、足りないときはエラーで止まる（NVIDIA公式）。VRAMが少ないならSD WebUI Forgeも選択肢だ。
「CUDA out of memoryエラーが出るたびに生成が止まる」「以前は数秒で生成できたのに急に数分かかる」——このStable Diffusionの定番トラブルは、GPUスペック不足だけが原因ではない。ドライバー設定とUIの選択で改善できることがある。本記事では4〜16GBのVRAM容量別に最適化手順を解説する。
急激な速度低下の原因は何か？ Sysmem Fallbackで生成が遅くなる
結論：NVIDIAドライバーの「System Memory Fallback」機能が原因のことがある。止めると速度は安定するが、VRAMが足りなければエラーで止まる。
NVIDIAはドライバー536.40で、VRAMを使い切ったときにメインメモリ（共有メモリ）を使って処理を続ける仕組みを入れた。以前ならメモリ不足で落ちていた処理が、遅くなりながらも動き続ける。NVIDIAの説明では、Stable DiffusionはVRAMを6GB近く使うことが多く、6GBのGPUではこの仕組みが働いて遅くなることがある。メインメモリはPCIe越しに使うので、VRAMよりずっと遅い。
プログラム追加でStable DiffusionのPython実行ファイル（python.exe）を指定する。パスは、Stable Diffusionを動かしている間にタスクマネージャーで確かめられる（NVIDIA公式）
CUDA - Sysmem Fallback Policy」を「Prefer No Sysmem Fallback」に変更して「適用」ドライバー546.01以降で使える設定。変えたらStable Diffusionを再起動する（NVIDIA公式）。VRAMが足りない設定ではOOMエラーで止まるようになる代わりに、速度は安定する。
PyTorchのメモリ断片化を防ぐには？ max_split_size_mbの設定方法
結論：空きがあるのに「Tried to allocate…」で止まるなら、断片化を減らす設定を試す価値がある。ただしPyTorchの文書は「最後の手段」としている。
VRAMの合計空き容量は足りているのにOOMが出る場合、断片化が原因のことがある。PyTorchのmax_split_size_mbは、指定より大きいメモリのかたまりを分割しないようにして断片化を減らす設定で、境目のケースならOOMを避けられることがある。PyTorchの文書は、性能への影響が「無し」から「大きい」まであり得るとし、OOMで止まる作業の最後の手段として位置づけている。webui-user.batのCOMMANDLINE_ARGSより上に、例えば次のように書く（値は環境しだいで調整する）。
set PYTORCH_CUDA_ALLOC_CONF=garbage_collection_threshold:0.6,max_split_size_mb:32
Forgeに乗り換えるべき？ A1111との速度差と移行メリット
結論：Forgeは、A1111を土台にリソース管理と推論の速さを改善することを目的にしたプラットフォーム。どれだけ速くなるかはGPUと設定しだい。
SD WebUI Forge（Forge）はAutomatic1111（SD-WebUI 1.10.1）を土台に、開発をしやすくし、リソース管理を最適化し、推論を速くし、実験的な機能を試すためのプラットフォームだ（README）。FLUXのNF4やGGUFも扱える（READMEの案内）。UIの選び方で迷うならComfyUI vs A1111比較記事も参考にしてほしい。
A1111と比べてどれだけ速くなるかの数字は今のREADMEに無く、当サイトでも測っていない。
【VRAM容量別】Stable Diffusion最適化設定マニュアル
| VRAM | 推奨モデル | 主要設定 | ポイント |
|---|---|---|---|
| 4GB | SD1.5（512×512） | --lowvram --xformers |
Forgeへの移行が最優先 |
| 6〜8GB | SD1.5 / SDXL入門 | --medvram-sdxl --xformers |
Flux.1はA1111ではなくForgeやComfyUIで、NF4・FP8などの量子化版を使う |
| 12GB | SDXL快適動作 | 設定不要 | LoRA学習のエントリーライン |
| 16GB+ | SDXL（Flux.1はForgeやComfyUIで） | 設定不要 | 不要な引数が残っていないか確認 |
6〜8GB帯でFlux.1を動かすなら、ForgeやComfyUIでFP8・NF4などの量子化版を使う。詳しくはFlux.1 VRAM量子化比較を参照してほしい。
Stable Diffusionを基礎から体系的に学びたい場合は、Udemyの動画講座も活用できます。
📘 VRAMを減らす設定が速度をどう変えるかを数字で知りたい方へ：当サイト運営者がZennで公開している電子書籍『画像生成AI・ローカルLLMを“安く速く”動かす実測ガイド』（有料・500円／第1〜2章は無料公開）で、量子化・オフロード・スライスが実際に何GB減らし、速度をどれだけ犠牲にするのかを RTX 4070 Ti SUPER（VRAM 16GB）で実測しています（この記事のSysmem Fallback・Forge・Tiled VAEなどは本の対象外です）。無料の第2章「VRAM早見表と判断フロー」で、そもそも自分のGPUで足りるのかを先に切り分けられます。
まだVRAMが足りない？ Tiled VAEとバックグラウンドVRAM解放のテクニック
結論：大きい画像は、Tiled VAEなどのタイル処理で少ないVRAMでも作れる範囲が広がる。ほかのアプリが使っているVRAMも確かめる。
Hires.fixなどで大きい画像をVAEでデコードすると、VRAMを多く使う。拡張機能「Tiled Diffusion & Tiled VAE」（multidiffusion-upscaler-for-automatic1111）は、画像をタイルに分けて処理する方法で、少ないVRAM（6GB以下）でも2K以上の大きい画像の生成・拡大を目指したものだ（README）。また、ブラウザやチャットアプリなどもGPUのメモリを使う。タスクマネージャーでGPUを使っているアプリを確かめ、必要ならそのアプリのハードウェアアクセラレーションを切る。
ここまでの最適化を試してもVRAM不足が解消しないなら、GPUを用意せずクラウドで生成する手もあります。ConoHa AI CanvasはブラウザからAUTOMATIC1111・ComfyUIを使え、公式の対応モデルはStable Diffusion 1.5/2.0/2.1/XLです。
まとめ：ソフトウェアの最適化でハードウェアの限界を超えよう
VRAM問題はGPUスペックだけが原因ではない。①Sysmem Fallback無効化、②PyTorchメモリ断片化対策、③ForgeへのUI移行——この3つを順に試すと、原因を切り分けやすい。自分のVRAM容量に合った設定を適用し、限界を感じたら高VRAM GPUへのアップグレードを検討しよう。RTX 5070 Tiの価格推移とBTOセール比較も参考に。
VRAM 4GBでStable Diffusionは実用的に使えますか？▼
--lowvram（速度は大きく落ちる）や--xformersを使います。SDXLやFlux.1は厳しく、ForgeやComfyUIで量子化版を使うのが現実的です。Sysmem Fallbackを無効化するデメリットはありますか？▼
--medvram等と組み合わせてバランスを取れます。
コメント