ComfyUI VRAM 12GBで複数モデルを切り替える設定と上限

RTX 3060 の 12GB VRAM で ComfyUI を使うとき、複数のモデルをどこまで同時に読み込めるか、上限はどこで決まるのかを整理します。公式の起動オプションと、モデルごとの VRAM 消費の目安をもとに、12GB という制約のなかで実用的な設定を組み立てます。

12GB VRAM で「複数モデル同時読み込み」をどう考えるか

ComfyUI はモデルを VRAM に読み込んで推論を行います。「複数モデルを同時に使う」という状況は、ひとつのワークフローの中で Checkpoint・ControlNet・LoRA・VAE を組み合わせる構成や、複数のキューでモデルを切り替えながら生成を回す構成を指すことが多いです。

ComfyUI には「スマートメモリ管理」という仕組みがあります。公式 GitHub のソースコードによると、VRAM が不足する場合に使われていないモデルを自動的にシステム RAM へオフロードする実装になっています。つまり、ワークフロー内のモデル合計サイズが 12GB を超えても動作自体はしますが、オフロードのたびに転送コストが発生するため処理速度は低下します。

モデルごとの VRAM 消費の目安（fp16 精度、モデルファイルサイズからの推定値）：

※ 実際の使用量はバッチサイズ・解像度・サンプラーによって変動します。環境によって異なります。

ComfyUI の VRAM 関連起動オプション一覧

ComfyUI の起動オプションで VRAM の扱い方を制御できます。以下は執筆時点のオプションです（公式 GitHub の comfy/cli_args.py に定義されています）。

# VRAM制御モード（いずれかひとつを指定する）
python main.py --highvram    # モデルをVRAMに常駐させる。VRAMに十分な余裕がある環境向け
python main.py --normalvram  # デフォルト。VRAMとRAMを自動で使い分ける
python main.py --lowvram     # 少ないVRAM向け。モデルを分割してロード
python main.py --novram      # VRAMを使わずCPU+RAMのみで処理

# 個別チューニング（上記と組み合わせ可能）
python main.py --reserve-vram 1    # 1GBをOS等のために予約して残す
python main.py --vae-on-cpu        # VAEをCPUで実行してVRAMを節約
python main.py --disable-smart-memory  # スマートメモリ管理を無効化
python main.py --fp8_e4m3fn-unet   # UNetをfp8精度に変換してロード

12GB 環境で複数モデルを切り替えながら使う出発点は --normalvram（オプション未指定のデフォルト）です。SDXL Checkpoint + ControlNet + LoRA の組み合わせなら合計 8〜9GB 程度に収まることが多く、スワップなしで動く可能性があります。

VAE でメモリ不足が起きる場合は --vae-on-cpu を追加します。VAE の処理が CPU に移るぶん生成時間は増えますが、Checkpoint やその他モデルへの VRAM 割り当てを増やせます。

--reserve-vram N は「ComfyUI が使える上限をN GBに絞る」オプションではなく、「N GB を ComfyUI が使わないように確保しておく」オプションです。挙動の違いを把握しておかないと期待と逆の結果になることがあります。

FLUX.1 を 12GB で動かすための選択肢

FLUX.1 は bf16 フルサイズだと 12GB をほぼ使い切るか超えます。12GB 環境での選択肢は主に二つです。

① fp8 量子化版のモデルファイルを使う

Hugging Face などで配布されている fp8 版（flux1-schnell-fp8.safetensors のような命名）を使います。ComfyUI の Load Checkpoint ノードでそのファイルを選択するだけで、特別な起動オプションなしで読み込まれます。

② 起動オプションで fp8 変換する

# fp16/bf16モデルをロード時にfp8へ変換する
python main.py --fp8_e4m3fn-unet

このオプションを指定すると、fp16 モデルを VRAM に読み込む際に fp8 精度に変換します。生成画質への影響は用途と設定によって異なるため、比較してから判断することをおすすめします。

SDXL と FLUX を同一セッション内で交互に使うと、モデル切り替えのたびにオフロードが発生します。12GB ではモデルを一種類に絞って使うのが最も速い運用です。

複数モデルを切り替えるときにスマートメモリで起きること

ComfyUI のキュー実行では、前のキューで読み込んだモデルが VRAM にキャッシュされます。次のキューで同じモデルを使う場合はロードをスキップするため、連続生成が速い理由のひとつはここにあります。

異なる Checkpoint を交互に使う場合の流れ：

1. モデル A を VRAM にロード → 生成（例：SDXL、約 6〜7GB 使用）
2. モデル B をロードしようとする → VRAM が足りなければモデル A を RAM にオフロード
3. モデル B で生成
4. モデル A に戻る → RAM から VRAM へ再ロード

この「オフロード＋再ロード」のサイクルが増えると、生成時間よりも転送時間のほうが支配的になる場合があります。

ControlNet モジュールもワークフロー実行中に別途 VRAM を消費します（ControlNet の基本的な使い方はこちら）。SDXL と ControlNet を組み合わせると合計 7〜9GB 以上になる組み合わせも出てくるため、使うモジュール数を絞ることが現実的な対策です。

他プロセスと VRAM を共有する場合の注意

ComfyUI・Stable Diffusion WebUI・Ollama など複数のプロセスが同一の GPU を共有する構成では、よくある問題として、ComfyUI がモデルをオフロードしても VRAM の確保済み領域が即座に解放されないことが挙げられます。PyTorch のメモリアロケータが確保したページを保持し続けるためで、他プロセスが必要とする VRAM が空かない状況が発生します。

他プロセスに VRAM を渡したい場合は、ComfyUI を完全終了させるのが確実です。プロセスの停止に pkill -f を使うと、引数の文字列が自分自身のシェルセッションにマッチして SSH ごと切れる場合があります。ポートから PID を取得して kill する方法が安全です。

# ComfyUIが使用しているポート（デフォルト8188）からPIDを取得してkill
pid=$(ss -tlnp | grep ':8188' | grep -oP 'pid=\K[0-9]+')
[ -n "$pid" ] && kill "$pid"

nvidia-smi でリアルタイムの VRAM 使用量を確認できますが、ドライバ更新後に再起動していない環境では NVML エラーになることがあります（筆者環境でも現在この状態のため、VRAM の直接監視には別手段が必要な状況です）。

まとめ

12GB VRAM での ComfyUI 複数モデル運用の要点を整理します。

まず試してほしいのは、使いたい FLUX モデルの fp8 版を Hugging Face で探してダウンロードすることです。モデルファイルの精度選択ひとつで、12GB という制約のなかでの快適さが大きく変わります。SDXL 以下のモデルであれば、デフォルト設定のまま ControlNet や LoRA を組み合わせた複数モデルのワークフローを組むことができます。