并发接收图片(30 路)
Thirty image generations, one receiver — the batch-collector for ComfyUI_Seedance
- future_1
- future_2
- future_3
- future_4
- future_5
- future_6
- future_7
- future_8
- future_9
- future_10
- future_11
- future_12
- future_13
- future_14
- future_15
- future_16
- future_17
- future_18
- future_19
- future_20
- future_21
- future_22
- future_23
- future_24
- future_25
- future_26
- future_27
- future_28
- future_29
- future_30
- image_1
- image_2
- image_3
- image_4
- image_5
- image_6
- image_7
- image_8
- image_9
- image_10
- image_11
- image_12
- image_13
- image_14
- image_15
- image_16
- image_17
- image_18
- image_19
- image_20
- image_21
- image_22
- image_23
- image_24
- image_25
- image_26
- image_27
- image_28
- image_29
- image_30
- status_json
If you've ever run a ComfyUI workflow where the slow part is a cloud API call instead of a local KSampler, you know the pain: each image generation takes real time and costs real money, and running ten of them back-to-back is a slog. This node is the fix for that. It's the "collector" half of ComfyUI_Seedance's concurrency system - the half that waits on up to thirty image jobs at once and hands them back to your graph as plain IMAGE tensors.
Think of the pair like this. The 并发提交| nodes (Seedream, Qwen Image, Nano Banana, Midjourney - any of the image submit wrappers) don't block while a picture renders. They hand you a little ticket typed SEEDANCE_IMAGE_FUTURE that says "I'm being generated, check back later." This node takes those tickets. You wire one to thirty of them into its future_1 … future_30 inputs, and it waits on the whole batch in parallel, then emits one image per slot in the exact order you connected them.
That ordering is the whole point. Twenty prompt-variation jobs come back in different amounts of time - some model is slow today, some request errored and got a placeholder - but slot 7 always comes out of image_7. You can build downstream nodes that assume the batch layout instead of racing to match outputs to inputs.
What you actually set
future_1is required;future_2throughfuture_30are optional. Slots are typed to image futures, not to a specific model - the README explicitly shows mixingSeedream,Zhenzhen Image G, andNano Bananafutures into the same receiver. Grab that if you're running an A/B bake-off.failure_mode-raise(default) kills the workflow and names the failing slot;placeholderkeeps the other 29 and drops an error image into the dead slot. For batch runs you actually want to babysit, useplaceholder.status_jsonoutput - a summary of which slots connected, completed, and failed, with API keys and task IDs redacted. Read this before you go hunting in logs.
Outputs are image_1 … image_30 plus status_json. Empty slots produce a placeholder image too, so the output grid always lines up.
Installing it
It comes with the whole pack, so install once:
# ComfyUI Manager: search "ComfyUI Seedance" → install → restart.
# or Comfy CLI:
comfy node install seedance
# or manual:
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
Only dependency is requests; there are no weights to download. You still need an API key - the Seedance API Config node, SEEDANCE_API_KEY env var, or a config/.env file.
Gotchas
- A failed slot isn't a bug. With
failure_mode=raiseit surfaces as "Concurrent image slot N failed"; the real cause is on the submit node's side (bad prompt, expired reference link, upstream rate limit). - Watch your concurrency. The image pool defaults to 30 workers but is tunable with
SEEDANCE_IMAGE_CONCURRENCY(1–30). Hitting a rate limit on uploads is normal with big batches - the README warns the API throttles per-token upload frequency and the pack retries automatically, so early runs with many reference images are just slow. - Cache seeds.
fixedon the submit nodes means unchanged inputs reuse cached results instead of burning another paid call. That's the money-saving habit to build.
One honest note: this is a reseller-gateway pack, so English community discussion is nearly nonexistent - don't expect a pile of r/comfyui threads to tell you what's broken. What's solid is the design: it's the standard "API wrapper" pattern (KB's external-api-nodes category), and its per-slot failure isolation is genuinely well built. Just remember your prompts and reference images are leaving the machine every time one of these fires.
Inputs (31)
| Name | Type | Default | Description |
|---|---|---|---|
| future_1 | SEEDANCE_IMAGE_FUTURE | — | |
| failure_mode | COMBO | raise | 2 options: raise, placeholder |
| future_2opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_3opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_4opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_5opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_6opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_7opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_8opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_9opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_10opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_11opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_12opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_13opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_14opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_15opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_16opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_17opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_18opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_19opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_20opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_21opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_22opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_23opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_24opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_25opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_26opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_27opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_28opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_29opt | SEEDANCE_IMAGE_FUTURE | — | |
| future_30opt | SEEDANCE_IMAGE_FUTURE | — |
Outputs (31)
| Name | Type | Description |
|---|---|---|
| image_1 | IMAGE | — |
| image_2 | IMAGE | — |
| image_3 | IMAGE | — |
| image_4 | IMAGE | — |
| image_5 | IMAGE | — |
| image_6 | IMAGE | — |
| image_7 | IMAGE | — |
| image_8 | IMAGE | — |
| image_9 | IMAGE | — |
| image_10 | IMAGE | — |
| image_11 | IMAGE | — |
| image_12 | IMAGE | — |
| image_13 | IMAGE | — |
| image_14 | IMAGE | — |
| image_15 | IMAGE | — |
| image_16 | IMAGE | — |
| image_17 | IMAGE | — |
| image_18 | IMAGE | — |
| image_19 | IMAGE | — |
| image_20 | IMAGE | — |
| image_21 | IMAGE | — |
| image_22 | IMAGE | — |
| image_23 | IMAGE | — |
| image_24 | IMAGE | — |
| image_25 | IMAGE | — |
| image_26 | IMAGE | — |
| image_27 | IMAGE | — |
| image_28 | IMAGE | — |
| image_29 | IMAGE | — |
| image_30 | IMAGE | — |
| status_json | STRING | — |