ComfyUI Wan2.2 Keeps Eating RAM Until It Crashes? The –cache-none Fix, Explained

There is a specific failure pattern that keeps showing up in ComfyUI threads about Wan2.2, and it is easy to misread. You load the 14B text-to-video or image-to-video workflow, generate one clip, and everything works. You generate a second clip, and RAM usage climbs. By the third or fourth run, the machine is thrashing into swap, the UI freezes, or the whole process dies with no useful error message — or worse, on Linux, the OS hard-freezes because the kernel overcommitted memory and ComfyUI filled it before the OOM killer could react.

If your first instinct is to blame the model, the BlockSwap node, or your 16GB GPU, you are looking in the wrong place. The model being “too big” causes an out-of-VRAM error at load time. This is different: this is RAM that is never handed back to the OS after a completed generation. It is an execution-cache problem, not a model-size problem.

Symptom: RAM Is Never Released After a Run

The clearest description of this exact issue is in ComfyUI issue #9484, titled “RAM not being fully released after WAN 2.2 generation.” The reporter describes running “pretty much any generation” and seeing roughly 30GB of RAM reserved for no obvious purpose, with the leaked footprint growing on each subsequent run until RAM saturates and spills into swap. The timeline matters here: the problem reportedly became common around the time subgraph support landed in the daily builds, which made it easy to attribute the regression to the newer ComfyUI versions rather than to the model.

Several commenters reproduced it under different hardware. One ran three ComfyUI instances — one per GPU — and watched a 128GB server start to OOM after only the second generation. Another confirmed it on an RTX 4090 with 32GB of system RAM, where ComfyUI would “crash a lot” without the fix. A third reported it on a 64GB machine with an RTX 3090: their Wan2.2 workflows that previously ran clean started breaking repeatedly, and ComfyUI would just stop with no error message, leaving the Windows console waiting on “Press any key to continue.”

How to confirm it is this issue and not something else. Watch system RAM (not VRAM) across two or three generations. On Linux, run free -h between runs; on Windows, use Task Manager. If available memory drops after every completed run and does not come back up when the queue is empty, you are seeing the leak. The model being loaded and then intentionally kept warm for fast re-use is normal — but an ever-growing footprint that never returns to a baseline is the leak.

The Real Cause: The Execution Cache, Not the Model

The confusion that trips most people up is the word “cache.” ComfyUI has two completely separate caching systems, and they get blamed for each other’s problems all the time.

• Model/diffusion-model cache — keeps loaded checkpoints in VRAM or RAM so you don’t re-read a 16GB file from disk on every run. This is what BlockSwap, --lowvram, and --normalvram interact with.
• Execution cache — stores the output of individual nodes so that if you only change one parameter downstream, ComfyUI can re-use upstream results instead of re-running them. This is what the --cache-* flags control.

The Wan2.2 leak lives in the second system. Video generation produces enormous intermediate tensors — latent frames across dozens of timesteps — and the execution cache holds onto them. On an image workflow, a cached latent is a few tens of megabytes and nobody notices. On a 14B video workflow producing dozens of frames, the cached intermediates are gigabytes, and they accumulate because the cache is not being reclaimed after the run completes.

The official ComfyUI troubleshooting guide documents the lever directly: switching cache strategies. The startup-flags reference states that the cache-mode flags are mutually exclusive — you pick one of --cache-ram, --cache-classic, --high-ram, --cache-lru, or --cache-none. The key distinction, per the docs, is that --cache-none is “less RAM usage, but slower” because it re-executes every node on each run.

This is why the fix is counter-intuitive. You are not changing how much VRAM Wan2.2 needs. You are telling ComfyUI to stop hoarding the gigabytes of intermediate results it would otherwise hang onto between runs.

The Fix: Launch ComfyUI with –cache-none

The fix reported working across hardware in issue #9484 is a single launch argument. Start ComfyUI like this instead of the default command:

python main.py --cache-none

On Windows Portable, edit the run_nvidia_gpu.bat (or whichever launcher you use) and add the flag to the python invocation line. On a headless Linux box or Docker setup, add it to whatever starts main.py. After restarting ComfyUI with the flag, run the same two or three Wan2.2 generations and watch free -h: available RAM should return close to the pre-run baseline after each queue drains, instead of ratcheting downward.

The trade-off you are accepting. --cache-none means ComfyUI re-executes every node on each run, which costs some speed — most noticeable if your workflow already hit the same upstream nodes repeatedly. For a one-shot video generation, the difference is minor because the dominant cost is the diffusion model itself, not re-running a cheap preprocessor. For a long batch or a loop that re-uses upstream results, the slowdown is real. If --cache-none costs you too much speed, the middle ground is --cache-lru N, which caps how many node results are cached — it still bounds memory, but keeps a small hot cache for the nodes you re-touch most.

One important correction from the issue thread: adding “clear VRAM” (or “Free Memory”) nodes to the workflow does not reliably fix this. Those nodes target VRAM/model cache, not the execution cache that is leaking. Multiple users confirmed the nodes had no effect while --cache-none did. Don’t waste time re-wiring the graph — the lever is a launch flag.

Linux Users: The Overcommit Freeze Is a Separate Danger

One comment in issue #9484 describes a failure mode worth flagging for Linux users specifically: the leak is worse on Linux because of memory overcommit. With default kernel settings (vm.overcommit_memory=0), Linux happily hands out more memory than physically exists, and when ComfyUI — already leaking — fills it all, the system hard-freezes before the OOM killer can react. The commenter tried tightening overcommit (sysctl vm.overcommit_memory=2 vm.overcommit_ratio=100) and found it caused ComfyUI to die when loading a second model instead — a different problem, not a fix.

Net result: on Linux, fix the leak at the source with --cache-none rather than trying to fight it with kernel overcommit settings. If you are running multiple ComfyUI instances per GPU for throughput, this flag is effectively mandatory — the multi-instance OOM report on a 128GB server is the canonical warning case.

How This Interacts With Wan2.2 Memory Optimization (and Why It’s Not the Same Thing)

It is worth separating this RAM-leak fix from Comfy’s recent Wan2.2 VRAM optimizations so you don’t conflate the two. The official Wan2.2 memory-optimization update shipped ~10% less VRAM for VAE decoding and a major improvement for the 5B I2V model, plus new template workflows for the 14B models. Those changes reduce peak GPU memory during a run — a different axis entirely.

You can think of the two levers this way:

• VRAM (GPU): controlled by BlockSwap (blocks_to_swap), offload_device, quantized fp8 checkpoints, and the newer model-loader memory optimizations. This governs whether a 14B model fits on your card at all.
• RAM (system): controlled by the execution-cache flags (--cache-none, --cache-lru). This governs whether your machine stays responsive across multiple runs.

They are not substitutes. A 16GB card can load and run Wan2.2 14B using BlockSwap to page transformer blocks between VRAM and system RAM — that is a solved problem — and still fall over on the third generation because the execution cache is leaking RAM on top of the BlockSwap reservation. You need the VRAM trick and the RAM fix together for a workflow you actually run repeatedly.

A Repeatable Verification Sequence

Here is a concrete, reproducible check you can run in a few minutes to confirm whether you are affected and whether the fix took.

1. Start ComfyUI normally and note system RAM baseline (free -h on Linux, Task Manager on Windows) with an empty queue.
2. Run the same Wan2.2 generation three times in a row. Record available RAM after each run completes.
3. If available RAM is shrinking after every run and not recovering, you have the leak.
4. Restart ComfyUI with --cache-none (or add --cache-lru 8 if speed is a concern).
5. Repeat the three generations. Available RAM should return close to the baseline after each queue drains.
6. Confirm the trade-off: leave --cache-none in place if the per-run slowdown is acceptable; otherwise test --cache-lru with a value that keeps memory bounded but preserves your most-hit nodes.

Conclusion

If Wan2.2 runs fine once in ComfyUI but steadily eats RAM until the process crashes or your Linux box freezes, the model is almost certainly not the problem — the execution cache is. The fix that has been reported working across 32GB, 64GB, and 128GB systems is a single launch flag: python main.py --cache-none, or --cache-lru N as a bounded middle ground. Keep it separate from the VRAM-side optimizations (BlockSwap, quantized checkpoints) that govern whether the 14B model fits on your GPU in the first place: you generally need both for a workflow you run more than once.

For a broader look at how the VRAM launch flags and offloading actually behave — the other half of this equation — see our earlier breakdown of ComfyUI VRAM launch flags.