ComfyUI GPU Requirements: How Much VRAM You Need

Picking a GPU for ComfyUI is a sizing exercise, not a shopping exercise. The model family you intend to run sets a hard floor, the resolution and batch size you work at set the variable part, and the runtime flags decide how much of the gap between those two you can paper over. Everything else, including the marketing tier of the card, is downstream of those three numbers.

The honest starting point is published file sizes, because model weights are the one part of the budget that is fixed and knowable before you buy anything.

Start from the weights, because they are published

Every model on Hugging Face lists the byte size of each file it ships. Those numbers are the load-bearing part of a VRAM estimate, and they are large enough that they usually decide the answer on their own.

Model	Distributed file	What it contains	Size on disk
Stable Diffusion 1.5	v1-5-pruned-emaonly.safetensors	UNet + CLIP + VAE	4.27 GB
Stable Diffusion 1.5	unet/…fp16.safetensors	UNet only	1.72 GB
SDXL 1.0 base	sd_xl_base_1.0.safetensors	UNet + 2 text encoders + VAE	6.94 GB
SDXL 1.0 base	unet/…fp16.safetensors	UNet only	5.14 GB
Flux.1 schnell	flux1-schnell.safetensors	transformer only	23.78 GB
Flux.1 schnell	text_encoder_2/ (2 shards)	T5-XXL only	4.99 + 4.53 GB
Flux.1 dev	flux1-dev.safetensors	transformer only	23.80 GB
Flux.1 dev	flux1-dev-fp8.safetensors	transformer + encoders + VAE, fp8	17.25 GB

Two things fall out of that table immediately. First, the jump from SDXL to Flux is not incremental: it is roughly three and a half times the weight footprint, which is why a card that handles SDXL comfortably can fail on Flux at the loader before a single sampling step runs.

Second, and this is the part most sizing advice gets backwards, the big Flux file is not the whole model. flux1-schnell.safetensors at 23.78 GB is the diffusion transformer on its own; it matches the sum of the three transformer/ shards in the same repository to within about 13 KB, which is the safetensors header. The T5-XXL text encoder is a separate download of 4.99 GB plus 4.53 GB, and it sits on top of that number, not inside it. Add the CLIP encoder and the VAE and a full bf16 Flux stack is roughly 34 GB of weights, which is more than any consumer card has.

That single fact explains why Flux runs at all on a 24 GB card: the text encoder and the transformer are never both resident. Conditioning is computed first, the encoder is evicted, and only then does the transformer occupy the card. Break that ordering, by holding a second model or forcing everything resident with --highvram, and a graph that worked yesterday fails at the loader today.

It also explains the fp8 all-in-one file. flux1-dev-fp8.safetensors is 17.25 GB for the transformer, text encoders and VAE together, which is smaller than the bf16 transformer alone. Where the split-file layout gives you control over what loads when, the fp8 bundle simply removes the problem by making the whole stack fit.

SDXL is larger than SD 1.5 for a documented architectural reason rather than an arbitrary one. The SDXL paper describes a UNet backbone three times the size of earlier Stable Diffusion versions, with the parameter growth driven by additional attention blocks and a larger cross-attention context, because SDXL adds a second text encoder.

What each VRAM tier realistically covers

Weights are the floor. On top of them sit activation memory during denoising, which scales with resolution and multiplies with batch size, and the decode step, which frequently peaks higher than the sampling that preceded it. The mechanics of that are covered in how ComfyUI graphs execute and where VRAM goes; the practical consequence is that you should never size a card at exactly the checkpoint size.

VRAM	Comfortable	Workable with flags	Out of reach
8 GB	SD 1.5 at 512–768 px	SDXL at 1024 px, batch 1	Flux at bf16
12 GB	SDXL at 1024 px	Flux with fp8 weights and offload	Flux bf16 with adapters
16 GB	SDXL with adapters and upscaling	Flux fp8 at 1024 px	Large batches at high resolution
24 GB	Flux fp8, SDXL batches	Flux bf16 single image	Multi-model video graphs at scale
32 GB+	Flux bf16, video models	Multi-model production graphs	—

Read the middle column carefully, because it is where most of the disagreement online comes from. Two people can run the same model on the same card and reach opposite conclusions, and both are telling the truth, because one of them accepted fp8 weights and CPU-side text encoding and the other did not. The card is rarely the variable. The configuration is.

To put a number on your own specific graph rather than a tier, the ComfyUI VRAM and execution sizer takes a checkpoint class, adapter count, resolution and batch size and returns an estimated footprint.

The rest of the machine matters more than people expect

System RAM is the most commonly under-specified component in a ComfyUI build, and the reason is in the runtime’s own defaults. ComfyUI unloads models to CPU memory after use rather than keeping them resident in VRAM; the --highvram flag exists specifically to opt out of that behaviour. Offloading to system RAM is the default path, which means your RAM has to be able to hold the model set that VRAM cannot.

The caching layer reinforces this. ComfyUI’s default caching mode is RAM-pressure based: the documented defaults set the active-cache threshold at 10% of system RAM with a 2 GB floor and a 10 GB ceiling, and the inactive-cache threshold at 100% of system RAM capped at 128 GB. A machine with 16 GB of system RAM and a 24 GB card is unbalanced, and the symptom is swapping and stalls rather than an error message.

The documentation does not state a RAM figure, so this is a recommendation rather than a requirement: treat 32 GB as the sensible baseline for SDXL work and 64 GB for Flux or video graphs, on the reasoning that offload is the default path and the inactive cache will happily use all of it.

Storage follows from the same file sizes. Three Flux checkpoints at 23.8 GB each is 71 GB before you add a single text encoder, VAE or LoRA, so a working set crosses 100 GB without feeling like it should. Load time is dominated by sequential read speed rather than capacity, so an NVMe drive is worth more here than a larger slow disk. ComfyUI even ships a --fast-disk flag that prefers disk-backed offload over unpinned RAM for exactly this case.

CPU choice barely registers by comparison. Sampling is GPU-bound, and the CPU matters mainly for model loading, VAE work if you push it there, and any preprocessing nodes in the graph.

Software requirements are stricter than they look

The official system requirements name Python 3.13 as the recommended and well-supported version, with 3.12 as the fallback if custom node dependencies give trouble on 3.13, and 3.14 working but with caveats around custom nodes and the free-threaded variant. PyTorch 2.7 and above is supported, and a CUDA 13.0 build or newer is required on NVIDIA 20-series cards and above.

There is also a browser requirement, which is unusual enough that people miss it: the documentation recommends Chrome 143 or later, noting that earlier versions have known issues causing visual glitches and performance problems in the interface. A graph that renders badly is not always a graph problem.

Non-NVIDIA hardware is supported, with conditions

The documented hardware list is broader than the community reputation suggests. AMD is supported on Linux through ROCm 7.2, with experimental Windows and Linux support limited to RDNA 3, RDNA 3.5 and RDNA 4 parts. Intel Arc works through native PyTorch torch.xpu. Apple Silicon M1 through M4 runs on the Metal Performance Shaders backend, and the documentation is explicit that ComfyUI uses PyTorch MPS rather than Apple’s MLX framework. Ascend NPU, Cambricon MLU and Iluvatar Corex are supported through their respective PyTorch extensions, and there is a --cpu mode that works and is slow.

One operational detail worth knowing before you plan a deployment: the project states that it does not provide an official Docker image, and that community images on Docker Hub are unsupported.

How to lower the requirement without buying anything

If you are close to a tier boundary, the runtime gives you several levers before hardware does.

Quantised weights are the largest single win. The --fp8_e4m3fn-unet and --fp8_e5m2-unet flags store diffusion model weights in fp8, and the matching --fp8_e4m3fn-text-enc and --fp8_e5m2-text-enc flags do the same for text encoders. Given that the Flux text encoder alone is nearly ten gigabytes at full precision, quantising it is often the difference between loading and failing.

Moving work off the GPU is the next lever. --cpu-vae runs the decoder on the CPU, which removes the decode peak entirely at the cost of speed. --novram exists for the case where reducing is not enough and everything has to stream.

Reserving headroom prevents a different failure. --reserve-vram sets the amount of VRAM in gigabytes to leave for the operating system and other applications, and --vram-headroom tells the dynamic VRAM system to keep an additional amount completely free, counting VRAM consumed by other applications. On a machine where the same GPU also drives your displays, these matter.

When these flags stop being enough and the failures become routine, the diagnostic path is a different piece of work: ComfyUI out of memory errors covers reading the error and finding which stage actually overflowed. And if you are still deciding whether ComfyUI is the right interface for the hardware you have, ComfyUI vs Automatic1111 vs Forge compares how the three handle memory on constrained cards.

The short version

Size for the model family, not the card tier. SD 1.5 fits almost anywhere. SDXL wants 12 GB to be pleasant. Flux wants 16 GB with quantisation and 24 GB without it, and video models want more than that. Then give the machine at least twice the VRAM in system RAM, put the models on NVMe, and keep the runtime flags in reserve for the days when the graph grows faster than the budget.