Load CLIP (Quadruple)
The HiDream loader that wants your whole VRAM
- CLIP
There are very few models that need four text encoders, and you're probably here because you're trying to run one of them. HiDream-I1 - the 17B MIT latent DiT from April 2025 - pairs its transformer with the whole encoder cabinet: long clip-l, long clip-g, t5xxl, and llama_8b_3.1_instruct. That's the recipe on the tin for Load CLIP (Quadruple), and it's the reason HiDream had a reputation as "best prompt adherence, too heavy to live" from week one.
Load CLIP (Quadruple) is the four-encoder member of the ComfyUI-GPUCLIP pack - the core ComfyUI QuadrupleCLIPLoader running under the pack's device handling. The pack exists because ComfyUI sometimes loads text encoders on CPU (you'll see CLIP/text encoder model load device: cpu in the console), and with four encoders on the line, CPU encoding is a proper wait. This node is the same loader you already know, but under ComfyUI's model-management patched so the encoders resolve to the GPU.
The inputs, all four of them
- clip_name1 - long clip-l
- clip_name2 - long clip-g
- clip_name3 - t5xxl (fp8 is the usual pick; GGUF T5 quants work if ComfyUI-GGUF is installed)
- clip_name4 -
llama_8b_3.1_instruct, the LLM that does most of HiDream's instruction-following
All four are dropdowns over ComfyUI/models/clip, and there's no architecture selector - this node is fixed to the HiDream recipe. Output is one CLIP object that feeds your CLIP Text Encode node exactly like any other loader's.
How it works
The pack is a slimmed-down subset of pollockjj's ComfyUI-MultiGPU. It patches comfy.model_management.get_torch_device and text_encoder_device at import, then wraps ComfyUI's core loaders. QuadrupleCLIPLoader gets the no-device-kwarg wrapper (the core load_clip here doesn't accept a device argument), so the forcing happens through the patched model-management context rather than a per-node knob. On a multi-GPU machine that means you can put the whole encoder stack somewhere that isn't the card running the sampler - genuinely the difference between "runs" and "stalls."
Install
cd ComfyUI/custom_nodes
git clone https://github.com/hum-ma/ComfyUI-GPUCLIP
then restart ComfyUI - or search "ComfyUI-GPUCLIP" in ComfyUI Manager → Install Custom Nodes. No model files to fetch; it reads what's already in models/clip. No extra pip requirements.
Where the fun stops
- This recipe is the reason HiDream needed 24GB+. Two CLIPs, T5-XXL, and an 8B Llama is a lot of resident memory before the 17B transformer even loads. The I1-era community advice was literally "QAT 4-bit the Llama, fp8 the T5, quantize the UNet as well." Quantize the LLM and the T5 first - the KB's quality ladder says the transformer is where you spend precision, and the encoder quants are where you save.
- "Quadruple" is HiDream-specific. The pack's dual loader handles Flux/SDXL pairs, and the triple loader is SD3's trio. If your workflow doesn't actually call for four encoders, you've got the wrong node.
- HiDream-O1 is not HiDream-I1. The newer 8B pixel-space model has no separate text encoders at all - no CLIP loader, no VAE loader - so this node is useless to it. Don't copy the recipe across; the KB flags these two as sharing a company and almost nothing else.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| clip_name1 | COMBO | 0 options: | |
| clip_name2 | COMBO | 0 options: | |
| clip_name3 | COMBO | 0 options: | |
| clip_name4 | COMBO | 0 options: |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | — |