Load CLIP (Triple)

Most loaders deal in one or two text encoders. SD3's triple loader has to babysit three at once: clip-l, clip-g, and the 4.7B T5-XXL that does the heavy lifting. That's a lot of model to drag through your prompt - and it's exactly the kind of load that ComfyUI will occasionally decide to run on CPU. If your SD3 generations start with a long stall while the prompt is being encoded, that's the tell.

Load CLIP (Triple) - which is what this node shows up as in the node menu, inherited from ComfyUI's core TripleCLIPLoader - is the SD3-flavoured member of the ComfyUI-GPUCLIP pack. It's the same loader you already know, but running under the pack's device handling, which patches ComfyUI's text_encoder_device at import so text encoders land on the GPU instead of wherever model management decided to put them.

How it works

The pack is a slimmed-down subset of pollockjj's ComfyUI-MultiGPU. Its wrappers subclass ComfyUI's core loaders and lean on a global patch: at import it replaces comfy.model_management.text_encoder_device (and get_torch_device) with versions that return the device the pack's machinery has been told to use. TripleCLIPLoader is wrapped by the pack's no-device-kwarg variant - the one used when the core loader's load_clip doesn't accept a device argument - and the three encoders are loaded through that patched context. The console line CLIP/text encoder model load device: cpu is the symptom this exists to kill.

The inputs, all three of them

• clip_name1 - CLIP-L (the small one, clip_l.safetensors).
• clip_name2 - CLIP-G (clip_g.safetensors).
• clip_name3 - T5-XXL (t5xxl_fp8_e4m3fn.safetensors is the usual pick; GGUF T5 quantizations work too if you have ComfyUI-GGUF installed).

Each is a dropdown over ComfyUI/models/clip. The output is a single CLIP object - same shape as any other loader's output, so it plugs into your existing CLIP Text Encode node and your workflow doesn't change. There's no architecture dropdown here: unlike the dual loader, this node is fixed to the sd3 encoder trio, so the recipe is the one shown in the brief: sd3: clip-l, clip-g, t5.

Worth knowing, and a good reason this node exists at all: the SD3 paper itself found you can drop T5 at inference for a big memory saving at a mostly-typographic quality cost. If you're on a tight card, a smaller or quantized third encoder is the standard VRAM lever - but when you do run all three, you want them fast, which is the whole point of the GPUCLIP pack.

Install

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

then restart ComfyUI - or use ComfyUI Manager → Install Custom Nodes → search "ComfyUI-GPUCLIP". No model downloads (it uses CLIPs already in your models/clip folder) and no extra pip requirements beyond what ComfyUI ships.

Gotchas

• FP8 or GGUF T5 to keep it sane. Three encoders on the GPU is fine on a 16GB+ card; on 8–12GB the T5 alone can be the difference between fitting and OOM. FP8 T5 is the common middle ground, and the GGUF T5 quantizations (Q4–Q8) go even further. The KB's ladder: Q8 is basically fp16 at half the size; Q4_K_M is the accepted squeeze.
• "Triple" here means SD3's trio, always. The dual loader handles the Flux/XL pairs; this one is specifically the SD3 recipe. If your workflow asks for a fourth encoder, you want the pack's quadruple variant instead.
• The patch is session-wide. Because the device forcing happens through patched ComfyUI internals, it affects how other nodes in the graph resolve devices too - not a bug, just the mechanism.