并发提交｜Zhenzhen Image G v2.5 Official 生成/编辑（2 合 1）

The Official Node's submit wrapper looks exactly like Zhenzhen_Image_G25_Official - all eleven required fields, all sixteen reference slots, both models in the dropdown - and behaves like it too, with one difference: instead of blocking your graph for a minute and a half per image, it validates, submits, and returns a handle. Do that thirty times and collect the whole batch at the end.

The registered class is SeedanceConcurrent_Zhenzhen_Image_G25_Official_Submit, shown in the canvas as 并发提交｜Zhenzhen Image G v2.5 Official 生成/编辑（2 合 1）.

Why bother

Because the Official node is the expensive, knob-heavy one. Quality tiers, exact pixel sizes, format, n up to 4. Sweeping it - six quality settings on the same prompt, or Flare versus Sunburst on the same reference set - is the natural thing to want, and running those serially through one blocking node is slow enough that people stop bothering.

The concurrent version decouples submission from waiting. Each submit node pushes its job into the pack's shared image thread pool (30 workers by default, tunable 1 to 30 with SEEDANCE_IMAGE_CONCURRENCY) and hands back a future. A receiver node waits on all of them and returns results in slot order.

One nice thing falls out of having one submit node per route: model is per-route. Route one can be Flare at quality=medium with a wild prompt, route two Sunburst at xhigh with the reference images attached, route three the same inputs at a different n. They all land in one receiver.

How it behaves

Inputs are the untouched original set: model (zhenzhen-image-g-v2.5-flare or -sunburst), prompt, size (including preserve_reference and custom), custom_size, resolution, quality, n (1 to 4), output_format, output_compression, background, moderation, plus optional image1 … image16, api_config, skip_error and the cache-only seed.

The wrapper runs the original node's strict validator before anything enters the pool, so a bad custom_size or a transparent-plus-JPEG combination fails immediately rather than queueing a doomed job. With skip_error on, that failure turns into a failed future carrying a placeholder and the rest of the batch keeps going; with it off, you get a proper error. Since v0.5.22 these wrappers no longer inherit the original validator, which is why a single wrong parameter no longer sprawls "invalid input" across every slot on the canvas.

Remember what n means here: it returns one IMAGE batch of up to four images from a single route. So a 30-slot submission is up to 120 images. Plan your RAM accordingly - everything lands in the receiver at once.

Wiring it up

The only output is future (SEEDANCE_IMAGE_FUTURE). Feed it into 并发接收图片（30 路） - class SeedanceConcurrent_Image_Await - on future_1 … future_30. That node returns image_1 … image_30 and a status_json, preserves your slot order regardless of completion order, and keeps its status text redacted.

failure_mode decides what one bad route costs you: raise halts the batch and names the slot; placeholder keeps the successes and substitutes a placeholder, with details in status_json. For a 30-wide sweep, use placeholder.

Image futures are one type, so Official routes can share a receiver with LowPrice, Seedream, Nano Banana or upscaler futures. Video futures are a separate type and a separate receiver - don't cross them.

Install

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 install from ComfyUI Manager (ComfyUI Seedance) or with comfy node install seedance - registry publisher t8star, node ID seedance. The requirements file is one line, requests>=2.28: no model downloads, no FFmpeg needed for this node. Restart ComfyUI and look under Seedance/并发提交; the receiver is under Seedance/并发接收.

You still need a key from api.seedance.nz - a single Seedance API Config node wired into all thirty routes, or SEEDANCE_API_KEY, or a config/.env in the pack directory. And the usual disclaimer for this whole category: prompts and reference images are uploaded to a third-party gateway, so don't put anything in there you wouldn't send to a stranger.

When things go sideways

• "Concurrent slot 3 expected ConcurrentTaskHandle" - the receiver got something that isn't a future, usually a plain IMAGE from the non-concurrent node.
• "At least one concurrent Future is required" - nothing connected to future_1 through future_30.
• Nothing seems to be happening - submit nodes are supposed to return instantly. Progress is reported by the receiver.
• Memory ballooning - thirty routes at n=4 at 2k or 4k is a big pile of tensors arriving together. Dial SEEDANCE_IMAGE_CONCURRENCY down, or run the sweep in chunks.
• Slow pre-flight - inserting sixteen reference images per route means a lot of uploads, and the API throttles upload frequency per token. The pack waits and retries; generation just starts later.
• A refusal from the host - moderation lives upstream. moderation=low is a documented level, not a bypass.