LoRA vs. QLoRA: what changes and what stays?
LoRA and QLoRA are related fine-tuning approaches, but they answer different resource constraints. LoRA trains small adapter updates alongside a base model; QLoRA combines that adapter approach with a quantized base model during fine-tuning to reduce memory pressure.
What LoRA means in practice
Low-Rank Adaptation (LoRA) adds trainable low-rank updates instead of changing every parameter of the base model. The resulting adapter is typically much smaller than a fully fine-tuned model, but it remains meaningful only in relation to its expected base model, architecture and loading workflow.
For retention, that relationship is the key fact. A file named “style-v7” may not tell a future you which base it expects, what project produced it, or which completed version you meant to keep. Treat the adapter and the context you need to recover as a deliberate family.
What QLoRA adds
QLoRA uses a quantized base model during fine-tuning while training LoRA adapters. Its central purpose is to make fine-tuning large models more memory-efficient. It does not mean that every artifact produced by the run is interchangeable with the non-quantized setup, nor does it eliminate the need to record the base, configuration and completed output you intend to preserve.
Do not use “QLoRA” as a storage label. It describes a fine-tuning approach and constraints around the base model. It is not a promise that an archive will make every resulting file smaller, and it is not a substitute for an exact recovery test.
What should you retain after a completed run?
Keep enough context to identify the completed artifact unambiguously: the released adapter, the intended base-model identity or revision, the configuration and evaluation material your project requires, and a clear project/version name. Maintain separate run-management material if your training stack needs it for resuming work.
Once a version is complete, a local archive can help preserve related files as one family and later recover them exactly. Do not archive a live run just to free space quickly; complete the run, retain what it needs, then apply a storage workflow to the finished artifact set.
Where Tensor Archive fits
Tensor Archive is a local storage and recovery tool, not a fine-tuning framework. After the completion boundary, you can analyse a related family, archive it, verify recoverability and restore a separate copy before manually removing a redundant source. This is especially useful when a base and its completed adapters or closely related releases are being retained together.
A practical rule of thumb
If the method itself is unfamiliar, start with what LoRA means in AI. Use LoRA or QLoRA terminology to describe how the artifact was produced, then use checkpoint vs. LoRA to identify what the finished files depend on. For the storage sequence, read the completed checkpoint archive guide.