How accurate are the VRAM estimates?

They are rough planning figures at fp16 and 1024px, meant to tell you whether a workflow is comfortable, tight, or impossible on your card. Real usage shifts with resolution, sampler, and attention optimizations, so treat the number as a guide rather than a guarantee.

Which node uses the most VRAM?

After the checkpoint itself, ControlNet is usually the largest single addition because it loads a second model. IPAdapter and upscalers are next. KSampler is already accounted for in the base model, so it adds nothing extra.

How does batch size affect memory?

Model weights load once regardless of batch, but the latent activations scale with each additional image. The planner adds roughly a quarter of the base model's footprint per extra image in the batch and suggests the largest batch that still fits.

What if my workflow does not fit?

Switch to fp8 or quantized weights, enable tiled VAE and tiled upscaling, run ComfyUI with --lowvram or --medvram to offload to system RAM, or reduce batch size and resolution. The planner flags the shortfall so you know how much to cut.

What is the ComfyUI Workflow Planner?

Plan ComfyUI pipelines before you build them. Select a base model and the nodes you intend to use — KSampler, VAE, LoRA, ControlNet, upscaler, IPAdapter — and get peak VRAM estimates, a fit check against your GPU, and batch-size recommendations. It runs free in your browser on Gera Tools, with nothing uploaded.

ComfyUI Workflow Planner

Name: ComfyUI Workflow Planner
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

ComfyUI workflow planner

ComfyUI’s node graph gives you total control — and total responsibility for fitting everything in VRAM. Stack a ControlNet, an IPAdapter, and an upscaler on top of an SDXL checkpoint and a 12GB card that handled the base model can fall over. This planner estimates the peak VRAM of a workflow before you wire it up, so you know in advance whether it will run, run tight, or need offloading.

How it works

The tool starts from your base model’s footprint, then adds the extra VRAM each selected node contributes — ControlNet loads a whole second model, IPAdapter pulls in an image encoder, the VAE spikes at decode, and so on. Model weights load once no matter the batch, so batch size only scales the latent activations: the planner adds about a quarter of the base footprint per extra image. It compares the total against your GPU’s VRAM, reports headroom or shortfall, and suggests the largest batch that still fits.

Tips for fitting big workflows

Quantize the checkpoint. Flux in fp8 roughly halves its 22GB fp16 footprint with little visible quality loss.
Tile the heavy nodes. Tiled VAE decode and tiled upscaling cap their memory spikes, often the difference between fitting and OOM.
Offload with flags. --medvram and --lowvram push weights to system RAM between steps; you lose speed but gain headroom.
Trim the batch first. Dropping from batch 4 to batch 1 frees the most VRAM for the least quality impact — generate sequentially if memory is tight.

VRAM requirements by model and configuration

Understanding the approximate VRAM floor for each model helps you plan before loading:

SD 1.5 at fp16 loads in roughly 2–3GB at 512px. With a ControlNet added, expect around 5–6GB total. This is the most accessible model family for lower-VRAM cards.

SDXL at fp16 needs approximately 6–7GB for the base model alone at 1024px. Adding a ControlNet or IP-Adapter pushes peak usage into the 10–12GB range. On a 12GB card like the RTX 3080, SDXL workflows with multiple extensions run tight.

Flux (the Black Forest Labs architecture) is the most demanding consumer model. The full fp16 model is around 22GB — only feasible on high-end cards (RTX 4090, A100, or similar). The fp8 quantized version brings this to roughly 12–14GB, making it just feasible on a 16GB card when no other extensions are loaded. Flux NF4 (4-bit quantization) reduces footprint further, though with some quality trade-offs.

SD3 at fp16 sits between SDXL and full Flux in memory demands. The fp16 checkpoint is around 8–10GB, and SD3 benefits significantly from fp8 quantization.

Node-by-node VRAM additions

Beyond the base checkpoint, specific nodes add predictable overhead:

KSampler: uses the UNet already loaded by the checkpoint — no additional VRAM.
VAE encode/decode: typically a 1–2GB spike at decode time. Using the integrated VAE included in most checkpoints is lighter; loading an external VAE adds its own weight.
ControlNet: loads a second full model (scaled to the checkpoint’s architecture). A ControlNet for SDXL adds roughly 5–6GB.
IPAdapter: loads a vision encoder (CLIP-based) and the IPAdapter weights. Combined addition is roughly 2–4GB depending on the variant.
Upscaler (Real-ESRGAN, 4x): tiled operation caps VRAM at roughly 2–4GB. Without tiling, a large 4x upscale of an SDXL output can spike to 8–10GB at the decode step.

The planner stacks these estimates to give you a peak figure, which is what your GPU needs headroom for at the most memory-intensive moment in the generation pipeline.

Reading the output

The planner shows three things: estimated peak VRAM, a fit assessment (comfortable / tight / over budget), and a suggested maximum batch size. “Tight” means you will likely succeed but OOM errors are possible if the resolution or a quantization mismatch pushes actual usage above the estimate. When the planner says “over budget,” you need to reduce the workflow before attempting to run it — either through quantization, tiling, fewer nodes, or a smaller checkpoint.