You have decided fine-tuning is genuinely the right tool. The next question is how, and the naive answer is wrong in a way that matters architecturally.
Full fine-tuning updates every weight in the model. It works, and it brings three serious problems.
It is expensive. Training requires memory for the weights, their gradients, and optimiser state — several times the memory needed merely to run the model.
It risks catastrophic forgetting. Optimising hard for your task can degrade general capabilities you never tested and did not intend to change.
It produces a whole new model. Every fine-tune is a full-sized artefact to store, deploy and serve. Ten customer-specific variants means ten complete models.
The insight behind adapters
Fine-tuning does not need to reach everywhere. The adjustment required to specialise a model is far smaller than the model itself — it can be expressed compactly.
So: freeze the original weights entirely, and train a small number of new ones alongside them.
The base model is untouched. Your adapter is a small file — often a fraction of a percent of the base model's size. At inference the two combine to produce the adapted behaviour.
Diagram, as text
- Input leads to Base model frozen
- Input leads to Adapter trained
- Base model frozen leads to Combined output
- Adapter trained leads to Combined output
Everything else in this lesson follows from that arrangement.
What it buys you
Training becomes affordable. With most weights frozen, there are no gradients or optimiser state for them, so memory drops enormously — this is what makes fine-tuning large models practical on modest hardware, particularly when combined with a quantized base.
Forgetting is contained. The original weights are literally unchanged, so general capability is preserved by construction rather than by careful tuning.
Artefacts are small. Storing fifty adapters costs a fraction of one full model.
Experiments are cheap. Training runs measured in hours rather than days means you can actually iterate — which matters more than any single run, because the first fine-tune is rarely the good one.
Base models can be swapped. You keep your training data and retrain adapters when a better base appears, rather than being locked to a checkpoint.
The serving consequence
This is where PEFT changes architecture rather than just cost.
Because the base is shared and adapters are small, one loaded base model can serve many adapters simultaneously. Requests carry which adapter to apply, and the server swaps small weight sets per request.
That makes per-customer or per-task specialisation economically viable:
┌── adapter: legal-summaries
one base model ─────┼── adapter: support-tone
(loaded once) ├── adapter: customer-acme
└── adapter: code-reviewWith full fine-tuning each of those needs its own GPU-resident model. With adapters they share one. For a product offering customer-specific behaviour, this is the difference between viable and not.
Rank, and the knob that matters
Adapters have a capacity parameter, usually called rank: how many new parameters they add.
Low rank is small and fast, and may lack capacity for complex behaviour. Higher rank captures more, costs more, and is likelier to overfit a small dataset.
The practical guidance: start low. Format and tone adaptations need very little capacity. Increase only when evaluation shows the adapter is underfitting — which is far less common than teams expect. Excessive rank on a few hundred examples memorises rather than generalises.
Data matters more than configuration
Teams spend days on hyperparameters and hours on data. That is backwards.
A small, clean dataset beats a large, noisy one. A few hundred clean, consistent examples of exactly the behaviour you want will outperform thousands of noisy ones. Inconsistent examples actively teach inconsistency.
Consistency is the point. If the goal is a tone, every example must exhibit that tone. One in five that does not teaches the model that variation is acceptable.
Cover the distribution. Include the awkward cases, not only the clean ones — otherwise the adapter is excellent on inputs resembling your examples and no better elsewhere.
Hold out a test set before training. Evaluating on training data tells you nothing, and the temptation to skip this is strong when a run finishes and looks good.
Operational reality
Version adapters with their base. An adapter is trained against a specific base checkpoint and is not portable across arbitrary versions. Record the pairing; loading a mismatched combination degrades quality without erroring.
Evaluate before promoting. Treat an adapter as a deployable artefact with a gate — the deployment lesson covers shadowing and canarying model changes.
Keep the training data. When the base improves, you retrain rather than starting over. The dataset is the durable asset; the adapter is disposable.
Watch for drift. An adapter trained on last year's ticket distribution degrades as the distribution moves. Schedule re-evaluation, not just deployment.
Check your understanding
Common mistakes
Full fine-tuning by default. Rarely the right trade for product work.
Rank chosen high "to be safe". Overfits small datasets and costs more.
Tuning hyperparameters instead of curating data. The examples decide the outcome.
No held-out set. You cannot distinguish learning from memorising.
Evaluating only the target behaviour. Regressions hide in capabilities you did not test.
Losing the training data. Makes future base upgrades a restart.
Mismatched base and adapter versions. Degrades silently.
Practice
You must serve 50 customer-specific model variants. Compare full fine-tuning with adapters on memory, latency and operations, and pick one.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Work out the memory for 50 copies of the base weights before considering anything else.
Show a strong answer
Memory decides it immediately. Take a base model whose weights occupy 40 GB at serving precision.
- Full fine-tuning: 50 variants × 40 GB = 2 TB of accelerator memory, before any KV cache. That is many machines, each mostly idle, since customer traffic is uneven.
- Adapters: one 40 GB base plus 50 adapters at, say, 100 MB each = 45 GB. One machine.
Latency.
- Full: each request goes to the machine holding that customer's model. Fine when warm; a cold customer means loading 40 GB, which is minutes.
- Adapters: swapping a 100 MB adapter is fast, and modern serving stacks can batch requests using different adapters together against the shared base — so a request for a rarely-used customer is not a cold start.
Operations.
- Full: 50 artefacts to version, deploy, monitor and roll back, each a full model. A base-model upgrade means 50 retraining runs and 50 deployments.
- Adapters: 50 small artefacts against one base. A base upgrade still means retraining all 50, but each run is far cheaper and the deployment is one base plus a directory of adapters.
Pick adapters, and it is not close at this count. Full fine-tuning becomes defensible when there are one or two variants, when the required change is too large for a low-rank update, or when a customer's contract requires genuine model isolation rather than shared weights.
The one thing to design for: adapter quality varies per customer because their data does. Evaluate per adapter, not once for the fleet — an average across 50 hides the five that are worse than the base model.
Your adapter improves the target task but the model has become worse at following general instructions. Explain what happened and how you would fix it.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Training on a narrow distribution moves the model away from everything not in it.
Show a strong answer
What happened: catastrophic forgetting, in miniature. Training on a narrow dataset moves the model towards that distribution and, unavoidably, away from behaviours the data does not exercise. If every training example is a product-support answer, the update rewards that pattern and nothing preserves the general instruction-following the base model had — so it degrades even though you never touched it.
Two things make it worse in practice: too many training steps on a small dataset, and a rank higher than the task needs, both of which let the adapter move further than the data justifies.
How I would fix it, in order:
- Measure it properly first. Build a regression set of general capabilities — instruction-following, refusals, format compliance, reasoning — and score every adapter against it alongside the target metric. Without this, the degradation is discovered by users. This is the fix that matters most, because it turns an invisible problem into a gate.
- Train less. Fewer epochs and a lower learning rate. Overfitting on a few hundred examples is the most common cause, and stopping earlier frequently recovers general behaviour at almost no cost to the target task.
- Lower the rank. Less capacity means a smaller departure from the base model. Try 8 or 16 before assuming more is needed.
- Mix in general data. Include a proportion of general instruction-following examples in the training set so the update is anchored. Even 10–20% helps noticeably.
- Reconsider whether this needs fine-tuning at all. If the target gain is modest and the regression is real, a longer prompt with good examples may be the better trade — instantly changeable and with no regression risk.
The principle: a fine-tune is a change to the whole model's behaviour, not an addition to it. Anything you do not measure, you are not preserving.
Key takeaways
- Full fine-tuning is expensive, risks forgetting, and produces a full-sized artefact per variant — rarely the right choice.
- Adapters freeze the base and train a small set of new weights, containing forgetting by construction.
- The architectural payoff is serving: one shared base can serve many adapters, making per-customer specialisation viable.
- Route by adapter identifier early, even with one adapter.
- Start with low rank and raise it only on evidence of underfitting.
- Data quality and consistency decide the outcome, far more than hyperparameter tuning — a few hundred clean examples beat thousands of noisy ones.
- Evaluate capabilities you did not intend to change, or ship silent regressions.
- Keep the dataset: adapters are disposable, training data is the durable asset.
Further reading
- Edward Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models" (ICLR 2022).
- Tim Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs" (NeurIPS 2023).
- Lequn Chen et al., "Punica: Multi-Tenant LoRA Serving" (MLSys 2024) — batching requests across different adapters.
- Chunting Zhou et al., "LIMA: Less Is More for Alignment" (NeurIPS 2023).
- Ian Goodfellow et al., "An Empirical Investigation of Catastrophic Forgetting in Gradient-Based Neural Networks" (arXiv, 2013).