Most teams reach for fine-tuning before asking whether they need it. Prompting, retrieval and routing are cheaper, faster to iterate, and reversible — and they solve a large share of the problems fine-tuning gets blamed for not solving.
Two situations where it genuinely pays
01A cost problemHigh volume on a narrow task. Tuning a small open model on production data can take per-million-token cost from around $10 to roughly $1.20 — an 88% reduction — while matching the hosted model on that specific task.
02An accuracy problemDomain language the base model has not seen enough of. With 2,000–3,000 curated examples, an accuracy gain of 10–15% is a reasonable expectation, and 20% is achievable.
Both cases share a precondition: enough real data to train on. Without volume, the economics never close and the quality gain does not materialise.
Six questions before you start
- —Have you exhausted prompting, retrieval and routing?
- —Do you have real production volume to train on?
- —Is the task narrow and stable, or still changing weekly?
- —Can you measure quality on a held-out set today?
- —Does the saving exceed the GPU and maintenance bill?
- —Who retrains it when the domain shifts in six months?
Data quality beats data quantity
The most consistent finding in this area is that 2,000 clean, well-labelled examples outperform 10,000 noisy ones. Time spent curating the set returns more than time spent collecting more of it.
