Nodes/ComfyUI-MultiGPU/UNETLoaderMultiGPU
ComfyUI Node

UNETLoaderMultiGPU

Pin a UNet-only checkpoint to any device you've got

By pollockjj·Created 2 years ago·Updated 3 months ago· 925
UNETLoaderMultiGPU
    • MODEL
    unet_name
    weight_dtype
    devicecpu

    If you've moved past SD1.5-era single-file checkpoints, you already know the drill for anything Flux-shaped: the diffusion weights come as their own file, separate from the text encoder and the VAE. UNETLoaderMultiGPU is exactly ComfyUI's built-in UNETLoader node - same file picker, same precision options - with one thing bolted on: a device dropdown. Point it at a second GPU, or at your CPU, and that UNet loads there instead of automatically landing on your main card.

    Why this exists

    The pack's own framing, straight from its footnote, is worth repeating because it sets expectations correctly: this enhances memory management, not parallel processing. Your workflow still runs sequentially, one step at a time. What changes is where things sit while they're not actively computing. Keep the UNet off your compute card and you get that VRAM back for the thing that actually benefits from more of it - bigger latents, longer video, more headroom before you hit an out-of-memory error.

    Worth knowing before you dig in: this pack has a real history. It started as Alexander Dzhoganov's experiment, got a substantial rebuild by City96 (the same person behind ComfyUI-GGUF) in late 2024, and is now maintained by pollockjj. The original relaunch post on r/comfyui was refreshingly candid about what this actually is - "monkey patches the memory management of ComfyUI in a hacky way," "neither a comprehensive solution nor a well-tested one. Use at your own risk." It's grown up a lot since then into the DisTorch2 system this pack now ships, but that honesty is useful context: it's a genuinely useful, actively-maintained tool, not a polished first-party feature - test it on your actual workflow before trusting it blind.

    The inputs and outputs that matter

    • unet_name - whatever's sitting in your models/diffusion_models (or unet) folder: a Flux UNet, a Qwen-Image diffusion file, anything shipped as a standalone weights file rather than a bundled checkpoint.
    • weight_dtype - default, fp8_e4m3fn, fp8_e4m3fn_fast, or fp8_e5m2. These are the fp8 casts: half the VRAM of fp16 for close-to-invisible quality loss, and the community's settled default for Flux-class models on 12–24GB cards. e4m3fn is the variant ComfyUI natively accelerates on RTX 40-series and newer. If your download is already fp8, match it here rather than double-casting.
    • device (default cpu) - where this component lives. A second GPU index if you have one; cpu (system RAM) if you don't.
    • Output: MODEL, straight into your sampler or wherever a UNet output normally plugs in.

    How to install it

    ComfyUI Manager is the preferred path per the README: search ComfyUI-MultiGPU, install, restart. Manual works just as well:

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

    Restart ComfyUI. No extra Python dependencies to chase down and nothing to download for the node itself - it wraps a loader you already have, it doesn't add new model requirements.

    Common issues & troubleshooting

    It's all-or-nothing. This node pins the whole UNet to one device. If it doesn't fit there - say, your GPU is already tight and cpu means "slow but everything" - you don't want this node, you want its sibling, UNETLoaderDisTorch2MultiGPU, which splits the model's layers across devices instead of moving the entire thing.

    Two GPUs ≠ 2x speed. Because there's no parallelism here, adding a second card doesn't make generation faster on its own. The win is capacity: things that couldn't run at all now fit, or run at a bigger batch/resolution/frame count than before.

    cpu is genuinely slower, not just theoretically. Every step that touches this component now crosses the PCIe bus instead of staying in fast GPU memory. For a UNet - the thing that runs on every diffusion step - that cost is real if you're compute-bound rather than VRAM-bound. If your card can hold it, keep it there; reach for cpu when the alternative is not running at all.

    Precision mismatch. Loading an already-quantized file with the wrong weight_dtype (or default when the file expects a specific cast) can waste the VRAM savings you downloaded the file for in the first place - check the model card for what precision it actually ships in.

    Categorymultigpu

    Inputs (3)

    NameTypeDefaultDescription
    unet_nameCOMBO0 options:
    weight_dtypeCOMBO4 options: default, fp8_e4m3fn, fp8_e4m3fn_fast, fp8_e5m2
    deviceoptCOMBOcpu1 options: cpu

    Outputs (1)

    NameTypeDescription
    MODELMODEL