Extract Kohya Lokr
Extract a LoKr (the LoRA that kept its rank) from a merge delta
- base (delta)
- kronecker_ratio (0.5)
- recipe
LoKR is the less famous sibling of LoRA, and it deserves the spotlight here. Where a plain LoRA decomposes a weight delta into two skinny matrices (up @ down), LoKR - Kronecker-based LoRA - factors the delta into a Kronecker product of two full-rank-ish smaller matrices. Net effect: a LoKr can represent a given change with less rank loss than a LoRA of the same size, which is why the community has been gravitating to it for character work on newer bases. This node extracts a kohya-format LoKr from any merge delta, same workflow as Extract Kohya Lora, different decomposition.
How it works
Extract Kohya Lokr takes a base (delta) recipe and runs a truncated Kronecker decomposition, controlled by one key knob:
kronecker_ratio- default 0.5. This decides how the matrix is split into the two Kronecker factors. 0.5 splits both dimensions roughly in half. Values toward 0 make the first factor tiny (more compression, more loss); toward 1 the opposite. 0.5 is the sane starting point, and honestly the place most people leave it.
The decomposition is rank-1 per factor pair, so the file stays small while the reconstruction quality is surprisingly good - that's the whole LoKr pitch. Output is a single recipe (MECHA_RECIPE) in LoKr weight space. Use it like any extracted adapter: wire it into Add Difference as the delta input on a compatible base, or serialize it. And same as its LoRA sibling, don't expect it to work standalone - it's a delta.
Unlike Extract Kohya Lora there's no rank / approximate-basis tuning here; the ratio is the only real parameter, which keeps the node mercifully simple.
Why pick LoKr over LoRA?
If you're targeting SDXL-era checkpoints and want max fidelity per byte, LoKr usually wins on the same budget. The catch is ecosystem support: not every tool and every base's LoRA stack treats LoKR files uniformly. On current architectures the convention has genuinely shifted - what people casually call "a LoRA" on post-Flux bases is increasingly a LoKr under the hood, as the LoRA knowledge doc in our KB notes. So extracting LoKr isn't a niche flex anymore; it's often the more future-proof choice. If you need maximum compatibility with older loaders, extract the plain LoRA instead.
Install & gotchas
ComfyUI Manager → search mecha → "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.
Two things that bite: the delta you feed it must be a weight delta (two models subtracted), not a recipe already in LoRA space - decompose once. And kohya-format LoKr keys assume the kohya naming; if your downstream expects the LyCORIS layout, grab Extract Lycoris Lokr instead. They're the same math with different labels.
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 | — |