UNETLoaderDisTorch2MultiGPU

This is the node people actually mean when they say "MultiGPU let me run a video model my card shouldn't be able to run." Same unet_name and weight_dtype as the plain loader, but instead of pinning the whole model to one device, it splits the model's layers across devices - DisTorch, "distributed torch." Some of the UNet stays on your compute card; the rest goes somewhere slower but out of the way.

How it works

The knob that matters is virtual_vram_gb (default 4, up to 128): how many gigabytes' worth of the model to push off your compute_device onto a donor_device. Bigger number, more of the model leaves your main card, more room left over for the thing that actually needs VRAM every step - latent space. Push far enough and you can offload nearly the entire model and still run compute on your GPU.

This setting confused enough people that a 27-comment thread was needed to sort it out, and the maintainer (pollockjj, posting as Silent-Adagio-444) answered it directly: "That setting is about how much of your DRAM (or if you have another video card, that card's VRAM) to use to offload the UNet model. The larger that number... the more latent space you will have available on your main card for compute." He also pointed out that ComfyUI's terminal prints a memory-budget summary at load time - model size versus available DRAM/VRAM - specifically so you can pick a sane number instead of guessing.

Is offloading free? Not quite. Community benchmarks are mixed but consistent in direction: one comparison found running fully in VRAM roughly 18% faster than pushing a meaningful chunk (20GB) to virtual VRAM on the same job; others reported multiples-slower results on heavily offloaded video models. The physics backs this up - GPU VRAM bandwidth is roughly 11x the PCIe bus, so shuttling data to system RAM is real, not imaginary, overhead. The rule of thumb: offload only as much as you need to make the run fit, not as much as the slider allows.

A hard limit worth knowing up front: this only spans devices inside one machine. It cannot bridge two separate computers - that's a different tool entirely (city96's ComfyUI_NetDist), per the maintainer's own answer in that same thread.

The inputs and outputs that matter

• unet_name, weight_dtype - same as the plain loader.
• compute_device (default cpu) - where the actual math runs.
• virtual_vram_gb (default 4) - how much to offload, as described above.
• donor_device (default cpu) - where the offloaded portion goes: system RAM, or a second GPU's VRAM.
• expert_mode_allocations - for exact per-device placement instead of one slider, using a bytes/ratio/fraction string (cuda:0,2.5gb;cpu,* style - the "bytes" mode mirrors HuggingFace's device_map and is the recommended one).
• eject_models (default true) - fully drop the model when the run ends, which makes sense for the UNet since it's the component you're most likely to swap between checkpoints.
• Output: MODEL.

How to install it

ComfyUI Manager, search ComfyUI-MultiGPU, or manually git clone it into ComfyUI/custom_nodes and restart. No extra dependencies.

Common issues & troubleshooting

Confusing compute_device and donor_device. They're two different knobs: one is where math happens, the other is where the offloaded weights sit idle between reads. Mixing them up gives you the opposite of what you wanted.

Cranking virtual_vram_gb when your system RAM is already tight. If your DRAM is close to full at current settings, raising the number further doesn't fix anything - it just moves the bottleneck instead of removing it. Watch actual RAM usage, not just the slider.

Expecting this to bridge two PCs. It won't. One machine only.

Not seeing the speedup you expected. If you're already comfortably fitting in VRAM, offloading buys you nothing but latency - dial virtual_vram_gb back toward 0 and let the model live on your card.