Concurrent Submit | zhenzhen-NB Pro / 2.1 Lowprice（生成/编辑·平价小屋）

If you're generating twenty variants from the same fourteen-photo reference set, running them one after another is painful in a very specific way: it's not your GPU that's slow, it's the queue on someone else's server. This node exists to stop waiting on that queue serially.

It's the concurrent twin of zhenzhen-NB Pro / 2.1 Lowprice. NB here is the pack's shorthand for the nano-banana family, and the two IDs it exposes - zhenzhen-image-nb-pro-lowprice and zhenzhen-image-nb-2.1-lowprice - map to the top of that line. If the shape of the capability looks familiar (native 4K, a reference budget in the low teens), that's the vendor lineage showing through; the relay doesn't document the mapping any further, so treat the model IDs as the contract.

The mechanism, honestly

The pack generates these wrapper nodes automatically at startup. Every node whose primary output is IMAGE or VIDEO gets a second class whose inputs are a deep copy of the original and whose only job is to call the original's generate() on a background thread, returning a single task handle of type COMFLY_IMAGE_FUTURE. One shared pool per kind: 30 image workers, 10 video workers, used by every submit node in the pack at once. Override with COMFLY_IMAGE_CONCURRENCY if 30 isn't the number you want (it clamps at 128), and COMFLY_IMAGE_PENDING if you want jobs to queue instead of the graph stalling.

Because the ticket isn't an image, the node does nothing useful on its own. Wire task into Concurrent Collect Images (30) and that node awaits everything connected, restores slot order, and hands you image_1 … image_30 plus a status string. Its failure_mode defaults to fail_fast - one dead job cancels the rest - while placeholder keeps the batch alive and drops a stand-in for the failures.

What you actually set

Four required inputs, and the first one is the interesting one:

• model - NB Pro or NB 2.1. The resolution and aspect-ratio menus change with it.
• resolution - 1k, 2k, 4k.
• size - a long list including auto, the usual print and phone ratios, and extremes like 1:4, 4:1. The wider set (1:8, 8:1) belongs to NB 2.1; the Pro model rejects it, and the node's validator will tell you so rather than sending a doomed request.
• prompt - 1 to 5000 characters. This one does have a ceiling, and it's short enough to hit if you paste a wall of prompt engineering.

Then image1 through image14, all optional, one image per slot. That's the feature. Fourteen references is enough to lock a character, a product, and a house style in one call, and it's the axis people actually switch models for.

Two things about those slots. First, order matters - the pack submits them in slot order, so image1 is not interchangeable with image9 when your prompt refers to "the first photo". Second, every connected reference is uploaded to the provider and billed as an upload, so wiring fourteen images into thirty jobs is a lot of transfer. If a run looks expensive, count the references before you blame the model.

api_config takes the key from a zhenzhen-seedance2-low-price-api-settings node (or the SEEDANCE_API_KEY environment variable). seed is cache-only - ComfyUI-level, never sent upstream - which is how you get "rerun one prompt in this batch without paying for the other twenty-nine". skip_error swaps a hard failure for a placeholder. Note the collector itself has no cache: it re-runs every time by design.

Install

Manager → search zhenzhen, or install from Git URL, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-zhenzhen
# restart; the console should log the submit-node count and pool sizes

Nothing to download model-wise; this is a thin HTTP client. Watch the first startup though - requirements.txt pulls aiohttp, transformers, GitPython, matrix-client, opencv-python and friends, and the pack's __init__ launches a small helper web app on port 8080 to serve its front-end assets. If something else owns 8080, that's your console spam.

Where people get burned

The big one is 4K. Nano-banana-class 4K output is a large file, and cross-border download of it fails more often than the generation does. The author's fix lives on the provider's website, not in ComfyUI: open your API token, edit it, and set the OSS region to CN or US so results come from a closer bucket. If you keep seeing oversized-download errors on 4K and never on 1k, that's this.

Second: upstream 429 and 500 responses are vendor load limits, usually unbilled. The README's advice is blunt and correct - run it again. Third: remember the 30 slots are shared with every other submit node in your graph, so a fifty-job batch doesn't fail, it just waits its turn behind whatever else you queued.