How to free disk space in a LoRA library without changing the weights
When a LoRA library takes over an SSD, “delete, prune or quantize” is not one answer. Each action changes a different thing. If you need the original bytes recoverable, archive the relationship between files before you reclaim working space.
Four actions that should not be confused
Deleting removes a copy. Pruning may remove data you later need. Quantization changes the representation and can alter runtime behavior. Archiving can preserve the original version for later exact recovery while helping manage a related local family.
The right choice depends on the requirement. If your goal is a smaller altered model for a particular runtime, investigate quantization. If your goal is to preserve a base, its LoRAs and related revisions without blindly keeping several duplicate deployments on an active SSD, use an exact recovery workflow instead.
Why the relationship matters more than the folder name
A folder convention can make libraries easier to browse, but it does not establish that two deployments carry the same data or that a version can be recovered after cleanup. The useful unit is a family with a reason to stay together:
- one base checkpoint and the LoRAs or adapters you use with it;
- a set of completed revisions from the same fine-tuning project; or
- self-contained deployments that repeat the same base model.
Keep unrelated models separate. An archive that answers “what is this for?” will also be easier to verify, restore and retire deliberately.
A lossless reclamation workflow
- Choose one related local family, not the full models directory.
- In Tensor Archive, select Add model family → Local folder, then run Analyse source.
- Review the result before archiving. The point is to measure this family, not to assume a universal percentage.
- Archive the family into a managed local copy, then run Verify.
- Restore a separate copy and load it in the workflow that matters to you.
- Only then decide manually whether an old working copy can leave the SSD.
Verification has a boundary. It proves recoverability of the stored files. It does not prove that a prompt, training run or inference result has the quality you expect. Test the restored files in the workflow you care about.
What a storage result can—and cannot—mean
The product site reports a 71.2% physical-storage reduction for a controlled family of five self-contained model-and-adapter deployments: 907.3 MB stored independently versus 261.6 MB as one family. That is an example of a family with shared data, not a claim that an isolated LoRA file will become 71.2% smaller.
Use the result as a model for thinking, not a promise. Related models can have repeat data worth retaining once. Unrelated or already-compressed files may not. The analysis result for your own family is the decision input.
The safest way to make space
Free space in stages. Start with the family you actually use. Keep an independent backup when the files matter. Verify and restore before deletion. Then repeat. This approach is slower than a mass cleanup, but it is much faster than rebuilding a library from memory after deleting the one adapter you needed.
For a technical distinction between exact storage and altered weights, read SafeTensors storage vs. quantization. To begin with one family, download Tensor Archive and follow the safe reclamation guidance.