ControlNetLoaderDisTorch2MultiGPU

ControlNet conditions generation on spatial structure - edges, depth, pose - while your prompt still decides what actually appears. The union checkpoints that dominate today (xinsir's SDXL union, Shakker-Labs' FLUX ControlNet-Union-Pro) bundle support for several condition types into a single file, which makes them noticeably bigger than the single-purpose ControlNets from the SD1.5 era. ControlNetLoaderDisTorch2MultiGPU is the DisTorch2 twin of core ControlNetLoader, built for that growth: control_net_name, plus the full split-across-devices toolkit instead of a single pin.

How it works

Same pattern as the rest of the DisTorch2 family: compute_device, virtual_vram_gb (default 4), donor_device, expert_mode_allocations, eject_models (default true). Running a big union ControlNet alongside an already-tight Flux or SDXL setup is exactly the case this earns its keep - push part of the ControlNet off your compute card so the UNet and your reference image conditioning both still fit.

Before you reach for offloading at all, check whether a quantized build of your ControlNet exists - a fp8 version of Shakker-Labs' FLUX.1-dev-ControlNet-Union-Pro-2.0 runs on 12GB VRAM on its own, which means even a "big" ControlNet may have a smaller-footprint option you haven't tried yet.

When to reach for this over the plain loader

The plain ControlNetLoaderMultiGPU pins a ControlNet wholesale to one device - fine for smaller, single-condition files. This DisTorch2 version earns its place specifically when a union checkpoint's file size, plus everything else already loaded in your graph, means even the whole file doesn't fit on any one device you have available. Splitting it is what makes the difference between "doesn't fit anywhere" and "fits, at a small speed cost."

The inputs and outputs that matter

• control_net_name - the ControlNet file.
• compute_device, virtual_vram_gb, donor_device, expert_mode_allocations, eject_models - the DisTorch2 controls, as above.
• Output: CONTROL_NET → your ControlNetApply node.

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

ControlNets run every step, unlike a text encoder or VAE. A ControlNet re-applies its condition throughout the whole sampling loop, so offloading a meaningful chunk of it costs more in speed than offloading something that only fires once. Only push virtual_vram_gb as high as you actually need to fit the run.

Stacking multiple ControlNets. Pose plus depth, say - each gets its own set of DisTorch2 controls on its own node. Budget your donor device's capacity across all of them together, not just the one you're looking at.

Try a quantized build first. As above - a smaller-footprint version of the same ControlNet is often a simpler fix than tuning offload settings at all.

Weigh the speed cost against just lowering control_net's strength or resolution elsewhere. Since this component recomputes every step, an aggressive offload here is one of the more expensive DisTorch2 trades in the whole pack. If your bottleneck is really the UNet or the reference image size rather than the ControlNet file itself, look there first before pushing virtual_vram_gb up on this node.