并发提交｜Zhenzhen Image GK v2 文生图

If you want to understand how the concurrent submit pattern works without any of the model-switching complexity, this is the node to study, because it's the plainest one in the entire 并发提交 family. Zhenzhen Image GK v2 文生图 - the concurrent submit version - is a pure text-to-image node with exactly three required inputs and one reference-free job: turn a prompt into a batch of images, in parallel.

The inputs:

• prompt - required, up to 20,000 characters.
• size - the output aspect ratio dropdown (the brief shows 1:1 as default; the GK v2 T2I family supports the usual ratios).
• n - 1 to 12 images per request. Note the range: this node goes to 12, one more than most of the pack's image nodes.

Plus the standard api_config, skip_error, and the ComfyUI cache seed. No reference image slots at all - that's what makes it so clean. Output is the single future (SEEDANCE_IMAGE_FUTURE), which goes into 并发接收图片（30 路）.

How it works

The concurrent pattern, distilled: your settings are validated immediately, then the render is handed to the image thread pool (up to 30 workers; shrink with SEEDANCE_IMAGE_CONCURRENCY) and you get the future back instantly. The receiver waits on every connected slot in parallel, returns images in slot order, and lets you pick failure_mode=raise or placeholder. Per-slot skip_error keeps one dud prompt from killing the batch. Since there are no references to upload, this is also the fastest node in the family to get moving - upload is a zero-step.

Installing it

ComfyUI Manager → search ComfyUI Seedance, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/ComfyUI_Seedance.git
python -m pip install -r ComfyUI_Seedance/requirements.txt

Restart, look under Seedance/并发提交. requests plus an api.seedance.nz key; nothing to download.

Where people get burned

• The future output catches everyone once. It is not an image - it goes into the receiver node's future_1…future_30 slots. Until you've internalized that, you'll keep trying to wire it into Save Image.
• n vs parallel slots. With n=12 on one node you get 12 images from one request; with 12 submit nodes you get 12 independent renders you can vary (prompt, seed, size). Both are legitimate, they just answer different questions.
• No references here. If your workflow suddenly needs image editing, this isn't the node - the GK v2 edit and region-edit submit nodes are separate, because the API structures their requests completely differently.

This is the node I'd point a beginner at to learn the concurrent flow: three inputs, one future, and the whole batch pattern in one glance. Cost is per image, so n on the cheap tier and parallel only when you're actually comparing variations.