ComfyUI's node-based interface makes it easy to build ambitious workflows. Too easy, in fact — because it also makes it easy to hit a wall you did not see coming. You chain SDXL with ControlNet, add IP-Adapter for style transfer, throw in a 2x upscaler, and suddenly your 8GB GPU throws a CUDA out-of-memory error with zero warning. Before that wall, throughput stays fine; after it, more compute on a smaller card does not save you — VRAM is the binding constraint, not FLOPS.
This guide maps out exactly how much VRAM each major ComfyUI component uses, how they stack up when combined, and which GPU you need for the workflow you actually want to build.
How ComfyUI Uses VRAM
Before diving into specific workflows, it helps to understand how ComfyUI allocates GPU memory. Unlike A1111 which loads and unloads models aggressively, ComfyUI tries to keep models in VRAM for speed. This is great for iteration speed but means VRAM fills up fast.
ComfyUI's memory usage breaks down into three categories:
| Category | What It Includes | Typical Size |
|---|---|---|
| Model weights | Checkpoint, LoRAs, ControlNet, IP-Adapter | 2–12 GB per model |
| Working memory | Latent tensors, attention maps, intermediate results | 1–6 GB |
| Output buffers | Decoded images, preview frames | 0.5–2 GB |
The total VRAM needed is roughly: model weights + working memory + output buffers. But it is not purely additive — ComfyUI offloads unused models to system RAM when possible, and some operations share memory.
Key insight: Model weights are fixed costs. Working memory scales with resolution and batch size. This is why the same workflow can run fine at 512×512 but crash at 1024×1024.
VRAM Usage by Component
Here is what each major ComfyUI component costs in VRAM, based on real-world measurements:
Base Models
| Model | Precision | VRAM (weights only) | Notes |
|---|---|---|---|
| SD 1.5 | FP16 | ~2 GB | Lightweight, runs on almost anything |
| SDXL | FP16 | ~6.5 GB | The standard for quality work |
| SDXL | FP32 | ~12 GB | Unnecessary for most use cases |
| SD 3.5 | FP16 | ~8 GB | Higher quality, higher cost |
| Flux.1 Dev | FP16 | ~12 GB | Demanding but excellent |
| Flux.1 Dev | GGUF Q8 | ~8 GB | Quantized, quality trade-off |
Control Models
| Model | VRAM | Use Case |
|---|---|---|
| ControlNet (SD 1.5) | ~0.7 GB | Pose, depth, edge detection |
| ControlNet (SDXL) | ~1.4 GB | Same controls, higher quality |
| IP-Adapter (SD 1.5) | ~1 GB | Style/face transfer |
| IP-Adapter Plus (SDXL) | ~2.5 GB | Advanced style transfer |
| IP-Adapter FaceID | ~1.5 GB | Face consistency |
| T2I-Adapter | ~0.3–0.8 GB | Lightweight alternative to ControlNet |
Post-Processing
| Model | VRAM | Use Case |
|---|---|---|
| 4x-UltraSharp upscaler | ~0.1 GB (model) + 2–6 GB (processing) | Image upscaling |
| ESRGAN upscaler | ~0.1 GB + 1–4 GB | Fast upscaling |
| Tiled upscaling (SDXL) | ~7–9 GB total | High-res upscale with detail |
| Face restoration (GFPGAN) | ~0.5 GB | Face fix after generation |
| Inpainting (SDXL) | ~7–8 GB | Selective region editing |
Animation
| Model | VRAM | Use Case |
|---|---|---|
| AnimateDiff (SD 1.5) | ~3.5 GB on top of base | Video generation |
| AnimateDiff (16 frames) | ~5–6 GB on top of base | Standard animation |
| AnimateDiff (24+ frames) | ~8–10 GB on top of base | Longer clips |
| SVD (Stable Video Diffusion) | ~8–10 GB total | Image-to-video |
LoRAs
| Type | VRAM per LoRA | Notes |
|---|---|---|
| Standard LoRA | ~0.1–0.3 GB | Merged into model weights |
| Multiple LoRAs (3–5) | ~0.5–1.0 GB total | Additive but small |
| LyCORIS / LoHA | ~0.2–0.5 GB | Slightly larger than standard |
LoRAs are cheap. Stacking 3–5 LoRAs adds less than 1 GB. They are almost never the bottleneck.
Common Workflow VRAM Requirements
Now let's combine components into real workflows and see what each one actually needs:
Workflow 1: Basic SDXL Text-to-Image
Components: SDXL base + refiner prompt
| Component | VRAM |
|---|---|
| SDXL checkpoint (FP16) | 6.5 GB |
| Working memory (1024×1024) | 1.5 GB |
| Output buffer | 0.3 GB |
| Total | ~8.3 GB |
Minimum GPU: RTX 3060 12GB (comfortable), RTX 4060 8GB (tight with --lowvram)
Workflow 2: SDXL + ControlNet + LoRA
Components: SDXL + ControlNet depth + 2 LoRAs
| Component | VRAM |
|---|---|
| SDXL checkpoint | 6.5 GB |
| ControlNet SDXL | 1.4 GB |
| 2× LoRAs | 0.4 GB |
| Working memory | 2.0 GB |
| Output buffer | 0.3 GB |
| Total | ~10.6 GB |
Minimum GPU: RTX 3060 12GB (just fits), RTX 3090/4090 24GB (comfortable)
Workflow 3: SDXL + IP-Adapter + ControlNet
Components: SDXL + IP-Adapter Plus + ControlNet pose
| Component | VRAM |
|---|---|
| SDXL checkpoint | 6.5 GB |
| IP-Adapter Plus SDXL | 2.5 GB |
| ControlNet SDXL | 1.4 GB |
| Working memory | 2.5 GB |
| Output buffer | 0.5 GB |
| Total | ~13.4 GB |
Minimum GPU: RTX 4090 24GB or RTX 3090 24GB. Will not fit on 12GB cards without aggressive offloading.
Workflow 4: SDXL + Hi-Res Upscale (2x)
Components: SDXL generation at 1024×1024 → 2x tiled upscale to 2048×2048
| Component | VRAM |
|---|---|
| SDXL checkpoint | 6.5 GB |
| Upscale model | 0.1 GB |
| Tiled upscale working memory | 4–6 GB |
| Total (peak) | ~12–14 GB |
Minimum GPU: RTX 3090/4090 24GB. The 12GB cards can do it with tiled VAE but expect slow processing.
For more on SDXL VRAM management, see our SDXL VRAM requirements guide.
Workflow 5: AnimateDiff + SDXL
Components: SDXL + AnimateDiff motion module + 16 frames
| Component | VRAM |
|---|---|
| SDXL checkpoint | 6.5 GB |
| AnimateDiff module | 3.5 GB |
| Frame buffer (16 frames) | 3–4 GB |
| Working memory | 2–3 GB |
| Total | ~15–17 GB |
Minimum GPU: RTX 3090/4090 24GB. This workflow does not fit on 12GB cards at all.
For GPU requirements specific to video generation, see our SDXL video generation guide.
Workflow 6: The Kitchen Sink
Components: SDXL + ControlNet + IP-Adapter + 3 LoRAs + face fix + 2x upscale
| Component | VRAM |
|---|---|
| SDXL checkpoint | 6.5 GB |
| ControlNet SDXL | 1.4 GB |
| IP-Adapter Plus | 2.5 GB |
| 3× LoRAs | 0.6 GB |
| Face restoration | 0.5 GB |
| Upscale processing | 4–6 GB |
| Working memory | 3 GB |
| Total (peak) | ~18–20 GB |
Minimum GPU: RTX 4090 24GB (tight) or A100 40GB (comfortable). This is where cloud GPUs really shine — you can rent an A100 for a few hours instead of buying hardware you only need for complex pipelines.
GPU Recommendations by Workflow Tier
Based on the measurements above, here is a clear recommendation for each VRAM tier:
| GPU (VRAM) | Best For | Not Suitable For |
|---|---|---|
| RTX 4060 (8GB) | SD 1.5 workflows, basic SDXL with --lowvram | Any multi-model SDXL pipeline |
| RTX 3060 (12GB) | SDXL + 1 ControlNet or LoRAs | IP-Adapter + ControlNet combos, AnimateDiff |
| RTX 3090 (24GB) | Most complex workflows, AnimateDiff, hi-res upscale | 8× H100-class workloads |
| RTX 4090 (24GB) | Everything the 3090 does, 2–3x faster | Nothing in single-GPU territory |
| A100 (40GB) | Kitchen-sink workflows, Flux.1, large batch sizes | Overkill for basic SDXL |
| A100 (80GB) | Multi-model inference, very large batches | Most individual users |
The sweet spot for ComfyUI power users is 24GB VRAM. It handles 90% of complex workflows without model offloading. The RTX 4090 is the best choice because it combines 24GB VRAM with the fastest single-GPU performance available.
Check current prices and availability on the SynpixCloud marketplace.
VRAM Optimization Techniques
If you are hitting VRAM limits, these techniques can help before upgrading hardware:
1. Enable FP16 Everywhere
Many ComfyUI nodes default to FP32. Forcing FP16 cuts model VRAM usage roughly in half:
--force-fp16This is safe for almost all workflows. Quality difference is negligible.
2. Use Tiled VAE
The VAE decode step can spike VRAM usage by 2–4 GB. Tiled VAE processes the image in patches:
# In ComfyUI, use the "VAE Decode (Tiled)" node
# Set tile_size to 512 for 8GB GPUs, 768 for 12GB3. Model Offloading
ComfyUI can offload unused models to system RAM. This is slower but lets you run larger pipelines:
--lowvram # Aggressive offloading, slower but works on 8GB
--novram # Extreme mode, almost everything on CPU, very slow4. Use GGUF Quantized Models
For Flux.1 and other large models, GGUF quantized versions dramatically reduce VRAM:
| Model | FP16 | GGUF Q8 | GGUF Q4 |
|---|---|---|---|
| Flux.1 Dev | 12 GB | 8 GB | 5 GB |
| SDXL | 6.5 GB | 4.5 GB | 3.2 GB |
Quality drops slightly with Q4, but Q8 is nearly lossless for most use cases.
For a complete optimization guide, see ComfyUI memory optimization.
5. Reduce Resolution, Upscale Later
Generate at a lower resolution (768×768 instead of 1024×1024) and upscale in a separate pass. This can save 2–4 GB of working memory during generation.
6. Sequential Processing
Instead of loading all models simultaneously, structure your workflow to process in stages:
- Generate base image with SDXL (unload after)
- Apply ControlNet refinement (unload after)
- Upscale (unload after)
- Face fix
Each stage only needs one model loaded at a time. ComfyUI handles this automatically if your graph is structured linearly.
When Optimization Is Not Enough
There is a hard floor to how much you can optimize. If your workflow needs SDXL + IP-Adapter + ControlNet + AnimateDiff, no amount of tiling or offloading will make it run well on an 8GB GPU. The models simply do not fit.
At that point, you have two choices:
- Buy a 24GB GPU — $1,600+ for an RTX 4090, plus the full build cost
- Rent a cloud GPU — $0.39/hr for an RTX 4090 on SynpixCloud
For most users running complex workflows a few hours per day, cloud is significantly cheaper. See our cloud GPU vs local GPU cost analysis for the full breakdown.
The advantage of cloud goes beyond cost. On SynpixCloud, instances come with CUDA pre-installed and ready to go. No driver conflicts, no CUDA version mismatches — just SSH in and start your workflow.
Real VRAM Measurements: Common Pitfalls
Here are issues that catch even experienced ComfyUI users:
The ControlNet Stack Trap
Each ControlNet model adds ~1.4 GB (SDXL). Using depth + pose + canny simultaneously means 4.2 GB just for ControlNet, on top of the base model. Two ControlNets is usually the practical limit on 12GB cards.
The IP-Adapter Surprise
IP-Adapter Plus (SDXL) loads both the IP-Adapter model (~2.5 GB) and a CLIP vision encoder. The vision encoder often catches people off guard — it adds another 1–2 GB that does not show up in the model size.
The Upscale Memory Spike
Upscaling from 1024×1024 to 2048×2048 quadruples the pixel count. Even with tiled processing, the peak VRAM during upscale can spike 4–6 GB above your baseline. If your workflow is already at 18 GB, an upscale step can push you over 24 GB.
AnimateDiff Frame Count
AnimateDiff VRAM scales roughly linearly with frame count:
| Frames | Additional VRAM (over base) |
|---|---|
| 8 | ~3 GB |
| 16 | ~5–6 GB |
| 24 | ~8–10 GB |
| 32 | ~12–14 GB |
Going from 16 to 32 frames nearly doubles the VRAM overhead. If you need longer animations, batch them in 16-frame segments and stitch the results.
Workflow Performance: Speed vs VRAM
More VRAM is not the only factor. GPU compute speed matters too, especially for iterative workflows where you are generating dozens of variations.
| GPU | VRAM | SDXL 1024×1024 (20 steps) | Relative Speed |
|---|---|---|---|
| RTX 3060 | 12 GB | ~25 seconds | 1.0x |
| RTX 3090 | 24 GB | ~12 seconds | 2.1x |
| RTX 4090 | 24 GB | ~6 seconds | 4.2x |
| A100 (40GB) | 40 GB | ~8 seconds | 3.1x |
The RTX 4090 is faster than the A100 for single-image generation due to higher clock speeds. The A100 pulls ahead for large batches and training workloads where its memory bandwidth matters more.
For a detailed GPU performance comparison, check our GPU comparison tool or read the RTX 4090 vs A100 vs H100 benchmark.
Decision Framework
Use this quick reference to match your workflow to the right GPU:
You need 8GB if:
- SD 1.5 only, basic workflows, single ControlNet
You need 12GB if:
- SDXL with 1–2 LoRAs
- SDXL with a single ControlNet
- Basic inpainting
You need 24GB if:
- SDXL + ControlNet + IP-Adapter
- SDXL + AnimateDiff (up to 16 frames)
- Hi-res upscaling (2x or higher)
- Flux.1 (FP16)
- Any "kitchen sink" workflow
You need 40GB+ if:
- Flux.1 + ControlNet + IP-Adapter
- AnimateDiff with 24+ frames at SDXL
- Multiple simultaneous model inference
- Batch processing with large queues
Don't know which GPU fits your budget? Use the cost calculator to estimate your monthly spend.
Conclusion
ComfyUI's flexibility is both its superpower and its trap. You can build incredibly sophisticated workflows — but each node you add has a VRAM cost. The key takeaways:
- Basic SDXL needs 8–10 GB. A 12GB card works fine.
- Multi-model workflows (ControlNet + IP-Adapter + LoRAs) need 12–16 GB. A 24GB card is ideal.
- Animation and upscaling push into 16–24 GB territory. Only 24GB cards (RTX 3090/4090) or cloud A100s handle this smoothly.
- Kitchen-sink workflows can easily hit 18–22 GB. Cloud GPUs with 40GB+ VRAM are the practical solution.
The most common mistake is building a workflow on a 12GB card, discovering it crashes, and then spending hours trying to optimize rather than simply using a bigger GPU. If your time is worth anything, the $0.39/hr for a cloud RTX 4090 is almost always cheaper than the hours lost to VRAM debugging.
Build the workflow you want first. Then match the GPU to the workflow — not the other way around.
Browse RTX 4090 and A100 instances on the SynpixCloud marketplace, compare GPU specs with the comparison tool, or estimate your costs with the cost calculator.
