LoRA fine-tuning: seven lessons from training marketing adapters, most of them about data

LoRA fine-tuning trains a small set of extra weights on top of a frozen model instead of retraining the whole thing, which makes it cheap enough to run on a laptop and leaves you with an adapter of tens of megabytes. That cheapness moves the hard part elsewhere. Across our own marketing adapters, the decisions that mattered most were about data and measurement, not about the method. Here are seven lessons, each with the number that taught it.

What LoRA fine-tuning is, and why it is cheap

LoRA, short for low-rank adaptation, was introduced by Hu and colleagues in 2021. Instead of updating every weight in a model, it freezes the original and learns two small matrices per layer whose product is added to it. On GPT-3 175B, the paper reports about 10,000 times fewer trainable parameters and about three times less GPU memory than full fine-tuning, with quality that matched or beat it on the models tested, and no extra inference latency once the adapter is merged.

In practice that means a 4-billion-parameter model can be adapted on a single machine, and the result is a small file you can version, swap and share. Our r25 adapter for gloofy-1-nano is 37 MB. Because adapters are this small, serving one per task costs little more than serving one in total.

Before training anything, check that the job needs it. On four of five marketing tasks we measured, the untrained base model with the rules written into its prompt beat our fine-tune; we covered that result in when to fine-tune an LLM. The lessons below apply once you have a job where training is worth it.

Seven lessons from our LoRA fine-tuning runs

Every row is recorded in our build log, including the ones where our first explanation turned out to be wrong.

Why one shared adapter failed

LoRA adds limited capacity, and tasks compete for it. When we trained five marketing jobs into one adapter, every gain on one task was paid for by a loss on another, round after round. Training one adapter per task ended it at once: each converged where the combined model never had. Since adapters are small, the cost of a family of them is close to the cost of one.

Why data quality beat everything else

The single biggest improvement in our project came from fixing labels, not from more data or a bigger model. We found 84 inconsistent labels by having three annotators judge the same ads blind and looking at where they disagreed. Later, retraining on labels from a more self-consistent annotator lifted our 4B model from 0.796 to 0.808 on exam v3.3 of our public marketing benchmark, while moving to a 14B model added only 0.008. A small adapter learns whatever the labels say, including their mistakes.

Why your training curves may be lying

For a dozen rounds we chose when to stop training by watching a validation loss computed on three examples. A number from three items moves more with which three landed in the split than with the model. One checkpoint picked that way scored 0.42 where a run stopped differently scored 0.66. Keep at least a few dozen validation examples, and confirm decisions on a held-out exam the model never saw.

Serving LoRA adapters: merge, quantise, then measure again

There are two ways to run an adapter. You can load it on top of the base model at run time, which keeps one base and many adapters, or merge it into the base and export a single file. For local tools that expect one GGUF file, merging and then quantising is the usual route.

Tooling here moves. In September, Ollama merged a change that removed its built-in converter from safetensors to GGUF and its server-side quantisation, leaving conversion and quantisation to llama.cpp's own tools. If your workflow relied on Ollama converting a model for you, check it still works, and expect to produce the GGUF with llama.cpp first.

Then measure the exported file, not the training checkpoint. Quantising our older adapter to a 4-bit GGUF cost 0.045, mostly on judgement-heavy labels; the current r25 lost 0.004. You only know which kind you have by scoring the file people will download. Our guide to choosing a local LLM for marketing covers file sizes and licences.

Where gloofy fits, and where it does not

Our released adapters are listed under the gloofy models: the r25 adapter and its GGUF for gloofy-1-nano, a creative-tagging adapter for Qwen3-14B, and a video hooks adapter. Each exists because a measurement said training beat prompting for that job. Most of our other jobs ship as the base model with a task prompt and no adapter at all.

These lessons come from one project, on marketing tasks, at 4B and 14B. They are not a general law, and some of our earlier conclusions about which data round fixed what were withdrawn once we measured seed noise. More on training and building models collects in the fine-tuning and building models hub.

What to do this week

• Before training, score the base model with your rules in its prompt on a frozen test set. That is the bar the adapter must clear.
• Audit 100 of your training labels with a second annotator before adding any new data.
• Give each task its own adapter rather than one shared one.
• Hold out a few dozen validation examples, and run at least three seeds before believing a gain.
• Score the exported, quantised file, not the checkpoint.

FAQ

What is LoRA fine-tuning?

LoRA, or low-rank adaptation, fine-tunes a model by freezing its original weights and training small additional matrices whose product is added to them. The original 2021 paper reported about 10,000 times fewer trainable parameters and three times less GPU memory than full fine-tuning on GPT-3, with comparable quality and no added latency once merged.

Should I train one LoRA adapter for several tasks or one per task?

In our experience, one per task. When we trained five marketing tasks into a single adapter, they competed for its limited capacity and each gain came at another task's expense. Separate adapters converged where the shared one never did, and lead scoring rose from 0.64 to 0.81. Adapters are small, so several cost little.

How much training data does LoRA fine-tuning need?

Less than people expect, but it has to be clean. In our runs, doubling the data bought nothing and adding 200 examples once made every score worse, while correcting 84 inconsistent labels improved results more than doubling the data or using a model 2.4 times larger. Fix label quality before adding volume.

Does quantising a LoRA model reduce accuracy?

It can, by very different amounts. When we quantised our older 4B adapter to a 4-bit GGUF, accuracy fell by 0.045, mostly on judgement-heavy labels. Our current version lost only 0.004. The only way to know is to score the exact quantised file you plan to ship on the same test set.