CLIP Text Encode + Unload (CRT)

Text encoders have gotten big. Flux's T5-XXL alone is a meaningful chunk of VRAM on its own; LTX-2 shipped with a 12-billion-parameter Gemma 3 encoder that's over 22GB in fp16 and was, by the community's own account, the single worst source of out-of-memory errors in that model's first weeks. The workaround people reach for by hand is unloading the text encoder from VRAM right after it's done its one job, before the much bigger diffusion model needs to run. This node does that automatically, with one checkbox.

What it does

Functionally it's the same node as ComfyUI's stock CLIP Text Encode - same text input, same clip input, same conditioning output. The one addition is keep_clip_loaded, and its own tooltip explains the tradeoff plainly: keep it on and the CLIP model stays resident in VRAM after encoding, same as normal; turn it off and the encoder gets offloaded before your main model runs. If you're VRAM-constrained and running a workflow with a large text encoder - Gemma 3, T5-XXL, Krea 2's Qwen3-VL - this is a small, low-effort way to claw back headroom for the part of the pipeline that actually needs it.

The inputs and output that matter

• text (STRING, multiline) - the prompt itself, per its own tooltip: "the text to be encoded."
• clip - your CLIP/text-encoder model, wired in as usual.
• keep_clip_loaded (BOOLEAN, default true) - the one thing different from a stock text-encode node. Leave it true if VRAM isn't a concern; flip it false when you're tight on memory and the text encoder is a large one.

Output is CONDITIONING - its own tooltip is equally plain: "Conditioning containing the embedded text used to guide the diffusion model." Wire it wherever your positive (or negative) conditioning normally goes.

How to install it

Part of CRT-Nodes. Via ComfyUI Manager, search CRT-Nodes and install. Manually: git clone https://github.com/PGCRT/CRT-Nodes.git into custom_nodes, pip install -r requirements.txt, restart.

Common issues & troubleshooting

You're not actually seeing VRAM freed up. Offloading the CLIP model only frees memory that model was using - if your bottleneck is somewhere else in the graph (the diffusion model itself, a large VAE, several LoRAs stacked), this node won't move the needle much on its own. It's targeted specifically at the text-encoder-is-huge problem, not a general VRAM fix.

Re-encoding a second prompt is slower than expected. If keep_clip_loaded is off, every fresh encode has to reload the CLIP model from disk or re-initialize it before it can run - that's the cost of the tradeoff. If you're doing a lot of prompt iteration in one session and VRAM allows it, leaving it on will feel snappier between runs.

This doesn't fix an out-of-memory error that happens during sampling, not encoding. If your OOM is happening on the diffusion model itself rather than the text encoder, this node isn't the fix - look at model quantization, offloading flags on the sampler, or resolution instead.