Nodes/ComfyUI_DeleteModelPassthrough/Smart CLIP Deleter (Auto-Detect)
ComfyUI Node

Smart CLIP Deleter (Auto-Detect)

Auto-detect where your CLIP lives — VRAM or RAM — and free it there

By Isi-dev·Created about a year ago·Updated 8 months ago· 5
Smart CLIP Deleter (Auto-Detect)
  • data
  • clip_model
  • *

Here's the ComfyUI memory problem nobody warns you about: when a CLIP model is done, the memory manager doesn't necessarily drop it - it unloads it to system RAM, keeping it warm in case you need it again. That's great on a machine with 64GB of RAM, and quietly fatal on a low-RAM box where the parked CLIP fills system memory and the whole thing grinds to a halt. The Smart CLIP Deleter (Auto-Detect) looks at where the CLIP actually lives and frees it there, instead of assuming.

It's a one-trick node with a slightly different interface from the pack's delete nodes: clip_model is typed as CLIP (so the wiring is unambiguous - you can't accidentally feed it a VAE), and data is the anything-slot that rides through untouched. Out comes your data again. The mechanism is where the "smart" comes in. The node inspects the CLIP's parameters and checks their device: if they're on the GPU it treats it as a VRAM problem, sizing its free_memory() call to the model's own memory footprint; if the parameters have already been shuffled to CPU, it instead nulls out the heavy attributes (transformer, tokenizer, text model), runs gc.collect() twice, and lets Python reclaim the RAM.

The honest assessment

This is a genuinely useful idea - it's the only node in the pack that acknowledges models can be parked in RAM rather than VRAM, which is exactly the failure mode the README is built around. But it's also the least tested of the pack's nodes: no community footprint, no threads to learn from, WIP code. The device check walks the parameters until it finds one, which is fine for a standard CLIP but brittle if you feed it a wrapped or unusual object. And like every delete node, it only helps if the CLIP is truly finished - if something downstream expects it, the freed memory comes right back or the workflow errors.

The practical recommendation: if you're running a workflow where a big text encoder (a T5-XXL, say) is loaded once and never used again, place this after the last CLIP-consuming node and route your CONDITIONING through data. It pairs naturally with the pack's Delete Model (Passthrough Any) for the diffusion model itself - use the smart one for the CLIP, the regular one for the UNet, and the Light one when you want to spare your other loaded models. Install ships with the pack: ComfyUI Manager (search "DeleteModelPassthrough") or clone https://github.com/Isi-dev/ComfyUI_DeleteModelPassthrough into custom_nodes, restart. No models to download, just psutil on top of torch.

CategoryMemory Management

Inputs (2)

NameTypeDefaultDescription
data*
clip_modelCLIP

Outputs (1)

NameTypeDescription
**