并发提交｜Qwen Image Global 2.1 文生图/图像编辑

Why this half of the node exists

The plain Qwen_Image_Global_2_1 node is fine for one image. It's actively annoying for ten.

A cloud image call isn't a sampler step - it's upload, submit, poll, download, and polling is most of it. So a serial queue of ten prompts spends ten minutes doing almost nothing but waiting on someone else's GPU. If you have six variants to audition before committing to a direction, you sit there watching a progress bar move four points.

This node splits that apart. Instead of blocking until the image comes back, it hands the queue a token and returns immediately. A second node - 并发接收图片（30 路）, registration name SeedanceConcurrent_Image_Await - collects up to thirty of those tokens and waits for them all at once. Thirty in flight instead of one. Same quiet infrastructure idea as the plumbing layer in comfyui-node-plumbing.md: the node touches no pixels, it just reorganises when work happens.

How it works

The submit node is a transparent wrapper. Its sockets are byte-identical to the original - prompt, resolution, ratio, seed, image1 through image10, api_config, skip_error - because it copies the original's input schema. Its only output is a future of type SEEDANCE_IMAGE_FUTURE.

Three things worth knowing:

• Validation runs first, synchronously. Before any task enters the pool, the wrapper runs the original node's strict validator, so an empty prompt is one clear error naming the actual input. That's a fix, not an accident - an earlier version let one bad parameter value expand into "invalid input" on every socket and control on the node.
• The original node runs in a worker thread, with its own HTTP session. Image pool default: 30 workers. Cap it with SEEDANCE_IMAGE_CONCURRENCY=4 (range 1–30) and restart ComfyUI.
• The await node restores slot order - future_1 in, image_1 out, whichever finishes first - and carries an aggregate progress bar instead of a dead spinner.

failure_mode on the receiver decides what happens when a slot blows up. raise (default) stops and names the failed slot; placeholder keeps the good ones and swaps failures for a placeholder, with a redacted per-slot report in status_json. Set skip_error on the submit node and that slot is isolated even under raise - the other tasks keep going, which is what you want for a batch.

Wiring it up

One submit node = one image task. This is the thing people get wrong: you don't put ten prompts in one node, you add ten nodes. Then:

[3 × 并发提交｜Qwen Image Global 2.1]  →  future →  [并发接收图片（30 路）]
      submit node A  ─────────────────────────────→  future_1
      submit node B  ─────────────────────────────→  future_2
      submit node C  ─────────────────────────────→  future_3

The receiver's outputs are image_1 … image_30 plus status_json. One gotcha from the source: the receiver always returns all thirty, and unwired slots come back as placeholder images rather than nothing. Wire the first three and you'll get three real images and twenty-seven placeholders; only trust the slots you connected.

The Future sockets are typed. An image future must go into the 30-way image receiver, a video future into the 10-way video receiver - swapping them is a TypeError, not a silent misfire. The receivers are media-generic, though, so you can absolutely mix Seedream futures and Qwen futures in the same 30 slots.

Install

Nothing extra - it ships inside the same pack as the node it wraps:

comfy node install seedance

or clone into ComfyUI/custom_nodes/ComfyUI_Seedance and pip install -r custom_nodes/ComfyUI_Seedance/requirements.txt. Restart, then look under Seedance/并发提交. Drop in examples/并发图片2路最小验证.json before you build anything bigger.

Where people get burned

No key, no pool. Every future is a real API call with real cost, so firing thirty variants of a prompt you haven't settled is an expensive way to learn you don't like it. Iterate with one node and a fixed seed (ComfyUI will serve you the cached result), then fan out once the prompt deserves thirty rolls.

Rate limits. Uploading several reference images per task across thirty workers is a lot of upload traffic, and the API throttles per token. The pack waits and retries, so it usually just gets slower rather than failing - but if you're sending ten references with every one of thirty tasks, stop and ask whether they all need to be there.

Interrupts. Cancelling the ComfyUI queue cancels the pending futures rather than orphaning them, because the await node checks for interruption while it waits. The expensive part - tasks already submitted upstream - you don't get back.

Parallelism here doesn't make the model faster; it frees the graph and stops you babysitting a bar. That's usually worth it. But thirty simultaneous calls to a metered endpoint is also the fastest way to spend a month's credits in an afternoon, so treat the 30-way ceiling as a capacity, not a target.