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
Use LoRA or QLoRA terminology to describe how the artifact was produced. Use a storage workflow to decide whether the completed files are recoverable, where they are retained and whether it is safe to remove a working copy. For the operational sequence, read the completed checkpoint archive guide.