DualCLIPLoaderDisTorch2MultiGPU

If you're running Flux, SD3, or HiDream and your VRAM is getting eaten before the sampler even starts, the two text encoders these models load are a big part of why. DualCLIPLoaderDisTorch2MultiGPU is the stock ComfyUI DualCLIPLoader with a memory-placement layer bolted on: instead of the pair of CLIP/T5 files landing wherever ComfyUI feels like putting them, you tell it exactly how much to keep on your compute GPU and how much to push off to CPU RAM or a second card. It doesn't make loading faster or run anything in parallel - it just frees up VRAM on the card that's actually doing the diffusion math, which is what lets you push resolution or batch size further before you hit OOM.

Why this exists

Flux pairs CLIP-L with T5-XXL, SD3 mixes and matches CLIP-L/CLIP-G/T5 depending on the recipe, and HiDream leans on T5 and/or an 8B Llama - all bigger than the humble CLIP-L SD 1.5 got by with. None of that is free, and unlike the UNet, the text encoder only has to run once per prompt, not once per step. That asymmetry is exactly why DisTorch (the pack's offload engine, now on its v2) exists: components that are read rarely tolerate being parked somewhere slower far better than ones read every single step. Pushing the CLIP pair to CPU costs you almost nothing in wall time and buys real VRAM back for the sampler.

The inputs that matter

• clip_name1 / clip_name2 - your two text-encoder files, pulled from ComfyUI/models/clip.
• type - tells the node which recipe you're loading. The node's own tooltip spells them out: sdxl wants clip-l + clip-g; sd3 accepts clip-l+clip-g, clip-l+t5, or clip-g+t5; flux wants clip-l + t5; hidream wants at least one of t5 or llama (both recommended); hunyuan_image wants qwen2.5vl-7b + byt5-small; newbie wants gemma-3-4b-it + jina-clip-v2. There are a handful more (kandinsky5, ltxv, ace, and others) - pick the one that matches your model family, not a guess.
• device (default cpu) - where the encoder actually computes.
• virtual_vram_gb (default 4, 0–128) - how much of the model's footprint to offload to the donor device. Higher number, more freed VRAM on your compute card.
• donor_device (default cpu) - where the offloaded portion lives. Your system RAM, or another GPU's VRAM if you have one.
• expert_mode_allocations - an optional override string for splitting the model across several devices by byte count or ratio, instead of the single virtual_vram_gb slider. Most people never touch this.
• eject_models (default false) - whether to clear other models off the target device first. It's off by default here, unlike its VAE sibling - text encoders are usually small enough that this doesn't matter as much.

Output is a single CLIP, same as the vanilla loader - wire it straight into your CLIPTextEncode (or model-specific) nodes.

Installing it

Preferred route is ComfyUI Manager - search "ComfyUI-MultiGPU" and install. Manually:

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

Restart ComfyUI. No extra Python dependencies to install - it's a memory-management wrapper around nodes ComfyUI already has, not a new inference engine. The pack auto-detects what loaders you have available (core ComfyUI, plus GGUF/WanVideoWrapper/etc. if those packs are also installed) and generates the matching MultiGPU/DisTorch2 versions, all filed under the "multigpu" category.

Common issues & troubleshooting

Wrong type for your files. Loading Flux's CLIP-L/T5 pair but leaving type on sdxl (or vice versa) is the classic mismatch - the encoder expects a shape it isn't getting. Match type to the model family, not the file names.

You added a second GPU as donor_device and it's slower than CPU offload. This is a real, measured effect, not user error: on typical consumer motherboards a second GPU only gets a fraction of the PCIe lanes (the "x8/x8" split), and peer-to-peer GPU-to-GPU transfer over that is often slower than DRAM-to-VRAM through pinned CPU memory. Unless you have NVLink or a workstation board with full x16 to both slots, CPU is usually the better donor for anything that needs to move often.

No speedup from raising virtual_vram_gb. That's expected - this node trades VRAM headroom for a small latency cost, it doesn't add compute. If you were hoping for faster generation from a second GPU, that's parallelism, which this pack explicitly doesn't do.

It's not finding your other GPU as a donor_device option. DisTorch only sees devices on the same machine - it can't reach across a network. If you were hoping to borrow a second PC's card, that's a different tool (city96's ComfyUI_NetDist), not this one.