Nodes/IAMCCS-nodes/LoRA Stack (Model In?Out) WAN
ComfyUI Node

LoRA Stack (Model In?Out) WAN

Four LoRAs, one node hop, no stack-then-apply tango

By IAMCCS·Created 11 months ago·Updated 8 days ago· 113
LoRA Stack (Model In?Out) WAN
  • model
  • lora
  • MODEL
lora1no
strength11.00
lora2no
strength20.00
lora3no
strength30.00
lora4no
strength40.00
model_typeflow

IAMCCS_WanLoRAStackModelIO is the pack's flagship convenience: take an already-loaded MODEL, apply up to four LoRAs to it in a single node, and get the patched MODEL out the other side. No separate "build stack" node, no stack-output hand-off - the stack and the apply are fused. If your WAN 2.2 / flow workflow has a base model, four character or style LoRAs, and a sampler, this is the cleanest way to wire them.

This node also sits at the heart of why the whole pack exists. The README's origin story: in native WANAnimate pipelines (no WanVideoWrapper), LoRA loading is broken - most weights get silently ignored and visual consistency falls apart. IAMCCS-nodes' fix is a WAN-style key remap that makes LoRAs load correctly at the torch level without the wrapper. This node inherits that machinery, which matters because the bug is real and people hit it all the time on WAN 2.2 Animate graphs.

How it works

You pick up to four LoRAs from the lora1lora4 dropdowns (populated from your ComfyUI/models/loras folder) with per-slot strength1strength4. Slots set to "no" or strength 0.0 are skipped, so leaving three empty is fine. The model_type dropdown chooses the key-remap logic: wan2x (WAN 2.1/2.2), flow (the default, for Flow-based checkpoints like WAN 2.2 LightX2V), or standard (no remap, plain apply). The remap is what makes WAN 2.1, 2.2, LightX2V, and Flow LoRAs talk to each other without you hand-editing keys.

There's also an optional lora input that accepts a LORA stack from another node (like the classic IAMCCS_WanLoRAStack), letting you exceed four LoRAs by chaining a prebuilt stack in - the README's recommended move for animation graphs that want more than four.

Inputs and outputs

Inputs: model, lora1lora4, strength1strength4, model_type, optional lora. Output: a single patched MODEL, ready for KSampler, WanAnimate, or your video pipeline.

The two that matter most: model_type (get this right or the remap won't) and the strength sliders (WAN LoRAs are usually happiest around 0.7–1.0, and you can go negative to push against a LoRA). If no LoRA is selected it warns and returns the input model unchanged - a safe fail, not a crash.

Installing it

Part of the IAMCCS-nodes pack. ComfyUI Manager → search IAMCCS, or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart ComfyUI; it's under IAMCCS/LoRA. No pip requirements, no model downloads - you bring the base WAN/Flow checkpoint and your .safetensors LoRAs, which it loads straight from the standard loras folder. README floor: ComfyUI ≥ 0.3.0, Python ≥ 3.12, Torch ≥ 2.8.

Where people get burned

  • Wrong model_type. A standard LoRA treated as flow gets key-remapped into nonsense (or "missing optional weights" warnings). Match it to the checkpoint family.
  • Dropping it in front of a sampler that isn't actually the one using the model. The patched MODEL is a new object - wire its output onward.
  • Expecting this to fix a LoRA that's simply trained wrong. The remap fixes key-naming and native-injection issues; it can't rescue a LoRA whose tensors don't match the architecture at all. If you see "missing optional weights" everywhere, check the LoRA is actually a WAN/Flow model LoRA first.
CategoryIAMCCS/LoRA

Inputs (11)

NameTypeDefaultDescription
modelMODEL
lora1COMBOno1 options: no
strength1FLOAT1.00-5–5
lora2COMBOno1 options: no
strength2FLOAT0.00-5–5
lora3COMBOno1 options: no
strength3FLOAT0.00-5–5
lora4COMBOno1 options: no
strength4FLOAT0.00-5–5
model_typeCOMBOflow3 options: wan2x, flow, standard
loraoptLORA

Outputs (1)

NameTypeDescription
MODELMODEL