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

The plain Qwen Image Global 2.1 node makes exactly one image per run. No num_images, no batch - one prompt in, one picture out. If you want eight variations, you queue the graph eight times and watch it crawl, because every run is a network round trip plus a poll.

Concurrent Submit | zhenzhen-qwen-image-global-2.1（文生/图像编辑） (ComflyConcurrent_T8Zhenzhen_Qwen_Image_Global_21_LowPrice_Submit) is the pack's fix. It runs the same node body on a background worker thread and returns a task handle instantly, so eight of them go out at once and ComfyUI moves on.

What's different from the normal node

Exactly one thing, and it's the output. The inputs are a deep copy of the original INPUT_TYPES - same prompt, same resolution (1k/2k/4k, default 2k), same eight ratio options defaulting to 3:4, same seed (-1 = let the API randomize, 0 is a legal fixed seed that gets sent), same image1 … image10 editing references, same api_config from the Settings node, same skip_error. The validator is delegated straight to the original class, so a batch where it wants a single image still fails the same way.

The return is a single task of type COMFLY_IMAGE_FUTURE - a future plus a note of which node submitted it. Not an image. This is the number-one beginner injury with every node in this family: task wired into Preview Image does absolutely nothing, quietly.

The collector does the waiting

Pair each Submit with the image collector, Concurrent Collect Images (30) (ComflyConcurrent_Image_Await):

• task_1 required, task_2 … task_30 optional. One Submit node per slot.
• failure_mode - fail_fast (the default) cancels the queue and raises on the first failure; placeholder keeps the batch going and gives the dead slot an empty image. For a 30-slot run you started and walked away from, use placeholder.
• Outputs image_1 … image_30 in slot order regardless of which job finished first - which is the actual point of a pool: your slot mapping is stable, so slot 7 is always the prompt you put in slot 7. Plus a status JSON string reporting per-slot success / failed (with the error text) / not_connected, and which node key submitted it.
• Unconnected slots come back as empty placeholders rather than errors.
• It waits on the futures in a quarter-second polling loop, honours ComfyUI's interrupt button by cancelling in-flight tasks, runs its own progress bar, and returns float("nan") from IS_CHANGED so it isn't cached away.

Pool sizing is env-var driven and read once at import:

export COMFLY_IMAGE_CONCURRENCY=12   # default 30
export COMFLY_IMAGE_PENDING=6        # queue depth behind the workers (default = pool size)
# export these before starting ComfyUI, then restart after changing them

Both are clamped to 128 max. The video side uses COMFLY_VIDEO_CONCURRENCY (default 10) with its own collector.

Where the wheels come off

Starting 30 jobs and blaming the vendor. The pool is one shared thread pool for the whole pack in one ComfyUI process, and 30 simultaneous uploads against a reseller endpoint is a lot. If polls start failing, drop the concurrency to 6–8 and restart rather than re-queueing harder. The README's own stance is that plenty of errors are server-side - but if you launched the flood, fix your side first.

Expecting fresh generations. ComfyUI still caches the Submit node on its inputs. With seed = -1 and an unchanged prompt you can get the cached task handle back instead of a new paid call. Change something, or drive the seed with randomize.

Blowing your own token budget. This is the node that turns "let me try a few variations" into a thirty-image bill. Every slot is a real metered call. The pool is a volume tool, not a free fan-out; if you need one image, the boring node is right there.

Nothing to install - it ships with the pack. Restart ComfyUI after updating: these Submit/Collect classes are generated by walking the node registry at import time, so a hot reload can leave stale ones behind.