ComfyUIのVRAM不足は、「本当にOOMか」「どのノードが原因か」「削るか逃がすか」の順に切り分けると、GPUを買い替えずに直せる範囲が見えてきます。この記事では、症状の見分け方、Peak VRAMの測り方、解像度・Batch・Model・Control系・Offloadの順に一つずつ変える手順と、買い替え判断の前に残す記録表をまとめます。
情報確認日：2026年8月22日（日本時間）
結論：原因を一つずつ分離してから、削るか逃がすかを決める
責任範囲
- CUDA OOM・共有メモリへの退避・単なる遅さを、ログと計測値で区別する
- 生成前・生成中のPeak VRAMを
nvidia-smiで記録する手順を示す - 解像度、Batch、Model、VAE、ControlNet系を一つずつ変えて負荷差を測る
--lowvramなどのOffload系オプションと速度低下の関係を説明する- GPUの機種選びや価格比較は扱わない。基本操作はComfyUIの基本を参照
VRAM不足の症状は三つに分かれる
「VRAMが足りない」と感じる場面には、実際には三つの別の状態が混ざっています。対処が違うため、最初に分けます。
| 状態 | 見え方 | 判断材料 |
|---|---|---|
| CUDA OOM | 生成が途中で止まり、エラーダイアログが出る | ターミナルにCUDA out of memoryを含むPyTorchの例外が出る |
| 共有メモリへの退避 | 止まらないが、途中から極端に遅くなる | Windowsのタスクマネージャーで「共有GPUメモリ」が増える。専用GPUメモリはほぼ上限に張り付く |
| 単なる遅さ | 最初から一定の速さで遅い | VRAMに余裕があるのに秒／枚が長い。Model読み込みの初回時間や、CPUで動いているノードが原因のことが多い |
CUDA OOMはPyTorchが確保に失敗した時点で止まるので、例外メッセージに「いくら確保しようとして、いくら空いていたか」が含まれます。ここを読むだけで、あと少し足りないのか、桁違いに足りないのかが分かります。
共有メモリへの退避は、GPUドライバーがVRAMの溢れ分をシステムRAMに逃がす挙動です。エラーにならないぶん気づきにくく、「Batchを上げたら急に10倍遅くなった」という訴えの多くはこれです。止まらないからといって足りているわけではありません。
ComfyUI自身の管理も見る：ComfyUIはModelをVRAMとRAMの間で動かす仕組みを持ち、現行版ではDynamic VRAM（公式の起動フラグ一覧で--enable-dynamic-vram / --disable-dynamic-vramとして説明されています）が関わります。OOMが出ないのに遅い場合、この退避が働いている可能性があります。
現在のVRAMをどう測るか
感覚で「足りない」と言う前に、生成前の使用量と生成中の最大値（Peak）を数字で残します。この二つが揃えば、どの変更が何GB効いたかを比べられます。
生成前の使用量を確認する
nvidia-smi --query-gpu=memory.used,memory.total --format=csvComfyUIを起動しただけの状態で、ブラウザ・他アプリが使っている分を含めた現在値が分かります。ブラウザのハードウェアアクセラレーションだけで数百MB使っていることは珍しくありません。
生成中のPeakを記録する
nvidia-smi --query-gpu=timestamp,memory.used --format=csv -l 1 > vram-log.csv1秒間隔で使用量を書き出しながら生成を実行し、終わったらCtrl+Cで止めます。CSVの最大値がPeakです。1秒の間に一瞬だけ跳ねる確保は取りこぼすことがあるため、OOMの境目を詰めたいときは-lms 200のようにミリ秒指定へ切り替えます。
ComfyUIの/system_statsエンドポイント（公式のServer APIルート一覧に記載）でもデバイスごとのVRAM情報を取得できますが、生成中の連続記録にはnvidia-smiのほうが向いています。
計測の前に揃えること：seed、sampler、steps、promptを固定し、ComfyUIを再起動してから測ります。前の生成でVRAMに残ったModelがあると、次の計測の「生成前」が変わってしまいます。
解像度とBatchはどちらから下げるか
結論は「Batchを先に1へ、次に解像度」です。Batchは潜在画像の枚数を線形に増やすので、VRAMへの効き方が素直で切り分けやすいからです。
解像度はKSamplerの潜在空間だけでなく、VAE Decodeの段階でも効きます。SD系のVAEはピクセル空間へ戻すときに大きな中間テンソルを作るため、「サンプリングは通るのにDecodeで落ちる」という現象が起こります。ログで落ちたノード名を見れば、どちらの段階かが分かります。
段階を変えて記録する手順
- 1
基準を作る
Batch 1・いつもの解像度で生成し、Peak VRAMと秒／枚を記録する
- 2
Batchだけ変える
解像度を固定したままBatch 2、4と上げ、Peakの増え方を見る
- 3
解像度だけ変える
Batch 1へ戻し、幅と高さを同じ比率で一段階ずつ上げ下げする
- 4
落ちたノードを控える
OOMが出たら、エラーに含まれるノード名と確保失敗サイズをそのまま表へ書く
| width×height | batch | Peak VRAM（GB） | 秒／枚 | 落ちたノード |
|---|---|---|---|---|
| 基準値 | 1 | |||
| 基準値 | 2 | |||
| 基準値 | 4 | |||
| 一段階下 | 1 | |||
| 一段階上 | 1 |
数値はGPU、Model、sampler、custom nodeで大きく変わるため、この記事では目安を示しません。自分の環境で表を埋めると、「Batch 1枚あたり何GB」「解像度を一段階上げると何GB」という自分用の係数が手に入ります。
VAE Decodeで落ちる場合は、画像を分割して復号するVAE Decode (Tiled)ノードへ置き換える選択肢があります。サンプリング側は変えずにDecodeだけ軽くできるため、解像度を下げたくないときの第一候補です。
Model・VAE・Control系を別要因として切り分ける
同じ解像度・Batchでも、読み込んでいるModelの種類と数でVRAMの土台が変わります。ここを混ぜたまま解像度を調整しても、原因が分かりません。
| 要因 | 効き方 | 切り分け方 |
|---|---|---|
| Checkpoint本体 | 系統（SD1.5・SDXL・それ以降）とデータ型で常駐量が決まる | 最小workflowで同じModelだけ読み、生成前の使用量を記録する |
| Text Encoder | 大型の言語モデルを使う系統では本体並みに大きい | 起動ログの読み込み先（GPUかCPUか）を確認する |
| VAE | 常駐は小さいがDecode時のPeakが大きい | Decodeで落ちるかどうかをログで見る |
| LoRA | 重ねるほど適用時の一時メモリが増える | LoRAを外した状態と比べる |
| ControlNet・IP-Adapter系 | モデルごとに追加で常駐し、前処理ノードも別にメモリを使う | 一つずつ外し、Peakの差を表に書く |
ControlNetを複数同時に使う構成は、負荷の切り分けと強度の調整が別の話題になるため、別記事で扱います。この記事では「外すとPeakが何GB下がるか」を記録するところまでにとどめます。
データ型の選択肢
ComfyUIの起動フラグには、UNet・Text Encoder・VAEの精度を指定するものがあります（例：--fp8_e4m3fn-unet、--fp8_e4m3fn-text-enc、--fp16-vae）。精度を下げればその部分の常駐量は減りますが、公式の説明にもあるとおり--fp16-vaeは黒い画像になる場合があります。画質の変化とセットで記録し、どちらを取るかを自分で決めます。
Model要因を疑うときの順番
- 最小workflow（Checkpoint・Text Encode・KSampler・VAE Decode・Save）で動くか
- Checkpointを同系統の軽量版に替えると生成前の使用量が下がるか
- LoRA・ControlNetを一つずつ戻して、どこでPeakが跳ねるか
- custom nodeが独自にModelを読み込んでいないか（起動ログで確認）
Offload・Low VRAMモードは何を犠牲にするか
削っても足りないときは、VRAMに置くものを減らしてRAMやCPUへ逃がします。速さと引き換えになるため、Trade-offを数字で残すことが前提です。
| 起動フラグ | 公式の説明（要約） | 代償 |
|---|---|---|
--lowvram |
Dynamic VRAMが有効なら効果なし。無効時はText EncoderをCPUで動かす | Encodeが遅くなる |
--novram |
--lowvramで足りないときの最小VRAM動作 |
全体が大きく遅くなる |
--cpu-vae |
VAEをCPUで実行する | Decodeが遅くなるが、Decode時のPeakを避けられる |
--reserve-vram N |
OSや他ソフト用にNGBを予約する | 使えるVRAMが減るぶん、マルチモニターや配信との共存が安定する |
--disable-smart-memory |
Modelを保持せず積極的にRAMへ退避する | 毎回の再読み込みで初回時間が伸びる |
--highvram |
使用後もModelをGPUに保持する | 余裕がある環境で速くなる。不足環境では逆効果 |
これらは公式の起動フラグ一覧（2026年8月時点）に基づきます。Dynamic VRAMが既定で有効な環境では--lowvramが効かない点は見落としやすいので、起動ログで現在のモードを確認してから試してください。
フラグの渡し方は導入方法で違います。Windows Portableならrun_nvidia_gpu.batなどの起動ファイルに追記し、手動導入ならpython main.pyの後ろへ付けます。Desktop版は設定画面からサーバー引数を渡す項目があるため、現行UIの名称は公式ドキュメントで確認してください。
万能設定はない：「とりあえず--lowvram」は、Dynamic VRAMが有効な環境では何も変わらず、無効な環境では速度だけ落ちることがあります。フラグは一つずつ試し、Peak VRAMと秒／枚の両方を記録してから採用を決めます。
買い替え前に残す記録表
ここまでの計測を一枚の表にすると、「どの条件なら今のGPUで足り、どの条件で足りないか」が客観的に残ります。買い替えを判断する材料としても、後で設定を戻すときの基準としても使えます。
| Model | ComfyUI version | 解像度 | batch | Offload設定 | Peak VRAM（GB） | 秒／枚 | 結果 |
|---|---|---|---|---|---|---|---|
| 1 | なし | ||||||
| 1 | --cpu-vae |
||||||
| 1 | --lowvram |
||||||
| 4 | なし |
「結果」列には、成功・OOM・共有メモリ退避のどれかと、落ちたノード名を書きます。versionはComfyUIの起動ログ先頭に表示されるものを写します。Model管理の仕組みは更新で変わるため、versionが違う記録を同じ行に混ぜないようにします。
表を埋めたあとで残る不足が「Peakが常にVRAM容量を上回る」種類なら、設定では解決しません。逆に「Batch 1なら通るが4で落ちる」なら、用途によっては買い替えよりも並列数の設計で足ります。その判断は表を見て自分で下せます。
よくある質問
OOMが出ないのに極端に遅いのはVRAM不足ですか？
多くの場合はそうです。GPUドライバーが溢れ分を共有メモリへ逃がしているか、ComfyUIがModelをRAMへ退避しています。タスクマネージャーの共有GPUメモリと起動ログを見て、どちらが起きているかを確認してください。
解像度を下げずにVRAMを減らす方法はありますか？
Decodeで落ちるならVAE Decode (Tiled)や--cpu-vae、常駐が大きいならデータ型の変更やLoRA・ControlNetの削減が候補です。どれも速度か画質と引き換えなので、記録表で差を確認してから選びます。
VRAMは何GBあれば足りますか？
Model系統・解像度・Batch・同時に使う制御系で変わるため、一律の数字は示せません。この記事の記録表を自分の条件で埋めると、必要量が自分の環境の数値として分かります。
まとめ
VRAM不足は、まずCUDA OOM・共有メモリ退避・単なる遅さを区別し、nvidia-smiで生成前とPeakを記録するところから始めます。そのうえでBatch、解像度、Model、VAE、Control系、Offloadの順に一つずつ変え、Peak VRAMと秒／枚を表に残します。
削る・逃がす・買い替えるのどれを選ぶかは、その表を見れば自分で決められます。ノードのつなぎ方や最小workflowの組み方はComfyUIの基本で確認してください。