BatchLoraLoader(mki-批量LoRA加载)

The core LoraLoader does one LoRA at a time. Want a character LoRA and a style LoRA and a detail-boosting LoRA? That's three loaders chained in a row, and every workflow you share needs them all kept in sync. BatchLoraLoader_makki (display name "BatchLoraLoader(mki-批量LoRA加载)") collapses that chain into a single node with up to 50 slots, each with its own LoRA name and its own model/CLIP strengths.

It does exactly the same math as chaining core loaders - it applies each selected LoRA sequentially to the model and CLIP via the same comfy.sd.load_lora_for_models call - so it's a convenience, not a magic trick. But for template workflows it's a real one: you set up the stack once, and testing a different combo becomes a couple of dropdowns instead of rewiring a chain.

The inputs that matter

The full list is huge (50 slots × 3 fields), so here's what you actually touch:

• model and clip - the checkpoint's MODEL and CLIP that everything gets applied to. These are required.
• loras_count - how many of the 50 slots are active. Default 3, max 50. This is the one that keeps the node sane: the pack's JS hides the widget rows beyond this number, so you're not staring at 47 empty dropdowns.
• loras_num - a nifty routing trick. -1 (default) loads all slots up to loras_count. 0 loads nothing - handy as a bypass switch. A positive number loads only that one slot (1-based), so you can flip between individual LoRAs in a stack without deleting anything.
• lora_name_N / strength_model_N / strength_clip_N - the per-slot pair. Strengths default to 1.0 and can be negative; negative model strength is a legit trick for reducing whatever the LoRA adds.

Outputs are MODEL and CLIP, feeding straight into your sampler like any loader.

Little behaviors worth knowing

• Slots set to None are skipped, and a slot with both strengths at 0 is skipped too - so you don't have to empty every unused slot.
• If you set loras_num higher than loras_count, it silently loads everything. That's a "load all" fail-safe, not a bug.
• The node caches the last-loaded LoRA file, which makes iterating over a stack noticeably faster than the equivalent chain.

Installing and gotchas

Install via ComfyUI Manager (search "ComfyUI-MakkiTools"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/MakkiShizu/ComfyUI-MakkiTools
cd ComfyUI-MakkiTools
pip install -r requirements.txt

Restart ComfyUI afterwards. A couple of real-world warnings:

• Stacking is additive, and it compounds fast. Three LoRAs at 1.0 each rarely look like "three LoRAs at 1.0" - they look like a melted image. Start your strengths around 0.4–0.7 and tune from there. The pack even lets you go negative, which is how you subtract an effect you over-applied in an earlier slot.
• LoRA order matters. The stack applies top-down, and later LoRAs see the already-modified model. Different orders give different results, so the order you list slots in is part of your recipe.
• If you load a workflow made before the pack's mid-2025 rename (nodes got _makki suffixes), ComfyUI may report this node missing - re-pull the pack and the mapping line up again.

It won't turn a bad checkpoint into a good one, and it doesn't train anything. But if you regularly run LoRA stacks, this is the kind of node that quietly removes friction from your whole setup.