GPUDualCLIPLoader
When your two text encoders only use one GPU
- CLIP
A huge chunk of what people actually generate runs on two text encoders at once. SDXL pairs CLIP-L with OpenCLIP-G. Flux pairs CLIP-L with T5-XXL. HiDream wants T5 and an LLM. And here's the annoying part: ComfyUI sometimes loads those encoders on CPU - the console line CLIP/text encoder model load device: cpu - and when one of them is the multi-gigabyte T5, prompt encoding turns into a tea break on every run.
GPUDualCLIPLoader is the dual-encoder member of the ComfyUI-GPUCLIP pack, a wrapper around ComfyUI's built-in DualCLIPLoader with a device input the core node doesn't expose. Its whole job: load both encoders onto the GPU you say, not the one ComfyUI picked.
How it works
Same machinery as the pack's other wrappers. The pack monkey-patches comfy.model_management.text_encoder_device at import, and GPUDualCLIPLoader is the core DualCLIPLoader subclassed with an optional device input. Set it to cuda:0, the wrapper records that as the text-encoder device, and hands the actual load to the normal path with device='default' - which ComfyUI resolves through the patched function, so both encoders land on your GPU. Output is a single CLIP object either way, so it drops into your existing graph without rework.
The inputs that matter
- clip_name1 / clip_name2 - two dropdowns over
ComfyUI/models/clip(plus.gguffiles when ComfyUI-GGUF is installed). Load CLIP-L into one, T5 or CLIP-G into the other. - type - which architecture this pair serves, straight from the core loader:
sdxl,sd3,flux,ltxv,hunyuan_video,hunyuan_image,hidream,kandinsky5,newbie,ace, and more. This is the setting beginners get wrong - the loader doesn't guess, and the wrongtypemeans the two encoders get wired up wrong. - device (optional) - the addition. A dropdown of
cpu,cuda:0,cuda:1, and whatever else ComfyUI can see (xpu, mps, directml, …), defaulting to your first GPU.
For the record: on a single-GPU box the node's practical value is "did ComfyUI pick CPU, and do I disagree?" On multi-GPU rigs it's genuinely useful - you can park the T5 on cuda:0 and leave your second card entirely free for the sampler. That's the multi-GPU lineage showing: this pack is a slimmed-down subset of pollockjj's ComfyUI-MultiGPU, and the device dropdown is the inheritance.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/hum-ma/ComfyUI-GPUCLIP
then restart ComfyUI - or search ComfyUI-GPUCLIP in ComfyUI Manager and click install. No downloads beyond that; it uses CLIPs you already have, and the only required installs are things ComfyUI ships anyway.
Common snags
- One encoder on GPU, one on CPU? If you quantized one encoder as GGUF, remember the GGUF loaders live behind a different class (GPUDualCLIPLoaderGGUF appears only when city96's ComfyUI-GGUF is installed) - grab the GGUF variant if that's your file.
- Default can cost you VRAM. The dropdown defaults to your first GPU. If ComfyUI had offloaded the encoder to CPU to fit the model, forcing both encoders to GPU can OOM. On tight cards, a Q4–Q8 encoder quant is the usual way to buy that VRAM back - the KB's VRAM ladder says Q8 is essentially fp16 at half the size, and Q4_K_M is the accepted 12GB compromise.
typecontrols everything.sdxlvsfluxvssd3are not interchangeable even when the file list looks the same. Match it to your checkpoint.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| clip_name1 | COMBO | 0 options: | |
| clip_name2 | COMBO | 0 options: | |
| type | COMBO | 12 options: sdxl, sd3, flux, hunyuan_video, hidream, hunyuan_image, +6 | |
| deviceopt | COMBO | cpu | 1 options: cpu |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | — |