Continuing to train an existing model on your own data so it adapts to a specific task, domain, style, or format — as opposed to just prompting an unchanged model.
Fine-tuning is the process of taking a model that's already been trained and training it further on a focused dataset of your own, so it specializes in something. Where prompting changes only the input you give an unchanged model, fine-tuning changes the model's actual weights, baking new behavior in. It's one of three main ways to steer a model's behavior — the others being prompting and retrieval — and knowing which to reach for saves a lot of time and money.
What fine-tuning is genuinely good at is teaching style, format, and task behavior. If you want a model to always reply in a specific JSON structure, adopt a consistent brand voice, follow a particular workflow, classify inputs into your categories, or handle the quirks of a narrow domain, fine-tuning on examples of the desired behavior works well. You show it hundreds or thousands of examples of "input like this → output like that," and it learns the pattern more reliably than prompting alone can achieve.
There are two broad ways to do it, and the difference is mostly about cost. Full fine-tuning updates every weight in the model. It's the most thorough but also the most expensive — it needs roughly the resources of training, including memory for the weights plus the optimizer state and gradients, which puts full fine-tuning of large models firmly in data-center territory. In practice, most people instead use parameter-efficient fine-tuning, above all LoRA and its 4-bit variant QLoRA, which freeze the base model and train only a tiny set of add-on parameters. These methods capture most of the benefit at a small fraction of the memory and time — often letting you fine-tune on a single consumer or rented GPU. For most individuals and small teams, LoRA/QLoRA is the practical answer.
Just as important is knowing what fine-tuning is not the right tool for: injecting fresh or frequently-changing facts. If your real need is "the model should answer questions about our current documentation / product catalog / knowledge base," fine-tuning is usually the wrong, expensive choice, because the facts go stale and re-tuning is costly. The better tool is retrieval — Retrieval-Augmented Generation (RAG) — where you store your documents as embeddings, look up the relevant pieces at query time, and feed them into the model's context. That's cheaper, updates instantly when your documents change, and keeps the model itself general. A common and effective pattern is to combine both: fine-tune for behavior and format, use retrieval for facts.
It's also worth realizing that fine-tuning is already everywhere in the models you download. An instruct or chat model is literally the product of fine-tuning a raw base model on instruction-following and preference data — that's what turns a next-token predictor into a helpful assistant (see the base vs instruct explainer). So when you fine-tune an instruct model on your own data, you're adding another specialization layer on top of one that already exists.
A word on data, since it's where fine-tuning succeeds or fails. Quality matters far more than quantity: a few hundred to a few thousand clean, consistent, well-formatted examples of exactly the behavior you want usually beats a much larger but messy dataset. The examples should look like the real inputs and outputs you'll use in production, because the model learns the pattern you show it — including any inconsistencies. Poor or contradictory training data produces a poor or confused model, so most of the effort in a good fine-tune goes into curating the dataset, not the training run itself.
It's also worth setting expectations about outcomes. Fine-tuning reliably improves format adherence, tone, and task-specific behavior, and it can make a smaller model punch above its weight on a narrow task — sometimes letting a fine-tuned small model replace a larger general one for a specific job, which saves on running cost. What it won't do is turn a weak base into a strong general reasoner or reliably add facts that weren't in the base's training. Match the tool to the goal: fine-tune for how the model should behave, retrieve for what it should know, and prompt for quick adjustments that don't justify training at all.
The outputs and inputs of fine-tuning are typically safetensors files, and the base models you'd start from are the open weights in Spanvero's catalog. If you're planning to fine-tune and then run the result yourself, the honest cost math is the same as running any model: you can compare running locally, renting a GPU for the training and serving, or using an API, all with $0 markup, at /calculator/, and browse candidate base models to adapt under /models/.
LoRA · Base vs instruct model · Inference · Safetensors · Embeddings · Quantization
All explainers → · Browse models →
Open the free Spanvero advisor → · Honest, $0-markup. © 2026 Cynosure LLC.
A short email of real AI price moves, straight from the daily log — no hype. We're collecting the list now; the first issue goes out when it opens. Unsubscribe with one click.