TwinFlow_SM_LoraLoader
Two slots, two strengths, no built-in loader required
- model
- model
You might look at a LoRA loader for TwinFlow and ask why ComfyUI's built-in one won't do. Fair question. The answer: TwinFlow models are loaded through a patched diffusers pipeline, not the normal Comfy model stack, so the standard loaders can't patch into them. This node is how LoRAs reach the model - it's the TwinFlow_SM_Model → TwinFlow_SM_LoraLoader → TwinFlow_SM_KSampler middle step in the example workflows.
How it works
Behind the scenes it uses diffusers' load_lora_weights / set_adapters machinery, with two layers of defensive glue. First, it sanitizes adapter names - filenames with Chinese characters, spaces, or digits-first names get normalized, because peft/diffusers choke on those. Second, and this is the part people hit, it actively cleans up previously loaded adapters. The author added that cleanup on purpose so LoRAs don't bleed from one generation into the next; if you've been mixing LoRAs in one session, that's why it doesn't silently stack them.
The inputs
There are two LoRA slots, and you don't have to use both:
- lora_1 and lora_2 - dropdowns filled from
ComfyUI/models/loras, plus anoneoption. Load one, leave the other atnone. - strength_1 and strength_2 - floats, default 1.0, range -0.1 to 10.0. For a two-LoRA stack, 0.5–0.8 each tends to behave better than two at full strength.
The single output is a model, ready to chain into the KSampler - or into another TwinFlow_SM_LoraLoader, if you're the ambitious type, though the Z-Image ecosystem's standing advice is that stacking more than one LoRA tends to collapse quality.
The honest caveats
LoRA support here is best-effort, and the README says so in so many words: it arrived via an @oliveagle PR, and the tip reads "use LoRA when inferring with 4 steps (untested, no guarantees)." A few things worth knowing before you get excited:
- Not every Z-Image or Qwen LoRA works. TwinFlow is a distilled model, so LoRAs trained for the regular Turbo/Base variants don't necessarily transfer. You generally want LoRAs trained on or verified against the TwinFlow weights. There are example workflow images in the repo showing both Qwen-Image and Z-Image LoRA usage, so it does work - just not with every file on CivitAI.
- Quant + LoRA is a tax. GGUF already pays a dequantize-patch-requantize penalty when LoRAs are involved, and at Q4 the LoRA is fighting a losing battle on top. If you want to actually use LoRAs, give the model Q8 or BF16 headroom.
- The cleanup can surprise you. Because the node deletes stale adapters when they change, don't expect cumulative stacking between runs - set your strengths in one place and it stays consistent, which is honestly the safer behavior.
Install
Same as the rest of the pack - Manager (search ComfyUI_TwinFlow) or:
cd ComfyUI/custom_nodes
git clone https://github.com/smthemex/ComfyUI_TwinFlow
cd ComfyUI_TwinFlow
pip install -r requirements.txt
LoRA files just go in ComfyUI/models/loras; nothing special. The one pack-level gotcha: diffusers >= 0.36.0 is required, and a few people have had ComfyUI Manager fail on this pack and needed the manual clone - if the Manager install errors, that's the fix.
Verdict
It's a utilitarian node for a niche within a niche: the distilled-model corner of an already-niche one-step workflow. The two slots, per-slot strengths, and adapter cleanup are all you'd reasonably want. Just set your expectations - 4 steps, Q8 model, one LoRA at a time, and it's a pleasant quality bump. Treat it as a "works, mostly" feature rather than the pack's headline, because the headline is still the speed.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| lora_1 | COMBO | 1 options: none | |
| lora_2 | COMBO | 1 options: none | |
| strength_1 | FLOAT | 1.0-0.1–10 | — |
| strength_2 | FLOAT | 1.0-0.1–10 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |