H3 Evict Text Encoder (unload after encode)

H3 Evict Text Encoder is the simplest node in the VRAM Lab, and possibly the easiest free memory you'll ever grab on a small card. It unloads the text encoder the instant encoding is done - a passthrough for the conditioning with a side effect - so the encoder's VRAM is free before the DiT ever loads, instead of letting ComfyUI's planner evict it on demand.

To get a feel for the scale: on this pack's own stack the H3 text encoder sits at ~15 GB resident (21.2 GB peak on a simulated 16 GB card). That's a whole other model's worth of VRAM parked in your card while the DiT is the only thing doing work. Evicting it early is the difference between the planner juggling and the DiT just fitting.

How it works

It's two inputs, one output, one call. Give it conditioning (the encoded prompt, which it passes straight through) and clip (the CLIP patcher it needs to unload). Under the hood it calls ComfyUI's unload_model_and_clones on the clip patcher, then empties the cache - the same call another H3 tools pack (MMH3Tools) makes inside its own nodes. The report output tells you device free memory before and after, so you can see exactly what you gained.

One honest caveat: under --gpu-only mode this is a no-op, because the offload device is the GPU - there's nowhere to evict to. In normal mode it works as advertised. The node's docstring is blunt about its purpose: it exists to measure whether explicit eviction matters on a small card. The pack has measured the effect; the verdict is that on cards at the offload cliff, not streaming beats not splitting - but for the specific question of "should I evict the TE early," this node is the experiment.

Where it sits

Straightforward: encode → this node → guider. The conditioning output feeds the guider; the CLIP input is fed from the same CLIP the encode used. If you're also using H3 Conditioning Bank, think of them as complementary: the bank avoids loading the encoder at all on cache hits, and this node evicts it early on the misses where it was loaded. Both attack the same 15 GB problem from opposite ends.

It's not going to change your image quality, your seed, or your prompt adherence. It only changes how much VRAM is free when the sampling starts, and on the right card that's the difference between a run and an OOM.

Installing it

Same pack, same story:

cd ComfyUI/custom_nodes
git clone https://github.com/matlowai/ComfyUI-MAINodes

Restart, look under MAINodes/VRAM Lab. Pure Python, no pip deps, no KJNodes requirement for the nodes themselves (that's only the example graphs). MiniMax H3 underneath, community-licensed - US, EU, UK and South Korea excluded, so check your region.

If you're on a card where you've never actually hit an OOM, this node will feel pointless. It probably is, for you. On a 16 GB card running long de-ropes it's the difference between an afternoon of runs and an afternoon of restarts.