ComfyUI Won’t Release RAM After Video Generation: Diagnose the Cache, Not a Leak

You run a Wan2.2 image-to-video workflow in ComfyUI. The first render completes fine. The second one starts crawling. By the third, your system fans are screaming, free -h shows almost everything gone, and eventually the whole machine freezes or the process gets OOM-killed. You check nvidia-smi and VRAM looks reasonable — so why is RAM bloated and never coming back?

The instinct is to call it a memory leak. In most cases it isn’t. It’s ComfyUI holding on to node results on purpose, combined with a smart-memory manager that is slower to reclaim than you expect — and on Linux, an overcommit default that turns a slow bleed into a hard system freeze. This guide walks through diagnosing the real cause and fixing it with launch flags, node ordering, and OS-level guardrails.

Why ComfyUI holds RAM that looks “leaked”

ComfyUI caches the output of every node it executes so that, if you change a downstream node and re-run, it doesn’t have to recompute the expensive upstream work. That cache lives in system RAM (and sometimes VRAM) by default. On a short image workflow the cache is small. On a video workflow — especially Wan2.2 at higher frame counts — a single latent batch can be gigabytes, and a chain of cached intermediates quickly adds up to tens of GB.

The ComfyUI maintainers characterize this explicitly as efficient caching, not a leak. In GitHub issue #11301 (“RAM Memory Leak”), a maintainer replied that the growth “isn’t actually a memory leak, it’s just efficient caching” and pointed to the --cache-ram flag as the fix. That’s the key reframe: your RAM isn’t being wasted, it’s being retained, and you can cap it.

A second, related issue #9484 (“RAM not being fully released after WAN 2.2 generation”) — still open — reports Wan2.2 workflows that “previously ran without issues” starting to break after ComfyUI and node updates. Several reporters trace it to the cache and to a specific Torch version regression where cache-none throws errors until they downgraded to torch 2.7.1. So the problem has two faces: the cache retaining memory, and occasional upstream regressions in torch or specific nodes.

Step 1: Confirm it’s the cache, not a leak

Before changing anything, prove where the memory is going. On Linux, run this right after a video render and watch it across three consecutive runs:

free -h                # system RAM
echo "---"
nvidia-smi --query-gpu=memory.used,memory.total --format=csv  # VRAM

If RAM climbs steeply on run one, then stays flat at that elevated level on runs two and three, you’re looking at the cache reaching a steady state — not an unbounded leak. A true leak keeps climbing every run toward exhaustion. The distinction matters because it changes the fix entirely: a cache is tunable, a leak is a bug report.

You can confirm the cache hypothesis directly. Restart ComfyUI fresh (RAM drops back to baseline), load the exact same workflow, and watch memory climb to the same plateau without ever rendering anything new — cached results from earlier are being replayed. If you enabled --cache-classic or left the default in place, this plateau will be large on video workflows.

Step 2: Pick the cache mode that matches your RAM

ComfyUI’s cache flags are mutually exclusive — you pick one of --cache-ram, --cache-classic, --cache-lru, or --cache-none. From the official startup flags reference:

• --cache-none — reduced RAM/VRAM usage; re-executes every node on each run. Slowest, but the most deterministic memory floor.
• --cache-lru N — cache only the most recent N node results, evicting the oldest. A good middle ground on 16–32 GB machines.
• --cache-ram G — cap the cache at G gigabytes and let cached results spill to disk rather than memory. The direct answer to “it holds too much RAM.”
• --cache-classic — old, aggressive caching. Rarely what you want on a RAM-constrained box for video.

For a Wan2.2 video workflow on a 16 GB or 32 GB machine, --cache-lru 10 or --cache-ram 8 is the sweet spot: your RAM stops growing past a known ceiling, and you keep most of the speed benefit of caching. --cache-none is the nuclear option when you need the absolute most predictable floor and don’t mind slower re-runs.

Step 3: Order matters when you clear memory mid-workflow

If your workflow uses a “Clear Cache” or “Clean VRAM” node, its position in the graph changes what actually gets freed. A common community fix reported on r/comfyui is that clearing after the VAE decode — not before — is what reclaims RAM. The reasoning: the decode produces the large pixel tensors that are the biggest single cache entries. Clear the cache after you’ve handed those tensors off to the VAE encode/decode, not before generating them.

The practical ordering that works on video loops:

Generate → VAE Decode → Clear Cache / Clean VRAM → (next iteration)

Put the cleanup node at the tail of each loop iteration, after decode, so the largest intermediates are evicted before the next iteration allocates. A cleanup node placed before decode often frees nothing meaningful because the real memory spike hasn’t happened yet.

Step 4: The Linux overcommit trap (the actual freeze)

The most dangerous symptom of this whole problem isn’t the slow RAM creep — it’s the hard system freeze on Linux. Issue #9484 documents it directly: “the issue is worse in linux due to overcommitting RAM, causing a hard freeze when comfy fills the RAM completely.”

Linux defaults to vm.overcommit_memory=0, which hands out more memory than physically exists and hopes applications don’t all use it at once. When ComfyUI’s cache balloons and a second model load needs another few GB, the kernel overcommits, then has to reclaim under pressure — and on a desktop box with a GPU workload in flight, the reclaim can stall the GUI, the display manager, and even SSH long enough that the machine looks bricked.

Two remedies, in order of preference:

1. Cap it at the application layer (preferred): set a cache ceiling with --cache-ram or --cache-lru so ComfyUI simply never asks for unbounded RAM in the first place.
2. Constrain it at the OS layer (belt-and-suspenders): run ComfyUI inside a systemd scope or cgroup with a MemoryMax hard limit, so the kernel OOM-kills ComfyUI instead of the whole desktop. A systemd-oomd marker on the service adds a second, softer layer that reaps the offender before the system decides to.

The cgroup approach is what I use on a shared 27 GB RAM / 16 GB VRAM machine that has to keep a GUI and other services alive. ComfyUI launches through a wrapper that sets MemoryMax=14G and marks the unit for systemd-oomd; if a runaway video workflow tries to grab more, the cgroup is killed cleanly and the desktop stays responsive. The same idea works on any distro with systemd — you don’t need the whole server, just a scoped limit.

When it is a leak (and a quick win)

Not every case is the cache. The two signals that push you toward a real bug:

1. RAM climbs every single run with --cache-none set — there’s no cache left, so nothing should grow.
2. The symptom tracks a recent update. #9484 reporters pinned a regression to torch on the cu128 wheel and fixed it by pinning: pip install torch==2.7.1 torchvision==0.22.1 torchaudio==2.7.1 --index-url https://download.pytorch.org/whl/cu128. If your memory behavior changed after a ComfyUI, torch, or node update, downgrading the specific component is a fast, reversible test.

For the general “which node is responsible” question, the official ComfyUI guidance is to rule out custom nodes first: launch with --disable-all-custom-nodes (or the newer --disable-all-custom-nodes --whitelist-custom-nodes ComfyUI-Manager) and confirm whether the growth persists on a known-good workflow. If it disappears, the culprit is a custom node; re-enable them in batches to isolate it. The full procedure is documented in the custom-node troubleshooting guide.

How to verify you fixed it

After changing flags and node ordering, prove the fix with a three-run cold test:

# snapshot before
echo "== before =="; free -h | grep Mem; nvidia-smi --query-gpu=memory.used --format=csv,noheader
# render 1..3, snapshot after each
for i in 1 2 3; do
  echo "== after run $i =="
  free -h | grep Mem
  nvidia-smi --query-gpu=memory.used --format=csv,noheader
done

A successful result: RAM rises on run one, then plateaus on runs two and three instead of climbing without bound, and it sits comfortably below your physical limit. If you added a cgroup, deliberately over-request once (a huge frame count or batch) and confirm the cgroup is reaped while the desktop and SSH stay alive.

For more on squeezing ComfyUI into a low-RAM box, see our write-up on ComfyUI VRAM launch flags, and for the model-side of the same OOM fight, our guide to fixing CUDA out-of-memory in llama.cpp.

Conclusion

ComfyUI “not releasing RAM” after video generation is almost always the result cache doing its job too enthusiastically, not a leak. Diagnose by watching RAM plateau across runs, then cap it with --cache-ram or --cache-lru, clear memory after VAE decode, and — on Linux — protect the rest of the box with a cgroup MemoryMax so overcommit never freezes your whole machine. If the growth is unbounded under --cache-none or started right after an update, that’s your signal to bisect custom nodes and pin torch back. Fix the cache first, and most “memory leak” reports dissolve on their own.