CLIPVisionLoaderMultiGPU

The plain, device-pin version of CLIPVisionLoaderDisTorch2MultiGPU. CLIP Vision models power IP-Adapter-style "use this image as a reference" workflows and anything else that needs a reference photo turned into embeddings the diffusion model can attend to. This node is the device-aware twin of core ComfyUI's CLIPVisionLoader - same clip_name file picker, one device dropdown, no splitting.

When to reach for it

If you're already running a big checkpoint that's eating most of your VRAM, and you're adding IP-Adapter-style reference-image conditioning on top, the CLIP Vision encoder is a good candidate to move out of the way entirely. It only processes reference images - it doesn't run on every diffusion step - so pinning it to cpu or a second GPU costs you almost nothing in practice while freeing up whatever headroom it would otherwise take on your compute card.

This is also the node you reach for before you'd ever need the DisTorch2 version. CLIP Vision encoders are generally modest files - nowhere near the size of a UNet or a modern LLM-style text encoder - so a plain whole-file device pin is usually all the control you need. Save the split-across-devices version for the rare case where even that doesn't fit.

The inputs and outputs that matter

• clip_name - the CLIP Vision file specifically, not a text-CLIP file. They live in different model folders and aren't interchangeable despite the similar node naming.
• device (default cpu) - where the encoder lives.
• Output: CLIP_VISION.

How to install it

ComfyUI Manager: search ComfyUI-MultiGPU, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/pollockjj/ComfyUI-MultiGPU

then restart. No extra dependencies.

Common issues & troubleshooting

All-or-nothing device pin. If the file's too big for wherever you place it, that's what CLIPVisionLoaderDisTorch2MultiGPU (splitting) is for - though in practice CLIP Vision files are rarely the reason a workflow runs out of VRAM in the first place.

Wrong file type. This loads CLIP Vision weights specifically. Pointing it at a regular text-CLIP file won't work - check you're browsing the right model folder.

No second GPU? cpu is a perfectly reasonable placement here, precisely because this encoder only runs occasionally rather than on every step - you won't feel the PCIe cost the way you would offloading a UNet.

Adapter output looks wrong, not just slow. If your IP-Adapter results degrade rather than merely run slower, that's not a device-placement issue - it's almost always a mismatch between the CLIP Vision model and whatever adapter or workflow expects it. Check that you've got the specific vision encoder your adapter was built against before troubleshooting placement further.

Loading several reference images per run. If your workflow processes multiple reference images through the same CLIP Vision encoder in one session, the encoder itself only needs to load once - it's the per-image embedding pass that repeats. Placement only affects that one-time load and each embedding call, not anything else in your graph, so this node's overhead stays flat regardless of how many reference images you throw at it.