VRAM Debug+
Free memory mid-workflow and see what happened
- any_input
- image_pass
- model_pass
- any_output
- image_pass
- model_pass
- freemem_before
- freemem_after
- memory_report
You're running a chunky multi-stage workflow - load a checkpoint, generate, hand off to an upscaler or a video model - and somewhere in the middle you hit an out-of-memory wall. The GPU is still holding onto stuff from the first stage that the second stage needs the room for. VRAM Debug+ is the node you drop into that seam: it clears the CUDA cache, runs garbage collection, optionally unloads all your models, and tells you exactly how much VRAM it freed. If you've used the KJNodes or rgthree "VRAM debug" node, this is the same idea with a report attached.
The clever part is how it fits into a graph. It's a passthrough. Whatever you route into it comes straight back out unchanged, so the node acts as a trigger - it fires at the point in execution where its inputs resolve, does its memory cleanup right there, and passes your data along. That lets you place the cleanup between two stages with surgical timing instead of hoping ComfyUI's automatic memory management frees things at the right moment.
How it works
ComfyUI mostly manages VRAM for you, but "mostly" is where big workflows die. VRAM Debug+ gives you a manual lever. When execution reaches it, it can empty PyTorch's CUDA cache (returns reserved-but-unused memory to the pool), run Python garbage collection (drops objects nothing references anymore), and - the nuclear option - unload every loaded model to reclaim the biggest chunk. It measures free VRAM before and after, so you get a real number for what the cleanup bought you instead of guessing.
The inputs and outputs that matter
empty_cache(default on) - clears the CUDA cache. The cheap, safe cleanup; leave it on.gc_collect(default on) - runs garbage collection. Also cheap and safe.unload_all_models(default off) - the big one. Kicks every model out of VRAM. Turn this on when you need a clean slate before a heavy next stage - but know that whatever gets unloaded has to reload when it's next used, which costs time.display_mode-SimpleorDetailed. Detailed gives you the fuller breakdown including system RAM; Simple is the quick before/after.
For placement, use the optional passthroughs: any_input (accepts anything, *), image_pass (IMAGE), and model_pass (MODEL). Route your pipeline through whichever matches, and the matching output - any_output, image_pass, or model_pass - carries it onward untouched. The two INT outputs freemem_before and freemem_after are the measured numbers, and memory_report is the human-readable string you can wire into a display node to actually read the result.
How to install it
- ComfyUI Manager - search ComfyUI-kewky_tools, install, restart.
- Manual -
cd ComfyUI/custom_nodes && git clone https://github.com/KewkLW/ComfyUI-kewky_tools.git, then restart.
Pure Python utility, no model downloads - installs and loads instantly.
Common issues & troubleshooting
It "did nothing." If your workflow was already comfortably within VRAM, there's nothing to free, and the before/after numbers will barely move. That's not a failure - it's the node telling you memory isn't your problem. The real fix for a genuine OOM is usually upstream: a quantized (GGUF) model, a smaller resolution, or fewer frames. VRAM management buys you room between stages; it doesn't shrink a model that never fit.
unload_all_models made everything slow. Expected. Unloading means reloading on next use, and reloading a big checkpoint or video model off disk isn't free. Only reach for it when you genuinely need the room for the next stage - not as a reflex on every run.
It has to actually execute to do anything. Because it works by sitting in the execution path, it only fires when something depends on its output. Wire your pipeline through it (via the passthroughs) at the point you want the cleanup - a VRAM Debug+ dangling off to the side with nothing consuming its output may never run.
System RAM isn't a substitute for VRAM. If you're leaning on this to survive a model that spills into system memory, the spill itself is the slowdown - moving weights across the PCIe bus is an order of magnitude slower than VRAM. Free what you can, but the durable fix is a model that fits.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| empty_cache | BOOLEAN | true | — |
| gc_collect | BOOLEAN | true | — |
| unload_all_models | BOOLEAN | false | — |
| display_mode | COMBO | Simple | 2 options: Simple, Detailed |
| any_inputopt | * | — | |
| image_passopt | IMAGE | — | |
| model_passopt | MODEL | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| any_output | * | — |
| image_pass | IMAGE | — |
| model_pass | MODEL | — |
| freemem_before | INT | — |
| freemem_after | INT | — |
| memory_report | STRING | — |