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.
The ComfyUI Ops Editorial desk bases this guide on published specifications and model documentation. Our research methodology and editorial disclosure explain how these sources are used.
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, exceeding a 32 GB card if all components stay resident together.
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. This reduces the fixed weight budget; it does not remove the need for working memory or offload on smaller cards.
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.
Best GPU for ComfyUI by tier
For an SDXL-focused build, the RTX 5060 Ti 16 GB is a capacity-first starting point: it provides more room for weights and intermediate tensors than a 12 GB card. These recommendations infer suitable tiers from the published model sizes above and NVIDIA’s specifications; actual fit still depends on precision, resolution, adapters and offload.
| VRAM tier | Desktop GPU to consider | ComfyUI workload to plan around | Capacity tradeoff |
|---|---|---|---|
| 8 GB | RTX 5060 | SD 1.5 and constrained SDXL graphs | Keep batches small; plan for offload as the graph grows. |
| 12 GB | RTX 5070 | SDXL at batch one | A higher model number does not provide the capacity of a 16 GB card. |
| 16 GB | RTX 5060 Ti 16 GB | SDXL with more graph headroom; quantized Flux with offload | Check the variant: the 5060 Ti also ships with 8 GB. |
| 24 GB | RTX 4090 | More room for quantized Flux and SDXL adapters | The roughly 34 GB full-precision Flux stack still exceeds this capacity. |
| 32 GB | RTX 5090 | Larger Flux working sets with staged model loading | Reserve space for activations and decode; weights alone are not the full budget. |
Capacities come from NVIDIA’s desktop comparison and RTX 4090 specifications. Choose the tier around the graph you need to fit, then check the card maker’s power and case requirements. This table does not establish generation-speed rankings or a universal minimum.
For text-generation workloads on the same machine, use the separate guides to VRAM for Ollama and VRAM for a 7B model in LM Studio. The tiers here cover ComfyUI image workflows.
GGUF vs safetensors in ComfyUI
In ComfyUI, choose a file that matches both the model architecture and its loader. The safetensors checkpoints above include both full-precision and fp8 weights, so the extension alone does not identify the memory requirement.
The ComfyUI-GGUF documentation describes a custom Unet Loader (GGUF) that replaces the standard diffusion-model loader for supported GGUF models. Its quantized weights can reduce the weight footprint, but the project’s supported model list and loader instructions still matter. A GGUF text model intended for a chat runtime is not a substitute for a compatible diffusion model.
For the broader format comparison and LM Studio runtime support, see GGUF vs safetensors. Keep ComfyUI sizing tied to the actual diffusion weights and graph stages.
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
AMD support depends on the operating system. As of September 16, 2026, the official system requirements distinguish these installation paths:
- Linux: AMD GPUs use the documented ROCm 7.2 installation path.
- Windows: Experimental ROCm 10.0 multi-architecture packages support RDNA 2, RDNA 3, RDNA 3.5 and RDNA 4 GPUs.
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.
