ComfyUI-Distributed spreads one workflow across several GPUs and machines

One graph, several GPUs, one collector

ComfyUI-Distributed is a ComfyUI extension that enables multi-GPU processing locally, remotely and in the cloud. The model is a master and a set of workers. The master holds the workflow and dispatches work, the workers execute parts of it, and the outputs are collected back on the master. The documentation claims you can convert any workflow to distributed with 2 nodes, which is the part that makes the approach interesting, because most ComfyUI graphs are a long chain of sampler and decoder nodes and rebuilding one for parallel execution would otherwise be a rewrite. The requirements section is short and blunt: ComfyUI, multiple NVIDIA GPUs, and that is it. If you have no additional GPUs, the documentation points you at the cloud worker option. The target audience is therefore people who have already outgrown one card and want the same graph to run wider.

Four kinds of worker, with two ways to reach the cloud

The extension supports four worker types, and the difference between the last two is the part that matters for cost and setup. Local workers are additional GPUs on the same machine and are auto-configured on first launch. Remote workers are GPUs on other computers in your network. Cloud workers are GPUs hosted on a cloud service like Runpod, reachable through secure tunnels. Serverless Runpod workers are queue-based endpoints for image collector jobs, and the documentation is explicit that they need no Distributed install and no inbound tunnel on the endpoint, with setup, an endpoint contract and preview limitations documented separately in the serverless workers guide. That last distinction is a real architectural difference, not a naming one. A cloud worker is a machine you administer that dials in, while a serverless endpoint is a job queue you post to, which changes both the failure modes and what you can preview.

Distributed Seed and Distributed Collector are the whole interface

Converting a workflow takes two nodes in the basic parallel generation recipe. You add Distributed Seed and connect it to the sampler's seed, then add Distributed Collector after the VAE Decode. Each worker then uses a different seed, which is what turns one generation into many. The Collector also has an optional load_balance setting that runs the job on one least-busy participant rather than everywhere. For video work there is one more node, Image Batch Divider, placed after the Distributed Collector, with a divide_by value set to the number of GPUs available. The documentation gives the arithmetic plainly: with a master and two workers, set it to 3. The result is that a workflow can be made parallel without touching the sampler or the decoder, which is the property that makes this usable with workflows you did not write.

Upscaling splits tiles instead of splitting jobs

The second workload is upscaling, and the distribution unit is different. Distributed upscaling accelerates Ultimate SD Upscale by distributing tiles across GPUs, and the documentation describes the distribution as intelligent. The recipe is short: load your image, upscale with ESRGAN or similar, connect to Ultimate SD Upscale Distributed, configure the tile settings, and enable the workers. The video variant follows the same path with a video input, and the documentation recommends RES4LYF from bong/res2 for better results on that path. There is also a guide for running the video upscaler entirely on Runpod with minimal setup. The distinction from the parallel generation path is worth holding on to, because in both cases the workers are doing the same kind of computation, but in one case they are producing different samples and in the other they are producing different tiles of a single output.

Image lists keep their input order across workers

The Dynamic Image List Processing feature covers batch jobs, and the description of the scheduling is specific. The master and every worker take the next image when they free up, and results come back in input order. You use Distributed Image List Start and Distributed Image List End around a per-image processing region. The documentation links to a separate page for wiring, supported inputs and first-version limits, which is worth reading before you plan a batch run, because a feature described as a first version usually has boundaries. The order guarantee is the interesting part: a naive work stealing scheme would return images as they finish, which is fine for generation and wrong for anything downstream that assumes the sequence, such as a before and after comparison or a video assembly.

A developer API, and a warning about exposing the port

There is a programmatic entry point for people who do not want to open the browser. The endpoint is POST /distributed/queue, it accepts a ComfyUI API-format prompt, dispatches it to the requested reachable workers, and returns the master prompt_id. The documentation points to a separate file of API examples and scripts. That is enough to build a scheduler that keeps a fleet of workers saturated without a human clicking run. The documentation also carries a security warning, and it is the part of the page that is cut off in the copy of the README available here, but it begins by telling you not to expose your ComfyUI port. The related instruction is in the installation section: if you will be using remote or cloud workers, add the --enable-cors-header flag to the launch arguments on the master. That flag is what allows the browser on the master to talk to a worker on another machine, which is also why it should only be enabled when you actually have remote workers.

Installation is a clone into custom_nodes, then a restart

The installation is three steps. Clone this repository into your ComfyUI custom nodes directory:

   git clone https://github.com/robertvoy/ComfyUI-Distributed.git

Then restart ComfyUI, adding the CORS flag to the master launch arguments if you plan to use remote or cloud workers. Then read the setup guide for adding workers, which is where the local, remote and cloud paths are documented in detail. The repository layout shows the shape of the project: nodes/ for the custom nodes, workers/ for the worker side, runtime/, api/, serverless_bridge/, image_list/ and upscale/ as separate packages, plus web/ for the interface, docs/, workflows/ with ready-made JSON graphs such as distributed-txt2img.json and distributed-upscale.json, and tests/. The Python packaging is declared in pyproject.toml:

[project]
name = "ComfyUI-Distributed"
description = "ComfyUI extension that enables multi-GPU processing locally, remotely and in the cloud"
version = "1.6.0"

That version number is worth noting against the release history. The most recent tagged releases listed for the project are v1.0.5 on 2025-08-01, v1.1.0 on 2025-09-15 and v1.4.0 on 2026-02-28, so the source tree is ahead of the last tag, and the last push was on 2026-10-14. The project is published under the Comfy Registry with a publisher identifier and display name, and the licence is Apache-2.0 with a LICENSE file at the root. The web part of the interface has its own test setup, driven by vitest through a shell script:

Where ComfyUI-Distributed is the wrong tool

The boundary is hardware and graph shape. The requirements ask for multiple NVIDIA GPUs, so a single card workstation gains nothing here beyond the two nodes and the overhead of a distributed run, and the documentation's own answer to a machine without extra GPUs is to rent cloud capacity rather than to install this. The second boundary is that the workers must be able to run the same graph, so a workflow that depends on state kept only on the master, or that reads local files that do not exist on the worker, will not simply work when split. The third is the operational one. Cloud workers and remote workers need reachable addresses, and the master needs the CORS flag to talk to them, so adding a worker expands the network surface of your ComfyUI instance. Between the two cloud options, choose deliberately. A serverless endpoint removes the install and the inbound tunnel, which is simpler, but it comes with its own documented preview limitations and a queue-based contract, while a cloud worker behaves like a machine you own. The honest framing is that this extension buys throughput by turning one process into a distributed system, and the operational cost of that is yours to run.

Editorial conclusion

Adopt ComfyUI-Distributed if your throughput ceiling is GPU bound and you already run ComfyUI with several NVIDIA GPUs, or if you can rent them by the hour, since the value is in using hardware you would otherwise idle. Do not adopt it for a single GPU workstation or for workflows that cannot be split, since the master and every worker must run the same graph and the collector only returns what the graph produces. Before you install, read docs/worker-setup-guides.md, decide between cloud workers over a secure tunnel and serverless Runpod endpoints with their own preview limits, and remember to add the CORS flag to the master only if you are using remote or cloud workers.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. robertvoy/ComfyUI-Distributed on GitHub