Full Fine-Tuning vs Adapters

Full fine-tuning updates every parameter in the model and produces a new checkpoint per task. Adapters leave the pretrained weights frozen and train a small set of extra parameters instead, producing a small file per task. The difference that matters in production is what you have to store and serve.

What exactly counts as an adapter?

An adapter is any small trainable component added to a frozen pretrained model — the term names a family, not a single method. Hugging Face PEFT describes the shared idea directly: fine-tune only a small number of extra parameters, cutting compute and storage costs while yielding performance comparable to a fully fine-tuned model.

The family has two branches worth separating, because they behave differently at serving time:

• Bottleneck adapters, introduced by Houlsby et al., insert new small layers into each transformer block. The inserted layers stay in the forward pass forever.
• Low-rank adapters (LoRA) learn an additive update to existing weight matrices rather than inserting layers. Because the update is additive, it can be folded back into the original weights.

Prefix tuning, prompt tuning and IA³ round out the family; PEFT implements them behind one interface, which is why moving between them is a configuration change rather than a rewrite.

How does each one change the model?

Each approach touches a different thing, and the parameter counts are reported in the source papers rather than estimated here.

	Full fine-tuning	Bottleneck adapters	LoRA
Weights that change	All of them	New inserted layers only	A low-rank update to existing matrices
Pretrained weights	Overwritten	Frozen	Frozen
Trainable parameters per task	100%	3.6% added per task on GLUE (Houlsby et al.)	Up to 10,000x fewer than Adam full fine-tuning on GPT-3 175B (LoRA paper)
Reported quality	Baseline	Within 0.4% of full fine-tuning on GLUE	On par with or better than full fine-tuning on RoBERTa, DeBERTa, GPT-2 and GPT-3
Artefact per task	A complete checkpoint	A small module	A small adapter file
Extra inference latency	None	Yes — extra layers in the forward pass	None; the update can be merged into the base weights

The last row is the sharpest practical distinction, and the LoRA authors make it explicitly: their method adds no additional inference latency, unlike adapters. If you serve one model under a latency budget, that difference outranks the parameter counts above it.

Do adapters cost you anything at inference?

It depends on which adapter and whether you merge it. A bottleneck adapter is extra computation in every forward pass by construction. A LoRA adapter can be added into the frozen matrix once, after training, leaving a model that is architecturally identical to the original.

That choice has an operational consequence. Merged, you serve one artefact and lose the ability to swap tasks. Unmerged, you keep one base model in memory and hot-swap small adapters per task, at the cost of the addition staying in the forward pass.

distil labs ships both representations. A downloaded model tarball contains a model/ directory and a model-adapters/ directory, as documented in the local deployment guide, so you can serve merged weights with vLLM or keep the adapter separate.

When is full fine-tuning still the right call?

When the parameter budget is not the constraint and the behaviour change is large. Adapters were designed for the case Houlsby et al. describe as the problem — many downstream tasks, where an entire new model per task is parameter-inefficient. If you have exactly one task and a small student, that argument weakens considerably.

Reasonable cases for updating every weight:

• Very small students. For a 135M or 270M model from the supported models catalog, a full checkpoint is not an unmanageable artefact.
• A large behavioural shift. Teaching an output style or reasoning pattern far from pretraining asks for more capacity than a low-rank update comfortably supplies.
• You want the accuracy ceiling and have the compute. Adapters track full fine-tuning closely; closely is not identically.

Against that, the frozen-base property has a safety value that is easy to undervalue: an adapter is detachable, so a fine-tune that narrows the model too far can be undone. A full fine-tune cannot. That matters most when the failure mode is catastrophic forgetting.

On distil labs the default is the adapter path — use_lora is true in the config file — and turning it off is a deliberate choice rather than a starting point.

Related terms

Term	Relationship
PEFT	The umbrella term for adapter-style methods, including LoRA
Rank	The width of a low-rank adapter; see what is LoRA rank
Merging	Folding a LoRA update into the base weights to remove inference overhead
QLoRA	Adapters over a 4-bit frozen base; see LoRA vs QLoRA

For the head-to-head decision on one specific pair, LoRA vs full fine-tuning goes into memory and speed trade-offs in more detail.