H3 Free Cache (empty allocator between stages)

H3 Free Cache is a passthrough node with a side effect: it empties the CUDA caching allocator (torch.cuda.empty_cache) between stages, and it hands your latent through untouched so you can drop it right before VAE decode. On the pack's own long de-rope passes this returned 17 GiB before the decoder ran. That's not a typo.

Why does a node like this need to exist? The CUDA caching allocator doesn't return memory to the driver just because tensors are freed - it keeps blocks around for reuse. Fine in general, but the pack's measured problem was specific: after a long H3 sampling pass, the VAE decode grew the pool from 69.6 to 77.9 GiB while live tensors were lower than during sampling, because decode-shaped blocks couldn't reuse sampling's freed blocks. The allocator was holding a pool of the wrong shapes. Emptying it lets the decoder grab fresh, correctly-shaped blocks instead of fighting the leftovers.

The honest math

Emptying the cache is not free lunch in the raw-VRAM sense - empty_cache is an allocation, not a deletion; the memory comes back to the driver and goes right back to the allocator when the next stage needs it. The win is the shape of what comes back, plus a few milliseconds of cost. The pack measured it as "costs a few ms; changes no math," and "17 GiB back on the long pass." For the marginal cost of one node in the graph, that's a strong deal on any card that's near the edge.

The inputs

Two, and they're almost insultingly simple: samples (the LATENT you want passed through - put the node right before your VAE Decode) and also_gc (default true, which runs gc.collect() first so dead Python references release their tensors too). The report output tells you reserved memory before → after, so you can see the refund in numbers.

The trap

Don't sprinkle it everywhere. The node's own description says "between stages," and the useful staging point is the one it was measured at: after the long sampling pass, before VAE decode. That's the spot where the pool has grown to its peak and the decoder can't reuse what's there. Putting it mid-sampling, where tensors are still actively allocating every step, buys you nothing and costs you a few ms per call. And because it's a passthrough, it can't hurt your outputs - worst case it does nothing.

Installing it

Pure-Python pack, no pip deps:

cd ComfyUI/custom_nodes
git clone https://github.com/matlowai/ComfyUI-MAINodes

Restart, look under MAINodes/VRAM Lab. The example graphs want ComfyUI-KJNodes; the nodes themselves don't. MiniMax H3 underneath - community license, US/EU/UK/South Korea excluded, so run it where you're allowed.

My honest take: on a 24 GB+ card this is probably a non-event. On a 16 GB card doing long de-ropes it's one of the first three nodes I'd add. It's a five-line idea with a well-measured payoff, and that's exactly the kind of node this pack does best.