ComfyUI Queue Concurrency?

[maxnbk]

Perhaps I am missing something obvious, or perhaps this is a core limitation, but, I cannot seem to set up Distribution amongst different workflows to different nodes concurrently.

In other words, a single workflow can have multiple slices of a single workflow get distributed as part of a single workflow execution, or via seed-randomization/distribution, etc.

But if what I want distributed is entirely separate workflows with a single "Distributed Collector" to push that job to another host...:

I can't force the ComfyUI queue to run more than one job at a time. It will only work through them sequentially, one at a time, rather than use whichever host does not currently have a job, to fill all available slots, at the same time. So unless I want to take massive workflows and combine them into a single even-more-massive singular workflow, this is just distributing work, but not achieving concurrency to help to parallelize it.

Any ideas? This seems like a possibly-fundamental limitation of ComfyUI's queue, but I had to guess that someone using this extension must have run into this limitation before.

[robertvoy]

You’re correct that a single ComfyUI instance processes its prompt queue sequentially. ComfyUI-Distributed cannot make one ComfyUI process execute multiple prompts concurrently.

For separate workflows, enable load_balance on the Distributed Collector in each workflow.

With that enabled, every submitted workflow is routed to one least-busy participant... either the master or an available worker. For example, if two workers are idle, workflow A can run on worker 1 while workflow B runs concurrently on worker 2.

The master queue may still appear sequential because it contains the collector/orchestrator prompts. Worker execution can nevertheless overlap, and completed results are held in each distributed job’s result queue until the corresponding master collector runs.

If your Distributed Collector does not show load_balance, update ComfyUI-Distributed to the latest version.

One limitation remains: this is not yet a persistent work-stealing scheduler. If many jobs are queued in advance, they are assigned based on queue depth at submission time rather than waiting to see which heterogeneous worker finishes next.

If load_balance=true still runs the workflows sequentially, please post the master debug lines beginning with Orchestration start and Least-busy worker selected, plus the /prompt queue status from each worker.