Select CLIP Device
Park that huge text encoder on your idle second GPU
- clip
- CLIP
Here's the thing nobody tells you about the modern text encoder: it's a second model, and these days it's often the component that decides whether anything fits on your card at all. Flux 2 Dev pairs a 32B transformer with a 24B Mistral-3 encoder - the encoder alone is 43% of the total weight. On a dual-GPU machine, that encoder can live on the second card, leaving your main GPU's VRAM almost entirely for the diffusion model. That's exactly what this node does, and it's the built-in replacement for the whole third-party "offload the text encoder" scene.
People have searched for this. There's a thread where someone spent months fighting the ComfyUI-MultiGPU custom node to get LTX 2.3's dual text encoder onto their second GPU, only to be told "you can just use the SelectCLIPDevice node" - and their reply was the whole story: "I missed this completely." If you've got a second GPU sitting idle while your main card chokes on an encoder, this is the node.
How it works
ComfyUI figures out your GPUs at startup and builds the device dropdown for you - default, cpu, and one gpu:N per card. The node clones your CLIP object's patcher and reroutes where it loads and where it offloads:
default- hands control back to the loader, restoring the device the loader originally assigned. Useful if you wired the wrong thing or want a portable workflow to just behave.cpu- pins both the load and offload device to CPU. This actually works for CLIP (unlike VAE - more on that in its sibling's article). Prompt encoding runs once per generation, so eating CPU speed there is cheap compared to a slow sampling loop.gpu:N- pins the load device to the Nth GPU. Pick your second card.
The safety behavior is worth knowing because it's what makes shared workflows survivable: if the selected device doesn't exist on the machine that's running the workflow - say a graph built on a 2-GPU box opened on a 1-GPU box - the node passes the CLIP through unchanged and logs a message instead of hard-failing. Portable graphs don't break; they just silently run on whatever the loader chose.
Inputs and outputs
Two inputs, one output. You'll set exactly one thing:
clip- the CLIP from your checkpoint or CLIP loader.device(COMBO:default/cpu/gpu:N) - where the encoder should live.
The output is the CLIP, rewired, ready to feed into whatever encodes your prompt. That's the clip input on CLIPTextEncode (or the equivalent on the newer LLM-encoder loaders). Nothing else changes in your graph - you're just telling ComfyUI which card the encoder occupies.
When to reach for it
The rules of thumb: single GPU and it fits? Don't bother, the loader's default is already right. Single GPU and VRAM is tight? cpu is a genuinely viable lever for the encoder specifically, because encoding is a one-shot pass. Dual GPU with a modern LLM encoder? This is the node - it's the cleanest VRAM play in the family.
One honest note: the node can't fix an encoder that's too big for either card. It routes, it doesn't resize. And if you're running a distilled model where the encoder is small (Anima's Qwen3-0.6B is barely a quarter of an already-tiny model), the payoff shrinks accordingly. It ships with ComfyUI core - no install, no Manager, nothing - and landed with the rest of the multigpu family around late May 2026.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| device | COMBO | 2 options: default, cpu |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | — |