GPUCLIPLoader

You can be burning along at 20 it/s through the sampler and still watch every generation stall for seconds before the denoise even starts, because the text encoder ran on your CPU. The text encoder is a whole second model that turns your prompt into conditioning vectors before the diffusion model gets a look at it - and on modern models it's no longer a rounding error. On Flux 2 Dev the encoder is 24B of a 56B total. It's the thing that eats your prompt, and when ComfyUI decides to host it in RAM instead of VRAM, it eats it slowly.

GPUCLIPLoader is the flagship node of the small ComfyUI-GPUCLIP pack: a drop-in wrapper around ComfyUI's built-in Load CLIP node that adds one thing it doesn't have - a device input. The pack README states the problem flat: "ComfyUI sometimes loads text encoders on CPU for various reasons." This node loads them onto GPU, and prompt encoding stops being the bottleneck.

How it works

At import, the pack monkey-patches comfy.model_management.get_torch_device and text_encoder_device so that whatever device you pick becomes what ComfyUI's model management reports back. GPUCLIPLoader is then a subclass of the core CLIPLoader with an optional device input bolted on. Pick cuda:0, and the wrapper sets that as the current text-encoder device before handing off to the normal loader with device='default' - meaning "use ComfyUI's own device logic," which now resolves to your GPU.

The tell that you need this: the console prints CLIP/text encoder model load device: cpu. If you see that line and encoding takes forever, this node (or its relatives) is the fix.

The inputs that matter

• clip_name - a dropdown of everything in ComfyUI/models/clip (and clip_gguf if ComfyUI-GGUF is installed). Pick the encoder your model needs.
• type - the encoder role, matching the core Load CLIP list: stable_diffusion for clip-l, sdxl-era encoders, sd3, wan (umt5 xxl), mochi (t5 xxl), cosmos, hidream (llama-3.1 or t5), and a couple dozen more. Get this wrong and conditioning silently misbehaves.
• device (optional) - the new bit. A dropdown of every device ComfyUI can see: cpu first, then cuda:0, cuda:1, and so on, plus xpu/npu/mps/directml if you run those. Defaults to your first GPU when one exists.

Output is a single CLIP object - wire it to your CLIP Text Encode node exactly like you would the core loader.

Install

Two ways, same result:

cd ComfyUI/custom_nodes
git clone https://github.com/hum-ma/ComfyUI-GPUCLIP

then restart ComfyUI. Or, easier: open ComfyUI Manager → Install Custom Nodes, search "ComfyUI-GPUCLIP", and install from there. No model files to download - it reads whatever CLIPs you already have. There are no heavy pip dependencies; the pack only probes for optional backends (IPEX, torch_npu, and so on) and ignores the ones you don't have.

Where people get burned

• You can OOM by "fixing" this. If ComfyUI put the text encoder on CPU deliberately - usually a low-VRAM setup with a big fp8/GGUF encoder - shoving it onto the GPU can push you past what the card holds. If forcing the device makes it crash, drop to a quantized encoder (GGUF Q4–Q8 is the usual lever) or let it stay on CPU.
• The patch is global. It affects the whole ComfyUI session, not just this node. A device you set here is what text_encoder_device() reports until something else changes it.
• GGUF encoders need the sibling pack. With ComfyUI-GGUF installed, GPUCLIPLoader gains a GPUCLIPLoaderGGUF variant that merges .gguf encoder files into the dropdown and gives them the same device control - which is exactly the case the author recommends the pack for in the wild.