Nodes/ComfyUI-GPUCLIP/GPUDualCLIPLoader
ComfyUI Node

GPUDualCLIPLoader

When your two text encoders only use one GPU

By hum-ma·Created 7 months ago·Updated 7 months ago· 1
GPUDualCLIPLoader
    • CLIP
    clip_name1
    clip_name2
    type
    devicecpu

    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 .gguf files 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 wrong type means 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.
    • type controls everything. sdxl vs flux vs sd3 are not interchangeable even when the file list looks the same. Match it to your checkpoint.
    CategoryGPUCLIP

    Inputs (4)

    NameTypeDefaultDescription
    clip_name1COMBO0 options:
    clip_name2COMBO0 options:
    typeCOMBO12 options: sdxl, sd3, flux, hunyuan_video, hidream, hunyuan_image, +6
    deviceoptCOMBOcpu1 options: cpu

    Outputs (1)

    NameTypeDescription
    CLIPCLIP