Base model, freshly pretrained
- Predicts plausible next tokens
- No notion of 'follow this instruction'
- Might complete a question with more questions
- Knows a huge amount, applies it inconsistently
Fine-tuned model
- Follows instructions, adopts a persona or format
- Trained on curated input/output demonstrations
- Same underlying knowledge, reshaped behavior
- Same architecture, same forward pass, updated weights
Fine-tuning continues training a pretrained model on a smaller, curated dataset, adjusting its weights so its behavior — not its underlying knowledge — better matches what you want. A base model has read a large fraction of the internet and can, in principle, complete almost any text; fine-tuning is what turns that into an assistant that answers questions instead of continuing them with more questions.
Two very different scales of fine-tuning
- Full fine-tuning — update every weight in the model. Most flexible, most expensive: needs enough memory for a full training run (weights + gradients + optimizer state) on the whole model.
- PEFT (Parameter-Efficient Fine-Tuning) — freeze the base model, train a small number of new parameters bolted onto it. LoRA is the dominant technique: inject tiny trainable low-rank matrices next to existing weight matrices and leave the originals untouched.
What fine-tuning is not good at
Fine-tuning bakes behavior into weights at training time. It cannot see documents added after training finished, it cannot cite sources, and updating it means running another training job. If the actual complaint is 'the model doesn't know about X', fine-tuning is rarely the fix — a small amount of new knowledge, sparsely represented in a fine-tuning set, is easily drowned out or poorly generalized. Retrieval (handing the model the current facts at query time) usually solves that problem better and faster.
Reach for fine-tuning when...
- You need a consistent output *format* (JSON schema, house style)
- You need a specific *behavior* the base model resists (refusals, tool-call syntax)
- Prompting the behavior in costs too many tokens, every request
- You have hundreds+ of high-quality examples of the target behavior
Reach for prompting or RAG when...
- The problem is missing or stale *knowledge*, not behavior
- You need per-answer citations or provenance
- The underlying facts change frequently
- You don't yet have enough examples to fine-tune on
The three costs of fine-tuning that don't show up in the demo
- Catastrophic forgetting — training hard on a narrow dataset can quietly erode general ability that was never touched by the new data.
- Overfitting — a small dataset trained for too many epochs teaches the model to recite examples rather than generalize the pattern behind them.
- Serving complexity — a fine-tuned model per customer or use case multiplies deployment cost, unless you're careful about how adapters are served.
The rest of this star covers how a fine-tuning dataset is actually built, how LoRA and QLoRA work mechanically, a from-scratch LoRA implementation, and the memory/rank math that explains why parameter-efficient methods took over the field.