Fine-tuning is continuing the training of a pretrained LLM on your own dataset — hundreds to thousands of examples — so that the model’s weights themselves change. Where a prompt instructs the model per request, fine-tuning rewires the default: the behavior is baked in and no longer needs to be asked for.
How it works, briefly
You start from an existing model and train further on input–output pairs demonstrating what you want. Full fine-tuning updates every weight and is expensive; in practice most fine-tuning uses LoRA and similar parameter-efficient methods, which freeze the base model and train small adapter layers instead — cutting cost so far that an open-weight model can be fine-tuned on a single consumer GPU. Closed vendors offer fine-tuning as a hosted API service for select models.
Fine-tuning vs. prompting vs. RAG
The three are often confused, and the division of labor is clean:
- Prompting changes behavior per call — flexible, instant, no training. Try it first; frontier models follow detailed instructions well.
- RAG supplies knowledge at query time — right for facts that change or private data the model never saw.
- Fine-tuning changes behavior durably — tone, output format, domain-specific conventions, or reliably following a workflow that prompting gets right only 90% of the time.
The classic mistake is fine-tuning to teach facts: weights are a lossy, expensive place to store knowledge that a retrieval step would deliver verbatim.
When it’s worth it
Fine-tuning earns its cost when you need consistent structured output at scale, a brand voice a system prompt can’t hold, or a small cheap model to match a frontier model on one narrow task (a common cost play: fine-tune a compact open model and undercut API pricing per task). It also shortens prompts — instructions you’d repeat in every call move into the weights, saving tokens. MIT-licensed models like GLM-5.2 and open-weight coders like Kimi K2.7 Code are popular bases precisely because their licenses allow it freely.