闲兔 LoRA 管理器

What you're actually getting

Despite the grand name, 闲兔 LoRA 管理器 is not ComfyUI-Lora-Manager - it doesn't browse CivitAI, download anything, or touch your LoRA metadata library. It's the smaller, more useful thing: one node that applies an ordered list of LoRAs to a MODEL wire, with a per-entry strength and a per-entry note. Think rgthree's Power Lora Loader, minus the trigger-word lookup and the CivitAI integration, plus a text output.

You reach for it the moment your Qwen Image 2.1 recipe is more than one LoRA. Character plus style plus a realism pass is the normal shape of a working recipe now, and LoRAs are stackable in theory - "style + character + concept, though interactions are unpredictable" is how the knowledge base puts it, which is the polite version of what happens when you pile three files onto one sampler. What goes wrong with chaining six separate LoraLoader nodes isn't the arithmetic, it's your memory. Six weeks later, qwen_char_v3_final.safetensors @ 0.75 tells you nothing about what that file was for. This node has a note field, and it hands you a receipt.

How it works

The node's frontend (a custom JS panel) maintains the list you see. What actually reaches Python is a JSON string in the hidden lora_stack widget: each entry carries a name, a strength_model, a note, and an enabled flag.

On execution it walks that list in order and calls comfy.sd.load_lora_for_models once per enabled entry - with the CLIP side passed as None and the clip strength hard-wired to 0.0. So each LoRA patches the model that the previous one already patched. That ordering isn't cosmetic: when two LoRAs fight over the same layers, the one later in the list has the last word.

Two implementation details that matter in practice. Loaded LoRA tensors are cached per node instance, keyed on the file's mtime and size, so re-queuing doesn't re-read hundreds of megabytes off disk. And IS_CHANGED hashes your stack plus the mtime and size of every referenced file - retrain a LoRA in place and the graph re-runs instead of serving you a cached image.

The inputs and outputs worth caring about

model - your Qwen 2.1 model wire going in; the patched MODEL comes back out to your sampler (or to another patch node before it).

lora_catalog - a widget, not a socket. The frontend fills it from whatever folder_paths finds in ComfyUI/models/loras. If the only option you can pick is 未找到 LoRA 文件, that's ComfyUI telling you it sees zero LoRA files - go check extra_model_paths.yaml before you blame the node.

lora_stack - the JSON list the UI maintains. You'll rarely type in it, but it's what ends up saved inside your workflow, which is why the notes are worth filling in: your reasoning travels with the .json when you share it.

model and LoRA清单 come out. The second is the receipt: one line per applied entry, name | 强度 0.8 | your note. Wire it into a Show Text or a save-notes node and you've got provenance for free.

Install

Manager is the lazy route - search the pack title, or "Xiantu". Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/xiantuhenlan/ComfyUI-Xiantu-QwenImage21-Workbench

Restart ComfyUI, then hard-refresh the browser tab (Ctrl-Shift-R). That last step is not optional here: the list UI is a JS extension, and without a refresh you get the raw JSON widget instead of a panel. The pack declares zero Python dependencies, so there's nothing to pip install. To update later, git pull --ff-only in the pack folder and restart.

Where people get burned

Anything text-encoder-side in your LoRA is ignored. Clip strength is forced to 0.0 and no CLIP is passed at all, so a LoRA whose weights are mostly text-encoder keys will look weak or inert. On Qwen the encoder is an LLM, and LLM-encoder LoRAs do exist - if one of those is in your stack and doing nothing, this is why, not your strength value.

Zero and disabled entries behave differently. Setting an entry's strength to 0 skips the model patching but still lists it in the receipt; unticking it drops it from the list entirely. If the receipt doesn't mention a LoRA, it never ran.

Stacking breadth still collapses quality. The general pattern across 2026 bases is 2–3 LoRAs at moderate strength and trouble beyond that; Z-Image users reported outright collapse past one. Nobody has published 2.1-specific numbers yet, so start at 0.7–0.8 each and add one at a time rather than setting three to 1.0 and wondering why the face melted.

It doesn't load the model. This is a patch node. If you're expecting a checkpoint loader with a LoRA panel on it, that's a different node - wire a real 2.1 loader upstream.