ComfyUI Node

LatentGC

ComfyUI hoarding VRAM? Drop this node in and force a cleanup

By 0000111100001111·Created 2 years ago·Updated 2 years ago· 4
LatentGC
  • samples
  • LATENT

ComfyUI is actually pretty good at managing VRAM on its own - it offloads models the moment something bigger needs the space, so most people never think about it. But "pretty good" isn't "predictable." On a card with 8GB or less, you hit stages where the sampler is done, a giant upscaler or a frame-interpolation model is queued up next, and you'd rather ComfyUI drop everything now instead of when the new model bumps into an OOM. That's exactly what LatentGC is for.

It's one of those nodes whose name lies a little. It takes a latent, does nothing to it, and hands it back - the "GC" part is the entire point. On the way through, it forces a Python garbage-collection pass, unloads every model ComfyUI has in VRAM, and empties PyTorch's cache. Think of it as a checkpoint where the pipeline stops to catch its breath.

How it actually works

The source is seven lines, which is half the appeal. When the node fires it does, in order:

s = samples.copy()
gc.collect()
mm.unload_all_models()
mm.soft_empty_cache()
return (s,)

The copy is cheap and shallow - it shares the same tensor data, it just keeps a reference alive so the GC doesn't collect your latent mid-pipeline. Then gc.collect() frees unreferenced Python objects (CPU-side junk that accumulates during long runs), unload_all_models() tells ComfyUI's memory manager to free everything it tracks - checkpoint, CLIP, VAE, controlnet, the lot - and soft_empty_cache() returns PyTorch's cached-but-unused CUDA allocations to the driver. The "aggressive" in the pack name is mostly marketing: it's unload_all_models rather than unloading just one, which is the strongest level ComfyUI exposes.

The tradeoff is baked into the design: whatever the next node needs gets reloaded from disk, and that load takes real time. The author says the penalty "appears negligible" on their system - that's true when the next stage needs a different model anyway, and a lie-ish hope when you unload a checkpoint only to immediately sample with it again. Put it where the handoff genuinely matters.

The input, the output

The entire interface is one wire:

  • samples (LATENT) - the latent you're carrying between stages. Required.
  • Output: LATENT - the same latent, untouched, ready to feed the next node.

That's it. The latent category placement tells you the intended usage: splice it into the latent stream after a sampler and before the heavy node - the README's suggestion is "before/after sampler, before VFI," and tiled upscalers are the other obvious candidate.

Installing it

No dependencies, no model downloads, no config - the whole pack is two tiny files that only import stuff ComfyUI already ships. Install via ComfyUI Manager (search "LatentGC Aggressive"), or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/Raapys/ComfyUI-LatentGC_Aggressive

Then restart ComfyUI. Given the ecosystem's malware history - the whole "custom node runs arbitrary code" problem - a node this small is trivially auditable, which is genuinely reassuring here. Open nodes.py and you've read the whole thing.

Troubleshooting

The biggest gotcha isn't the node, it's expectations. LatentGC unloads models ComfyUI tracks - checkpoint, CLIP, VAE, the standard loaders. It will not pry a model loose that the live graph is still holding onto. People specifically report that IPAdapter models stay resident no matter what unload node they try, because ComfyUI just doesn't manage them the same way. If your VRAM hog isn't a tracked checkpoint, this node won't be the fix.

Other things worth knowing:

  • It won't make a model fit that doesn't fit. If the next stage alone needs more VRAM than you have, forcing an unload doesn't create memory. That's what GGUF or fp8 quantization is for.
  • ComfyUI already does this on OOM - this node is for forcing it at a chosen point, not for fixing a card that's fundamentally too small.
  • Unloading before a node that needs the same checkpoint just adds a reload. Wasteful, not harmful.

Bottom line: it's a niche utility that does one small thing well, and for 8GB survivors juggling samplers and upscalers it can be the difference between a clean run and a stuttering one.

Categorylatent

Inputs (1)

NameTypeDefaultDescription
samplesLATENT

Outputs (1)

NameTypeDescription
LATENTLATENT