Archive completed LoRA training checkpoints without treating restore as an afterthought
A completed training artifact is not the same thing as a live training checkpoint. Preserve the finished versions you need to keep and recover, but do not confuse a storage archive with the machinery required to resume an interrupted run.
Separate storage, training and recovery
“Checkpoint storage” is often used for several jobs at once: retaining a completed version for inference, keeping project history, recovering from a failed run, and moving data between machines. Those are not interchangeable requirements.
Tensor Archive is useful after a version is complete and you want a local family of related artifacts to remain recoverable. It is not a trainer, a live checkpoint manager or a substitute for the files and process your training stack needs to resume safely. Keep the live-run material where that stack expects it until the run is genuinely finished.
Choose the completed family deliberately
A sensible family could include completed LoRA versions from one experiment, the base model they are meant to accompany, evaluation outputs you must retain, and the small project files that make a release understandable. It should not automatically contain every experiment on the disk.
Before archiving, write a plain name that captures the project, the intended base and the version boundary. This is not busywork: a clear family is easier to restore correctly when the original training context has faded.
Archive after the completion gate
- Finish the run and retain the live training material required by your training workflow.
- Choose the completed artifacts that belong together for retrieval or deployment.
- Run Analyse source in Tensor Archive and inspect what will be included.
- Archive the family as a managed local copy, then run Verify.
- Restore to a separate output and test the recovered version in the target inference or evaluation workflow.
- Only after that proof should you manually reclaim a redundant working copy.
Exact recovery has a narrow meaning. It establishes that the archived files can be restored exactly. It does not say that the restored model is the best checkpoint, that it has the same evaluation quality you expect, or that it can resume a live run.
What the published checkpoint result shows
In Tensor Archive’s controlled sequential BF16 checkpoint validation, five complete versions totaling 4.060 GB source occupied 1.846 GB in Tensor Archive, 34.318% less than the Gear CDC comparison, with 50 out of 50 files restored and zero differing bytes. That is a storage and exact-recovery result for that fixed workload.
Keep the scope attached to the number. The result says nothing about your unrelated experiment, the performance of a live training loop, or a general savings promise. Use Analyse on your completed family before forming an expectation.
A practical operating rule
Keep two policies, not one: a live-run policy owned by the training workflow, and a completed-artifact policy for local preservation and later retrieval. The separation makes deletion less risky and makes it clearer what an archive actually proves.
For the user-facing workflow, see the Tensor Archive quick start. For a related storage decision, read why lossless storage is not weight quantization, then download Tensor Archive to test a completed family locally.