ComfyUI runs each model on one GPU, and two GPUs do not pool their memory for one model. What a second GPU buys depends on the job. The simplest use is a second ComfyUI on the second card, each on its own port, which doubles how many jobs run at once. Since v0.23.0, ComfyUI itself can also place the text encoder, VAE and diffusion model on different GPUs, and split one sampling job across GPUs when the workflow uses CFG above 1, with a full copy of the model on each card. Custom nodes go further: ComfyUI-Distributed spreads seeds and tiles over workers, and Raylight splits one image or video across GPUs. The custom node that shares its name with the search, ComfyUI-MultiGPU, was archived on 30 September 2026.
What ComfyUI does with two GPUs on its own#
The honest answer used to be "nothing": ComfyUI picked one GPU and left the rest idle. Three things changed in ComfyUI v0.23.0, released on 1 June 2026.
| Feature | What it does | What it does not do |
|---|---|---|
--cuda-device | Chooses which GPUs one ComfyUI process sees: 0, 1, 0,1 or all. On Linux every GPU is visible by default, while Windows defaults to the first GPU | Spread work by itself |
| Select Model Device, Select CLIP Device, Select VAE Device | Put the diffusion model, the text encoder or the VAE on a chosen GPU, gpu:0, gpu:1 and so on | Split one model across two GPUs |
| MultiGPU CFG Split | Copies the model to each extra GPU and runs the positive and negative passes of each step on different GPUs at the same time | Help at CFG 1, where ComfyUI runs no negative pass, so there is nothing to split |
The CFG split comes with its author's own numbers: 1.85x faster for Wan 2.1 1.3B and 1.89x for Wan 14B on two RTX 4090s against one, in the pull request that added it. Its limits are just as clear in the same text. It needs a model that uses more than one conditioning, it works best when the GPUs are the same model, and on a lightly loaded GPU the work of splitting and combining makes it slower than one card. Every GPU holds a full copy of the model, so memory does not add up. Workflows with CFG above 1 include Wan 2.2's TI2V-5B template at CFG 5, Qwen-Image-Edit-2511 at its default 40 steps and Z-Image Base. Distilled and turbo setups run at CFG 1 and gain nothing: FLUX.1 [schnell], Z-Image Turbo, and Wan 2.2's 14B templates, which ship with a 4-step lightx2v LoRA.
The device nodes are the native answer to a model and its text encoder that do not fit one card together. FLUX.2 [dev] as ComfyUI ships it is a 33.02 GiB diffusion model and a 33.14 GiB text encoder (our calculation): too much for one 48 GB card at once, while each half fits the 41.39 GiB budget of its own card. Select CLIP Device set to gpu:1 keeps the text encoder on the second card, so neither half has to be swapped out between prompts.
The custom nodes, and where they stand#
The custom nodes fill the gap between "one model per GPU" and "one job across GPUs", and their state matters more than their feature lists.
| Project | Maintainer and state | What it does with several GPUs |
|---|---|---|
| ComfyUI-MultiGPU | pollockjj. Archived on 30 September 2026, final version 2.6.4 from May 2026, GPL-3.0. No fork is endorsed | Places models, or parts of them with its DisTorch nodes, on other GPUs or in system RAM. Its README says this "enhances memory management, not parallel processing" |
| ComfyUI-Distributed | robertvoy. Version 1.7.0, 1 November 2026, Apache-2.0 | Runs the same workflow on every GPU with different seeds and collects the results, splits Ultimate SD Upscale tiles across GPUs, and works through image lists in parallel |
| Raylight | komikndr. Version 1.11.0, 4 November 2026, Apache-2.0 | Splits one image or video across GPUs with sequence parallelism, can shard the weights with FSDP, and runs CFG in parallel, for Wan, FLUX, Qwen-Image, Z-Image, Hunyuan, LTX-2 and more |
ComfyUI-MultiGPU is the one to move off. Its maintainer's last note points out that ComfyUI core now has device placement and Dynamic VRAM offloading, and says those are not a replacement for every one of its workflows. A pinned issue lists forks, with no designated successor. city96's ComfyUI_NetDist, an older project for the same job, has had no commit since February 2024.
Raylight is the one that splits the sampling of a single image or video across GPUs. Its own benchmark ran Flux in FP8 at 1024 by 1024 at 2.22 seconds per step on one RTX 2000 Ada and 1.26 on two. Each GPU still loads the full model in its sequence-parallel mode, so it needs FSDP to fit a model that one card cannot hold, and its README warns that the GPU topology matters. On QuantaCloud's multi-GPU VMs, check the link between the cards before you count on it:
nvidia-smi topo -m
ComfyUI-Distributed is the practical choice for batches of images or clips, because each worker is a whole ComfyUI on its own GPU. Its local workers run on the same machine, each on its own port. Remote workers are another matter: its guide starts them with --listen --enable-cors-header, which puts an unauthenticated ComfyUI on the network and replaces ComfyUI's own origin check, so keep any worker on another machine behind an SSH tunnel.
Run one ComfyUI per GPU#
The most reliable setup is one ComfyUI process per GPU, each on its own port. QuantaCloud's ComfyUI template starts one ComfyUI in one container on port 8188, so this uses your own install on the Bare Metal template. Launch a 2-GPU VM, install ComfyUI with comfy-cli as in running ComfyUI on a cloud GPU, and connect over SSH as ubuntu.
- Start one instance per GPU.
--cuda-devicemakes each process see only its own card, and each gets its own output and temp folder, because ComfyUI deletes its temp folder at startup and a second instance would otherwise wipe the first one's previews:
source ~/comfy-venv/bin/activate
cd ~/comfy/ComfyUI
for i in 0 1; do
mkdir -p ~/gpu$i
nohup python main.py --cuda-device $i --port $((8188 + i)) \
--output-directory ~/gpu$i/output --temp-directory ~/gpu$i \
> ~/gpu$i/comfyui.log 2>&1 &
done
- Check that both answer, each with one GPU:
curl -s http://127.0.0.1:8188/system_stats | python3 -c 'import json, sys; print([d["name"] for d in json.load(sys.stdin)["devices"]])'
curl -s http://127.0.0.1:8189/system_stats | python3 -c 'import json, sys; print([d["name"] for d in json.load(sys.stdin)["devices"]])'
- From your own machine, open one tunnel with both ports, then browse to http://127.0.0.1:8188 and http://127.0.0.1:8189:
ssh -N -L 8188:127.0.0.1:8188 -L 8189:127.0.0.1:8189 ubuntu@<instance-ip>
Both instances read the same models folder, so you download each model once. Both bind 127.0.0.1, because ComfyUI has no authentication and the tunnel is the safe way in. For the native multi-GPU nodes instead, start a single instance with python main.py --cuda-device 0,1, add MultiGPU CFG Split after the model loader with max_gpus set to 2, or use the Select Device nodes from the advanced/multigpu category.
Two 48 GB cards or one 96 GB card#
The choice that matters when you rent is whether your job needs more memory in one place or more jobs at once. A model cannot use the memory of two cards as one pool in plain ComfyUI, so a workflow that does not fit 48 GB wants the 96 GB card. Language models are a different case, because vLLM and llama.cpp do split one model across cards: the GPUs with the most VRAM shows when several smaller cards can stand in for one large one.
| Workload | Better choice | Why |
|---|---|---|
| A model that fits 48 GB, run many times: SDXL, FLUX.1, Z-Image, Qwen-Image in fp8 | Two 48 GB cards | Two ComfyUI instances, or ComfyUI-Distributed, run two jobs at a time |
| Wan 2.2 A14B at 720P, which peaked at 59.8 GB in Wan's own code | One 96 GB card | One model's working memory has to sit on one GPU |
| FLUX.2 [dev] with its bf16 text encoder, 66.47 GiB in all | Either | One 96 GB card holds it all. On two 48 GB cards, Select CLIP Device puts the 33.14 GiB text encoder on the second card |
| Video or image models at CFG above 1 | Two 48 GB cards, if the model fits one | MultiGPU CFG Split runs the positive and negative passes in parallel, with a copy of the model on each card |
| Splitting one large generation for speed | Two or more cards with Raylight | The only option that divides one generation's sequence across GPUs |
| Several different models in one workflow | One 96 GB card | No routing of models to devices to manage, and room for both |
Prices move, so compare them live: two RTX A6000 cards cost about twice the per-GPU price below, against one RTX PRO 6000 Blackwell.
| GPU | Memory | From | Available now |
|---|---|---|---|
| RTX A6000 | 48 GB | $0.48/GPU-hr | Yes |
| RTX 6000 Ada | 48 GB | $0.78/GPU-hr | Yes |
| L40 | 48 GB | $0.94/GPU-hr | Yes |
| RTX PRO 6000 Blackwell | 96 GB | $2.16/GPU-hr | Yes |
Configurations with four or eight GPUs run these setups when the catalog lists them. For a standing render farm or a cluster for Raylight on hardware the catalog does not list, send a capacity brief and we quote a build to your spec in writing. The RTX A6000 page lists its live configurations with their RAM and disk.
Fan a queue out over instances with the API#
The simplest way to keep several GPUs busy is a script that hands each ComfyUI its own share of the queue. The same script serves two instances on one VM or instances on several VMs, each behind its own tunnel: list one address per ComfyUI in SERVERS. This one builds on comfy_client.py from the ComfyUI API from Python, so save that file next to it first, and export your workflow in API format there. Save this as fan_out.py:
#!/usr/bin/env python3
"""Spread prompts over several ComfyUI servers, one worker thread per server."""
import copy
import json
import queue
import random
import sys
import threading
import uuid
from pathlib import Path
import websocket # from the websocket-client package
from comfy_client import save_outputs, set_inputs, wait
from comfy_client import queue as queue_prompt
SERVERS = ["127.0.0.1:8188", "127.0.0.1:8189"] # one entry per ComfyUI, through your tunnels
def worker(server, jobs, base, prompt_node):
out_dir = Path("outputs") / server.replace(":", "_") # each server numbers its own files
out_dir.mkdir(parents=True, exist_ok=True)
client_id = str(uuid.uuid4())
ws = websocket.create_connection(f"ws://{server}/ws?clientId={client_id}", timeout=600)
try:
while True:
try:
text = jobs.get_nowait()
except queue.Empty:
return
workflow = copy.deepcopy(base)
set_inputs(workflow, prompt_node, text, random.randint(0, 2**63 - 1))
prompt_id = queue_prompt(server, workflow, client_id)
wait(ws, prompt_id)
for path in save_outputs(server, prompt_id, out_dir):
print(f"{server}: saved {path}")
finally:
ws.close()
def main():
workflow_file, prompt_node, prompts_file = sys.argv[1:4]
base = json.loads(Path(workflow_file).read_text())
jobs = queue.Queue()
for line in Path(prompts_file).read_text().splitlines():
if line.strip():
jobs.put(line.strip())
threads = [threading.Thread(target=worker, args=(s, jobs, base, prompt_node)) for s in SERVERS]
for t in threads:
t.start()
for t in threads:
t.join()
if __name__ == "__main__":
main()
Run it with the workflow, the id of its prompt node and a file with one prompt per line: python3 fan_out.py workflow_api.json 6 prompts.txt. Each thread takes the next prompt as soon as its server finishes the last one, so a slower GPU simply takes fewer prompts, and the results land in one folder per server. Stopping a QuantaCloud instance deletes its disk, so let the queue drain and check the saved files before you stop.
ComfyUI multi-GPU questions#
Can ComfyUI use two GPUs for one image?
Partly. Since v0.23.0 its MultiGPU CFG Split node runs the positive and negative passes of each step on different GPUs, which helps only when CFG is above 1. Raylight, a custom node, splits one image or video across GPUs with sequence parallelism.
How do I choose which GPU ComfyUI uses?
Start it with --cuda-device 1 to use the second GPU only, or set CUDA_VISIBLE_DEVICES=1. To move one part of a workflow, use the Select Model Device, Select CLIP Device or Select VAE Device node.
Is ComfyUI-MultiGPU still maintained?
No. pollockjj archived it on 30 September 2026, with 2.6.4 as the final version, and endorsed no fork. ComfyUI's own Select Device nodes cover whole-component placement on a chosen GPU.
Does a second GPU add VRAM for a bigger model?
Not in plain ComfyUI: each model has to fit on one GPU. You can put the text encoder or VAE on the second card, and Raylight's FSDP mode shards one model's weights across GPUs.
My decision rule: one ComfyUI per GPU on a 2x RTX A6000 for throughput, the native CFG split when the workflow runs at CFG above 1, Raylight only when one generation has to get faster, and the 96 GB RTX PRO 6000 Blackwell whenever a single model needs more than 48 GB. ComfyUI GPU requirements has the file totals that decide which side of that line a model falls on, and vLLM tensor parallelism covers the different case of language models across GPUs.
Launch a 2x RTX A6000 VM