CLIP Text Encode (with Offload)

ComfyUI's default behavior is to keep a loaded CLIP text encoder parked in VRAM after it's done encoding, on the theory that you might need it again soon. On a 8GB card - or any card running one of the new 7B-class encoders that Qwen-Image and similar workflows demand - a text encoder that just sits there is VRAM your sampler can't have. CLIP Text Encode (with Offload) is a drop-in replacement for the core CLIP Text Encode node that kicks the encoder out of VRAM (and optionally RAM) the moment the conditioning is produced.

The pitch is simple: swap it in for your regular positive and negative CLIP Text Encode nodes, and the text encoder stops being a permanent occupant of your GPU. This is the node from the pack's README that says "explicitly frees" for a reason - ComfyUI's normal memory management uses a scoring heuristic to pick what to evict, and it can't guarantee your CLIP gets unloaded. This node bypasses the heuristic and unloads the specific patcher it just used. Deterministic, not best-effort.

How it works

Encoding is identical to the stock node: tokenize, then encode_from_tokens_scheduled, and out comes your CONDITIONING. The offload happens after, and it's where the interesting code lives. It finds the LoadedModel entry in ComfyUI's loaded-models list that owns this CLIP's patcher, calls model_unload to move every weight off the GPU, removes the entry from the tracking list so future scoring won't pull it back, and empties the cache. The RAM toggle goes further: it unpins page-locked memory and, on dynamic patchers, releases staged memory so the encoder isn't holding RAM hostage either.

Because the conditioning is already computed and returned before any of this runs, offloading is safe - you're never unloading something a downstream node still needs.

The inputs that matter

• text - the prompt, multiline and dynamic-prompt aware, same as stock.
• clip - the CLIP to encode with. If you feed it a checkpoint CLIP that turns out to be None, it raises a clear error telling you the checkpoint has no usable text encoder.
• offload_from_vram (default on) - unload the encoder from GPU after encoding.
• offload_from_ram (default on) - implies VRAM offload and additionally releases pinned memory. Frees more RAM, at the cost of a slightly slower next load since the weights come back without the pinned fast path.

Output is a single CONDITIONING, wired into your sampler exactly like a normal positive/negative. That's the whole migration: replace the node, keep the wires.

Install

Search Easygoing in the ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/easygoing0114/ComfyUI-easygoing-nodes.git

Restart ComfyUI. No pip extras; needs a recent ComfyUI with the V3 node API or nothing from this pack registers.

The honest caveats

ComfyUI caches node outputs, so with the same prompt you don't re-encode and re-offload every run - the cache is what keeps this from slowing you down on repeats. But the first encode still pays the load, and after a RAM offload the next load of that encoder is measurably slower. On hardware where ComfyUI's normal retention already handles memory fine, this can be a pure tax with no benefit. The README says it plainly: performance impact depends on your hardware, test both ways. Where it shines is tight-VRAM setups that OOM during sampling after the encode stage - if that's you, this node often buys back the run.