LLM CLIP Text Encode

This node is the payoff half of the ComfyUI-LLM-CLIP pack: you give it the bundle from LLM CLIP Loader plus your prompt, and it hands back real SDXL CONDITIONING that drops straight into a KSampler. Same shape as the conditioning the built-in CLIP Text Encode produces, which is the entire point - the swap is invisible to everything downstream. It's a proof-of-concept from the "I replaced CLIP with an LLM for SDXL" experiment, and it genuinely does what it says. Whether the images are better is a different question.

How it works

Two inputs, one output, no knobs. clip_bundle comes from the Loader node (it carries the 4-bit Qwen3-4B, its tokenizer, and the trained resampler), and text is a plain multiline prompt. When you hit Queue:

1. Your text is tokenized - chat-style, since Qwen is a chat model - and truncated at 256 tokens. Worth knowing: the old CLIP 77-token wall is gone, but this node still has a ceiling, and it's much friendlier than it looks.
2. Qwen runs the prompt as one coherent instruction and its last hidden state is grabbed.
3. The Perceiver-style resampler squashes that into exactly 77 vectors at 2048 dims plus a 1280-dim pooled embedding - the precise shape OpenCLIP-G feeds SDXL. That's why it wires into any SDXL graph where CLIP Text Encode used to be.
4. Out comes CONDITIONING, wired to the positive and negative inputs of your KSampler, with the standard SDXL checkpoint feeding model.

The author's own workflow does exactly this: one Loader, two of these nodes, a KSampler, and a plain CheckpointLoaderSimple (AlbedoBase XL in his case). Nothing else changes.

How to write prompts for it

This is the part that trips people up, and it's grounded in how the mechanism actually runs. Because an LLM reads your prompt as an instruction, full sentences beat comma-separated tags: "a woman standing in green grass, in golden hour" is the workflow's example. Two CLIP-era habits you should drop:

• Prompt weighting is dead. ((face:1.4)) syntax isn't implemented on LLM-encoder paths - it's a CLIP thing that never got ported, not a bug and not a setting.
• Quality-tag spam does nothing. masterpiece, best quality, 8k is SDXL vocabulary that an LLM encoder has no use for; it just burns your token budget.
• And the old long-prompt urge: LLM encoders take thousands of tokens, but attention still drifts past roughly 75-100 effective ones. State 3-5 strong concepts, subject first.

Negatives are the one thing that works better here than on modern distilled models. SDXL still runs true CFG, so the negative conditioning from this node actually steers the sampler - unlike on guidance-distilled 2026 models where negatives are inert.

Common issues

• Red node on Queue - clip_bundle is empty. The Loader has to run first; there's no self-contained fallback here.
• First encode is slow. The LLM forward pass on a 4-bit 4B model takes a few seconds, and it re-encodes every generation. You notice it after a lifetime of CLIP being instant.
• Weird or soft images. That's the POC reality, not a configuration error - the adapter was trained on 10k captions at 4-bit. If you want a quality comparison baseline, render the same prompt through a stock CLIP Text Encode and squint at the difference.
• VRAM spikes during encode. The Qwen model sits on the text-encoder device while conditioning runs, then gets freed. Tight-VRAM cards can hiccup right after the first Queue.

Installing

Same story as the Loader: ComfyUI Manager (search ComfyUI-LLM-CLIP) or clone the repo, then pip install transformers accelerate peft bitsandbytes. Remember the resampler.pth from the adapter repo goes in ComfyUI/models/text_encoders, and the first run downloads the 4-bit Qwen3-4B base from Hugging Face.

Fun to play with, educational as hell, not a daily driver. For understanding why every 2026 model dropped CLIP skip and prompt weighting, it's hard to beat actually feeling it.