Wan Video Multi-LoRA Select (CRT)

There's a specific, hard-won piece of Wan 2.2 wisdom this node is built entirely around: if you stack a speed LoRA (LightX2V, CausVid, or similar) onto both the high-noise and low-noise expert models, you wreck the things that make Wan 2.2 good - scene composition, lighting, motion, emotion. The community's fix, worked out the hard way after a widely-read PSA on the topic, is to apply the speed LoRA to the low-noise pass only, at a moderate strength, and leave the high-noise pass running clean. This node exists to make that split easy instead of something you rebuild by hand every workflow.

What it does

Rather than one LoRA stack feeding one model, this node outputs two - high_lora_stack and low_lora_stack - parsed from a single text config so you can decide, per LoRA, which pass (or both) it applies to. That maps directly onto Wan 2.2's two-expert MoE architecture, where the high-noise model handles early structure and motion and the low-noise model handles late-stage detail. Note the output type: WANVIDLORA, which is the type Kijai's ComfyUI-WanVideoWrapper ecosystem uses - this node is built for that wrapper's node graph, not the newer native ComfyUI Wan nodes, so it expects to sit inside a WanVideoWrapper-style pipeline.

The inputs and outputs that matter

• lora_batch_config (multiline STRING) - where you list which LoRAs to load, at what strength, and (implicitly, via the two-output design) which pass they're meant for. This is the node's whole interface; there's no per-LoRA widget row, it's config-driven.
• merge_loras (default true) - whether the LoRAs get baked into the model weights at load time versus applied as a live patch each step. Merging avoids repeated per-step overhead but commits you to that combination; leave it off if you're planning to swap LoRAs frequently in the same session.
• low_mem_load (default false) - flip this on if you're VRAM-constrained and loading several LoRAs at once is straining memory.
• Optional blocks (SELECTEDBLOCKS) - hooks up to a block-selector node elsewhere in the pack for applying a LoRA to specific transformer blocks only, rather than the whole model. This is an advanced technique; skip it unless you already know you want block-level control.

Outputs: high_lora_stack and low_lora_stack, each WANVIDLORA, wired into the respective model-loading stage of your WanVideoWrapper graph.

How to install it

Part of CRT-Nodes. ComfyUI Manager: search CRT-Nodes, install. Manual: git clone https://github.com/PGCRT/CRT-Nodes.git into custom_nodes, pip install -r requirements.txt, restart. You'll also want ComfyUI-WanVideoWrapper (Kijai) installed and working, since this node's output type only means something inside that pipeline - it won't connect to native ComfyUI Wan sampler nodes.

Common issues & troubleshooting

Motion and lighting look worse with a speed LoRA than without one. That's the exact failure this node is designed to prevent - double-check your lora_batch_config isn't putting the same speed LoRA on both the high and low stack. Community convention is high-noise clean, low-noise at roughly 0.4-0.6 strength.

Nothing connects to your sampler. The WANVIDLORA output type is specific to the WanVideoWrapper ecosystem - if you're using native ComfyUI Wan nodes instead, this node isn't the right one; you'd want a native LoRA loader instead.

LoRA has no visible effect. Wan 2.1 LoRAs are broadly forward-compatible with Wan 2.2, so an old LoRA not working is unusual but not impossible - check the strength value in your config text first, since a typo there (or a LoRA silently routed to the wrong stack) is the far more common cause.