VRAM Debug

If you've ever hit an out-of-memory crash in the middle of a workflow - the first model ran fine, then the upscale or the second model tipped you over - this is the node that fixes it. VRAM_Debug is a little pressure-release valve you drop between two heavy stages. When execution reaches it, it clears the CUDA cache, runs garbage collection, and optionally kicks every model out of VRAM, then reports how much free memory you had before and after. It doesn't touch your image data at all. It's purely there to make room.

How it works

Here's the clever bit: the node passes its inputs straight through unchanged. They're not data it processes - they're triggers. Because ComfyUI executes nodes in dependency order, wiring your image or model through VRAM_Debug guarantees the cleanup happens at exactly that point in the graph, after the upstream stage finishes and before the downstream one starts. It's a way to inject a "free the memory now" command into a specific slot in an otherwise declarative graph.

Under the hood it's calling ComfyUI's own model-management and Python's garbage collector - the same things that normally happen automatically, just forced to run now instead of whenever the framework feels like it.

The inputs

Three booleans control what it does:

• empty_cache - clears PyTorch's cached CUDA allocations. On by default. This is the cheap, safe one and usually the only one you need.
• gc_collect - runs Python garbage collection. Also on by default. Cleans up objects that are holding references to GPU tensors.
• unload_all_models - off by default, and the heavy hammer. This evicts everything from VRAM, which means the next node that needs a model has to reload it from disk. Use it when you're genuinely tight and can eat the reload time; leave it off otherwise.

Then there are three passthrough slots - any_input (wildcard), image_pass (IMAGE), and model_pass (MODEL) - that come back out as any_output, image_pass, and model_pass. You wire whichever one matches what's flowing through this part of the graph, purely to anchor when the node fires. The other two outputs, freemem_before and freemem_after, are integers reporting free VRAM around the operation - handy for actually seeing whether your cleanup did anything.

Installing KJNodes

ComfyUI Manager: Custom Nodes Manager, search "KJNodes for ComfyUI", install, restart. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt (portable: python_embeded\python.exe -m pip install -r ComfyUI\custom_nodes\ComfyUI-KJNodes\requirements.txt), restart. No downloads - it's a utility node.

When it helps and when it doesn't

This is a real fix for multi-model workflows on limited VRAM: text-to-image then a separate upscaler, or two big models that don't fit at once. Slot it between them and you often clear the OOM.

What it won't do is create memory that isn't there. If a single stage doesn't fit - one model too big for your card - no amount of cache-clearing helps, because the problem isn't fragmentation, it's raw size. For that you want quantized weights (GGUF, fp8), tiling, or model offloading, not this node.

One practical note: if you turn on unload_all_models between stages that both use the same model, you've just told ComfyUI to reload it from disk for no reason. Only reach for that toggle when the next stage genuinely needs a different model and you need the room right now.