Comet 批量图像

The single-image node is nice, but the reason people run API packs at all is volume. "Comet 批量图像" is where CometAPI earns its keep: it takes a list of prompts, a pile of reference images, or a whole folder of them, and grinds through the combinations with proper concurrency, per-task failure handling, and a summary instead of a wall of errors. If you've ever hand-run the same Nano Banana prompt across twenty images and wanted to scream, this is the node that stops it.

How it works

The engine is the same upload-and-call machinery as Comet 图像, wrapped in a scheduler. It reads prompts from either the batch_text input (a COMET_BATCH_TEXT payload, which you get from the 批量文本卡片 node or an LLM output) or from a folder, then runs the generation jobs with concurrency (1–10) workers and assembles the finished images into a single batch tensor.

The part that confuses everyone is pairing_mode. Three options, and they mean very different workloads:

• 全部图片作为一组参考，跑每条提示词 - all reference images become one combined reference set, and each prompt runs against that set. Use this for "same style, many prompts."
• 每张图跑全部提示词 - each image runs every prompt. This is the cross-product mode; expect a big bill.
• 图片和提示词一一配对 - image and prompt are zipped one-to-one. Use it when the Nth prompt belongs with the Nth image.

Then batch_mode splits it: 常规批量 is the prompt/reference combinator above, and 文件夹批量 switches the source to folder_path - a directory of images where relative paths resolve against the current directory, your input folder, or your output folder. Folder mode's pairing is fixed to "each image runs all prompts," so don't look for a pairing switch there.

The rest of the inputs are the shared image params - channel, model, aspect_ratio, image_size, quality, reasoning_effort, background_mode - and they behave exactly as on the single node. Outputs are images (the batch tensor, ready for a card or save node) and summary (a STRING with per-task status, so a partial failure doesn't leave you guessing which of the twenty actually succeeded).

The failure-handling that makes it usable

Per-task failures don't kill the batch. The summary tells you which jobs failed and which succeeded, and the pack writes each task's outputs to its own directory under your ComfyUI output folder, so you don't get one giant folder of unlabeled PNGs. That independent output-per-task behavior is a quiet quality-of-life win - you can tell at a glance which runs you need to retry.

Install, config, and the warnings

Same pack, same ritual: install via ComfyUI Manager (search "ComfyUI-CometAPI") or git clone https://github.com/jieg9341-lab/ComfyUI-CometAPI into custom_nodes, restart, then configure a channel key in the 设置中心 before running. Dependencies are requests + aiohttp only; there are no model downloads.

Where people get burned:

• Cost is a straight multiplier. Batch × concurrency × image_size × quality is your bill. "每张图跑全部提示词" with 30 images and 10 prompts is 300 billed calls. Do the math before you queue it, not after.
• Pairing mode defaults trip people up. The default "all images as one reference group" is a reasonable choice, but if you assumed images and prompts would zip 1:1 you'll get results that look like they ignore your prompts. Check pairing_mode first when output doesn't match expectations.
• Folder batch reads whatever is in the folder, with no whitelist - put only the reference images you want in there, because everything else gets uploaded too.
• All the standard API-node caveats apply: every image leaves your machine, the vendor's filter applies at the source, and the key lives in plain JSON in the plugin's data folder. Don't point this at a folder of client assets without thinking about who's now holding copies.