PurgeVRAMNode

This is the node people reach for when a workflow runs fine once and then OOMs on the second pass. It doesn't generate anything, doesn't touch your image - its entire job is to clear VRAM (and optionally unload models) at a specific point in your graph, so whatever runs next starts with a clean slate instead of inheriting a session's worth of leftover allocations.

How it works

PurgeVRAMNode isn't unique to tbox as an idea - it's a whole genre. rgthree-comfy's Power Puter has a built-in purge_vram option, and people building long Wan 2.2 video workflows routinely chain several purge/clean-VRAM nodes through a graph, one "behind each KSampler," specifically to stop memory from accumulating across a multi-stage pipeline. tbox's version is the same idea in its own node.

The mechanism is a bit clever given how ComfyUI schedules execution: it accepts literally anything as input, purely so the graph has a data dependency forcing it to run after whatever you plugged into it finishes. You wire your KSampler's output (or any other node's output) into anything, the purge runs once that upstream node completes, and because ComfyUI lets one output feed multiple consumers, the same data can also keep flowing to your actual pipeline in parallel. It's a side-effect node bolted onto the execution order, not a real transformation.

The inputs and outputs that matter

• anything (required, wildcard type) - plug in anything at all. The value itself doesn't matter; it only exists to sequence the purge after that node runs.
• purge_cache (BOOLEAN, default true) - clears general caches.
• purge_models (BOOLEAN, default true) - actually unloads models from VRAM, not just cache. This is the heavier of the two flags: it frees the most memory but means the next model you use has to reload from disk.

No outputs. It's an output node - always executes even though nothing downstream consumes it - and there's nowhere to wire it forward, because there's nothing coming back out.

How to install it

Via ComfyUI Manager: search ComfyUI-tbox, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ai-shizuka/ComfyUI-tbox

then restart. This one needs no extra models or heavy dependencies - it's pure memory management, no downloads involved, which makes it one of the safest tbox nodes to just drop in and try.

Common issues & troubleshooting

VRAM still climbs even with this wired in. Placement matters more than presence. Put it right after the thing you actually want freed - after a VAE decode, right after a KSampler that's done its job - not tacked onto the very end of the graph where the damage is already done.

Everything's noticeably slower after adding it. That's purge_models doing its job a little too well: forcing a model unload means the next node that needs that model pays a full reload cost. If you're purging between two stages that reuse the same model, try leaving purge_models off and only clearing cache, or accept the reload time as the price of not OOMing.

Wiring in more than one of these feels excessive. It isn't - this is exactly how people run it in practice, one purge behind each heavy stage in a long video pipeline, not a single purge at the very end.

Still OOMing even with aggressive purging. A purge node buys you back memory between stages; it doesn't shrink the model itself. If you're still hitting the ceiling, that's a sign to look at quantized (GGUF) checkpoints or offload techniques like BlockSwap before adding more purge nodes - this one is a mop, not a bigger bucket.