GGUF CLIP Loader

Everyone quantizes their checkpoint to fit a GPU and forgets the text encoder is often the thing actually eating the VRAM you're trying to save. GGUF CLIP Loader loads a single quantized (or plain safetensors) text-encoder file - and for VRAM-constrained setups, getting the encoder quant right matters at least as much as the model quant does.

Why it matters more than people think

Text encoders got a lot bigger once diffusion models moved off CLIP and onto general-purpose LLMs for conditioning - T5-XXL for Flux, Qwen3 for Z-Image, and so on. On something like Flux 2 Dev, the encoder alone can be as heavy as the diffusion model itself. So the encoder isn't a footnote you load once and forget; on a tight card it's frequently the file that decides whether the whole pipeline fits at all. Quantizing it with this loader is a legitimate lever, separate from whatever quant level you picked for the checkpoint.

How it works

You pick a text-encoder file and tell the node what architecture it belongs to via the type dropdown - the same mechanism ComfyUI's own built-in CLIP loader uses, just extended to accept gguf files. The type selection matters because different model families expect their text encoder handled differently (tokenization, embedding dimension, how conditioning gets shaped) - pick wrong and you won't necessarily get an error, you'll get conditioning that doesn't match what your diffusion model expects.

Inputs and outputs

• clip_name - the text-encoder file, gguf or safetensors.
• type - which architecture this encoder belongs to. The dropdown is long: stable_diffusion, stable_cascade, sd3, stable_audio, mochi, ltxv, pixart, cosmos, lumina2, wan, hidream, chroma, and more beyond those. Match it to the diffusion model you're pairing this with, not to the encoder file's name.
• device (optional, default / cpu) - pin the encoder to CPU. This one's worth actually using: text encoding runs once per prompt, not once per sampling step, so forcing it onto CPU frees up VRAM at essentially no speed cost for most workflows.

Output is a single CLIP, which wires into your positive/negative CLIP Text Encode nodes same as always.

Installing it

ComfyUI Manager: search gguf, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/calcuis/gguf

No separate pip install needed on the current version. Drop text-encoder files into ComfyUI/models/text_encoders. This is a single-encoder loader - if your model needs two, three, or four separate encoder files combined (Flux, SDXL, HiDream, etc. all pair multiple), you want this pack's DualCLIP/TripleCLIP/QuadrupleCLIP siblings instead, not this one.

Common issues

Wrong type selected. The most common mistake, and it doesn't always announce itself as an error - sometimes it just quietly produces conditioning that doesn't line up with the model, and you spend an hour blaming your prompt. Double-check against your model's family before troubleshooting anything else.

Mixing loaders across GGUF packs gets flaky. This pack and city96's much more common ComfyUI-GGUF are separate, unrelated implementations that happen to read the same file format. Real-world reports back this up: one user loading a text encoder through this pack, then trying to load the same or a related file through city96's nodes, hit an outright error citing an int64 mismatch. If a text-encoder gguf loads fine here but breaks in a different pack's loader (or vice versa), that's a known kind of friction - stick to one pack's loader family for a given file rather than assuming they're interchangeable.

Empty dropdown. File's not in text_encoders, or you added it after ComfyUI was already running - restart to pick it up.