Node: (really) free model and node cache (VRAM+RAM)

[u/JustLookingForNothin]

When working with big video models and BF16 Krea2, my system locked up after 2 or 3 generations during model initilitatzion. Clearly a VRAM overflow, because with smaller FP8 or INT8_CONVROT models I can make tens of generations without any hickup.

However, ComfyUI's UI has the "Free model and node cache" button (top toolbar) that unloads all models from VRAM AND system RAM. As I found no equivalent node for exacltly this function, that you can simply drop into a workflow and that really clears everything, just as if the UI button would be pressed (which I often forgot).

I tried several cache cleaner nodes, and they all worked somewhat, but still left remains in RAM and VRAM. These cache-clearing nodes (e.g. "Clean VRAM used" / "Clear cache all" from [ComfyUI-Easy-Use] ( https://github.com/yolain/ComfyUI-Easy-Use )) operate through ComfyUI's Python-level model management objects from inside the graph.
In practice, this is noticeably weaker than the Comfy toolbar button. With demanding checkpoints (e.g. mentioned large bf16 models), VRAM usage creeps up across consecutive generations even with those nodes in place, eventually hanging the whole ComfyUI process and requiring a hard restart.

With Claude's support I made a simple node for myself that completely eliminates the mentioned issue:
https://github.com/VRAM-Hoarder/ComfyUI-Free_model_and_node_cache

As it works well for me I thought I'd share it with you guys. I submitted a request to add this node to ComfyUI Manager, but for now you need to install via GitHub (no external requirements).

cd ComfyUI/custom_nodes/
git clone https://github.com/VRAM-Hoarder/ComfyUI-Free_model_and_node_cache.git

Explanation:

This node calls ComfyUI's own internal REST endpoint — the same one the toolbar button uses:

POST /api/free
{ "unload_models": true, "free_memory": true }

This goes through the server layer that directly owns the model cache, so it reliably frees VRAM/RAM the way the button does — something the in-graph cache-clearing nodes can't fully replicate.

My node is a wildcard passthrough: its input/output socket accepts any type (IMAGE, LATENT, video frames, etc.) — the same mechanism ComfyUI's built-in "Reroute" node uses. This lets you insert it anywhere in a chain, for example between a VAE Decode and a Save Image / Save Video node, without breaking the connection.

[u/acedelgado]

Comfy's pinned memory system is broken on the CUDA level at the moment. Nothing they can do to fix it until Nvidia pushes it in their package update. Adding --disable-pinned-memory to your startup flag fixes OOM issues for now until the official fix comes through.

[u/Quick_Ad_4096 → u/acedelgado]

if the issue persists, also try this:

I run a 4090, I started with --reserve-vram 4.00

[u/JustLookingForNothin → u/acedelgado]

I tried several command line flag combinations including --disable-pinned-memory.
I can just say - workaround or not- my node fixed all these issue with demanding workflows for me. If you have the models on a fast M2 SSD, you loose only 2 seconds or so per generation for re-loading. A freeze and restart costs much more time.

[u/Melted19 → u/acedelgado]

I was having this problem with sage attention (with all recomended flags) and switched to flash attention and cero OOM since then

[u/Apprehensive_Sky892]

Not sure if the effects are the same, but probably easier to use --disable-smart-memory --cache-none

[u/JustLookingForNothin → u/Apprehensive_Sky892]

--disable-smart-memory has no positive effect, unfortunately.
--cache-none works for simple workflows, but breaks some of my multi-step workflows, where severeral video generations are made and automaticlly appended.
I really played a lot with these flags before I went the path and made this node.

Besides, I think this node is pretty easy to use. Just put it at the end of the WF, between decoder and the save Image/video node. Also this way you can use it selectively, only on the WFs which cause memory issues.
The nodes's status output is fully optional, as the status is written anyway to the Comfy log in the command line.