KSampler (Batch Seeds)

You've got one prompt and you want to see what it does at seed 42, 43, 44, and 45. The boring way is to run the graph four times, or wire up a seed node that increments between queue runs - which works, but it burns GPU idle time on four separate load/encode/sample cycles. KSampler (Batch Seeds) is the "give me the whole contact sheet now" answer: it takes your one latent, copies it batch_size times, gives every copy its own seed, and pushes the whole stack through the model in a single forward pass. You get N images out for roughly the wall-clock cost of one, minus the batch's extra VRAM.

It's a drop-in stand-in for the stock KSampler - same model/positive/negative/CFG/scheduler wiring, same LATENT output, same idea. The only real difference is batch_size.

How it works

The README sums it up in three steps, and the source matches: replicate the input latent batch_size times, generate per-item noise with genuinely different seeds, then sample the whole batch at once.

The "genuinely" part is the trick. ComfyUI's own samplers will happily process a batch latent, but they use one noise seed for the whole batch - that's why you can't just stack your own latents and get varied results. This node instead builds a noise tensor where item i gets its own seed, then calls the sampler with disable_noise=True because the noise is already baked in. It also temporarily drops the model's memory_usage_factor to basically zero, which stops ComfyUI's memory planner from secretly sub-batching your items back into a sequential loop. Without that override, you'd get the same images but none of the speedup; with it, one real batch.

One honest warning before we go further: the console logging is chatty. Every run prints config, VRAM, and a line per batch item with the seed it's using. That's actually kind of handy for the reproducibility math below - just expect a wall of [KSampler Batch] text.

The inputs that matter

You'll touch exactly three knobs on top of the standard KSampler fields (steps, cfg, sampler_name, scheduler, denoise - all the usual suspects):

• seed - the base seed. Item i uses seed + i, per the tooltip.
• batch_size - default 2, max 64. Number of images to generate in parallel on the GPU. This is the whole point of the node.
• seed_mode - incremental (default) is seed+0, seed+1… and each result is individually reproducible. random derives a fresh random seed per item from the base seed - good for quick variety, still deterministic for a given base seed. fixed gives every item the same seed, i.e. N identical images; the author's tooltip says it's for testing, and that's exactly what it's good for (does the batch actually work? then turn it off).

The single output is a LATENT whose batch dimension is now batch_size. Wire it into a normal VAEDecode, and Save Image will save each image in the batch as its own file. No special decode node needed.

Reproducing one image later

Say you ran seed=42, batch_size=4 and image #3 (index 2) is the winner. To reproduce exactly that image, run a plain KSampler with seed=44. That's the README's own tip and it's worth internalizing, because this is where people get burned: the PNG metadata embeds the batch node's base seed, not each item's. Re-running gives you the same batch, but for just the one image, remember the math - base + index.

Install

Nothing to download beyond the code. This pack has no requirements.txt and no model files - it's pure Python on top of ComfyUI internals.

• ComfyUI Manager: search "comfyui-ksampler-batch" (or "Batch Seeds") and install.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/adbrasi/comfyui-ksampler-batch then restart ComfyUI.

Minor gotcha: the README's own clone line still points at an older GitHub handle (adolfocesar/…). The repo lives at adbrasi/comfyui-ksampler-batch now - clone that one.

Common issues

• OOM at higher batch sizes. VRAM scales roughly linearly with batch_size, and this node deliberately disables ComfyUI's automatic sub-batching so the whole batch must fit in one pass. If it doesn't fit you'll get an out-of-memory error instead of a graceful slowdown. The fix is honest math: if one image takes ~2GB of model VRAM on your 8GB card, don't set batch_size to 5 and hope. Start at 2–3. A quantized model (GGUF, fp8) stretches the same headroom - the KB's VRAM guidance applies here in full.
• "Why is fixed mode giving me identical images?" - Because that's what it's for. You probably want incremental.
• Not faster than expected. Same total compute; the win is reduced per-image overhead. On a small card where the batch barely fits, that gap shrinks - batch seeds shine when your GPU has idle headroom.