CLIP Text Encode (Streamed LLM)

Same two inputs, same conditioning, one odd superpower

This is CLIP Text Encode. The inputs are the same, the output is the same conditioning, and the author claims bit-for-bit identical results to ComfyUI's own node. The difference is what happens under the hood: the text encoder runs layer by layer out of system RAM instead of being resident on the GPU.

There are two engines inside, chosen automatically. Anima's text encoder - Qwen3 0.6B plus the adapter that also takes t5xxl ids - gets a purpose-built streamed LLM engine; the author measured about 1.7–1.9x faster than ComfyUI's own encoder code on a Qwen2.5-VL 7B. Everything else runs ComfyUI's own encode with its layer stack streamed, the same machinery as the pack's ⚡ Text Encoder Layer Streaming node.

Why swap it in for a 0.6B encoder that fits fine? Two reasons, and one of them is quietly great. First, it costs nothing - same numbers, and it's a ready-made slot if you later move to a 7B encoder. Second, disk_cache. Turn that on and the resulting conditioning is written to disk and reinflated for the same text and the same CLIP, including across ComfyUI restarts. On a cache hit the node doesn't request its clip input at all, so if nothing else in the graph needs the CLIP, the text encoder is never loaded - no load time, no RAM, no VRAM. For a workflow where you're iterating on the same prompt through a re-roll of seeds, that's a genuinely nice trick.

How it works

The engine reads the encoder's layers from pinned host memory, two at a time, overlapping the copy with the layer's matmuls. The arithmetic is ComfyUI's own. The disk cache key is built from the text, the nodes that produced the CLIP (their inputs and model files), and your ComfyUI / PyTorch / GPU versions - which is why it stays valid across a restart but not across a PyTorch upgrade. Cache lives in <ComfyUI base>/.cache/weightferry/te_cache and is capped at 1GB; WEIGHTFERRY_TE_CACHE_GB raises it.

Inputs and outputs

• text - the prompt. Multiline, same as always.
• clip - the loaded encoder. Here's the one behavioural difference to be ready for: when disk_cache is on and hits, this input isn't pulled.
• disk_cache (optional, off by default) - cache the conditioning to disk. Off is correct while you're tuning prompts; on is correct once your prompts have settled.

One output, CONDITIONING, into your KSampler's positive or negative slot. The negative prompt matters more than usual here - Anima's defaults are 30–50 steps at CFG 4–5, so it isn't running CFG 1, and both prompts go through the encoder.

Install

Manager → search WeightFerry (registry comfyui-weightferry) → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/nyanmi-1828/ComfyUI-WeightFerry

No model downloads, no extra pip packages - the pack's requirements.txt deliberately asks for nothing beyond ComfyUI. Optional: sageattention, triton-windows. You need NVIDIA, ComfyUI 0.38.0+, and enough RAM for the encoder file.

Where it goes wrong

Caching a prompt you're still editing. Change one word and you're on a new key, so it still works - but if you're flipping settings outside the key (a different sampler, a different scheduler), you'll get an identical conditioning and wonder why nothing moved. That's expected; the key is text plus the CLIP's producers plus the environment, not the whole workflow.

Expecting it to fix a quantized encoder. It can't copy weights that aren't plain tensors. For Anima with a quantized text encoder, use CLIP Text Encode (Streamed LLM, from File) instead - that's what the model_name field on the sibling node is for.

Memory flags that fight it. If you launch ComfyUI with aggressive --lowvram style offloading on a card that could actually hold the encoder, you're paying the streaming cost for no reason. The pack's own benchmarks assume defaults; the general low-VRAM advice applies - try plain flags before stacking memory tricks.

Assuming the cache is free. The first encode still costs a full text-encoder load plus a write. The saving appears on the second run, in a workflow where the CLIP has no other consumer. If you're feeding the same CLIP into a face-detail pass, the encoder is loaded anyway and disk_cache buys you less.