Nodes/ComfyUI Deadline Distributed/Deadline Distributed Collector
ComfyUI Node

Deadline Distributed Collector

The node where your farm's images come home

By doubletwisted·Created about a year ago·Updated 3 months ago· 9
Deadline Distributed Collector
  • images
  • IMAGE

This is the node that makes distributed rendering actually feel like distributed rendering. Every other node in this pack is a helper - seeds, batch sizes, placeholders. The Collector is the return valve: it's where the master's workflow parks itself and waits for every worker to hand its results back, then stitches them together into one batch so the rest of your graph runs exactly as if a single GPU had done the work.

Where it goes. At the end of your image-generation chain - after VAEDecode, before your Preview/Save node. One images (IMAGE) input, one IMAGE output. On the worker side, the exact same node behaves completely differently: when a worker's pruned copy of the workflow reaches the Collector, it takes the images it just rendered and POSTs them back to the master as chunked PNGs at /distributed/job_complete, marking the last chunk so the master knows that worker is done. On the master side, the node waits on an internal queue, collecting results from every enabled worker until they've all reported in, then concatenates them - master's own images first, then each worker's in index order - and hands the combined batch to whatever node comes next. Same node, two jobs, no user configuration. The framework injects hidden values (multi_job_id, is_worker, master_url, the enabled worker list, the job token) when it prunes and distributes the graph.

Why it's the one you'll actually reach for. The README's basic workflow is basically "add DistributedSeed and DistributedCollector to your workflow." The Collector is the piece that turns a master and some workers into one coherent pipeline. The hidden pass_through mode even returns images unchanged when there's no distributed job running, so the node is harmless in a plain local workflow.

What can go wrong. The honest answer, grounded in the source: the master waits a configurable time for each worker and then gives up. settings.worker_result_wait_timeout in gpu_config.json controls how long it waits without hearing from a worker, and when the master isn't rendering (master rendering disabled), the first-result wait gets an extended multiplier because workers take longer to spin up than the instantly-finishing master. If a worker never registers or dies mid-job, you'll see timeouts and missing workers rather than a clean image. Requeued or locally-completed fallbacks exist for tile work in the upscale node, but for a plain collector the fix is usually "check the worker is actually reachable and the models are installed on it." A worker with a different set of custom nodes or missing model files will fail at a completely different node and the collector just times out waiting.

It ships under the Deadline name by default in this pack - same class as DistributedCollector, cleaner name for Deadline submission workflows. If you're running a multi-GPU setup and wondering where the magic happens, it happens here.

Categoryimage

Inputs (1)

NameTypeDefaultDescription
imagesIMAGE

Outputs (1)

NameTypeDescription
IMAGEIMAGE