🧹 Clear VRAM

You know the situation: a 3D pipeline that generates a mesh, textures it, then renders 8 views from it, and somewhere in the middle of that you get an OOM that has nothing to do with the node that crashed. The generator's weights are still resident, the texture stage wants its own model, and ComfyUI's automatic offloading hasn't got there yet.

Clear VRAM is the crude answer: a node with no inputs and no outputs that you drop between two heavy stages and let it bulldoze everything.

What it does when it fires

It's 90 lines and most of them are repetition. In order: comfy.model_management.unload_all_models(), then soft_empty_cache(), then eight gc.collect() passes, a torch.cuda.synchronize(), then torch.cuda.empty_cache() five times, torch.cuda.ipc_collect(), then empty_cache() three more times for luck. Finally it prints allocated and reserved VRAM in GB to the console so you can see what it actually recovered:

[Antonioilev] CUDA allocated: 3.42 GB
[Antonioilev] CUDA reserved : 4.10 GB

The repeat loops look like superstition and partly are - but fragmentation in the CUDA caching allocator genuinely does take a few passes to collapse, and the loop count is the author optimising for their own 3090.

It is an output node with IS_CHANGED returning the current time, so it re-runs every time you hit Queue. That matters: it can't be cached away and skipped.

The trade you're making

unload_all_models() doesn't move your models to RAM - it evicts them. The next stage that needs a checkpoint reloads it from disk, which is seconds to minutes depending on size and storage. So:

• Good use: between generation and a heavy Refine Mesh / MeshProjector / texturing stage, when the next node would otherwise OOM. One firebreak, in the right place.
• Bad use: sprinkled before every node "just in case". You'll convert a workflow that ran in 40 seconds into one that spends most of its time re-reading safetensors from an SSD. VRAM is meant to be full; that's the point of it.
• Worse use: inside a loop or a batched multi-view render, where every iteration reloads the model you just evicted. If your batch spirals, this node is a suspect.

If you're fighting OOM on a card that barely fits your model, the KB's note is worth repeating: memory flags like --lowvram can make a card that just fits slower rather than faster, and ComfyUI's own management is usually right. Reach for this node when you've actually seen the allocation graph blow past the card, not preemptively.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Antonioilev/ComfyUI_Antonioilev_Lightpack.git

Restart ComfyUI. That's the whole install - this is one of the few nodes in the pack with no third-party dependency at all beyond torch and ComfyUI's own model_management, both of which are already there. Manager users: search Antonioilev Light Pack. Note that the repo ships no requirements.txt, so Manager has nothing to offer you for the pack as a whole; the mesh nodes need pip install trimesh etc., but this one doesn't.

Fine print

There's nothing to wire and nothing to configure, which is also why it's easy to forget it's in the graph. When you're done debugging a memory problem, delete the node rather than leaving it in the workflow - a stale Clear VRAM in a shared graph quietly taxes everyone who runs it.

And read the console once after a run. If reserved is still large after the cleanup, the memory is held by something the Python side can't see - a live tensor referenced elsewhere in the graph, or an extension with its own allocator (the 3D-Pack's CUDA extensions are the usual culprit in mesh pipelines). No amount of empty_cache() fixes a reference that's still alive.