CheckpointLoaderAdvancedMultiGPU

This node sits between the two extremes in this pack. CheckpointLoaderSimpleMultiGPU pins an entire checkpoint to one device. The DisTorch2 loaders split a component's layers across devices with a slider. CheckpointLoaderAdvancedMultiGPU is the middle ground: same single-file ckpt_name checkpoint, but three separate whole-component device pins - unet_device, clip_device, vae_device - no splitting, no virtual VRAM, just "which device does each piece live on."

Why that's genuinely useful on its own

The UNet is the only piece that runs on every diffusion step, which makes it the one component you almost always want on your fastest GPU. CLIP runs once, at the start, to encode your prompt. VAE runs once, at the end, to decode. Pinning those two to cpu or a second card while keeping the UNet on your main GPU is one of the simplest, lowest-risk ways to claw back VRAM - no tuning a virtual-VRAM slider, no watching a memory summary, just three dropdowns.

It's also the node to reach for before you touch DisTorch2 at all, if your checkpoint is the older single-file SD1.5/SDXL style. A lot of people jump straight to virtual_vram_gb tuning when a much simpler move - just relocating CLIP and VAE wholesale - already buys most of the headroom they need. Try this node first; only step up to the Advanced DisTorch2 sibling once the UNet itself still doesn't fit your compute GPU on its own.

The inputs and outputs that matter

• unet_device, clip_device, vae_device - each defaults to cpu, each set independently.
• Outputs: MODEL, CLIP, VAE - same three as any checkpoint loader.

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

No splitting, ever. Each component lives fully on the device you pick - all or nothing. If your UNet alone doesn't fit your compute GPU, this node can't fix that; that's what CheckpointLoaderAdvancedDisTorch2MultiGPU exists for, with independent DisTorch2 splitting per component.

Wrong node for a split-file setup. This reads a single-file checkpoint. If you're actually running a Flux-style setup with separate UNet, CLIP, and VAE files, load them through UNETLoaderMultiGPU, CLIPLoaderMultiGPU (or DualCLIPLoaderMultiGPU), and VAELoaderMultiGPU instead - each with its own device control.

Putting CLIP or VAE on a second GPU rather than cpu. That's fine - those components run rarely, so the cross-device hop barely registers - but if your workflow does heavy img2img batching with lots of encode/decode calls, that hop adds up faster than it would on a typical text-to-image run. Watch for it if VAE-heavy work feels slower than expected.

Three dropdowns is easy to set and forget. Because there's no slider to tune and no memory summary to watch, it's tempting to set unet_device, clip_device, and vae_device once and never revisit them. If you swap in a much bigger checkpoint later, come back and re-check that the split still makes sense for the new file's proportions - a checkpoint with an unusually large text encoder relative to its UNet may want a different split than the one you tuned for last time.