Concurrent Submit | zhenzhen-image-nb-2.1（文生/图像编辑）

Nano Banana 2.1 is the reference-image editor people actually want in their graph: it holds a face across a wardrobe change, keeps a product label legible, and takes a pile of references instead of one. The bad news is that it's a metered API with a queue, so the serial node gives you one image per round trip and about a minute of staring.

The concurrent submit version fixes the staring. It's the same node - same widget list, same fourteen reference slots, same 1K/2K/4K resolutions - with one difference: it returns a task handle and drops the job into a shared pool of 30 image workers, so ComfyUI can fire the next prompt while the first is still rendering upstream.

n: 1 on every one of those calls, so this is thirty separate jobs rather than one job asking for thirty images. That matters for billing, and it's why the fan-out is useful: each slot gets its own prompt, resolution and ratio widgets, so one graph can do "same character, five outfits, six lighting setups" with no cleverness at all.

The mechanism, briefly

The pack generates these nodes at import. It scans its own registry, finds every node whose primary output is an IMAGE or VIDEO, and mints a sibling that copies the original's INPUT_TYPES and VALIDATE_INPUTS verbatim, exposes task as a COMFLY_IMAGE_FUTURE, and submits the real work to a pack-wide thread pool. The serial node is left exactly as it was.

Two pools exist - 30 image workers, 10 video workers - and this node draws from the image one because its output is an image. Both are overridable before ComfyUI launches:

COMFLY_IMAGE_CONCURRENCY=30
COMFLY_IMAGE_PENDING=30

There's nothing local about the parallelism. Your GPU is idle throughout; you're running 30 concurrent HTTP requests against a reseller relay, and the real ceiling is whatever quota that relay has upstream.

You have to add the collector

The task output is not an image, so it doesn't wire into Save Image. The terminal half of the pair is Concurrent Collect Images (30): task_1 … task_30 in (only the first is required), image_1 … image_30 and a status string out.

Slot order is preserved - the graph holds thirty independent promises and re-orders results back to their input slot, so the expensive 4K job you put on task_14 always comes back on image_14, no matter which job finishes first. Unconnected slots are reported as not_connected and skipped rather than erroring.

failure_mode picks the failure behaviour. fail_fast (default) raises on the first failure and cancels everything still queued. placeholder substitutes a red 64×64 image for the failed slot and completes the batch, with a status JSON telling you which slots went down and why - with API keys and URLs scrubbed out of the message. On a 30-wide batch of a model with a real content filter, placeholder is the saner default, because "one refused prompt killed my other twenty-nine images" is a genuinely annoying way to lose a session.

Inputs, unchanged from the serial node

prompt, resolution (1K / 2K / 4K), aspect_ratio (eleven options from auto upward), image1 … image14, skip_error, seed. Output: just task.

The seed still does exactly one job - it's a ComfyUI cache seed and never reaches the API. So randomize here is not "make the image different", it's "buy a new one". With thirty nodes in a graph, an accidental randomize across all of them is thirty paid generations; leave them fixed and editing one prompt only re-runs that node.

If you want the per-job receipts - image_url, task_id, response - run that job through the serial node instead. The submit node throws them away.

Installing and key setup

It ships with the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-zhenzhen
# restart, then search "Concurrent" in the node menu

You'll find the submits under zhenzhen/…​/Concurrent Submit and the collector under zhenzhen/Concurrent Collect. The key still goes in Zhenzhen API Settings (api_base defaults to the domestic channel at https://api.seedance.nz), whose api_config output wires into each submit node. Remember that key lives in the workflow widget, and thirty expensive nodes is a bad thing to leak inside a shared JSON.

Where people get burned

Cost does not scale down with concurrency - only time does. Thirty 4K calls are thirty 4K calls. Draft the batch at 1K, pick the survivors, then re-run just those at 2K or 4K. The pool makes the loop fast; it doesn't make it cheap.

Upstream load hits all thirty at once. Google-side congestion comes back as 429s and 500s - the pack's notes say those are upstream conditions that usually clear on retry and normally don't bill, but thirty simultaneous failures is a much worse afternoon than one. Lower COMFLY_IMAGE_CONCURRENCY to 6–10 if you're being rate-limited.

The 61st job parks the graph. Once the workers and the pending queue are full, the next submit blocks its ComfyUI thread while it waits for capacity. Cancelling recovers it, but the node won't spin up new workers no matter how nicely you ask.

Large 4K downloads are the pack's known soft spot. Thirty in parallel is the worst case for cross-border transfers; the relay's token page has an OSS region setting (CN/US) that exists for exactly this failure.

Two layers of skip_error. The submit node's own skip_error reports a white placeholder as a success, and the collector calls it success too. If you turn it on, read status.