🧹 VRAM Purge by Steve Lasmin

You know the feeling. You finish a generation, the image is sitting there, and Task Manager still shows your RTX card mostly full. ComfyUI keeps models cached on the GPU on purpose - reloading weights is the slow part of any workflow, so it holds onto what it already loaded in case you need it next. Great for speed, terrible when you're about to chain a second heavy model and there's nowhere left to put it.

This node is a "clear the cache now" button you can wire directly into the middle of a graph. Drop it between stages, and the moment execution reaches it, it tells the GPU driver to give unused VRAM back. That's the whole job, and it does it with no model downloads, no API key, and no dependencies beyond what ComfyUI already has.

What it actually does

The "VRAM Purge by Steve Lasmin" node is a passthrough: you wire anything into its trigger input, and the same data comes out of trigger_out unchanged. Its only job is to run a cleanup routine when execution lands on it.

Under the hood it does three things, each optional:

• unload_models - calls ComfyUI's own unload_all_models(), which moves currently loaded checkpoints, LoRAs, and CLIP models off the GPU and back to system RAM.
• empty_cache - calls torch.cuda.empty_cache(), which returns cached CUDA allocations to the driver.
• synchronize - calls torch.cuda.synchronize(), which waits for all in-flight GPU operations to finish before the cache clear runs, so you're not racing a half-done sampler step.

One thing worth knowing: empty_cache() doesn't reclaim memory that's still in use. If a node elsewhere in the graph is actively holding tensors, no purge node in the world can free them. It returns cached blocks - the slack PyTorch grabs and hangs onto for speed - to the driver. If your VRAM is pinned by something live, this won't fix it, and nothing in this pack will.

The inputs that matter

You'll set two of them and leave the rest alone:

• trigger - wire any output into this. It's just a gate; the value passes through untouched, so you can drop the node anywhere data flows.
• empty_cache and synchronize - both default to on, and on is right. The only time you'd flip synchronize off is if you're short on time and willing to risk clearing while the GPU is still chewing on work.

unload_models defaults to on too, and that's the setting with the real cost. Unloading every model guarantees the next stage reloads from disk, which is exactly why a mid-graph purge can make a workflow slower if you overuse it. It fires torch.cuda.mem_get_info() at the end and logs free/total VRAM to the console, so you can see what it bought you.

Where it earns its place

ComfyUI already calls empty_cache() between stages on its own - that's its normal memory management. The value here is control of timing. You put this node exactly where ComfyUI's lazy behavior would otherwise let things pile up: before loading a second big model, or between the heavy stages of a video workflow like LTX-2, where a checkpoint, a 13B video model, and a VAE decode all want space in the same run. And despite the "Windows" in the class name, there's nothing Windows-specific here - this node works on any CUDA machine.

Installing it

ComfyUI Manager is the easy path: search for "RAM/VRAM Purge by Steve Lasmin" and install. Or clone it manually:

cd ComfyUI/custom_nodes
git clone https://github.com/Eklipsis/comfyui-ram-vram-purge-by-steve-lasmin.git

Restart ComfyUI either way. The pack's pyproject.toml lists zero dependencies, so there's nothing else to fetch - it appears under RAM/VRAM Purge by Steve Lasmin in the node menu.

When it won't help

The honest caveat, from people who've been burned: purge nodes are not a universal fix for ComfyUI memory problems. In r/StableDiffusion threads about ComfyUI holding RAM, at least one user reports "even the vram cleanup nodes don't do the trick for me" - usually because the memory is genuinely in use, not cached. If you're hitting OOM mid-sampler, the real levers are quantized models (GGUF for video, fp8 for Flux-class weights) and ComfyUI's own launch flags, not a cleanup node. Use this one as a targeted nudge between heavy stages, not as a permanent resident in every workflow - and if you notice generations getting slower after adding it, that's the reload tax talking, and you should probably remove it.