GGUF Dual CLIP Loader

Flux needed two text encoders - clip-l for the CLIP half, t5xxl for the language half - and the fat one is t5. An fp16 t5xxl is right around 9.5GB of your VRAM sitting there doing nothing but tokenizing. That's the entire argument for a dual loader that reads GGUF: quantize the big encoder, keep the small one as-is, and claw back most of that memory.

What it is

The same bundled GGUF machinery as the pack's single CLIP loader (city96's ComfyUI-GGUF, Apache-2.0, adapted into py/gguf_core/), but building one CLIP object out of two files. Each path is handled independently - a .gguf goes through the GGUF reader, anything else through load_torch_file - so mixing is fine: a Q5 t5xxl GGUF next to a normal safetensors clip-l is a perfectly ordinary setup. The loaded state dicts go into ComfyUI's load_text_encoder_state_dicts together, with GGML quantization ops registered, and the result is wrapped in the pack's GGUFModelPatcher.

Because clip-l is tiny, quantizing it saves you almost nothing. The economics here are all about t5 (and its equivalents on other architectures), which is why mixing rather than quantizing everything is usually the right call.

Inputs and outputs

• clip_name1 (required) - first encoder
• clip_name2 (required) - second encoder
• type (required) - the same 12-entry list your ComfyUI's core DualCLIPLoader uses: sdxl, sd3, flux, hunyuan_video, hunyuan_image, hunyuan_video_15, hidream, kandinsky5, kandinsky5_image, ltxv, newbie, ace

Output: one CLIP. Wire it into CLIP Text Encode like any other.

Both dropdowns list regular and .gguf encoders together.

On ordering - the core node's own recipe notes say flux: clip-l, t5, sdxl: clip-l, clip-g, sd3: clip-l, clip-g / clip-l, t5 / clip-g, t5, and hunyuan_image: qwen2.5vl 7b and byt5 small. Follow the order the core node documents for your architecture; if loading fails with the pair you'd expect to work, swap the two and retry before you go looking for a deeper problem. And pick type deliberately - it's the switch that decides how the two encoders get wired together internally, and it's the field most likely to be wrong in a downloaded workflow.

Install and file placement

Manager → search Practical-Tools, or:

cd ComfyUI/custom_nodes
git clone https://github.com/wenchengxiang/ComfyUI-Practical-Tools.git

gguf is in the pack's requirements.txt; without it this file won't import and the loader simply won't exist in your menu (the pack logs [WCX Nodes Error] to the console and carries on loading everything else).

Both encoders go in the same place:

ComfyUI/models/text_encoders/    # legacy alias: models/clip/

Common issues

Scaled FP8 won't mix here. If either file contains scaled-fp8 tensors, the loader raises: "Mixing scaled FP8 with GGUF is not supported! Use regular CLIP loader or switch model(s)". Use the core dual loader for an all-fp8 pair.

Empty dropdowns. The files aren't in models/text_encoders, or you copied them in and didn't refresh. ComfyUI caches the file list and only re-checks when a folder's mtime changes, so hit refresh or restart, then re-add the node.

You wanted to load one encoder. Then this isn't your node - use the single GGUF CLIP Loader (or the core one). Feeding a single file into a dual loader with a type that expects two gives you a load error you'll spend an hour on.

Output is mush / the prompt does nothing. Check type first, then check you didn't pair, say, a clip-g with a t5 for an architecture that expects clip-l. On the LLM-encoded models, remember the CLIP-era habits don't apply either - weighting syntax like (word:1.4) is fed to the encoder as literal punctuation, and negatives are dead at CFG 1. Nothing about this loader changes that.