DualCLIPLoaderMultiGPU

Flux needs two text encoders working together - clip-l for fine detail, T5-XXL for the actual language understanding - and it's not the only architecture that does this. DualCLIPLoaderMultiGPU is the device-aware twin of core DualCLIPLoader: it loads clip_name1 and clip_name2 together as one combined CLIP output, tagged with a type so ComfyUI knows how the pair fits together, plus a device dropdown for where the pair lives.

The recipes, straight from the node itself

Trust the node's own description over guessing - it's effectively the author's cheat sheet: sdxl → clip-l + clip-g; sd3 → pick two of clip-l, clip-g, t5 (any combination); flux → clip-l + t5; hidream → at least one of t5 or llama, both recommended; hunyuan_image → qwen2.5vl 7b + byt5 small; newbie → gemma-3-4b-it + jina clip v2. The type dropdown also covers hunyuan_video, hunyuan_video_15, kandinsky5, kandinsky5_image, ltxv, and ace.

Why offload this specifically

T5-XXL alone can run several gigabytes. Since both encoders here only fire once per prompt - not on every diffusion step - this is a genuinely low-risk place to free up VRAM: keep the UNet on your compute card, and let the encoder pair live in system RAM or on a second GPU.

The inputs and outputs that matter

• clip_name1, clip_name2 - the two encoder files.
• type - must match the actual pair you picked; see the recipes above.
• device (default cpu) - pins the combined pair, all or nothing, same pattern as the other plain MultiGPU loaders.
• Output: CLIP → your text-encode node (or the architecture-specific dual-encode node your workflow uses).

How to install it

ComfyUI Manager: search ComfyUI-MultiGPU, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/pollockjj/ComfyUI-MultiGPU

then restart. No extra dependencies.

Common issues & troubleshooting

Slot order matters less than type does. For most recipes ComfyUI resolves the pair by type internally, but stick to convention (for Flux, clip_name1 = clip-l, clip_name2 = t5xxl) to avoid surprises - and get type itself wrong and you'll get a CLIP object that loads cleanly but conditions your prompt incorrectly, which is a much harder bug to spot than a load error.

T5-XXL doesn't fit even offloaded. Grab a quantized text encoder instead of fighting this loader - fp8 and GGUF builds of T5-XXL are standard now, and the KB's own coverage of quantization notes that shrinking the text encoder specifically is a common first move on tight setups. The pack also ships DualCLIPLoaderDisTorch2MultiGPU for splitting the pair across devices rather than pinning it whole, if a quantized file isn't available for your case.

Mismatched architecture. Feeding SD3-style files into a Flux-tagged type (or vice versa) won't error cleanly - it'll just condition wrong. Double-check the pair actually matches the recipe you picked.