并发提交｜Moss Image 图像生成/编辑

This node looks identical to Moss Image - same prompt box, same ratio list, same optional single reference - and that's on purpose. The one difference is the output: instead of an image, it hands back a future. That future is a promise of a picture that hasn't been made yet, and you cash it in with a receiver node at the end of the graph.

Why bother? Because a Moss call takes ten to thirty seconds of network waiting, and if you want the same prompt at four ratios plus a reference edit, doing it serially means four to five full round trips stacked end to end. Fan it out and you wait for roughly the slowest one. The pack calls these 并发提交｜ nodes - "concurrent submit" - and it's the single most useful idea in the whole add-on.

How the pair works

Under the hood these aren't hand-written twins of the original nodes. The pack generates a wrapper class for each image generator at import time, re-uses the original INPUT_TYPES verbatim, and only swaps the output for a SEEDANCE_IMAGE_FUTURE. So there's no drifting parameter list to worry about - if Moss Image gains a knob, the submit version gets it too.

On execution, the submit node validates your inputs, then queues the actual API job on a shared, lazily-created thread pool and returns immediately. The pool is sized by SEEDANCE_IMAGE_CONCURRENCY, defaults to 30 and caps at 30. Nothing about this uses ComfyUI's own queue; all the parallel work happens inside a single workflow run, which is why the connection between the two halves has to be explicit.

The receiving half is 并发接收图片（30 路） (SeedanceConcurrent_Image_Await). Wire your futures into future_1 … future_30, and it waits for all of them, then emits image_1 … image_30 in slot order - not completion order, which is the behaviour you want when you're assembling a contact sheet or matching prompts to outputs downstream. It also has a failure_mode: raise stops with an error naming the offending slot, placeholder keeps the good slots and drops a status summary into status_json.

What you actually wire

Three things, minimum:

1. One Seedance API Config node, its api_config output connected to each submit node.
2. N submit nodes, each with its own prompt and ratio.
3. One 并发接收图片（30 路）, each submit node's future into its own slot.

Then image_1, image_2, … into Preview Image or Save Image. If you build the graph and see nothing render, that's the classic mistake: these submit nodes are not output nodes. Left dangling, they run, the tasks complete, and the images evaporate because no receiver ever collected them.

Tuning the pool is an environment variable, set before launch:

export SEEDANCE_IMAGE_CONCURRENCY=8   # 1..30, default 30

Lower it if the gateway starts throwing rate-limit errors at you during reference-image uploads; there's no point holding twenty open connections that all get pushed back. Leave it at default if your prompts are simple.

Where people get burned

It's per-call money, multiplied. Thirty lanes is thirty billed generations. Fan-out is a good idea for "give me the same shot at nine ratios", and a bad idea for "let's see what happens" with a 40-word prompt you've never tested. Get one good image from the single Moss Image node first, then parallelise the variants.

A missing key burns the whole batch, not one lane, because every submit node needs its own api_config connection or env fallback.

skip_error is per lane. Turn it on for the submit nodes you expect to be flaky and keep the receiver's failure_mode at raise; the lane that failed returns a placeholder and the other twenty-nine still land. Without it, one bad ratio can cost you the batch.

One genuinely nice detail: because the submit wrapper validates parameters synchronously before creating the future, a typo in a prompt or an unsupported ratio shows up on that one node instead of smearing "invalid input" across all thirty slots - a bug the author fixed back in v0.5.22, and the kind of thing you only appreciate if you used the earlier version.

For a single image, use the plain Moss Image node. This one exists for the moment you find yourself duplicating a node eleven times.