LC VRAM Cache Clear

LC VRAM Cache Clear is a pass-through node that clears GPU memory mid-graph. You drop it between two heavy stages - say, between a big sampling pass and an upscaler - and when it executes, it tells ComfyUI to drop cached models and free GPU memory, then hands your data along unchanged. It's the "clean the VRAM before the next act" node, and it exists because the classic out-of-memory failure in ComfyUI isn't one big model - it's stacked models and cached activations that nobody released.

The honest framing first: this won't magically make a 14GB workflow fit on an 8GB card. It's a housekeeping node, not a miracle. Where it earns its place is those long graphs where you load a checkpoint, run a detailer pass, upscale, and run a second model - and the second model chokes even though it would fit on its own. When that happens, the culprit is usually leftover state, and a cache-clear at the right seam fixes it.

How it works

Under the hood it calls ComfyUI's own memory management - cleanup_models() and soft_empty_cache() - then layers on a gc.collect() and a torch.cuda.empty_cache() (plus ipc_collect() for the CUDA allocator). These are the same soft-clears a "clean GPU" button would trigger; they don't unload your loaded model, they just return what can be freed. Which is exactly what you want from something sitting in the middle of a live graph.

The interface is almost insultingly simple: one any input, one any output, both wildcard type. It accepts anything - an image, a latent, a conditioning, even a string - and returns it bit-for-bit unchanged. That's the whole trick: because it passes through whatever you route through it, you can drop it into an existing wire without rerouting anything, and it fires in the right order relative to the stages around it.

How to actually use it

Wire it into the data line at the point where you want the clear to happen - usually right after a heavy node's output and before the next heavy one. Because it executes in graph order along its connection, the placement is the scheduling. Common seams:

• between the first sampler and a hi-res fix or detailer
• before an upscaler that pulls in a second model
• between a tiled decode and the next encode

A couple of realities worth knowing. First, the clear is best-effort and wrapped in try/except - it can't crash your graph, which is good, but it also won't always reclaim everything. Second, don't sprinkle it everywhere; every call has a small cost, and in a graph that already fits in VRAM it does nothing but slow you down slightly. Third - and this is the one that surprises people - it won't fix an OOM caused by a single model that genuinely needs more VRAM than you have. That's a model-selection or quantization problem, not a caching problem. The KB's practical-VRAM table is the better map for that: GGUF quants are the real lever for fitting big models on small cards.

Install

This ships in lonecatone23's ComfyUI_LC123_nodes pack, alongside ~89 other small utility nodes. Install like any custom node:

• ComfyUI Manager - search "LC123" or "ComfyUI_LC123_nodes", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/lonecatone23/ComfyUI_LC123_nodes, restart.

No extra pip packages - it's pure torch/ComfyUI environment, no requirements.txt, no model downloads.

The honest verdict

As a node, it's nearly invisible - that's the point, and arguably the design win. If you've never hit a mid-graph OOM you'll never need it, and that's fine. If you have, you know the feeling of eyeballing your graph for where the memory dies; this is a cheap, harmless thing to drop at the likely seam and test. When it works, it's the difference between a workflow that OOMs at step 7 and one that just runs.