ComfyUI Out of Memory Errors: Causes and Fixes

An out of memory error in ComfyUI is not one problem. It is at least five, they fail at different points in the graph, and the fix for one makes another worse. Working through them in a fixed order is faster than trying flags at random, which is what most troubleshooting threads amount to.

The order that works is: read the message, identify the stage, reduce the fixed cost, reduce the variable cost, then rule out the environment.

Read the allocator message first

The error comes from PyTorch, not from ComfyUI, and it carries more information than people extract from it. A typical message names the size of the allocation that failed, the total capacity of the device, how much is currently free, and how much memory PyTorch itself has reserved but not allocated.

That last figure is the one worth understanding. PyTorch uses a caching memory allocator, and its documentation is explicit that unused memory held by the allocator still appears as used in nvidia-smi. So a card that looks full is not necessarily full of tensors. If the failed allocation is small but the reserved figure is large, you are looking at fragmentation rather than genuine exhaustion, and the fixes are completely different.

The two situations to separate:

• Failed allocation is large, free memory is small. Genuine exhaustion. Reduce what the graph asks for.
• Failed allocation is small, reserved memory is large, free memory is small. Fragmentation. The allocator has the space but not in a usable shape.

For the fragmentation case, PyTorch exposes allocator tuning through an environment variable. Note that the current name is PYTORCH_ALLOC_CONF; PYTORCH_CUDA_ALLOC_CONF still works but the documentation describes it as an alias kept only for backward compatibility, which is worth knowing because most guides written before the rename still use the old name.

Two options matter here. expandable_segments:True instructs the allocator to create allocations that can later be expanded, which the documentation says handles jobs that change allocation sizes frequently, such as a changing batch size. That describes a diffusion graph precisely. It is marked experimental and defaults to off. The second is max_split_size_mb, which stops the native allocator from splitting blocks larger than the given size; the documentation recommends it as a last resort for workloads aborting on out of memory while showing a large amount of inactive split blocks, and warns the performance cost can range from zero to substantial.

Identify which stage overflowed

ComfyUI’s console shows how far execution got. That is diagnostic information, because each stage fails for its own reason.

Failure at the loader means the weights alone do not fit. No sampler setting will help. This is a precision or model-choice problem, and the sizes involved are large enough to decide the outcome on their own, as covered in ComfyUI GPU requirements.

Failure during sampling means weights fit but activation memory does not. Resolution and batch size are the levers, along with the attention implementation.

Failure at the decode step, after sampling has visibly completed, is the one that surprises people. The decoder can peak higher than the sampling that preceded it, which is why a run appears to succeed and then dies at the last moment. The fix is specific to that stage and does nothing for the other two.

Failure partway through a multi-model graph usually means two or more sets of weights are resident at once. The graph structure is the problem, not the card.

Why the graph holds what it holds, and why a change in one place forces reloads elsewhere, is the subject of how ComfyUI graphs execute and where VRAM goes.

Reduce the fixed cost: precision and offload

Weight precision is the largest single lever available, because weights are the largest single consumer.

ComfyUI exposes precision per component rather than globally, which matters more than it sounds. --fp8_e4m3fn-unet and --fp8_e5m2-unet store the diffusion model in fp8. --fp8_e4m3fn-text-enc and --fp8_e5m2-text-enc do the same for the text encoder, and on Flux-class models the text encoder is a substantial fraction of the total, so quantising it alone can move a graph from failing to loading. There are matching --bf16-unet, --fp16-unet and --fp32-unet options when you need to go the other way for a model that misbehaves at reduced precision.

The decoder has its own controls. --cpu-vae moves decoding to the CPU, which removes the decode peak from VRAM entirely at a speed cost, and is the correct answer to a decode-stage failure when nothing else has worked. --fp16-vae runs the decoder at half precision, with a documented caveat in the flag’s own help text that it might cause black images. --fp32-vae forces full precision when that happens.

For offload behaviour, --disable-smart-memory forces ComfyUI to aggressively offload to regular RAM instead of keeping models in VRAM when it can. It is slower and it works. --novram exists for the case where reducing is still not enough, described in its own help text as the option for “when lowvram isn’t enough”.

One flag deserves specific correction because outdated advice about it is everywhere. --lowvram is now documented as doing nothing if dynamic VRAM is enabled; when dynamic VRAM is not in use it makes text encoders run on the CPU. If your ComfyUI build has dynamic VRAM active, adding --lowvram and observing no change is the expected outcome, not a broken installation. The controls that do apply to the dynamic VRAM system are --vram-headroom, which keeps a stated amount of VRAM completely free even counting memory used by other applications, and --disable-dynamic-vram if you want the older estimate-based model loading back.

Reduce the variable cost: resolution, batch, attention, cache

Activation memory scales with resolution and multiplies with batch size. Batch is the cheapest thing to cut and usually the first thing to try: generate one image at a time.

Resolution deserves a structural answer rather than a numeric one. Sampling directly at a high target resolution is the most expensive way to reach it. Sampling at the model’s native resolution and running a second upscale pass costs less peak memory for a comparable result, because the two peaks happen at different times instead of at once.

The attention implementation changes the memory profile of sampling itself. ComfyUI ships several: --use-split-cross-attention, --use-quad-cross-attention (sub-quadratic), --use-pytorch-cross-attention, --use-sage-attention and --use-flash-attention. The split and sub-quadratic variants trade speed for a lower peak, which is the trade you want on a constrained card. The Diffusers documentation covers the same family of techniques, including slicing and tiling for the decode step, and is a useful cross-reference for what each approach costs.

Result caching is the lever most people forget. ComfyUI’s default caching mode is RAM-pressure based, with documented defaults putting the active-cache threshold at 10% of system RAM (minimum 2 GB, maximum 10 GB) and the inactive threshold at 100% of system RAM capped at 128 GB. When memory is the binding constraint rather than iteration speed, --cache-none reduces RAM and VRAM usage at the cost of re-executing every node on each run, and --cache-lru N caps the cache at N node results. On a machine with fast storage, --fast-disk prefers disk-backed dynamic loading and offload over unpinned RAM.

Rule out the environment

Three environmental causes account for a large share of the errors that survive everything above.

Other applications hold the card. Browsers, desktop compositors and anything using hardware acceleration reserve VRAM before ComfyUI starts. --reserve-vram sets, in gigabytes, the amount to leave for the operating system and other software, and setting it explicitly is better than discovering the shortfall at the decode step. On a multi-GPU machine, --cuda-device restricts the instance to specific device IDs.

A custom node is leaking or holding weights. This is testable rather than guessable. Start ComfyUI with --disable-all-custom-nodes and run a baseline graph. If the memory problem disappears, add packs back using --whitelist-custom-nodes until it returns. That bisection turns a vague suspicion into a named cause in a few restarts, and it is the single most useful diagnostic flag in the whole set. Why packs collide at all is a packaging problem rather than a memory one: custom nodes install their Python requirements into the same environment as ComfyUI, so one pack pinning a different torch or transformers version silently changes the memory behaviour of every other node in the graph.

The build is wrong for the hardware. The system requirements state that PyTorch 2.7 and above is supported and that a CUDA 13.0 build or newer is required on NVIDIA 20-series cards and above. A PyTorch built against the wrong CUDA version can fall back to paths with much worse memory behaviour, and the symptom looks like an application problem rather than an installation one.

Before you change anything

Sizing the graph before running it prevents most of this. The ComfyUI VRAM and execution sizer estimates the footprint of a checkpoint class, adapter count, resolution and batch size, which is enough to tell you whether you are trying to solve a tuning problem or a hardware problem. If the answer turns out to be hardware, ComfyUI vs Automatic1111 vs Forge covers how the alternatives handle constrained cards, since their memory architectures differ in ways that occasionally matter more than the interface does.