I was drowning in fine-tuned LLM checkpoints — so I built a local archive that cut storage by ~76%
I fine-tune a lot of models (LLMs, LoRAs, adapters, checkpoints). Every experiment left another full copy on disk. Same base weights, again and again. Local SSDs filled up. Cloud storage bills crept up. I kept buying drives.
Existing tools mostly treat each version as a random pile of files. I wanted something that understands a model family: one base + many versions, exact restore, private, on my machine.
So I built Tensor Archive.
What it does:
Archives model families (base + LoRAs / adapters / checkpoints)
Shows logical size vs stored size vs space reclaimed
Restores byte-for-byte (no quantization)
Runs locally — weights stay on your Mac
Real numbers from the app (1 base + 3 adapters, three different architectures):
BERT Tiny → 76.35% reclaimed
DistilBERT → 76.46%
SmolLM2-135M → 76.33%
Average → ~76.4%
All restores exact
Public benchmark vs self-contained deployments: about 71% less space. We also measured against strong byte-level baselines (and Xet’s official engine) on sequential checkpoints — details on the site.
It’s not a public model hub. It’s a private archive for people who actually keep many versions.
Status: macOS app (Apple silicon), local-first, early access / Local Pro.
Site: tensorarchive.ai
This is a sharp pain point — full checkpoint copies get absurd once you have more than a handful of fine-tunes. The one base + many deltas model matches how people actually iterate.
Curious how you handle non-LoRA full fine-tunes vs adapter-only runs, and whether restore is bit-exact. Storage savings only matter if the restore is trustworthy.
Nice work shipping a local-first tool for this.
Slashing storage by ~76% by smart-archiving model families and deduplicating base weights across LoRAs and checkpoints is a massive relief for anyone training or fine-tuning locally. NVMe space and cloud storage bills get out of hand fast when experimenting with LLMs. Brilliant, high-utility tool for ML workflows!
A 76% storage cut is a big enough number that it's worth explaining how — is that mostly from deduplication across similar checkpoints, or more aggressive compression on the weights themselves?
The 76% saving gets attention, but the longer-term value may be recall rather than compression: helping a team answer which checkpoint came from which data and configuration, why it existed, and why one version won.
Storage pain gets the archive installed; lineage and retrieval could make it part of the team’s workflow. Are you capturing experiment context and provenance when a model is archived, or currently focusing mainly on the binaries?
"76% savings" is a dev metric — but who's feeling the pain? The ML engineer managing storage, or the finance person seeing the cloud bill? The engineer wants the tool, the finance person approves the budget. Different buyers.
The interesting part is that Tensor Archive seems less like a storage optimization tool and more like infrastructure for managing model evolution.
What would convince you that ML teams need a dedicated model archive workflow, rather than simply solving the problem with cheaper storage?