What Fine-Tuning Changes
Lesson 1 of 4 in Fine-Tuning: Full, LoRA, QLoRA.
You already know how supervised fine-tuning works from the post-training domain: demonstration pairs, a Chat template, next-token Loss on the responses — the mechanics live in the SFT module and we will not reteach them. This module is the practitioner’s path: you are not a lab turning a Base model into an assistant, you are a team with a working model that keeps getting one class of things wrong, and you are deciding whether to reach for the heaviest adaptation lever there is — changing the weights.
That decision has a clean shape. Fine-tuning excels at behavior that is consistent, repeated, and present in every request: an output format the model should always emit, a house style, the phrasing and vocabulary of a specialty domain, a classification policy applied at volume. These are patterns — exactly what gradient descent on demonstrations encodes well. What fine-tuning does not reliably do is install facts: knowledge written into weights is frozen at training time, expensive to update, and recalled statistically rather than looked up. If the failure is missing, stale, or private information, the answer is Retrieval and Grounding — the two RAG modules you may have just read — not a training run. (And if an agent is orchestrating that retrieval, that is our sister AI Agent Academy’s territory; the mechanics here are the same either way.)
Key terms: Fine-tuning, LoRA, QLoRA, Adapter, Quantization, Supervised fine-tuning (SFT)
Suppose the lever is right. The next question is cost shape, and full fine-tuning — updating every parameter — has the same shape as pre-training, just shorter. Each trainable parameter needs a gradient, and the optimizer keeps its own state: Adam holds two moment estimates per parameter, typically in full precision, alongside master weights when training in Mixed precision. The training footprint is therefore a multiple of the weight footprint, which for a large model means sharding work across many GPUs — the machinery of the distributed training module, rented for your afternoon. And what you get back is a full copy of the model: gigabytes to store, version, and serve per variant.
Parameter-efficient methods attack exactly those two pain points — the optimizer-state multiple and the full-copy artifact. The comparison below is the map for the rest of this module.
| Full fine-tuning | LoRA | QLoRA | |
|---|---|---|---|
What trains | Every parameter of the model | Small low-rank matrices added beside chosen layers; the base is frozen | The same low-rank adapters; the frozen base is also stored in 4-bit |
Training memory | Weights + gradients + optimizer state for all parameters — a multiple of model size; multi-GPU territory | Frozen base needs no gradients or optimizer state; only the tiny adapters do | Quantizing the frozen base shrinks the largest remaining slice — single-GPU territory for many models |
Artifact you ship | A full model copy per variant (gigabytes and up) | An adapter file — megabytes-scale, one per task or tenant | An adapter file, same as LoRA |
Serving | Replaces the base model outright; each variant is its own deployment | Merge into the base for zero overhead, or attach at runtime — many adapters can share one base | Merge or attach likewise; inference precision is a separate decision |
Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.