ComfyUI VRAM Calculator
[ ComfyUI VRAM calculator ]
How much VRAM does your ComfyUI workflow need?
Pick a model and an output size. You get a peak memory estimate, a fit check for your own GPU, and the Xesktop card that runs it.
- Image workflows
- Video workflows
- GPU fit check
MethodHow the estimate works
This calculator uses editable engineering assumptions, not a benchmark database. It models weights separately from temporary working memory and uses a ±30% range around working-memory allowances (±50% for VAE stages, where uncertainty is larger). This range is illustrative, not a statistical confidence interval; actual usage can fall outside it.
Sampling work = base sampling workspace × max(0.25, output megapixels / reference megapixels) × batch size, plus the same scaling for each ControlNet workspace. The output includes the latent-upscale factor on both dimensions. Linear pixel scaling assumes memory-efficient attention and can underestimate other attention implementations.
VAE workspace scales with pixels (and batch when untiled). Defaults of about 4 GiB/MP decode and 3.3 GiB/MP encode at FP16/BF16 are based on ComfyUI’s own estimates in comfy/sd.py (about 2178 and 1767 bytes per pixel × dtype size); verify against the current source, and double them for FP32. Tiled mode uses a 512 × 512 tile at batch 1 and omits full-image assembly buffers. CFG > 1 doubles sampling workspace.
Offloading floor = largest stage working memory (VAE stages assume ComfyUI’s tiled fallback) + reserve, with only denoiser weights streamed (at least 0.5 GiB or 5% resident). System RAM = all weights + the OS/ComfyUI allowance. Both are rough.
Text-encoding workspace is fixed and assumes an ordinary prompt, not long prompts or unusually large conditioning batches. Weights include a 5% packing/alignment allowance. Each stage adds the runtime reserve and Extra allowance. Staged mode counts that stage’s model weights; resident mode counts all weights in every stage. The headroom budget is the upper peak estimate multiplied by 1 + headroom percentage.
Changing sampling steps or queue count does not multiply these estimates. Quantization reduces stored weights; the activation workspace does not automatically shrink by the same ratio. FP8 support, compute dtype and conversion buffers depend on your GPU and loader.
GPU recommendations now separate full-weight VRAM fit from GPU suitability. The upper full-weight peak determines whether a GPU can hold the modeled stage; headroom is checked separately. A GPU can therefore fit the workflow but still be marked Compatible with limitations because of architecture, precision, PyTorch/ROCm/XPU support, attention kernels or custom-node compatibility. Offloading can make a below-VRAM workflow run, but it is not counted as a full-GPU fit or a recommendation-quality capacity match.
Xesktop sizing uses one 96GB RTX PRO 6000 Blackwell as the single-GPU capacity match. The dual server contains 2 × 96GB GPUs, but ComfyUI does not automatically pool them into one 192GB device. Multi-GPU workflows require explicit model/node placement or parallel jobs. See ComfyUI device-placement nodes.
Image mode uses a bandwidth-only numerical illustration, not a measured generation-time prediction. Video mode instead checks VRAM fit, offloading, model family, GPU architecture, precision and selected workflow settings; it does not show numerical speed multipliers or generation-time estimates without benchmarks.
Video mode uses a separate calculation engine. It scales temporary diffusion workspace around each preset’s reference resolution and frame count. Playback FPS is used to derive output duration; it does not independently multiply peak VRAM when frame count is held constant. I2V adds a reference-image encode stage, while V2V/reference-video mode scales that encode stage across the reference clip. Temporal/VAE chunking only reduces the modeled VAE peak; it does not assume the diffusion transformer itself can be chunked.
Cloud/API models are not given a fabricated local VRAM estimate. Their model inference runs remotely through Partner/API nodes, so the calculator replaces the normal VRAM result with a cloud-model explanation. Local VRAM still matters for any other local nodes used before or after the API call.
Selected preset weight assumptions (GiB, rounded and approximate):
| Preset | Denoiser | Text encoders | VAE |
|---|---|---|---|
| SDXL FP16 | 4.8 | 1.5 | 0.16 |
| FLUX.1 FP8 + FP8 T5 | 11.2 | 4.6 | 0.16 |
| FLUX.2 Klein 4B FP8 | 3.79 | 7.49 | 0.31 |
| FLUX.2 Klein 9B FP8 | 8.78 | 8.07 | 0.31 |
| FLUX.2 Dev FP8 mixed | 33.06 | 16.76 | 0.31 |
| Qwen Image FP8 | 19.0 | 8.7 | 0.24 |
| Z-Image Turbo BF16 | 11.46 | 7.49 | 0.31 |
| Lumina Image 2.0 BF16 | 4.86 | 4.87 | 0.31 |
| Hunyuan Image 2.1 FP8 | 16.2 | 9.1 | 0.76 |
| HiDream I1 FP8 | 15.93 | 14.8 | 0.31 |
ComfyUI references explain memory behavior, not the numeric workspace allowances used here: memory troubleshooting · FLUX examples and weight precision.
How much VRAM do you need for ComfyUI
There is no single VRAM requirement for every ComfyUI workflow. Model weights take up part of the memory, while sampling, text encoding and image decoding need additional space. A checkpoint fitting on your GPU does not mean the complete workflow will fit.
For a first test, keep the workflow simple: one model, one image at a time and no optional processing stages. Then add the features you actually need. This makes the estimate easier to interpret and helps you identify which change raises memory use.
The capacity guidance below gives starting points for testing, not benchmarked guarantees or official minimum specifications. Results depend on your GPU, model files, ComfyUI version, nodes and memory settings.
| GPU memory | Starting point for testing | What to watch |
|---|---|---|
| 4GB VRAM | A simple SD 1.5 workflow at 512 × 512, batch size 1. | Larger models may depend on quantization and partial offloading. |
| 6GB VRAM | SD 1.5 first; assess more demanding models with a stripped-down workflow. | Sampling and VAE decoding can exceed the space left after loading weights. |
| 8GB VRAM | Assess SDXL Base at batch size 1, without a refiner or ControlNet initially. | Upscaling, added models and larger batches can use up the remaining capacity. |
| 12GB VRAM | Compare SDXL workflows with individual extras enabled. | FLUX.1 FP8 still needs working memory beyond its stored denoiser weights. |
| 16GB VRAM | Compare more involved SDXL workflows or a suitable quantized FLUX.1 setup. | Precision, text-encoder size and model residency still affect the result. |
These are starting points for testing, not guaranteed minimum requirements. Actual memory use depends on your model files, workflow, nodes and memory settings.
ComfyUI with 4GB or 6GB VRAM
For ComfyUI on 4GB VRAM, start by testing the smallest workflow that meets your needs. Avoid adding several ControlNet models, a large batch and a high-resolution second pass at the same time.
With ComfyUI on 6GB VRAM, use the extra capacity to test one change at a time. If the workflow stops during decoding, investigate tiled VAE processing. If it runs out of memory during sampling, lowering the batch size or sampling resolution is more relevant.
An estimate above your GPU capacity is a reason to investigate memory settings, rather than an automatic verdict that the workflow cannot run. ComfyUI can move model data between memory locations, and its Dynamic VRAM system supports on-demand weight allocation on supported setups. These strategies change memory use and performance; they do not create additional physical VRAM. [1]
ComfyUI with 8GB VRAM
When assessing ComfyUI on 8GB VRAM, distinguish a basic image workflow from the finished workflow you intend to use. Test SDXL Base on its own before adding a refiner, ControlNet or an upscale pass. SDXL’s base model can be used without its separate refiner. [2]
Keep batch size at 1 initially. Queuing several individual generations is different from sampling all those images together. Record where memory use peaks, then compare that stage with the calculator’s breakdown.
ComfyUI with 12GB or 16GB VRAM
For ComfyUI on 12GB VRAM, the useful question is how much memory remains after the active models load. That remaining space must accommodate intermediate data and temporary buffers.
ComfyUI on 16GB VRAM gives you more capacity to work with, but model names alone are not enough to judge fit. A FLUX.1 configuration using FP8 weights and an FP8 text encoder differs from one using a full-precision text encoder. ComfyUI’s FLUX examples include lower-memory weight and text-encoder options. [3]
Use the exact format you intend to load, and check the complete workflow. More VRAM does not, by itself, tell you how quickly an image will finish.
ComfyUI hardware requirements beyond VRAM
ComfyUI hardware requirements also include system memory, storage and a compatible software environment. A VRAM calculator cannot verify these from a capacity figure alone.
| Component | What to check |
|---|---|
| GPU | Compatibility with your installation method, drivers, PyTorch backend and selected nodes, as well as available VRAM. |
| System RAM | Space for the operating system, model loading, cached data, offloaded weights and other applications. |
| CPU | The demands of preprocessing, custom nodes and any work moved off the GPU. |
| Storage | Room for checkpoints, text encoders, VAEs, ControlNets, outputs and temporary files. Plan for the files you will actually keep. |
| Operating system and software | A supported installation route with compatible dependencies. Custom nodes can add their own requirements. |
A remote GPU workstation can also address more than VRAM alone. Xesktop GPU workstations provide the GPU, system RAM, CPU, storage and operating environment as one machine. This can be useful when your local bottleneck is the overall system rather than GPU memory by itself.
ComfyUI supports several hardware backends, including NVIDIA, AMD, Intel and Apple Silicon, with different installation requirements. Check the current official system requirements and the instructions for your hardware before choosing a setup. [4]
On Apple Silicon, unified memory is shared across the system. A machine advertised with 16GB of unified memory should not be treated as having 16GB of dedicated VRAM available exclusively to ComfyUI.
How to interpret the calculator results
The main range estimates peak GPU memory under the selected assumptions. The headroom figure adds an allowance above the upper estimate. Neither number is a measured minimum requirement.
Read the stage breakdown as well as the headline result. Text encoding, sampling and VAE processing happen at different points in the workflow. With appropriate offloading, their memory peaks do not simply add together. Keeping models resident on the GPU changes that calculation.
Treat any rough offloading figure as a scenario to investigate, not a guaranteed threshold. Likewise, the system-RAM figure is a planning allowance, not a complete measurement of every allocation. Validate both against your actual workflow before buying or renting hardware.
The calculator focuses on image generation. Video, additional diffusion models, refiner pipelines and custom-node behavior need separate checks.
How to reduce ComfyUI VRAM requirements
Start with the stage causing the problem. ComfyUI’s troubleshooting guidance recommends reducing resolution or batch size and closing other applications that use GPU memory. [5]
For sampling problems, try batch size 1 and a lower resolution. Review the memory used by additional models before reducing image quality further. For decoding problems, test tiled VAE decoding rather than assuming you need a smaller diffusion model.
Lower-precision weights can also help where your model and loader support them. However, reducing weight size does not reduce every activation or temporary buffer by the same proportion.
When comparing changes, keep the model, resolution and workflow otherwise consistent. Record peak GPU memory, system-RAM use and total completion time. A configuration that finishes without an error may still be too slow for regular work.
When to run ComfyUI on a cloud GPU
If your current GPU already runs the ComfyUI workflows you need at an acceptable speed, there may be no reason to move them elsewhere. A cloud GPU becomes more useful when the workflow you actually want to run repeatedly exceeds your local VRAM, relies heavily on offloading, or forces you to reduce resolution, batch size or model complexity just to make it fit.
This is where our cloud GPUs for AI can fit into a ComfyUI workflow. Instead of replacing your local computer, you can use a higher-memory GPU workstation when a job needs more capacity than your local GPU can provide.
For example, if a workflow runs comfortably on your 8GB or 16GB local GPU, continuing to run it locally may make the most sense. But if the calculator shows that a larger FLUX workflow, high-resolution generation, multiple additional models or another demanding setup needs substantially more memory, you can move that workflow to a higher-VRAM GPU rather than simplifying it purely to fit your local hardware.
Xesktop offers GPU workstations with high-VRAM options such as the RTX PRO 6000 Blackwell with 96GB of VRAM. ComfyUI can be used on the remote workstation while you retain the flexibility to work with your own models, custom nodes and workflow dependencies.
For workloads that can make use of multiple GPUs, Xesktop also offers dual-GPU RTX PRO 6000 Blackwell systems with 2 × 96GB of GPU memory. However, two GPUs should not automatically be treated as one 192GB VRAM pool for every ComfyUI workflow. How effectively both GPUs can be used depends on the workflow, nodes and software support.
Whichever option you choose, size the GPU for the complete workflow rather than model weights alone. The calculator’s upper estimate and headroom figure are more useful for this decision than simply checking whether the checkpoint itself fits.
Editorial sources
These references support the technical explanations. The capacity table is suggested testing guidance, not a set of measured benchmark results.
- ComfyUI: Dynamic VRAM and on-demand model memory management — https://blog.comfy.org/p/dynamic-vram-in-comfyui-saving-local
- Stability AI: SDXL Base model card — https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0
- ComfyUI FLUX examples — https://comfyanonymous.github.io/ComfyUI_examples/flux/
- ComfyUI system requirements — https://docs.comfy.org/installation/system_requirements
- ComfyUI troubleshooting — https://docs.comfy.org/troubleshooting/overview