ComfyUI Out of Memory on Windows: VRAM, RAM or Disk?
When ComfyUI reports CUDA out of memory on Windows, first investigate GPU memory and the workflow that failed. Deleting generated images frees disk space, but it does not increase dedicated VRAM. A generic out-of-memory message can also involve system RAM, so keep the actual error text instead of treating every failure as the same problem.
Keep the failing workflow and locate the stage
Save the workflow and note the model, resolution, batch size and node where execution stops. Use the error report and terminal log to distinguish loading a model, sampling, decoding an image and running a custom node. The stage matters because each can need a different amount of memory.
ComfyUI's troubleshooting guide recommends checking the report, reducing image size or batch size and ruling out custom-node issues. Treat these as controlled comparisons. Do not update every node, replace Python and change the model simultaneously, because a successful rerun would no longer reveal which change mattered.
Read GPU memory and system memory separately
Open Task Manager › Performance and inspect the GPU's dedicated memory alongside the Memory page while reproducing the failure. Make sure you are looking at the GPU actually used for the workflow on a multi-GPU PC.
| Resource | What a shortage changes |
|---|---|
| Dedicated GPU memory | Whether model and intermediate tensors fit on the GPU |
| System RAM and commitment | Whether Windows and CPU-side work have room |
| Disk space | Whether models, outputs and paging files can grow |
Shared GPU memory is not extra physical VRAM on the graphics card. A large free SSD does not mean a large model will fit on that card. Microsoft's Task Manager GPU explanation describes the different readings.
Match the first experiment to the failing node
An out-of-memory report usually contains more useful information than the red node alone. Keep the first allocation error and the node that raised it; later exceptions can be consequences of that first failure. Save a copy of the workflow before changing its graph.
| Failure stage | First controlled comparison | What the result can establish |
|---|---|---|
| Loading a checkpoint or text encoder | One compatible smaller model with the same minimal task | Whether the loading demand is the obstacle |
| Sampling | Batch one, then lower supported image dimensions in a separate run | Whether the intermediate workload fits at a smaller size |
| VAE decode after sampling | A compatible tiled VAE decode | Whether decoding was the peak that failed |
| Upscaling or video processing | One smaller input or fewer frames, if supported | Whether that stage's input size drives the failure |
| A custom node | The smallest supported built-in equivalent | Whether the failure is specific to that node path |
These are experiments, not guarantees. A smaller checkpoint can change the model family, required nodes or output quality, so use a workflow that supports it. If the first error concerns loading weights, reducing the final JPEG quality will not change the amount of model memory required.
Keep a simple record of model, seed, resolution, batch, changed node and result. Preserve the same seed when the workflow supports it so visual comparisons are easier, while recognizing that changing precision or nodes can still change the image. Once a small configuration completes, restore one requirement at a time until the limiting stage becomes clear.
Reduce one demand at a time
Start with a batch size of one and a smaller supported resolution. If the workflow then completes, increase only one dimension and repeat. Doubling both image width and height makes four times as many pixels, but it does not imply exactly four times the total VRAM because models and different nodes have their own costs.
If failure happens at decoding rather than sampling, try a compatible tiled VAE decode node when the workflow supports it. Check the output for seams or other differences. If a single model cannot load, smaller output dimensions alone may not solve the problem. Test a model or precision supported by that workflow and hardware.
Save and close other GPU-heavy work before another run. If memory remains occupied after a failed job, restart ComfyUI normally after saving the workflow. A restart can release an abandoned workload, but it does not make an oversized workflow fit reliably.
Change VAE decoding without rebuilding the whole workflow
ComfyUI's VAE Decode Tiled documentation describes decoding latent samples in smaller tiles. In a saved copy of a compatible image workflow, connect the same latent samples and VAE to the tiled decode node, then connect its image output to the existing save or preview node. Keep the original workflow so the change is reversible.
Start with the node's available defaults rather than copying several tile and overlap values from another model. If a smaller tile is needed, change that value alone and check both memory use and the resulting image. Smaller pieces can reduce the working set but add processing overhead; inspect smooth gradients, boundaries and fine details before accepting the result.
Tiling at decode does not reduce the memory needed earlier to load the model or run the sampler. If the run never reaches decode, move the investigation back to the failing stage. A video VAE or a specialized model may need its own compatible node, so do not substitute an image decoder solely because its name includes “tiled.”
Use the optimization path for your installation
The official guide documents --lowvram for manual installations. For a manual installation launched from its own environment, the form is:
python main.py --lowvram
This is not a universal command to paste into ComfyUI Desktop, a portable bundle or a third-party launcher. Use that installation's supported launch settings and keep existing arguments. Moving work away from GPU memory can trade speed and system RAM for a lower VRAM requirement.
For failures involving custom nodes, compare with a built-in workflow and follow ComfyUI's custom-node troubleshooting. Preserve the original workflow and record which nodes were disabled. A missing custom node changes the workflow, so compare the smallest equivalent task you can reproduce.
Restore launch settings after the comparison
Keep a copy of the launcher or a note of its arguments before trying a memory option. A manual Python environment, Windows portable package and Desktop app do not necessarily start the same way. Add an option only through the mechanism that actually starts this installation; creating a second Python environment can introduce a different problem.
ComfyUI's startup flag reference describes several independent memory and cache controls. They are not a collection of switches to enable together. For example, reducing result caching can lower retained memory but cause more nodes to execute again. CPU offloading can need additional system RAM and slow the workflow.
After a successful run, check that the output is complete and usable, then repeat the normal task. If the change only allows a tiny test but the required workflow still fails, record that boundary. Remove an unhelpful test argument from the original launcher and return to the last working configuration before another experiment.
If system commitment is the bottleneck, inspect Windows Memory alongside GPU memory and retain a working paging-file configuration. Increasing disk capacity, increasing the paging-file limit and reducing dedicated VRAM demand are different interventions; none should be presented as a universal cure for the others.
Keep the output cleanup as a separate task
Generated images and videos can consume considerable disk space. Review them by project and keep the workflow and assets needed to reproduce valuable results. Back up anything you intend to retain before deleting its only copy.
If the error is a Windows commitment shortage, the Windows memory guide explains how that differs from VRAM. Do not delete the paging file to make the drive look cleaner. When reporting a persistent failure, include the exact error, GPU and driver, installation type and smallest failing workflow, with private prompts and paths removed.