Free Memory

Free Memory is a garbage-collection button you can put inside a workflow. Two of its switches are genuinely useful, one is a "if you're desperate" option, and the node's own source comments are more honest about its limits than most memory-cleaning nodes ever are.

Inputs and outputs

Heads up: this node's three switches are labelled in Chinese. Here's the mapping, with the author's own tooltips for the two ambiguous ones:

• 执行垃圾回收 - "run garbage collection", default on. Calls gc.collect().
• 卸载模型缓存 - "unload model cache", default off. Tooltip: unloads models ComfyUI isn't using, freeing more VRAM and system RAM, but the next use has to reload them.
• 多轮GC - "multi-round GC", default off. Tooltip: runs gc.collect() three times - more thorough, slightly slower.

There's also an optional passthrough input of the wildcard * type, and one output, passthrough, which returns whatever you fed it. That matters more than it sounds: you can drop this node in the middle of an existing wire - image, latent, whatever - as a checkpoint without breaking the graph.

It's also an output node, so ComfyUI treats it as terminal and runs it every execution even if nothing downstream needs it. Stick one at the end of the graph and you get a cleanup pass at the end of every run.

What it does under the hood

On execute it reports GPU and system memory (name, total, allocated, reserved, plus process and system RAM via psutil), then does the work:

1. optionally comfy.model_management.unload_all_models() - it falls back to cleanup_models(force_unload=True) on older ComfyUI builds
2. gc.collect() once, or three times with 多轮GC
3. torch.cuda.empty_cache() and torch.cuda.synchronize(), if CUDA is present

Then it reports the deltas. The report comes back as UI text, so depending on your frontend you may see it on the node - the switches work either way.

When it helps, when it's theatre

empty_cache() returns cached blocks to the CUDA driver, and PyTorch's caching allocator was going to reuse them anyway for the very next allocation. So the real-world case for it is when something outside the current graph wants that memory - handing the card back between phases, running another process alongside ComfyUI, or freeing room before one big allocation. It won't lower the process's virtual memory, and if tensors are still referenced, nothing gets freed at all. If the "allocated" number barely moves after you run it, that's the answer: you're still holding references.

The important honest take is what it does not solve. "My model plus text encoder don't fit" is a load-time problem; freeing cache after the fact doesn't buy you a bigger card. The real levers are quantization and resolution - a 12GB card runs Flux comfortably at fp8 or Q6+ GGUF - and, per the community A/B testing, sometimes just removing --lowvram --reserve-vram flags, which can force offloading a card that didn't need it. Try default memory flags before you start cleaning.

Where this node earns its place: switching between large models inside one workflow (video especially), long batch/loop runs where memory creeps, or freeing the card before a handoff. Where it hurts: dropping it inside a loop with cache unloading enabled - every subsequent generation reloads gigabytes from disk, and on a big video model that's a lot of dead time.

Install

Manager → Practical-Tools, or:

cd ComfyUI/custom_nodes
git clone https://github.com/wenchengxiang/ComfyUI-Practical-Tools.git

One wrinkle worth knowing: the pack's requirements.txt lists onnxruntime, nvidia-vfx, openai>=1.0.0 and gguf - but not psutil. Installing the requirements gives you the node, minus the system-RAM numbers, and you'll see the author's own "pip install psutil" note in the output. Also, if you're not on CUDA, the node says so and skips the GPU half entirely; on a CPU-only or non-CUDA setup it still does the garbage collection.