LoRA Resize (Cumulative)

You trained a character LoRA at rank 128 because you weren't sure how much rank you'd need, and now you've got a 300MB file when 60MB would've done the job just as well. The naive fix is to retrain at a lower rank and hope you picked right. The better fix is this node: it takes an existing LoRA and resizes it down, layer by layer, keeping only as much rank as each layer actually needs to preserve a target amount of its information - rather than chopping every layer to the same fixed number and hoping nothing important got in the way of the axe.

How it works. For every weight matrix in the LoRA, the up/down decomposition gets re-run through an SVD, and instead of truncating to a fixed rank, the node keeps however many singular values are required to retain your target fraction of the cumulative singular-value sum - 90% by default. Some layers in a LoRA carry a lot of the model's actual change and need real rank to represent well; others are doing almost nothing and can be represented with rank 4 or 8 without losing anything you'd notice. A uniform rank truncation treats both the same; this node doesn't. The result is a variable-rank-per-layer LoRA that's smaller on disk than the original, in principle with less quality loss than you'd get from naively truncating every layer to the same lower number.

Inputs that matter. lora_name is the LoRA you're resizing - a dropdown of your local LoRA folder. target (default 0.9, range 0.1–1) is the one dial that actually matters: it's the fraction of cumulative singular-value energy to keep per layer, so 0.9 means "keep enough of each layer to explain 90% of its variation." Push it toward 1.0 for something closer to the original at a smaller-but-not-tiny size; pull it down toward 0.5–0.7 if you're chasing a genuinely small file and can tolerate more quality loss. max_rank (default 128, 1–3072) is a hard ceiling - no layer will end up with a higher rank than this even if hitting your target would otherwise call for more, which matters if the original LoRA itself was trained at a high rank and you want a real reduction rather than a no-op.

The rest is standard extraction plumbing shared across this pack's LoRA and DoRA tools: output_filename (default resized_lora_cumulative), save_dtype (default fp16), device (default cuda), lazy_load (on by default, streams tensors from disk instead of loading the whole file into memory), and force_clear_cache (off by default here - flip it on if you're VRAM-constrained and don't mind a slower run, since it clears CUDA memory after every layer instead of letting it accumulate).

Output. output_path (STRING) - where the resized LoRA landed. It's an output node, so ComfyUI runs it as a terminal step whether or not you wire that path anywhere further.

Installing it. Through ComfyUI Manager, search "Model Utility Toolkit," or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-ModelUtils

then restart. Nothing extra to download - it works on LoRAs already in your folder.

Troubleshooting. If the output is barely smaller than the input, your target is probably set too close to 1.0 for that particular LoRA - some LoRAs genuinely do use most of their trained rank across most layers, especially ones trained for a complex style rather than a narrow character concept, and there's not much headroom to reclaim without accepting real quality loss. If quality visibly degrades after a resize, that's target set too aggressively for that specific file rather than a fixed number that'll work everywhere - LoRA rank tables don't generalize well even for training, and they generalize even less for a post-hoc resize like this. Treat 0.9 as a starting point to A/B against the original, not a setting to trust blind.