Load LLM as CLIP

The name sounds like a joke, and it's actually the point. LLMCLIPLoader (display name "Load LLM as CLIP") takes a plain HuggingFace LLM sitting in your models/LLM folder and hands it to ComfyUI as a normal CLIP object. Not a knockoff CLIP, not a text string that kind of behaves like one - a real comfy.sd.CLIP that any node wanting a CLIP socket will accept. The CLIP Text Encode you already have? It'll run your LLM instead of the checkpoint's encoder. That's the whole trick, and it's a bigger deal than it sounds.

Here's the context. The 2026-era bases - Z-Image, Klein, Chroma - don't use CLIP at all. Their text encoder is a language model (Qwen3, T5), frozen into the checkpoint. You don't install it, and you can't swap it. Most people never think about it because it just works. But if you want a different encoder - an uncensored one, a tiny one that frees up VRAM, one you actually control - you're stuck. This node is the escape hatch: load any HF LLM you can fit, and it becomes the conditioning path. Offline, free per call, no API key anywhere in the file.

How it works

Under the hood it's a proper little adapter. It loads the HF model and tokenizer from your local folder, then wraps them in a custom LLMTextEncoderComfy that feeds ComfyUI's comfy.sd.CLIP machinery. On encode it grabs the penultimate hidden state (hidden_states[-2]) - the same layer SDXL's CLIP already conditions on - masks out padding, and projects it to target_hidden_size. If your model's hidden dim doesn't match the target, it lazily creates an orthogonal projection layer on the spot, which is the classic move: you don't get a perfectly tuned encoder, you get a working one.

It also patches in a LLMTokenizerComfy subclass of ComfyUI's SD tokenizer. That's what makes enable_weights work: the (word:1.5) weight syntax and auto-chunking of very long prompts that would otherwise blow the context window.

The inputs that matter

• model_folder - a dropdown of subfolders in models/LLM. Each one must be a complete HuggingFace repo (config.json and all).
• target_hidden_size - the one that burns people. It must match what your base model's encoder expects (tooltip: Gemma-2 2B = 2304, Qwen-3 = 1024). Get it wrong and the auto-projection is randomly initialized - output will look scrambled until you set it right.
• system_prompt - baked into every encode, which is how you steer an LLM encoder without touching the graph.
• dtype - default, BF16, FP16, FP32, or FP8 if your torch supports it. FP16 is the default for good reason.
• force_offload (default on) - unloads the model to CPU between encodes. Slower first call after idle, way gentler on VRAM.
• enable_weights (default on) - the ComfyUI weight syntax and long-prompt chunking.

Output is a single CLIP, wired straight into your normal conditioning chain.

Installing and the real gotchas

Install once, share the knowledge: ComfyUI Manager → search comfyui-ez-llm - or:

cd ComfyUI/custom_nodes
git clone https://github.com/spawner1145/comfyui-ez-llm

Restart. The only real dependency is transformers + accelerate, which the pack's requirements install. Then the part the README insists on: download a full model repo from HuggingFace and drop everything into models/LLM/<name>/. The README's own example is Qwen3-0.6B-Prompt-Gen-v0.1, a tiny prompt-writing model - the right instinct. A 0.6B–3B model is plenty for rewriting prompts; you don't need a 32B reasoning monster, and it'll leak scratch-pad text into your conditioning anyway.

Gotchas worth knowing before you fight them: on cpu the node refuses anything but FP32 or default (hard error). And the (word:1.5) syntax - a core ComfyUI habit - is passed through as literal punctuation on LLM encoders unless enable_weights is on, so leave it on. Finally, remember this is arbitrary Python running on import, from the exact category that's already shipped malware once (the ComfyUI_LLMVISION incident). This pack loads only from your local folder, but read fresh nodes before running them, same as always.