CLIPLoaderDisTorch2MultiGPU

Text encoders used to be small enough that you'd never think twice about where they lived. That stopped being true once models started using Llama-3.1, big Qwen-VL encoders, or gpt-oss-20b for conditioning - some of these rival mid-size diffusion UNets in file size. CLIPLoaderDisTorch2MultiGPU is the DisTorch2 sibling of CLIPLoaderMultiGPU: same clip_name and type selector, but instead of pinning the whole encoder to one device, it splits it - some layers on your compute card, the rest pushed to a donor device.

How it works

Same mechanism as the UNet DisTorch2 loader (see UNETLoaderDisTorch2MultiGPU for the full walkthrough on tuning it): virtual_vram_gb sets how much of the encoder, in gigabytes, gets pushed off compute_device onto donor_device. Bigger number, more offloaded, more VRAM left over on your card for the UNet and the actual generation.

One detail worth noticing: eject_models defaults to false here, unlike the UNet, Checkpoint, and ControlNet DisTorch2 loaders in this pack, which default to true. That tracks with how text encoders actually get used - you typically run the same one across many prompts in a session, so keeping it cached between runs instead of reloading from disk each time saves real wall-clock time. Flip it to true yourself if you're swapping encoders often and want the memory back sooner.

The inputs and outputs that matter

• clip_name, type - same as the plain loader. Trust the node's own recipe list over guessing (sd3 → t5-xxl/clip-g/clip-l, wan → umt5-xxl, hidream → llama-3.1, and so on) - get type wrong and no amount of memory tuning fixes broken conditioning.
• compute_device, virtual_vram_gb (default 4), donor_device, expert_mode_allocations - the DisTorch2 split controls.
• eject_models (default false) - as noted above.
• Output: CLIP.

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

Wrong type for the model. Same trap as the plain loader - this node's memory-splitting doesn't help you if the conditioning itself is wrong from a mismatched architecture selection.

Offloading here is more forgiving than offloading a UNet. A text encoder only runs once per prompt, not on every diffusion step, so the PCIe cost of splitting it across devices is much less noticeable than the same trick applied to a UNet. This is one of the more forgiving DisTorch2 nodes to push aggressively if you need the VRAM elsewhere.

You probably don't need this for a small CLIP file. If your model just needs plain clip-l on SD1.5, splitting buys you nothing - DisTorch2 earns its keep on the big LLM-style encoders (Llama, Qwen-VL, gpt-oss), not the small ones. Use the plain CLIPLoaderMultiGPU for those instead.