Truncate Kronecker
The LoKr path
- a (delta)
- kronecker_ratio (0.5)
- use_approximate_basis (True)
- approximate_basis_iters (2)
- approximate_basis_seed (None)
- cache
- recipe
Kronecker-factorized adapters - LoKr in LyCORIS terms - became the community's default for character LoRAs on the newer architectures, and for good reason: they pack a lot of expressiveness into very few parameters. Truncate Kronecker lets you take an existing delta and re-factorize it into that same Kronecker form, instead of training one from scratch. Same family as Truncate Rank, but a different compression philosophy.
What it actually does
Where Truncate Rank keeps the top rank SVD directions, Truncate Kronecker does a rank-1 decomposition with a twist: it reshapes the tensor and factors it as a single Kronecker product w1 ⊗ w2, then rebuilds. The kronecker_ratio (default 0.5) controls the shape of the split - it picks the factor dimensions that land closest to that balance, from the tensor's integer divisors, so the decomposition stays square-ish instead of lopsided. It's aggressive compression: one rank-1 pair per tensor, no rank dial to tune. That's why it's compact, and why it's very much a "know what you're doing" node.
It shares its controls with Truncate Rank: use_approximate_basis (default on) swaps the exact SVD for torch.svd_lowrank with approximate_basis_iters and approximate_basis_seed, and there's a cache input for a Cache Unit so re-running at a different kronecker_ratio reuses the previous factorization. Output is a recipe in the delta merge space.
Wiring it up
Feed it a delta - a Mecha Lora Recipe load, or a subtract of two models - and the Kronecker-truncated delta comes out. From there it merges back into a base via a weighted-sum recipe into Mecha Merger (UNet + text encoder out). The practical use: take a regular LoRA you already have, fold it into Kronecker form, and see whether the compressed version keeps the likeness - the KB's read on LoKr is that it converges better on post-Flux architectures, so converting can genuinely win.
Installing it
This is one node in the Mecha Merge Node Pack by Louis-Jacob Lebel (ljleb), author of the sd-mecha library underneath. Install via 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
Only dependency is sd-mecha==1.1.7. No model downloads - it works on the LoRAs and checkpoints already in your ComfyUI models folder.
Gotchas
This is the fiddliest of the three. The input must be a delta; the node validates the merge space, but you still need the mental model that a full checkpoint won't behave here. kronecker_ratio is the dial everyone mis-sets first - it's not a strength, it's a shape parameter, and the effect is subtle until the factorization goes lopsided and quality drops. And single-factor Kronecker is a lossy hammer: great for a compact character LoRA, wrong tool if you need fine control over what's preserved. The merge_checkpointing toggle (fp16 CPU caching of the branch) is there like on the other recipe nodes, but for a one-shot conversion it rarely earns its memory. Use this node when you specifically want Kronecker form - otherwise Truncate Rank is the more predictable first stop.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| a (delta) | MECHA_RECIPE | — | |
| kronecker_ratio (0.5)opt | MECHA_RECIPE | 0.5 | — |
| use_approximate_basis (True)opt | MECHA_RECIPE | true | — |
| approximate_basis_iters (2)opt | MECHA_RECIPE | 2 | — |
| approximate_basis_seed (None)opt | MECHA_RECIPE | — | |
| cacheopt | MECHA_MERGE_METHOD_CACHE | — | |
| 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 | — |