Concurrent Submit | zhenzhen-gpt-image-2.5（6合1·AI工坊）

Cloud image APIs are slow in a way local generation isn't: nine hundred seconds of someone else's GPU queue, mostly spent waiting. Run thirty of those one after another in a normal ComfyUI graph and you've built a workflow that finishes tomorrow. This node is the pack's answer - a submit-only twin of the GPT Image 2.5 Workshop node that hands the work to a shared thread pool and returns immediately.

The key thing to internalise: it renders nothing. Its single output is a task handle of type COMFLY_IMAGE_FUTURE. You don't wire that into a Save Image node, because there's no image yet. You wire it into the collector.

The two-node pattern

The pack ships a pair for images and a pair for video. This page is the image submitter; the matching collector is ComflyConcurrent_Image_Await (displayed as Concurrent Collect Images (30)). The collector has a stack of task inputs and a failure_mode switch, plus thirty image_* outputs and a status output. Plug submit nodes into the task sockets in the order you want results, and the collector blocks until they've all landed, then emits the images in that slot order - not in completion order.

That ordering promise is the whole reason this exists. Without it, batching cloud calls means writing filenames and matching them up by hand afterwards.

The counterpart node for this one is important too, and it's why the funnel works: the collector declares itself as always-run (the pack uses the float("NaN") IS_CHANGED idiom, the same trick any node uses when it must fire every execution regardless of caching). So the wait happens on the collector, once, at the end - not scattered across thirty submit nodes.

failure_mode has two settings and they change how you debug. fail_fast cancels the queued tasks and raises the first error it sees. placeholder keeps going and substitutes an empty image for the slot that failed, reporting it in the status string. For a throwaway batch, placeholder is kinder. While you're tuning prompts, fail_fast tells you what broke.

What it takes and what it returns

Every input is a straight copy of the normal node's - prompt, model, quality, size, custom_width, custom_height, n, background, moderation, api_key, image1–image14, mask, skip_error, seed. Same validation too: the submit class reuses the original's VALIDATE_INPUTS, so a bad size or a mismatched mask is rejected before a job is queued, and the pool never wastes a slot.

The only new thing is the output - one task socket.

Two practical notes. n on each submit node multiplies jobs, so n=4 across eight submit nodes is 32 billed images, queued 30 at a time; the pool doesn't stop you, your card does. And each submit node still has its own seed, which is cache control only. With fixed and unchanged inputs, ComfyUI reuses the cached result and doesn't re-submit an already-completed task - that's the pack's stated behaviour and it's the difference between a re-run costing nothing and a re-run costing thirty calls.

Tuning the pool

The size is a default, not a law. The pack reads these from the environment at load time:

export COMFLY_IMAGE_CONCURRENCY=8     # worker threads, default 30
export COMFLY_IMAGE_PENDING=8         # extra queued slots

Lower the worker count if the upstream provider starts throwing 429s at you - this relay is a shared service and hammering it thirty-wide is the fastest way to find its ceiling. Raise COMFLY_IMAGE_PENDING if you have a very wide graph and don't want submission to block on a full queue. Both are clamped between 1 and 128, and invalid values just get ignored with a console line.

Install

Same pack, same install as everything on this page - Manager search for Comfyui-zhenzhen, or:

cd ComfyUI/custom_nodes && git clone https://github.com/T8mars/Comfyui-zhenzhen

Restart, and the concurrent nodes appear alongside the originals. Nothing extra to install; the pool is plain concurrent.futures, no queues to run, no broker.

Gotchas

These submit nodes need the same api_key as their normal counterpart, and an empty key fails inside the worker thread - which surfaces as a failed slot on the collector rather than a red node at submission time. Connect the API Settings node's apikey output once and fan it out to every submit node.

Interrupting: the pool checks ComfyUI's interrupt flag while queuing, and the collector checks it while waiting, cancelling outstanding futures when you hit cancel. What it can't do is un-spend a credit on a task already accepted upstream - cancelling stops the wait, not the invoice.