← Back to Projects

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.

N
NOTE

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 (or nvidia-smi -l 1 for 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-smi alone.
T
TIP

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:

SymptomLikely causeWhere it's covered
"Missing Models" / red-outlined nodeFilename mismatch between workflow and what's actually in your models folderPart 3
A specific input dot shows unconnected, run refusesA required input was never wiredPart 3
Inpainted region doesn't changeEmpty mask, or wrong source image reselected after paintingPart 5
Positive prompt seems ignoredStale wiring still pointing at an old/unused node chainPart 5
LoRA "does nothing"Missing trigger word, or strength set too lowPart 4
Output distorted/oversaturated after adding a LoRAStrength set too highPart 4
Two similar subjects merge into one hybrid figureFundamental limit of regional conditioning; try distinct poses or inpainting insteadPart 5
Hires-fix pass makes the image worseSecond-pass denoise set too highPart 6
Upscale node errors on mismatched size/channelsFeeding it a latent instead of a decoded image, or vice versaPart 6
ComfyUI fails to start after installing an extensionA custom node pack failed to import — check console traceback for which onePart 7
"Missing node type" loading someone else's workflowA custom node pack referenced isn't installed — use Manager's resolverPart 7
Out-of-memory errorBatch size, resolution, or total loaded models exceeding available VRAMThis part
Out-of-memory specifically at decodeTry tiled VAE decodeThis part
N
NOTE

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