Extract Lycoris Lokr
Extract a LyCORIS-format LoKr, for when the layout matters
- base (delta)
- kronecker_ratio (0.5)
- recipe
If the name "Extract Lycoris Lokr" sounds like it should do something specific, it does: compress a merge delta into a LoKr (Kronecker-factorized adapter) using LyCORIS key naming. It's the intersection of the two axis options in this pack's extraction family - the other three corners being kohya-LoRA, kohya-LoKr, and lycoris-LoRA. You pick this one when you want the LoKr's better size-for-fidelity and your downstream expects the LyCORIS layout, which as of the current generation of bases is often the layout people actually want.
What it takes and gives
base (delta)- the checkpoint difference you're compressing. From aSubtractor any delta recipe.kronecker_ratio- default 0.5. Splits the matrix into the two Kronecker factors. 0.5 splits roughly in half and is the right starting point; extremes compress harder or keep more detail at the cost of size.
Output is one recipe (MECHA_RECIPE) in LyCORIS LoKr space - a delta you feed into Add Difference on a compatible base, or serialize out as a .mecha file. Not a standalone model, same as every extraction in this pack.
Choosing the format, briefly
The extraction math - truncated Kronecker decomposition - is identical between Extract Kohya Lokr and this node. The only real difference is the prefix convention on the output keys, and that choice is downstream compatibility, not quality. Since "LoRA" as a term now does double duty for LoKrs on modern bases (see the LoRA knowledge doc in our KB - the file people call a LoRA on post-Flux architectures is frequently a LoKr under the hood), the LyCORIS flavor is the one to reach for when you're extracting for an ecosystem where LyCORIS conventions dominate. For older SDXL-era tooling, the kohya variant is the safe default. When in doubt, extract one of each and see which loads cleanly in your actual workflow - it's a two-minute test that settles the argument better than any forum thread.
The merge_checkpointing toggle caches this node's output on CPU in fp16 for repeated runs, which is the standard pack-wide convenience.
Install & gotchas
ComfyUI Manager → search mecha → install "Mecha Merge Node Pack", or:
cd ComfyUI/custom_nodes
git clone https://github.com/ljleb/comfy-mecha.git
pip install -r comfy-mecha/requirements.txt
Restart after; dependency is sd-mecha==1.1.7.
The usual extraction rules apply: feed it a weight delta (two models subtracted), not a recipe already in adapter space, and don't re-extract an extract or you compound the loss. If a downstream loader rejects the file, double-check you picked the format it expects rather than redoing the math.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| base (delta) | MECHA_RECIPE | — | |
| kronecker_ratio (0.5)opt | MECHA_RECIPE | 0.5 | — |
| merge_checkpointingopt | BOOLEAN | false | Speeds up an entire branch of a merge graph that does not change often in exchange of memory. - true: store the first output of this recipe node on cpu memory in fp16. On subsequent workflow executions, as long as the inputs do not change, the cached keys are returned after being cast to the original device and dtype. - false: do not store the output. The recipe and its inputs will re-execute on subsequent workflow executions. Note that the memory used to checkpoint the output is distinct from the cache feature. In general, you probably want to either use this *or* a cache unit, but not both at the same time because the memory adds up. The difference between merge checkpointing and cache is that merge checkpointing completely re-merges from scratch if any input changes. Merge checkpointing is also generally much faster than cache in the fast path. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| recipe | MECHA_RECIPE | — |