Nodes/ComfyUI-FreeMemory/Free Memory (CLIP)
ComfyUI Node

Free Memory (CLIP)

Clearing VRAM between text-encoder swaps

By ShmuelRonen·Created 2 years ago·Updated about a year ago· 144
Free Memory (CLIP)
  • clip
  • CLIP
aggressivefalse

Most single-checkpoint workflows never need this node - ComfyUI already loads and evicts the CLIP text encoder on its own. Where Free Memory (CLIP) earns its keep is the busier graphs: SDXL's dual-CLIP setups, prompt-comparison loops that re-encode dozens of prompts in a row, or workflows that hop between checkpoints with different text encoders. In those cases you sometimes want the encoder's VRAM back at a specific point rather than whenever ComfyUI's own bookkeeping decides to release it.

What it does

It's one of five nearly-identical nodes in this pack (Model, CLIP, Latent, Image, String), all built on the same trick: take a typed input, run a memory cleanup as a side effect, hand the same data back out unchanged. For CLIP specifically, that means your CLIP object passes through untouched - the node isn't touching the encoder's weights, it's clearing the memory around it.

Standard mode runs torch.cuda.empty_cache() for VRAM and gc.collect() for system RAM - cheap, safe, no side effects beyond releasing memory PyTorch was holding but not using. Set aggressive to True and it goes further: comfy.model_management.unload_all_models() plus a soft cache empty before the CUDA clear, which drops every model ComfyUI currently has loaded, not just this CLIP. On Linux that also means flushing pagecache and dentries (which may need elevated privileges to fully take effect); on Windows it trims the process's working set via the Win32 API. The node logs memory usage before and after so the effect isn't invisible.

The inputs and outputs that matter

  • clip - the CLIP model you're routing through. Required.
  • aggressive - boolean, False by default. Standard clears CUDA's unused cache; aggressive unloads everything currently loaded, GPU-wide.

Output is a single CLIP, identical to the input. Wire it straight back into whatever consumes it next - typically a CLIPTextEncode node, or onward into your conditioning chain.

Installing it

ComfyUI Manager: search ComfyUI-FreeMemory, install, restart. Manual install:

cd ComfyUI/custom_nodes
git clone https://github.com/ShmuelRonen/ComfyUI-FreeMemory
pip install psutil

Restart ComfyUI. psutil is the only dependency - no model weights to download, and installing the repo gives you all five FreeMemory nodes at once.

Where people get burned

The thing worth internalizing before you drop this everywhere: aggressive mode is a full reset, not a targeted one. It unloads every model ComfyUI has cached - your checkpoint, VAE, ControlNets, all of it - because unload_all_models() doesn't know or care that you only asked to clear the CLIP node. The next step in your graph then has to reload from scratch, which can easily cost you more time than the cleanup saved. This mirrors a pattern seen across low-VRAM tooling generally: people reach for the aggressive flag reflexively "just in case," and end up paying a reload tax on a workflow that would've run fine without it. Save aggressive mode for genuine OOM situations or real checkpoint-swap boundaries - a comparison loop testing many prompts against one loaded CLIP, for instance - not for a single linear text-to-image graph.

Also worth knowing: this clears caches, it doesn't fix leaks. If your VRAM usage keeps climbing across a batch even with this node wired in, the leak is somewhere else in the graph - a custom node not releasing tensors properly - and no cache-empty downstream will patch that. And because it reaches into comfy.model_management directly, a ComfyUI core update that renames or removes an internal function can break it; if you update and it suddenly throws an attribute error, that's why.

CategoryMemory Management

Inputs (2)

NameTypeDefaultDescription
clipCLIP
aggressiveBOOLEANfalse

Outputs (1)

NameTypeDescription
CLIPCLIP