并发提交｜Zhenzhen Image NB Pro / 2.1 Lowprice 生成/编辑

Zhenzhen Image NB Pro / 2.1 Lowprice gives you one image per run. That's fine until you're producing a set - twelve product shots from one reference board, or the same subject at four ratios and three art directions. Then serial generation becomes the bottleneck, and this node is the answer: identical inputs, one output difference, future instead of image.

What the wrapper changes (and doesn't)

The pack builds these submit nodes programmatically from the base node's own INPUT_TYPES, so every field is the same object - model, prompt, resolution, size, image1 through image14, api_config, skip_error, seed. Nothing is reimplemented, which means nothing silently drifts. The only new thing is the output type, SEEDANCE_IMAGE_FUTURE, and the fact that the node returns the moment the job is queued onto a shared thread pool instead of blocking for the round trip.

That pool is 30 workers by default and capped at 30, adjustable before launch:

export SEEDANCE_IMAGE_CONCURRENCY=6   # 1..30

Collect the results with 并发接收图片（30 路） - futures into future_1…future_30, images out of image_1…image_30 in slot order. failure_mode=placeholder keeps the successful slots and reports the dead ones in status_json; raise aborts with the slot number named.

The workflow this actually unlocks

Because each submit node carries its own full set of reference slots, the pattern that pays off is: one Load Image (or one image-generation branch) feeding several submit nodes at once, each with a different prompt and ratio. The author validated exactly that shape during development - two Lowprice edit lanes sharing a single reference image, submitted concurrently, both landing through one receiver.

That's the real value. Not "thirty unrelated images", but "one reference board, twelve different instructions, one wait."

Where people get burned

Node graph real estate. Each submit node exposes fourteen image inputs. Wire four of them side by side and your canvas is a wall of ports. Collapse or use subgraphs, and remember slots only become visible as you fill the previous one - so you rarely need all fourteen visible at once.

Upload volume multiplies. Fourteen references, times six lanes, is eighty-four uploads before a single image is generated, all against a gateway that rate-limits uploads per token. Start with fewer references than you think you need for the fan-out, confirm the prompt works, then add the rest.

It's metered per lane. Thirty lanes is thirty billed images. This is the node where a "let's just try it" graph gets expensive quietly.

No receiver, no images. These submit nodes aren't output nodes. Left unwired, they'll happily queue and pay for thirty generations and return nothing you can look at.

A bad parameter fails on the submit node, not the receiver. Validation runs before the future is created, so an over-length prompt or a ratio the chosen model doesn't support surfaces as an error on that specific node - not as thirty broken slots downstream. That fix shipped in v0.5.22 and it's the difference between a five-second correction and an afternoon of guessing.

For a single image, use the plain node. For a gallery, this one.