GGUF QuadrupleCLIP Loader

Some models don't stop at two or three text encoders - HiDream is the clearest real-world example, wiring together CLIP-L, CLIP-G, T5, and an LLM as four separate encoder files feeding one conditioning path. GGUF QuadrupleCLIP Loader is what loads all four and combines them into a single CLIP, taking gguf or safetensors files in any of the four slots.

Why a model needs four encoders

Piling on encoders is how some architectures chase better prompt understanding and typography without redesigning the diffusion backbone - each encoder contributes a different flavor of language grounding, and the model was trained expecting all of them together. HiDream's community setup guides are the concrete case people actually run: CLIP-L and CLIP-G for the SDXL-style visual/style grounding, T5 for stronger text rendering, and a separate LLM (commonly a Llama variant) layered on top for language understanding - all four loaded together through a node exactly like this one.

Inputs and outputs

Four required inputs: clip_name1 through clip_name4. No type selector on this node - you're just handing it four files in the order your model's documented setup expects. Get the order right; a scrambled slot assignment tends to fail silently rather than error out.

One output: CLIP, wired into CLIP Text Encode exactly like any simpler encoder setup - downstream, it makes no difference that four files went into building it.

Installing it

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

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

No extra pip installs on the current version. All four encoder files go in ComfyUI/models/text_encoders.

Common issues

A specific gguf clip file doesn't get recognized. This is a real, reported problem, not a hypothetical: someone running a HiDream setup found their quantized CLIP-L and CLIP-G gguf files weren't recognized by this loader even though the node itself loaded fine. If you hit that with a particular file, try the safetensors version of just that encoder instead of the gguf one - it doesn't mean the whole setup is broken, just that one specific conversion didn't play nice.

Wrong encoder order. With no type dropdown to catch it, this is the easiest mistake to make and the hardest to notice - output won't necessarily error, it'll just be off in ways that are easy to blame on the prompt or the checkpoint instead. If you're following a community guide for a specific model (HiDream's uncensored-encoder setups being the common example), match their slot order exactly rather than guessing.

VRAM adds up fast. Four encoder files, even quantized, is real memory - this is the situation where the optional device: cpu behavior on this pack's simpler loaders would help, but note this node's schema doesn't expose that toggle itself. If you're VRAM-constrained with four encoders loaded, quantizing each file more aggressively (lower gguf tier) is your main lever here, not a device switch.

Cross-pack loader mismatches. This pack and city96's more widely used ComfyUI-GGUF are separate implementations of the same format. Mixing which pack's loader you use for which file in the same graph is a known source of friction - stick to one pack's loader family per file rather than assuming any gguf-format encoder behaves identically everywhere.

Zero search traffic on this node is honest. Four-encoder architectures are a small slice of what most people run; don't go looking for this unless your specific model's setup guide calls for exactly this node.