CLIPLoaderMultiGPU

CLIP hasn't meant just "CLIP" for a while now. Every recent architecture picked its own text encoder - T5-XXL, UMT5, Llama-3.1, Gemma, Qwen-VL - and they all load through this one node family. CLIPLoaderMultiGPU is the device-aware twin of ComfyUI's core CLIPLoader: same clip_name file picker, same type selector, plus a device dropdown that lets you park the whole thing somewhere other than your main GPU.

Why you'd bother

A diffusion UNet runs on every single step of sampling. A text encoder runs once, to turn your prompt into conditioning, and then it's done for the rest of the generation. That asymmetry makes it one of the easiest, lowest-risk things to move off your compute card: you pay one PCIe round-trip to get the conditioning back, and for the entire sampling loop afterward, that memory is free for the model that actually needs it every step.

The inputs and outputs that matter

• clip_name - the encoder file itself, from models/text_encoders or models/clip.
• type - this is the one that actually matters, and getting it wrong is the most common way to break this node silently. The node's own description doubles as a recipe cheat sheet, and it's worth trusting over guessing: sd → clip-l, stable cascade → clip-g, sd3 → t5-xxl / clip-g / clip-l, stable audio → t5 base, mochi → t5-xxl, cogvideox → t5-xxl (226-token padding), cosmos → old t5-xxl, lumina2 → gemma 2 2B, wan → umt5-xxl, hidream → llama-3.1 (recommended) or t5, omnigen2 → qwen vl 2.5 3B, lens → gpt-oss-20b, pixeldit → gemma 2 2B elm. There are 25 choices in total on the dropdown; match it to whichever family your checkpoint actually belongs to.
• device (default cpu) - where this encoder lives.
• Output: CLIP, into your text-encode node.

How to install it

Via ComfyUI Manager: search ComfyUI-MultiGPU, install, restart. Or manually:

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

then restart. No extra dependencies - it's a thin wrapper around a loader ComfyUI already ships.

Common issues & troubleshooting

Wrong type for the model. This is the trap. The encoder loads fine, gives you a CLIP object, and the run either errors deeper in the graph or - worse - produces conditioning that's just quietly wrong. The KB's own framing of what happened to text encoders explains why the list is this long: once every new base model picked a different encoder, every habit built on the old CLIP-only world stopped generalizing, and matching type to your actual model became load-bearing rather than cosmetic.

This is for one file. If your architecture wants two or three encoders together - Flux's clip-l + T5, or SD3's three-way setup - this single-file loader isn't the right node. Use DualCLIPLoaderMultiGPU or TripleCLIPLoaderDisTorch2MultiGPU instead.

A big LLM-style encoder still doesn't fit even offloaded. Llama-3.1, Qwen-VL, and similar encoders can rival mid-size diffusion models in footprint. If pinning the whole thing to cpu or a second GPU still doesn't work, don't fight this node - reach for CLIPLoaderDisTorch2MultiGPU, which splits the encoder's layers across devices instead of moving it whole, or grab a quantized (fp8 or GGUF) build of the same encoder if one exists.

Slow first prompt, then fine. If device is cpu, expect a one-time hit while the encoder loads and does its single pass. That's expected - it's not reloading on every step.