PM LoRA Stack Sampler

Before you merge LoRAs into one file, wouldn't it be nice to know what each one actually does? That's the whole job of this node. You've stacked four style LoRAs and you're about to bake them together - the Stack Sampler runs the sampler once per LoRA in the stack, all with the same prompt, seed, and settings, and hands you an annotated comparison grid. No swapping files, no rerunning the graph four times.

It's one of the pack's quiet superpowers. The merge workflow looks impressive on paper, but the people who actually get good merged results are the ones who verify their inputs first. This node is that verification step. It also earns its keep for a simpler job: figuring out which of your LoRAs is subtly doing nothing.

How it works

It takes the same LoRAStack and LoRAWeights the decompose node eats, but instead of merging, it iterates: for each LoRA in the stack it applies that one LoRA to the model and samples with your settings, then labels each output with the LoRA's name and strength. Since every sample shares the same latent, seed, and sampler settings, the grid is a fair test - you're isolating the LoRA's effect, not workflow differences.

It outputs latents (all samples concatenated), images (each sample as its own image), and image_grid - a combined grid with LoRAs on the X axis and batches on the Y axis. Long LoRA names get wrapped automatically so the grid stays legible.

The inputs that matter

Most of the inputs are the standard sampling rig you already know from KSampler-based workflows:

• noise, guider, sampler, sigmas, latent_image - build these with the normal nodes (KSamplerSelect, BasicGuider, etc.). This node is a drop-in for where a KSampler would sit, just with a stack feeding it.
• vae - for decoding the latents to images.
• lora_key_dicts and lora_strengths - the LoRAStack and LoRAWeights from a stacker node. This is the LoRA-specific part.

One tip: set the per-LoRA strengths in the stacker before you run this. The strength is baked into each comparison image, so you're simultaneously checking which LoRAs work and how strong they should be.

Installing

It ships in the LoRA Power-Merger pack. ComfyUI Manager is the easiest route - search "LoRA Power-Merger". Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/larsupb/LoRA-Merger-ComfyUI
cd LoRA-Merger-ComfyUI
pip install -r requirements.txt

Then restart ComfyUI. You'll find it under LoRA PowerMerge/sampling. The requirements are PyTorch, lxml, and mergekit from Arcee's git repo.

Common issues

The changelog for 2.3.0 fixed real bugs in the sampler family: previews now show live during sampling instead of only at the end, and the progress bar runs across all LoRAs rather than resetting per item. If your installed version still behaves like the old one, update the pack. Dual Model CFG users specifically should update - the uncond pass previously ran on the wrong model for DualModelGuider, giving subtly wrong results. And remember: with ten LoRAs in the stack you're doing ten full samples, so don't be surprised by the runtime. That's the cost of a fair comparison.