并发提交｜Zhenzhen Image Nano Banana 2.1 生成/编辑

The pitch is small and specific: Zhenzhen_Image_NB_2_1 takes up to 14 reference images and a prompt between 5 and 5000 characters. This node takes the same three inputs - prompt, resolution, size, plus image1…image14 - and returns one future instead of an image, so you can run a stack of them in parallel and collect the results in slot order.

Why you'd bother

If you're generating single hero images, don't bother; the base node is simpler. This earns its keep when the job is repetitive - the same 14-image reference set with 20 different prompts, or the same prompt against a folder of product shots. Reference-image editing is exactly where a 30-wide fan-out pays, because each job is an upload plus a poll plus a download, and all of that overlaps instead of queueing.

It's also the one place where the pack's prompt validation saves you real money. The base node refuses prompts shorter than 5 characters, and the wrapper runs that check synchronously before enqueuing. So a too-short prompt in branch 19 fails in your console in milliseconds, not after a remote round trip - and it never becomes a remote job.

How the plumbing works

Submit enqueues into the pack's image thread pool (default 30 workers, SEEDANCE_IMAGE_CONCURRENCY to tune between 1 and 30). Receive happens in 并发接收图片（30 路）: 30 image slots, each one paired with the submit branch you wired in, plus status_json. Ordering is by slot, not by completion - a branch that finishes in 9 seconds still lands in its own slot.

Each slot reports its task type and the outputs it produced in that JSON summary, and errors get redacted before they're written: keys, result URLs and task IDs don't end up in your console log. That's a nicety you only appreciate after your first pasted error dump.

The 14-reference reality

The reference slots are per branch. There's no "shared reference" bus - if 30 branches all use the same 14 images, that's 420 uploads. The node will do it, the API will accept it, and on a rate-limited token the upload stage will dominate your first minute. If you're doing a big sweep against one reference set, expect to wait, and don't convince yourself mid-wait that the node has hung.

Each slot takes exactly one image; a batch tensor in image1 fails validation. And 14 is a hard cap, not a hint - the pack caps it and the underlying service is built around that same number.

There's no n control on this node, by the way. It sends n: 1, so one branch produces one image. Want four variations of the same prompt? Four branches. That's not a limitation imposed by the wrapper, it's how the model node is built.

failure_mode and interruption

raise is the default and it stops the receiver with the offending slot named. placeholder keeps the good slots, drops a placeholder into the failed ones and records a redacted per-slot status in status_json. For a 30-wide sweep you'll usually want placeholder, precisely because losing one prompt shouldn't cost you 29 images. Branch-level skip_error composes with either setting.

Hitting the interrupt button stops polling on the receiver and cancels jobs that haven't started. Already-submitted jobs may still finish remotely - and you've still paid for 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

ComfyUI Manager users: search ComfyUI Seedance, install, restart. Dependencies are requests>=2.28 - nothing to download, nothing to compile. You need a key: a Seedance API Config node wired into each submit node's api_config, or SEEDANCE_API_KEY in the environment, or config/.env in the plugin folder. And before you build anything, load examples/并发图片2路最小验证.json from the pack - two branches, one receiver, and it takes thirty seconds to understand.

Two things to keep in mind

First, cost. Every slot is a billed call to a reseller endpoint, and 4k costs more than 1k in both money and wait. Sweep at 1k, then re-run the keepers at 2k or 4k.

Second, provenance. zhenzhen-image-nb-2.1 is the vendor's own catalogue label rather than a public model name, and the 14-reference cap plus the resolutions it accepts line up with Google's Nano Banana Pro spec - which is a reasonable read, not a published fact. What is certain is that the images and prompts go to a third-party endpoint you don't control, and per-call pricing means a 30-wide sweep is 30 charges. Budget accordingly, and don't discover the price after the fan-out.