Fine-tuning is a data-asset decision, not a model decision

When teams debate fine-tuning, they argue about models: which base, LoRA or full fine-tune, what rank, whose GPUs. I think that's the wrong locus of decision. The model you tune starts depreciating the day a better base ships; the dataset you built to tune it appreciates every time you reuse it. Fine-tuning is a data-asset decision wearing a model decision's clothes.

The mechanics have been commoditized, which is exactly why they no longer deserve the meeting time they get. QLoRA fits a 65B model on a single 80GB A100 — around 48GB, against more than 780GB for full fine-tuning — and Guanaco reached 99.3% of ChatGPT's benchmark performance in 24 hours on one GPU. A LoRA adapter for a 175B model is a 35MB checkpoint that merges back into the weights with zero inference latency. When the tuning run costs a day and the artifact fits on a thumb drive, the run is not the scarce input. What feeds it is.

And what feeds it behaves like every data asset I've ever managed: quality dominates volume, and quality is manufactured upstream. A thousand curated OASST1 examples beat nine thousand unfiltered ones. Five hundred well-chosen GPT-4 tool-use trajectories produced meaningful capability gains in the FireActs work; five thousand approached teacher parity. The most common cause of a poor fine-tune isn't hyperparameters — it's annotation inconsistency, where preference labels routinely show 30–40% inter-annotator disagreement until someone writes real guidelines and embeds honeypot tasks to enforce them. Deduplication with MinHash, task-distribution audits, lineage tracking so recursively generated synthetic data doesn't collapse the distribution after a few generations — these are data-engineering disciplines, not modeling ones. The team that owns your warehouse quality checks already knows how to do this; most fine-tuning efforts just never ask them.

The asset framing changes real decisions. It survives base-model churn: when the next open-weight model ships, you don't restart — you re-run a cheap adapter pass over the same instruction set, eval suite, and preference pairs, and the asset transfers. It makes synthetic generation legible as manufacturing: Self-Instruct, Evol-Instruct, and Magpie are production lines for the asset, valuable precisely when you filter aggressively and track which model made what. And it reframes distillation: run the expensive frontier discovery once, capture the trajectories, and amortize them across every model size you'll ever deploy. In client conversations I now ask one question first — not "should we fine-tune?" but "what data asset would this engagement leave behind?"

One concession, because it marks a real boundary: sometimes it genuinely is a model decision. Fine-tuning data teaches capabilities — format, tool habits, reasoning style — not novel factual knowledge, and no dataset closes a capacity gap the base model can't represent. If the failure is missing knowledge, the answer is retrieval, not weights; if the failure is a capability the base fundamentally lacks, the answer is a different base. The data-asset framing applies once you've confirmed you're shaping behavior rather than installing facts.

The practical shift: put the dataset on the balance sheet. Version it, govern it, budget for curation the way you budget for GPU hours, and treat the eval set as part of the asset — it's the acceptance test every future model has to pass. Teams that do this compound; teams that treat fine-tuning as a sequence of one-off model projects pay for the same data over and over and own none of it.