Wan Analyzer + Selective Loader V2

Wan character LoRAs have a known problem: stack more than one or two and quality collapses, or a single strong LoRA bleeds its face onto every character in frame. Block-level control is one of the few real levers against that, and this node is the whole toolkit - analyze which of Wan's 40 blocks a LoRA actually uses, then keep only the ones you want.

What it is and why you'd reach for it

Wan 2.2's DiT has 40 transformer blocks, and this node scores each one for a given LoRA (0-100% by weight magnitude) and gives you a toggle plus strength slider for every single one - live, in the same node that does the loading. That "combined" behavior is the V2 generation of this pack's design: earlier versions split analysis and selective loading across two nodes you had to wire together yourself.

This matters more for Wan than for most architectures. The community's documented failure mode with Wan character work is a LoRA's face bleeding across an entire scene when you only wanted it on one subject, or multiple LoRAs fighting each other into a blurry mess when stacked. Turning off the blocks a LoRA doesn't actually need is a direct answer to both: less surface area for a LoRA to interfere on, more headroom to stack a second one without collision.

It's one of 31 nodes in ShootTheSound/comfyUI-Realtime-Lora, which also trains Wan 2.2 LoRAs directly (High/Low/Combo noise modes) via Musubi Tuner, so you can go from training run to selectively-loaded LoRA without leaving the workflow.

How it works

The 40 blocks are grouped into rough zones - 0-9 early, 10-19 early-mid, 20-29 mid-late, 30-39 late - and there's an other_weights slider for anything a LoRA touches outside the numbered set, which matters more than it sounds: LoKR and LoHa (both auto-detected here) don't always land cleanly inside the numbered blocks. The V2 node also connects to analysis_json from a separate analyzer if you'd rather do a first pass elsewhere, and the checkboxes color themselves by impact once that's wired - blue low, red high.

Inputs and outputs that matter

• model / positive / negative - the pipeline this patches; conditioning is touched too since V2's schedule hooks run through it.
• lora_name, strength - pick and global weight.
• preset - jump to Late Only (30-39), Mid-Late (20-39), Skip Early, Mid Only (15-25), Early Only, or Half Strength before hand-tuning individual blocks.
• block_0 through block_39, plus other_weights - each a toggle with a -5 to 5 strength slider.
• strength_schedule (optional) - step:strength pairs for fading the LoRA's strength across the run, with 40+ named presets.
• save_refined_lora (optional) - bake your surviving-blocks combination into a new .safetensors file, so a stacking experiment that finally worked doesn't live only in your node graph's toggle state.
• Outputs: model, positive, negative (patched), analysis (readable), analysis_json (for chaining).

Installing it

Search "Realtime LoRA Trainer" in ComfyUI Manager, or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ShootTheSound/comfyUI-Realtime-Lora

Restart ComfyUI. This node needs nothing beyond that - no video model, no training backend. Those are only relevant to the pack's Wan trainer node.

Troubleshooting

lora_name dropdown is empty. It only lists Wan LoRAs already sitting in your loras folder. If you just trained one with this pack's own Wan trainer, feed its lora_path output into lora_path_opt instead - the dropdown is ignored once that's connected.

Stacking two LoRAs still collapses quality even with blocks trimmed down. Selective loading reduces interference, it doesn't eliminate it - Wan's documented multi-LoRA problem is real and block trimming is a mitigation, not a fix. If two full-strength LoRAs still fight, try lowering the strength on the less important one before pruning more blocks off it.

A Wan 2.1-trained LoRA behaves oddly on 2.2. Wan 2.1 LoRAs are broadly forward-compatible with 2.2, but "compatible" isn't "identical" - the block impact map you see here is for whatever architecture you loaded the LoRA against, so re-run the analysis rather than assuming a 2.1 LoRA's block scores carry over unchanged.