Concurrent Submit | zhenzhen-VOSR2-4K-image-upscale-lowprice

The standalone VOSR2 image node takes exactly one image. Which is fine until you have twenty, and then the one-at-a-time behaviour stops being a quirk and becomes the bottleneck - every 4K restore is a cloud call with an upload, a poll and a download, and doing them in series means your graph sits there for as long as the sum of all of them.

This submit node is one task slot. Wire twenty of them, one image each, and they all go into the shared pool at once.

What it does, mechanically

It's a copy of zhenzhen-VOSR2-4K-image-upscale-lowprice with the rendering removed. Same input set - input_image (required), api_config, skip_error, seed - same validator, so a five-frame batch tensor is still rejected before it reaches the pool. Instead of returning the upscaled picture, it queues the job on a shared thread pool and returns a single task output of type COMFLY_IMAGE_FUTURE.

That handle is useless on its own. The companion is Concurrent Collect Images (30), class ComflyConcurrent_Image_Await: thirty task sockets, a failure_mode dropdown, thirty image_* outputs and a status string. It waits for everything it was given and then emits the results in slot order - socket nine produces image_9, whenever it happened to finish.

That ordering is the reason to use this pair instead of a Queue or a for-each-loop construct. Parallel cloud calls are easy; keeping the results matched to their inputs afterwards is the part that eats your evening.

failure_mode is the dial on failure handling. fail_fast raises on the first bad slot and cancels the rest. placeholder substitutes a blank image and names the dead slot in status. For a 25-image upscale run you're going to bed through, placeholder is the sane choice.

Sizing, and the constraint nobody reads

The pool is thirty image workers by default, and it's an environment variable read when ComfyUI loads:

export COMFLY_IMAGE_CONCURRENCY=10    # workers, default 30
export COMFLY_IMAGE_PENDING=10        # queued slots beyond that

Drop the worker count if the relay starts returning 429s; that's the provider's rate limit, and a shared reseller endpoint feels it before you do. Both values clamp to 1–128.

The constraint worth stating plainly: this node still upscales one image per task, exactly like its parent. It does not accept a batch, and the pool doesn't magically fan a batch out. The parallelism lives in having many submit nodes, each fed a single image - an Image From Batch node with an index, or a chain of Load Image nodes, one per clip you want to feed. If you were hoping to plug a 50-image tensor into one socket and get 50 tasks, that isn't this.

The rest of the plumbing

api_config on every submit node, from one T8Zhenzhen_API_Settings node - its config output fans out to as many inputs as you need, one wire per node. Forget one and you get a failed slot inside a worker thread, reported through the collector's status string rather than as an immediate node error.

seed is cache control only; the tooltip says so and VOSR2 never sees it. With fixed and unchanged inputs, ComfyUI serves the cached 4K result and never re-uploads or re-bills. That matters more here than on a normal sampling node, because each of these calls costs money, and a "just re-run it to see" habit gets expensive fast.

skip_error behaves as on the parent: a white 512×512 placeholder, which will be sitting in your batch looking plausible. Check the status output before you assume a clean run.

Install

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

Or ComfyUI Manager → Comfyui-zhenzhen → install → restart. No models, no extra services: the concurrency is a plain bounded thread pool inside the pack, and the compute is on the vendor's side either way.