ControlNetLoaderMultiGPU

The plain, device-pin twin of ControlNetLoaderDisTorch2MultiGPU. Same control_net_name file picker as core ComfyUI's ControlNetLoader, plus one device dropdown - no splitting, whole file, one place.

When this is the right node

ControlNet conditions generation on spatial structure - edges, depth, pose - while your prompt still decides content. Today's ControlNets skew toward large union checkpoints that bundle several condition types into one file, but plenty of workflows still use a smaller, single-condition ControlNet, or one that already comfortably fits your VRAM budget. That's this node's use case: the file's small enough that it just needs a home off your main GPU, not a partial split.

A second-GPU setup is where this earns its keep the most. If you're running a checkpoint plus a ControlNet plus a reference image, every one of those is competing for the same pool of VRAM on a single card. Moving the ControlNet to a second GPU (or, if you don't have one, to cpu) is a one-click way to give your main card's memory back to the sampling loop, without touching anything about how the ControlNet itself behaves.

The inputs and outputs that matter

• control_net_name - the ControlNet file.
• device (default cpu) - where it lives.
• 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 apply on every sampling step. Pinning one to cpu rather than a second GPU costs more in speed than pinning something that only runs once, like a VAE - test on your actual workflow before committing to that placement on anything long-running or high-step-count.

File doesn't fit anywhere you have. This node can't help with that - it's a whole-file pin. That's what ControlNetLoaderDisTorch2MultiGPU is for, splitting the file's layers across devices instead.

Check for a quantized build first. Where one exists (fp8 versions of the popular Flux and SDXL union ControlNets are increasingly common), a smaller file is often a simpler fix than any amount of device juggling.

Wrong ControlNet for your base model. This node's device setting has nothing to do with compatibility - loading an SD1.5-trained ControlNet against an SDXL or Flux checkpoint produces broken conditioning regardless of where the file sits. Match the ControlNet to your model family first, then decide where it should live.

Multiple ControlNets in one workflow. Stacking pose plus depth, or several conditions from a union checkpoint used more than once, means each ControlNetLoaderMultiGPU node makes its own independent device choice - nothing stops you from spreading them across your compute GPU, a second card, and cpu all in the same graph, if that's what your VRAM budget needs.