LC LoRA Save
LC LoRA Save Writes a LoRA You Can Actually Use Anywhere
- lora
What it's for
Everything the pack's LoRA nodes do - the block curve, the attention and MLP scaling, the spike softening, the per-block merge - lives in an LC_LORA object that only exists inside your workflow. LC LoRA Save is the node that turns it into a file.
Out comes a standard lora_A/lora_B safetensors under models/loras, with every edit and the strength already baked in, so it loads at 1.0 in any LoRA loader. Core's LoraLoader, another UI, someone else's workflow, a CivitAI upload - none of them need this pack, or to know what a block curve is.
That's the whole value proposition: you get to share what you tuned, and reuse it without carrying a graph around. It's the last node in the chain - Editor or Merge in, nothing out the other side.
How it works
It walks the LC_LORA object's layers and writes two tensors per layer, name.lora_B.weight and name.lora_A.weight, using the ComfyUI key convention every loader understands.
Rank is the interesting knob. At rank 0 it keeps each layer's own rank - no re-fitting, no loss, and what you'd want while you're still testing. Any other number re-fits every layer to that rank with a singular value decomposition, keeping the strongest directions and throwing away the rest: a smaller file that still behaves like the edit, as long as you don't go too low.
Format conversion is automatic. Edits stored as full adapters rather than plain low-rank pairs (LoKr, LoHa and friends) get converted to lora_A/lora_B on the way out - per layer, via a low-rank refit that defaults to rank 32 when you've left rank at 0. So a LoHA-style file goes in, a normal LoRA comes out.
dtype is bf16 by default, with fp16 and fp32 available. bf16 is the right default: same size as fp16 with a wider exponent, and no reason to reach for fp32 for a LoRA you're going to load in bf16 anyway.
The edit settings go into the file's metadata under an lc_edit key, so a saved file can tell you what was done to it.
The inputs
lora- theLC_LORAobject, from LC Krea2 LoRA Editor or LC Krea2 LoRAMerge. The tooltip names the Editor; the Merge node's output is the same type and works the same way.filename- defaultedited/%source%_edit, saved undermodels/loras.%source%becomes the original LoRA's name, and the node appends_01,_02and so on rather than overwriting.rank- 0 keeps the incoming ranks.dtype-bf16,fp16,fp32.
No outputs. It's an output node: it runs when you queue, writes the file, and shows up in the UI's outputs.
Installing it
ComfyUI Manager → search LC ModelBuilder → install → restart. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/lonecatone23/ComfyUI_LC_ModelBuilder_nodes
Check __init__.py sits directly in the pack folder, restart, Ctrl+Shift+R.
No requirements.txt here, and no heavy dependencies - this node is file I/O plus torch. The pack's install.py exists only for the face-scoring half (it sorts out onnxruntime), so if you never touch LC Face Variety Scorer or LC Krea2 LoRA Block Scan, a plain git clone is a complete install. You still need the usual Krea 2 setup to load the model: a recent ComfyUI (Krea 2 support landed in 0.25.0) and the Qwen3-VL text encoder and Qwen-Image VAE next to the checkpoint.
Where people get burned
It's beta, like its neighbours. Test the edit on a fixed seed before you bake it, and never overwrite the LoRA you started from - save into edited/, as the default filename suggests.
Nothing seems to happen. There are no outputs to wire, so the node's only evidence is the file and the log line. If you want to see the effect, that's the Editor's model output feeding a sampler, which is the intended loop anyway.
It writes on every queue. Unlike the pack's LC Checkpoint Save, there's no enabled toggle on this one, so it fires each time you hit Queue. Set filename before you start iterating or you'll accumulate a tidy pile of _01 through _19.
Filename can't escape models/loras. The node resolves the path and refuses anything that lands outside that folder - ../ tricks throw instead of writing somewhere odd.
Re-ranking is lossy, and it's the one way to ruin a good edit. Keep rank 0 while you're dialling things in, then re-rank once when you actually want a smaller file to ship. And saving then reloading gives you the same image as running the Editor directly, so a difference in output means you saved with a rank that was too low.
Hunt down the metadata before you share. lc_edit records your settings in the file. Usually a feature; worth knowing if you're posting it.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| lora | LC_LORA | Edited or merged LoRA from an LC LoRA Editor or LoRA Merge (Krea 2 or Anima). | |
| filename | STRING | edited/%source%_edit | Saved under models/loras. %source% = the original LoRA's name. A number is added if the file exists. |
| rank | INT | 00–512 | 0 = keep each layer's rank. Any other number re-fits every layer to that rank (smaller file, keeps the strongest directions). |
| dtype | COMBO | bf16 | 3 options: bf16, fp16, fp32 |
| enabled | BOOLEAN | true | Off = skip the save entirely (no file written), without physically bypassing the node. Convert to an input to gate saving from a switch elsewhere in the graph. |
| embed_workflow | BOOLEAN | true | Include the prompt and workflow JSON in the saved file's metadata. Turn off before sharing/publishing a checkpoint if you don't want your exact node graph attached. |
| metadataopt | COMBO | keep all | keep all = everything this save normally writes (with embed_workflow on, your whole node graph). necessary only = just what loading needs (quant settings, if any) plus the architecture and trigger words: no workflow, no training details, no titles or edit notes. Use it before sharing a file. |
Outputs (0)
No outputs