AutoMultiGPU - PyTorch Engine (Native Device Split)

Between the pack's three engines, this is the one I'd actually reach for. The PyTorch Engine doesn't shard layers and it doesn't try to be clever - it just loads the UNet onto GPU0 and the text encoders and VAE onto GPU1, using ComfyUI's own native loading calls. That "boring" is the whole appeal: no layer patching, no external sharding pack required, so LoRAs and ControlNets behave exactly as they do in a stock workflow. The README's claim of "100% stability and zero OOM" is overselling, but the stability part is legitimately the strongest in the pack.

You use this when you have two GPUs and a model that almost fits, and the pressure point is the encoders or the VAE, not the UNet itself. Move the T5 and the VAE off the main card and suddenly the sampler has the whole card. That's a real win for FLUX-class workflows, and it's why this engine is the safe default of the trio.

How it works

It reads your diffusion_models/unet folders (plus GGUF), the text encoder folders, and the VAE folder, then loads each piece with explicit load_device targeting. clip_device and vae_device default to cuda:1; model_type picks the right ComfyUI CLIPType (37 architectures, auto guesses from the filename). The cpu_offload_mode dropdown sets offload behavior: always_offload_to_cpu (default, weights sit in RAM when idle), keep_in_vram, or comfy_default. The optional weight_dtype handles fp8 (fp8_e4m3fn, fp8_e5m2, fast variants) and plain fp16/bf16/fp32 casting.

The inputs that matter

unet_name, clip_name1, clip_name2, vae_name, model_type, then the two device pickers clip_device and vae_device. That's the whole layout. Outputs: MODEL, CLIP, VAE, wired to your sampler and decoder exactly like a stock loader.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/nexusfinancial-dev/ComfyUI-AutoMultiGPU.git
cd ComfyUI-AutoMultiGPU
pip install -r requirements.txt

No extra packs needed for the safetensors path - that's the point. GGUF files still require ComfyUI-GGUF; the pack's README won't tell you that, but the code will refuse to load .gguf without it.

Where people get burned

Manage the "zero OOM" expectation: this engine splits components, not the model. If your UNet itself exceeds one card's VRAM, the PyTorch engine can't save you - that's DisTorch's job, or quantization's. Also, don't expect a speedup from owning two cards; you get capacity and headroom, not raw throughput. The second card is doing encode/decode work while the first samples, which is parallel-ish, but PCIe bandwidth on a typical consumer board still governs how fast the pieces can talk. And if you're on a single-GPU machine, this is a stock loader wearing a bigger shirt - the default cuda:1 targets just fall back.