Mastering ComfyUI — Part 9: Performance & Troubleshooting
Understand where your GPU's VRAM actually goes, the levers you control (batch size, resolution, tiled VAE, loaded models), how to monitor usage, and a consolidated error reference for the whole series.
Goal for this part: understand where your GPU's VRAM actually goes, how to manage it deliberately instead of hitting walls by surprise, and have one consolidated place to check when something breaks.
Previous: Part 8 — Workflow Management
Where VRAM actually goes
Every piece of a workflow that's loaded onto the GPU competes for the same pool of VRAM:
- The checkpoint itself (
MODEL+CLIP+VAE) — several GB depending on the model; Flux and other larger architectures cost more than SDXL-family checkpoints. - Any LoRAs applied on top (small individually, but they still occupy memory once loaded).
- Any ControlNet models in use.
- Any upscale models in use.
- The actual working memory needed during sampling, which scales with resolution and batch size — this is the part that changes run-to-run even with the same models loaded.
When you run out, ComfyUI throws an out-of-memory error rather than silently degrading — so the goal is managing the inputs you control (resolution, batch size, how many models are loaded at once) rather than reacting after a crash.
The levers you actually control
Batch size — the most direct trade: batch_size on Empty Latent Image (or
wherever your batch is set) multiplies VRAM cost roughly linearly. Generating 4
images at once costs roughly 4x the working memory of generating 1. If you're
pushing resolution or a heavy model and hit memory limits, batch size is the
first thing to drop back to 1.
Resolution — also scales memory cost, though less linearly than batch size. This is another reason the "generate at native resolution, then upscale" pattern from Part 6 matters for more than just quality — a native-resolution generation followed by an upscale pass is often cheaper in peak memory than one enormous single-pass generation, in addition to producing better output.
Tiled VAE decode — VAE Decode (and VAE Encode) can, on some ComfyUI
builds/nodes, run in tiled mode (VAE Decode (Tiled)), processing the image in
smaller chunks rather than all at once. This trades a small amount of speed for a
real reduction in peak VRAM specifically during the decode step — worth reaching
for if you're comfortably fitting a generation in memory but hitting an
out-of-memory error specifically at the decode stage, which is a distinct symptom
from running out of memory during sampling itself.
How many models are loaded simultaneously — a workflow with a checkpoint, two LoRAs, a ControlNet model, and an upscale model all active at once has all of them resident in VRAM together. If you're memory-constrained, look for the actual heaviest workflow you're running and count what's loaded, rather than assuming the checkpoint alone is the whole cost.
Monitoring GPU usage
Keep an eye on actual usage rather than guessing:
nvidia-smi(ornvidia-smi -l 1for a live-updating view) from a terminal shows current VRAM usage and GPU utilization directly — the most reliable source of truth for what's actually happening on the card right now.- ComfyUI's own Console panel (Part 1) will often show a specific out-of-memory
traceback naming which allocation failed, which is more informative for
diagnosing where in the pipeline memory ran out than
nvidia-smialone.
Watch usage while a new, heavier workflow runs for the first time. Running
nvidia-smi -l 1 in a spare terminal while you test a new upscale chain or a
newly-added ControlNet setup for the first time tells you immediately how much
headroom you actually have, rather than finding out the hard way with a batch
size increase later.
Consolidated error reference
A single place to check first when something goes wrong, gathering everything covered across this series:
| Symptom | Likely cause | Where it's covered |
|---|---|---|
| "Missing Models" / red-outlined node | Filename mismatch between workflow and what's actually in your models folder | Part 3 |
| A specific input dot shows unconnected, run refuses | A required input was never wired | Part 3 |
| Inpainted region doesn't change | Empty mask, or wrong source image reselected after painting | Part 5 |
| Positive prompt seems ignored | Stale wiring still pointing at an old/unused node chain | Part 5 |
| LoRA "does nothing" | Missing trigger word, or strength set too low | Part 4 |
| Output distorted/oversaturated after adding a LoRA | Strength set too high | Part 4 |
| Two similar subjects merge into one hybrid figure | Fundamental limit of regional conditioning; try distinct poses or inpainting instead | Part 5 |
| Hires-fix pass makes the image worse | Second-pass denoise set too high | Part 6 |
| Upscale node errors on mismatched size/channels | Feeding it a latent instead of a decoded image, or vice versa | Part 6 |
| ComfyUI fails to start after installing an extension | A custom node pack failed to import — check console traceback for which one | Part 7 |
| "Missing node type" loading someone else's workflow | A custom node pack referenced isn't installed — use Manager's resolver | Part 7 |
| Out-of-memory error | Batch size, resolution, or total loaded models exceeding available VRAM | This part |
| Out-of-memory specifically at decode | Try tiled VAE decode | This part |
The pattern behind almost every entry here. Nearly every failure in this table comes down to one of three things: something isn't wired to what you think it's wired to, a file the workflow expects doesn't match what's actually on disk, or a setting (strength, denoise, batch size) is outside the range that setting actually needs for what you're trying to do. When something new breaks that isn't in this table, checking which of those three categories it falls into is usually the fastest way to narrow it down.
Next: Part 10 — Looking Ahead.
Previous: Part 8 — Workflow Management