Free Memory

The classic out-of-memory failure is a long pipeline that dies on its last stage. You load a big model, upscale, and then - just as you reach the video encode or the final pass - ComfyUI tells you there's no room on the card. It feels like the last stage needs too much VRAM. Often it doesn't: the first stages are still resident, hogging memory you need downstream, and the only way to free them from ComfyUI's own menu is… a menu you can't reach while a queue is running.

WAS Free Memory fixes that specific pain. Drop it into the graph at the point where one heavy phase ends and the next begins, and it hands memory back to the graphics card partway through the run, between stages. The tooltip's description is the whole sales pitch: "a chain that loads, upscales and then encodes video can run out on the last stage while the first two are still resident."

How it works

The node calls the same machinery ComfyUI's free-memory menu uses - unloading loaded models and emptying torch's cache - plus a Python garbage collection pass, and reports the numbers before and after so the effect is a figure, not a guess. Three toggles decide what actually happens:

• unload_models (on) - hands every loaded checkpoint, VAE, CLIP and ControlNet back. This frees the most. They reload automatically when a node next asks for one, which costs the seconds that load originally took.
• collect_garbage (on) - runs Python's collector first so things the graph has finished with are actually handed back rather than merely marked unused. Costs a few milliseconds and makes unload worth more.
• empty_cache (on) - returns to the driver the blocks torch has reserved but isn't using. Torch reuses those blocks itself, so this rarely changes what the next sampler can fit - reach for it when another program, or a library such as OpenCV, needs room on the same card.

To pin the free to a point in the chain, wire passthrough: anything at all (an image, a model, a latent, text) comes back out unchanged once the freeing is done, and nothing wired to the output starts until the free is over. Leave it unwired and the node frees on its own.

What comes back

passthrough (the value that came in, unchanged), vram_before and vram_after (gigabytes in use when the node started and once it finished), freed (before minus after), and report - the device, the used/free/total figures on both sides and what was done, on five lines, drawn on the node and wireable to Display Any or a text save. Wire vram_after into a Compare node to stop a run that still has too little room, which is a genuinely useful guard.

Installing it and reading the fine print

WAS Node Suite v3: ComfyUI Manager → search WAS Node Suite v3, or clone into custom_nodes, restart.

Two honest caveats before you lean on it. First, it runs on every queue rather than being cached, so everything below it runs again as well - place it where that re-run is what you want. Second, unload_models means the next stage pays the reload tax; on a machine where VRAM is tight but the model fits, that tax may cost more wall-clock time than you save. And a machine with no graphics card isn't a problem - it just reports system RAM instead. The freed figure reads negative if another program grabbed memory on the same device while the node ran, which is the one "wait, that can't be right" moment - it's a real number, just a shared device.