LoRA Resize (Fixed Rank)

Not every LoRA you download comes at the size you actually need. Someone trained at rank 128 for maximum fidelity and shipped that; you don't need that much capacity and would rather have a smaller, faster-loading file. LoRA Resize (Fixed Rank), from silveroxides' ComfyUI-ModelUtils, takes an existing LoRA and re-targets it to a rank you specify - no retraining, no access to the original checkpoints required.

How it works, and it's cleverer than it sounds. The node's own description spells out the mechanism: "Resize existing LoRA to a specific rank by merging and re-extracting via SVD." It effectively reconstructs the full-size weight delta the LoRA represents (by multiplying its up/down matrices back together), then runs the same SVD-based extraction this pack's LoRA Extract nodes use, at your new target rank. It's the resize operation applied to an already-compressed LoRA instead of to a raw model diff.

Inputs that matter. lora_name (tooltip: "LoRA to resize") is your source file. new_rank (default 64, range 1-3072) is the whole point of this node - pick the rank you actually want. svd_niter (default 2) trades SVD accuracy for speed, same as in the extraction nodes. output_filename defaults to resized_lora. save_dtype (fp16 default) and device (cuda default) round out output settings. Output is output_path.

Installing it. ComfyUI Manager, search "Model Utility Toolkit" - or cd ComfyUI/custom_nodes && git clone https://github.com/silveroxides/ComfyUI-ModelUtils, restart. No extra dependencies in the README, no model downloads; it works directly on a LoRA file you already have.

Shrinking works better than growing. This is the honest limit worth knowing going in: SVD can't invent information that was never captured. Resizing down to a lower rank is genuinely useful - you're discarding the least-important singular values and keeping the parts of the LoRA that carried the most signal, which is exactly what rank selection is for. Resizing up past the LoRA's effective original rank mostly just pads the file with low-energy directions that don't add real capacity back; if the source LoRA's meaningful information was already compressed into rank 16, asking for new_rank 128 gets you a bigger file, not a better one. Use this for compression, not for recovering detail you never had.

Lighter than extraction, and the defaults reflect it. LoRA Extract has to hold two full checkpoints (2-12GB apiece) in play at once; this node only ever works with a single LoRA file (10-200MB), which is a much smaller job. That's reflected in the defaults: lazy_load is still on by default, but force_clear_cache defaults to off here (versus on in the extraction nodes) - the tooltip even notes it's "slower but saves VRAM," which is only worth enabling if you're resizing on a genuinely tight card. For most setups, the defaults are already fine as-is.

Where it bites. Rank isn't the only thing that determines how a LoRA behaves at inference - a resized LoRA still needs the same trigger words and roughly the same strength as the original to look right, since resizing changes capacity, not the concept the LoRA encodes. If a resized LoRA looks noticeably worse than the source, try a higher new_rank before assuming the node did something wrong; and if you're chasing the smallest possible file at a target fidelity rather than a specific rank number, LoRA Resize (Frobenius) or LoRA Resize (SV Ratio) - both in this same pack - let the node pick the rank for you instead.