MultiGPU CFG Split

This is the one node in the whole advanced/multigpu family that's actually a speed trick, not a VRAM trick. Its siblings - Select Model Device, Select CLIP Device, Select VAE Device - just shuffle components around to keep your main card unclogged. This one makes two GPUs compute in parallel and can nearly halve your sampling time. If you've got a second identical GPU sitting there doing nothing, this is the node you've been missing.

The catch is in the display name, so read it before you get excited: CFG split. It doesn't shard the model the way raylight or xDiT do, and it won't make a model that doesn't fit on one card fit across two. Each GPU holds a full copy of the weights. What gets split is the work that CFG already forces your sampler to do.

How it works

Here's the background you need, and it's worth having because it explains both the promise and the limitation. When CFG is above 1, every sampling step runs the model twice - once with your prompt (conditional) and once without (unconditional) - then extrapolates between the two. Above CFG 1, "the sampler has to run the unconditional pass it was avoiding," and your render time roughly doubles. That redundant second pass is the "work unit."

MultiGPU CFG Split takes that pair of passes and hands them to different cards. It deepclones the model patcher onto up to max_gpus - 1 other devices, each clone owning independent weights on its own GPU. A persistent thread pool keeps one worker per card, calls set_torch_device() once at startup so compiled kernel caches stay warm, and the sampler's batch scheduler hands the conditional and unconditional evaluations to whichever GPU is free. It'll even reuse a clone that's already loaded instead of re-spawning it.

Inputs and outputs

Only two inputs, and you'll only ever touch one:

• model - the MODEL you want prepared. Wire it right before your KSampler.
• max_gpus (INT, default 2, min 1) - set this to the number of identical GPUs in your machine. This is the knob that matters.

Output is a single MODEL, ready for accelerated sampling. The node's own docs are clear on placement: put it between the model loader and the sampler, and if anything else hangs off the loader's output, make this the last node in that chain before sampling. Its own description adds one carve-out - it should go after nodes that modify the model object itself, like compile or attention-switch nodes. Other than those, any order works.

The honest part

Speedups of up to 1.95x have been measured in common workflows - near the theoretical ceiling, because the two passes aren't perfectly balanced. But three things gate it:

• Your CFG must be above 1. This is the big one, and it's easy to miss. Distilled workflows at CFG 1 show no benefit, per the docs. And given that most of the mainstream 2026 models are guidance-distilled and run at CFG 1 by default, this node is squarely aimed at classic SD 1.5/SDXL-style CFG workflows and non-distilled bases - LTX-2.3, WAN 2.2, SDXL, SD 3.5 Large, Flux.2 Klein base, Qwen-Image-Edit, Hunyuan - the docs list the supported set, and it's the same family.
• Your GPUs must be identical. Mixing a 4090 with a 2070 is explicitly not supported. The thread pool and the work scheduler assume homogeneous cards, Ampere or newer. If you're the person with the mismatched pair, this node isn't for you - go pin components with the Select* nodes instead.
• Each card must fit the whole model. This is parallelism, not pooling. A model that OOMs on one card will OOM on both.

No files to download - it transforms the MODEL you feed it, nothing more. It ships with ComfyUI core (landed with the rest of this family around late May 2026), so there's nothing to install. An early build could hang on a manual abort; that got fixed upstream within a week. If you want to confirm it's actually helping, watch both GPUs in Task Manager or nvidia-smi while the sampler runs - both should light up. If only one does, your CFG is probably at 1 and you've found your answer.