How to Fix ComfyUI “CUDA Out of Memory” Error with FLUX.1 Models

Last updated October 14, 2026 · 11 min read

FLUX.1-dev is a 12-billion-parameter model. Loaded at full precision it wants more VRAM than a single consumer GPU has, which is why ComfyUI throws CUDA out of memory the moment you queue a prompt. The fix is almost never “buy a bigger card” — it is picking the right checkpoint precision and passing the right launch flags.

Why FLUX.1 exhausts VRAM so fast

FLUX.1 is not one model. It is three models loaded simultaneously, and ComfyUI keeps all of them resident in VRAM between runs so that subsequent generations stay fast. Here is what is actually sitting on your card:

That is before anything is generated. On top of the weights you need room for attention activations, the latent tensor, and the VAE decode buffer — typically another 1–3 GB at 1024×1024 with a batch size of 1.

So the arithmetic is brutal and simple. A 3060 with 12 GB cannot hold a 34 GB model. It cannot even hold a 17.4 GB fp8 pipeline alongside a browser. But it holds a 12.3 GB GGUF pipeline with room to spare. The entire problem is precision selection, and the error message does not tell you that.

Step 1 — Read the error: three different OOMs

These three messages look similar and have completely different fixes. Read the terminal output before you change anything.

A. torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate X MiB

This is PyTorch telling you it genuinely cannot find enough memory. It will print something like GPU 0 has a total capacity of 11.99 GiB of which 412.50 MiB is free. The free figure is the useful part:

• Free memory is near zero — you are loading weights that do not fit. Go to Fix 1 and Fix 2.
• Free memory is several GB but allocation still failed — this is fragmentation, not a shortage. Go to Fix 4.

B. CUDA error: out of memory (no PyTorch prefix)

A bare CUDA error from the driver rather than the framework usually means the driver-level budget is exhausted, not PyTorch's cache. On Windows this is frequently caused by the display driver holding back memory for the desktop compositor, or by another process holding a context open. See Fix 7.

C. No error, but generation takes 10+ minutes and Task Manager shows GPU memory “shared” usage climbing

There is no exception here because nothing failed — the model is silently spilling into system RAM and streaming weights over PCIe on every step. That is a 10–50× slowdown. Go to Fix 6.

Fix 1 — Switch to an fp8 or GGUF checkpoint

This is the single highest-impact change and it costs you almost nothing in output quality. Place the file in ComfyUI/models/unet/ (older builds) or ComfyUI/models/diffusion_models/ (current builds).

GGUF checkpoints require the ComfyUI-GGUF custom node. Once it is installed you will get a Unet Loader (GGUF) node to replace the standard Load Diffusion Model node. The text encoders and VAE still come from the ordinary models/clip/ and models/vae/ folders — GGUF only replaces the diffusion model.

If you are on a card with 8 GB or less, Q4_K_S is the difference between “this does not work” and “this works in about two minutes per image”. At Q4 the visual degradation is noticeable if you look for it in fine texture, but it is far better than not rendering at all.

Fix 2 — Load the T5 text encoder in fp8

This step is skipped constantly and it is worth roughly 4.6 GB. FLUX.1 does not use CLIP as its primary text encoder — it uses T5-XXL, and the fp16 build is 9.5 GB of pure text encoding that most people never think about.

Swap the file in ComfyUI/models/clip/:

t5xxl_fp16.safetensors    →  9.5 GB   (avoid on < 24 GB)
t5xxl_fp8_e4m3fn.safetensors  →  4.9 GB   (use this)

Then point the DualCLIPLoader node at the fp8 file for the t5xxl slot and keep clip_l.safetensors for the clip_l slot.

Newer ComfyUI builds add a device dropdown on the DualCLIPLoader node. Setting it to cpu moves the entire text encoder off the GPU — it costs a few seconds of prompt-encoding time and frees nearly 5 GB. On a 12 GB card that is often the change that finally makes fp16 diffusion weights feasible.

Fix 3 — The launch flags that actually matter

ComfyUI exposes a large flag list. These are the six that change VRAM behaviour:

How to apply the flags in ComfyUI Portable (Windows)

Do not type flags into a terminal you relaunch each time. Edit run_nvidia_gpu.bat in the ComfyUI Portable folder and add them to the existing command line:

.\python_embeded\python.exe -s -m ComfyUI --windows-standalone-build ^
    --lowvram --disable-smart-memory --reserve-vram 1.0

The ^ is a line continuation. Everything must be on one logical line, or on lines joined by ^. Save the file and launch through that .bat from now on.

If you use the ComfyUI desktop app or a manual install

Add the same flags to the end of the launch command in your shortcut or start script:

python main.py --lowvram --disable-smart-memory --reserve-vram 1.0

Fix 4 — Cure memory fragmentation

This is the fix for the maddening case where you have 4 GB free, a 2 GB allocation fails, and Task Manager insists nothing is wrong. PyTorch's caching allocator reserves memory in blocks sized for previous allocations. When a new allocation needs a different shape, the free blocks are the wrong size and cannot be reused — even though the total free memory is sufficient.

Set this environment variable before ComfyUI starts, not after:

Windows (PowerShell)

$env:PYTORCH_CUDA_ALLOC_CONF = "expandable_segments:True"
python main.py --lowvram

Windows (CMD / .bat file)

set PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
.\python_embeded\python.exe -s -m ComfyUI --windows-standalone-build --lowvram

Linux / macOS

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
python main.py --lowvram

With expandable segments enabled, the allocator can grow and re-split an existing segment instead of demanding a fresh contiguous block. It resolves a large share of “I have free VRAM but it still OOMs” reports, and it costs nothing when memory is not fragmented.

Fix 5 — Stop exceeding 1024×1024

FLUX.1 was trained at 1024×1024. Pushing the Empty Latent Image node to 1536×1536 does not give you proportionally more detail — it gives you attention matrices that scale roughly with the square of the token count, which is where the uncontrolled VRAM growth comes from.

• Stay at or below 1024×1024. Use 1024×768 or 768×1024 for non-square output.
• Keep batch size at 1. A batch of 4 at 1024×1024 quadruples the activation memory. Generate four separate images instead — it is slower in wall-clock terms but it does not fail.
• Generate small, upscale after. If you need a large final image, generate at 1024 and run a separate upscale pass with a dedicated upscale model. That decouples the memory cost of resolution from the diffusion step entirely.

If you want to go larger during the diffusion step itself, look at tiled or latent-upscale workflows — they process the image in overlapping tiles so peak VRAM stays bounded.

Fix 6 — Disable Windows sysmem fallback

NVIDIA drivers on Windows ship with a sysmem fallback policy enabled by default. When VRAM fills up, instead of failing, the driver quietly pages GPU memory into system RAM and streams it back over PCIe. You get no error, no crash, and a generation that takes twenty minutes.

Turn it off so that failures are visible and diagnosable:

1. Open NVIDIA Control Panel.
2. Go to Manage 3D settings → Global Settings.
3. Find CUDA — Sysmem Fallback Policy.
4. Set it to Prefer No Sysmem Fallback.
5. Click Apply.

After this, an out-of-memory condition produces an actual error rather than a silent slowdown. That is what you want — a visible failure you can fix beats an invisible one you cannot.

Fix 7 — Reclaim VRAM from other apps

ComfyUI competes with everything else on the machine. On a 12 GB card, 2 GB of recycled VRAM frequently decides whether a workflow runs.

• Browsers are the biggest offender. Chrome and Edge with hardware acceleration enabled hold hundreds of MB per active tab. Close them, or disable hardware acceleration in chrome://settings/system. This matters double when you are running ComfyUI in a browser tab.
• Other ML processes. A forgotten Ollama instance, a LocalAI server, or a second ComfyUI instance keeps a CUDA context alive and holds its weights. Check with nvidia-smi and kill what you do not need.
• Restart, do not just close. Some apps release their CUDA context only on process exit. If nvidia-smi shows memory in use but no processes listed, a driver reset is needed — the quickest reliable way is a reboot.
• Windows desktop composition. Multi-monitor high-refresh-rate setups and HDR consume a surprising amount. Dropping to a single display at 60 Hz during a long batch is not superstition.

How to check what is actually using your GPU

nvidia-smi

The Memory-Usage column shows total used versus total capacity. The process table below it lists per-PID usage — but note that on Windows, processes using the WDDM model often show as N/A in that table, which is why Task Manager's Performance → GPU tab (with the Dedicated GPU memory column) is a better cross-check on Windows specifically.

How much VRAM does FLUX.1 actually need?

Practical recommendations by card, assuming a batch size of 1 at 1024×1024 and 20 steps:

If your card is in the bottom two rows, a cloud GPU or a hosted API is genuinely the better engineering decision rather than a compromise. Offloading to system RAM means every generation step crosses the PCIe bus, and no amount of flag tuning changes that.

FAQ

Is 8GB of VRAM enough to run FLUX.1 in ComfyUI?

Yes, but only with a quantized checkpoint. Use a GGUF Q4_K_S or Q5_K_S build of FLUX.1-dev with the T5-XXL text encoder loaded in fp8, and start ComfyUI with --lowvram. Expect roughly 1.5 to 4 minutes per 1024×1024 image at 20 steps on an 8GB card.

Why does ComfyUI report CUDA out of memory when Task Manager shows free VRAM?

This is almost always memory fragmentation, not a true shortage. PyTorch reserves cached blocks that cannot be reused for a differently shaped allocation. Setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True before launching ComfyUI lets the allocator release and re-split those blocks, which resolves most of these cases.

What is the difference between --lowvram and --novram in ComfyUI?

Both offload model weights to system RAM. --lowvram keeps the parts of the model that are actively executing in VRAM and swaps the rest in blocks, while --novram keeps almost nothing in VRAM and streams far more across the PCIe bus. --lowvram is faster when it fits; --novram is the fallback when it does not.

Does FLUX.1-dev really need 24GB of VRAM?

Not in fp16. The full-precision pipeline is about 34GB, but the fp8 UNet plus fp8 T5-XXL encoder brings that to roughly 17GB, and a GGUF Q4 build drops it to about 12GB. A 12GB card runs FLUX.1 comfortably once you stop loading full-precision weights.

Is flux1-dev-fp8.safetensors the same as flux1-dev-fp8-e4m3fn.safetensors?

No. The original flux1-dev-fp8.safetensors from Black Forest Labs stores scaled fp8 layers but still expands to roughly 23GB in memory unless you pass --fp8_e4m3fn-unet. The pre-quantized flux1-dev-fp8-e4m3fn.safetensors from the Comfy-Org repackaging loads at about 11.9GB without extra flags.

Quick reference: the whole fix on one line

# Windows ComfyUI Portable — edit run_nvidia_gpu.bat
set PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
.\python_embeded\python.exe -s -m ComfyUI --windows-standalone-build ^
    --lowvram --disable-smart-memory --reserve-vram 1.0

...plus flux1-dev-fp8-e4m3fn.safetensors and t5xxl_fp8_e4m3fn.safetensors in place of the full-precision files. Apply those together and the CUDA out of memory error stops, on every consumer GPU from 8GB upward.