并发提交｜Zhenzhen Image G v2.5 LowPrice 生成/编辑

Open this node in ComfyUI and you'll think you opened the wrong thing. Same prompt box. Same resolution, size, nsfw_check. Same fifteen reference image slots. The display name says 并发提交｜Zhenzhen Image G v2.5 LowPrice 生成/编辑, the registered class is SeedanceConcurrent_Zhenzhen_Image_G25_Lowprice_Submit, and the only structural difference is a single output called future.

That one output is the entire point.

What problem it solves

A normal API node blocks. ComfyUI queues it, it uploads your references, polls the remote job, downloads the result, and then the next node runs. Put five of them in a graph and you wait five times in a row. Thirty, and you go make coffee, twice.

The concurrent version does none of the waiting inline. It validates your inputs, hands the job to a shared background thread pool, and returns a handle immediately. That handle - the future - gets collected later by a receiver node that waits for everything and returns the results in slot order. You're paying for one image either way; this version just stops serialising the wait.

For this node specifically, that's a real win, because Zhenzhen Image G v2.5 LowPrice always returns exactly one image and takes up to 15 reference images. It's built for prompt sweeps: one character sheet, same 15 references, ten different prompts. Ten blocking nodes is a long grid.

How the plumbing works

Two pooled executors live in the pack, one for image jobs and one for video jobs. The image pool defaults to 30 workers and can be set anywhere from 1 to 30 with SEEDANCE_IMAGE_CONCURRENCY. Admission is capped at twice the worker count, so you can't pile thousands of pending jobs into memory. That pool knob changes how many run at once - it does not change the receiver's 30 slots.

Before any job enters the pool, the wrapper runs the original node's strict validation. A blank prompt or a bad size fails right there. Since v0.5.22 each concurrent wrapper is its own class rather than inheriting the original's validator, which fixed an annoying bug where one bad parameter painted "invalid input" across every slot on the canvas. Turn on skip_error and a validation failure becomes a failed future holding a placeholder instead of a red error; leave it off and it raises.

Inputs

Identical to the base node - prompt (1 to 5000 characters, required), resolution (1k/2k/4k), size (the sixteen documented ratios), nsfw_check, then optional image1 … image15, api_config, skip_error, and seed (ComfyUI cache only). Reference slots are still submitted in numeric order with gaps compacted, and each route's skip_error is honoured independently, so one route failing doesn't take the batch down.

Outputs and the receiver

The only output is future, typed SEEDANCE_IMAGE_FUTURE. It's useless until you wire it into 并发接收图片（30 路） - search SeedanceConcurrent_Image_Await - on one of future_1 … future_30. The receiver outputs image_1 through image_30 plus status_json, and it always restores your slot order even though the jobs finish in whatever order the server feels like. Status output is redacted: no keys, no result URLs, no task IDs.

failure_mode on the receiver is the dial you'll actually care about. raise (the default) stops the whole batch and tells you which slot blew up. placeholder keeps the good slots and substitutes for the bad one, with a summary in status_json. For a 30-wide sweep, you want placeholder.

You can mix submit flavours in one receiver: futures from the Official node, Seedream, Nano Banana or anything else that outputs an image future are all the same type, and slot order is preserved per what you wired where.

Install

Same pack, standard route - no extra dependency for the concurrent nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/ComfyUI_Seedance.git
cd ..
python -m pip install -r custom_nodes/ComfyUI_Seedance/requirements.txt

Or search ComfyUI Seedance in ComfyUI Manager, or comfy node install seedance. Restart ComfyUI; the submit node lands under Seedance/并发提交 and the receiver under Seedance/并发接收. The dependency list is just requests.

An API key is still mandatory: Seedance API Config wired into api_config, or SEEDANCE_API_KEY, or config/.env. One config node can feed all thirty submit nodes.

When things go sideways

• "Concurrent slot 1 expected ConcurrentTaskHandle" - you wired a plain IMAGE output into the receiver. Futures only come from 并发提交｜... nodes.
• "At least one concurrent Future is required" - every slot is empty. Connect at least one.
• It looks frozen - the progress bar for concurrent jobs lives on the receiver, not the submit nodes. Submit nodes finish instantly by design.
• RAM spikes at the end - thirty results all land in the receiver at once. At 4k that's a lot of tensors. Batch smaller, or lower the resolution for sweeps.
• Uploads crawl at the start - the API rate-limits uploads per token, and the pack backs off and retries. Thirty routes each referencing 15 images means a lot of slow PNG uploads before generation even begins.
• Cost - nothing here is metered by ComfyUI. Thirty routes means thirty billed calls, and the pack's own front page is a shop with a price list. Check it.