Dual Model KSampler Batch

DualModelKSamplerBatch is the answer to the question you'll have within five minutes of using its sibling node: okay, so which switch step is actually right? Instead of re-running the whole workflow for each candidate, you feed it a comma-separated list of switch points and it runs the same dual-model sampling for each one, then hands you back one batched LATENT - an image per switch point, all from the same seed. It's the node the paper's authors used to build those "same prompt, different switch" comparison grids you saw in the launch post.

Mechanically it's a for-loop around DualModelKSampler. For every value in switch_steps_csv (default 3,5,7,10,15) it runs the full 2-phase sampling with that switch point, then torch.cats the results along the batch dimension. Because every pass uses the same seed, steps, and scheduler, the images differ only in where the handoff from model_a to model_b happened - which is exactly the controlled comparison you want. The info output reports each switch point, like sw=3 | sw=5 | sw=7 | sw=10 | sw=15, so you know which slot in the batch is which. Note there's no switch_end input here: it's 2-phase only. If you want sandwich-mode sweeps you're doing them one node at a time.

The inputs are DualModelKSampler minus the switch knobs plus one string: model_a, model_b, your positive/negative conditioning, latent_image, seed, steps, cfg, sampler_name, scheduler, denoise, and switch_steps_csv. Outputs are latents (the batch) and info. Wire latents straight into a SaveImage node - it writes each image in the batch to its own file - or into PreviewImage to eyeball the sweep in the canvas.

A few things to set expectations before you run it. First, it's N full samplings in one go. A five-point sweep at 20 steps is five samplings, so budget five times the generation time. Second, since each pass is a full run, the model-swap overhead the README admits to (roughly 7 seconds per handoff on an RTX 4070) multiplies too - the batch node is not the fast path, it's the thorough path. And third, the same caveats as the whole pack apply: it's validated on FLUX.1-dev with GGUF quants, peak VRAM is set by the larger of the two models, and the practical value is finding your model's robust zone rather than saving wall-clock time. The sensible workflow: load Q2_K as model_a, Q5_1 as model_b, run the default sweep, spot the earliest switch point where output stops changing, then drop that value into a plain DualModelKSampler for production runs.

Install is the same as the rest of the pack - ComfyUI Manager, search "Asymmetric Quantization Sampler", or:

cd ComfyUI/custom_nodes/
git clone https://github.com/lee09lee26/ComfyUI-AsymQuantSampler.git

Then restart ComfyUI. No pip dependencies at all; the pack uses only ComfyUI built-ins. You do need city96's ComfyUI-GGUF to load the two .gguf checkpoints in the first place. This is a niche research tool from a tiny pack, but for this specific job - "show me what switching at 3 vs 5 vs 7 does to the same prompt" - there isn't really a stock-ComfyUI equivalent. That's what makes it worth having around.