Fine-Tuning's Real Cost Isn't the Training Run

Below roughly 5,000 to 10,000 training examples, fine-tuning on a general-purpose model produces unreliable results. The model improves on examples that look like your training data. It degrades in unpredictable ways on everything else. The fine-tuning objective pushes the model toward your examples and doesn't preserve behavior on inputs outside your training distribution.

That band is a rule of thumb. No seed, no named task, and no cited run stands behind it in this essay. Treat 5,000 to 10,000 as a planning floor, not as a measured result.

Fine-tuning is the second most frequently requested thing in applied AI work, after RAG. Teams reach for it as the default next tool. Like RAG, it's often applied to the wrong problem. The cost they price is the training run. The scoreboard is whether you have enough consistent labeled data, and a production-sampled eval against the real alternatives, to know the specialization is worth owning.

Teams hear a weight update as teaching. You take a pretrained model, you show it your data, you adjust the weights. That sounds like installing a new world. It is not. Pretraining already gave the model a general representation of language, and fine-tuning specializes that representation for a narrower purpose. In practical terms it changes the model's default behavior: the shape of the answers it tends to produce before a prompt has to force it there.

The key word is specializes. Fine-tuning changes how the model applies what it already knows. It does not reliably teach the model new knowledge, and it does not reliably raise general reasoning capability. Those are the two most common misapplications. Both fail for the same reason: fine-tuning adjusts the output distribution of a model, not its internal world model.

What fine-tuning is not good for

Knowledge injection is the most common misuse. The reasoning is intuitive. The model does not know your internal product documentation, so you fine-tune it on the documentation. This sometimes works, in the narrow sense that the model will mention the right product names and terminology. But the model is not storing facts the way a database stores records. Fine-tuning on factual information produces a model that sounds more like it knows your domain. It does not reliably know your domain the way retrieval does.

The failure mode is specific. Fine-tuned models hallucinate confidently inside the domain they were fine-tuned on. The terminology sounds right and the general framing is correct. The specific facts are wrong, in ways that are harder to detect than the generic hallucinations of the base model. The model has learned to write in your register without learning to be accurate about your content. RAG is the right solution to the knowledge problem. Fine-tuning is not.

Retrieval-plus-fine-tune and continued pretraining can look like they close this gap. They are different jobs. The run this is about is the vanilla one: the specialization you request after RAG, on a general-purpose checkpoint, with a labeled set you already have. That run does not turn the weights into a store of facts.

General capability improvement is the second misuse. Teams see a frontier model outperforming their current model on reasoning tasks and conclude that fine-tuning on reasoning examples will close the gap. It almost never does. The difference in capability between a 7B and a 70B model is not a function of the training data distribution. It's a function of parameter count, and fine-tuning doesn't change parameter count. You can adjust the surface behavior of a model, but you cannot change its fundamental reasoning ceiling.

What specialization buys

Format and style normalization is the strongest use case. If a task requires a specific output structure — a particular JSON schema, a consistent tone for customer communications, a specific way of formatting code examples — fine-tuning is very good at internalizing the requirement. The base model can be prompted to follow a format. After fine-tuning, the format compliance rate approaches ceiling and does not degrade over long context windows.

Narrow, high-frequency tasks with a consistent schema benefit for a related reason. The task is well-defined, the correct outputs are unambiguous, and you have, or can generate, enough training examples to make the specialization reliable. A model that classifies support tickets into categories, extracts structured fields from a specific document type, or translates between two well-defined formats is a good fine-tuning candidate. A model that answers general questions about a domain is not.

Then the latency case, which is system prompt compression. Long system prompts that specify personas, output formats, behavioral guardrails, and domain context add tokens to every request and increase inference cost. Fine-tuning on examples that reflect those instructions produces a model that behaves as if it has read the system prompt without the prompt being present. For high-volume inference, this can cut cost.

Behavior that lives in a prompt is easy to change and easy to accidentally bypass. Behavior that lives in weights is harder to change. It is more stable across product surfaces, prompt variants, and long conversations where the instruction hierarchy starts competing with user-provided context. That stability is valuable when the task is narrow enough that you want the model to behave the same way every time.

The data work

Quantity is the constraint teams underestimate, and the quality requirement is stricter still. Noisy training data produces a model that has memorized the noise patterns along with the signal. If your training examples contain inconsistencies, such as the same input with different expected outputs, labeling errors, or edge cases handled differently across raters, the fine-tuned model will reflect that inconsistency. Pretraining can average over enormous amounts of noisy data. Fine-tuning on a small high-noise dataset tends to amplify the noise.

Before the run, you need a data audit. The question is not whether you have 10,000 examples. It is whether those 10,000 examples are consistent, correctly labeled, and representative of the actual production distribution. That work takes longer than the fine-tuning itself — which is usually a few hours on a modern training cluster.

The evaluation problem

Evaluation is harder than a holdout suggests. The standard approach is to hold out a portion of the fine-tuning dataset and measure performance on it. That measures how well the model generalized from the training examples. The held-out set is drawn from the same distribution as the training set. It measures generalization inside your fine-tuning distribution, not on the full production distribution.

The failure mode is a holdout that looked fine. The model improves on your evaluation set, gets deployed, and performs worse on a meaningful fraction of production traffic because those inputs don't look like the fine-tuning distribution. This is a general evaluation problem. It's particularly acute for fine-tuned models, because the objective is specifically pushing the model toward the training distribution and away from inputs that don't resemble it.

An honest evaluation samples from production traffic, labels those samples, and compares the fine-tuned model to the base model on that sample. It is more expensive and takes longer. It is also the evaluation that tells you whether fine-tuning helped.

The comparison needs the actual alternative, not an artificially weak baseline. A fine-tuned small model should be compared against the prompted base model, a stronger off-the-shelf model, and a retrieval-backed version if the task touches knowledge. The useful question is not whether fine-tuning improved the model relative to itself. It is whether the improvement is large enough to justify the dataset maintenance, training process, regression risk, and operational complexity that come with owning a specialized model.

The honest state of it

Fine-tuning is useful in a narrow set of circumstances: format normalization, narrow high-frequency tasks, and latency optimization through prompt compression. With sufficient high-quality data and an honest evaluation setup, it works reliably there. You cannot use it as a knowledge store, a capability upgrade, or a substitute for retrieval infrastructure.

The teams I've seen get the most out of fine-tuning spent a long time being honest about the problem they were trying to solve before reaching for the technique. Sometimes the measured answer is that fine-tuning is not the right tool. They find that out before wasting six weeks on a training run.

The training run is cheap compared with being wrong about why you needed it. If you do not have 5,000 to 10,000 consistent, production-representative examples and a production-sampled comparison against the real alternatives, do not start the run.