HuggingFace Quadruple CLIP Loader

Some models don't want two text encoders, they want four. HiDream-I1 is the big example: it conditions on a stack of CLIP-family encoders plus an actual LLM (Llama-3.1-8B) for instruction understanding. Getting all four into one ComfyUI CLIP object is exactly what HfQuadrupleClipLoader does - and like its dual and triple siblings, it reads everything straight from your Hugging Face cache or any local path, no copying files into ComfyUI's model folders.

If you're not running HiDream-I1, this node is dead weight. If you are, it's the missing piece that turns "download four checkpoints and wire them up" into "type a repo ID."

How it works

Same engine as the rest of the pack's HF loaders. Each repo_id resolves to a cached HF snapshot (or a local path), the checkpoint file is auto-detected in its subfolder (sharded checkpoints get merged from their model.index.json), and all four state dicts go into Comfy's load_text_encoder_state_dicts. Out comes one CLIP wire that feeds CLIPTextEncode like any other.

The defaults already know the HiDream layout: repo_id_1..3 point at HiDream-ai/HiDream-I1-Full with subfolders text_encoder, text_encoder_2, text_encoder_3, and the fourth (repo_id_4) defaults to meta-llama/Llama-3.1-8B-Instruct with no subfolder, since that's where the LLM lives in the repo. For the stock HiDream workflow you can leave nearly everything at default.

Inputs and outputs

Four repo_id_1..4 fields (each: HF repo ID, absolute path, or ./relative from the ComfyUI root), four optional subfolder_1..4 fields, and four optional filename_1..4 fields for when auto-detect can't decide. All four repo IDs must resolve - an empty one raises a clear "Repository ID cannot be empty" error.

Output is a single CLIP.

Installing it

It ships in Duanyll Nodepack:

cd ComfyUI/custom_nodes
git clone https://github.com/Duanyll/duanyll_nodepack

or via ComfyUI Manager ("Duanyll Nodepack"), then restart. Dependencies are the pack's usual huggingface-hub + safetensors.

Where people get burned

The same trap as every loader in this family: the node doesn't download anything despite the "Downloads a model from Hugging Face" description. It reads your HF cache and raises a FileNotFoundError telling you to run hf download <repo> first when the repo isn't there. Before you queue a HiDream run, make sure all four repos are cached - and note the Llama one is a separate repo from the HiDream one:

hf download HiDream-ai/HiDream-I1-Full
hf download meta-llama/Llama-3.1-8B-Instruct

Also brace for the size. Four encoders, one of them a 8B LLM - this loader's job is correctness, not memory efficiency. If VRAM is tight, that's not a node problem, that's a "maybe run a quantized encoder" problem. And if a folder has multiple candidate files, fill in filename or the node will refuse to guess.