Where prompting alone stops working.
Most teams should not fine-tune. Better prompting, better retrieval, and better tool design solve 80% of cases people ask us to fine-tune for. The 20% that genuinely need it - domain-specific terminology, your company's voice, output formats the base model can't reliably produce, latency requirements that need a smaller model - are where this service exists.
Last updated:
Almost what you want, consistently off.
You've optimised the prompt. You've added retrieval. You're running few-shot examples. The output is almost what you want, but consistently off in a way no prompt-engineering trick fixes. Or you need a 7B model because latency budget is sub-second and the 70B base is too slow.
That's where fine-tuning earns its keep - and where most teams should not start, because better prompting and better retrieval get them most of the way there for a fraction of the work.
Six things every fine-tune engagement gets.
Pre-fine-tune diagnostic
First, we try to make your problem go away with prompting + retrieval. About 30% of teams who came to us for fine-tuning did not need it once we ran that pass.
Data preparation
Extracting, deduplicating, formatting your training data. This is 70% of the work - we will not pretend otherwise.
Base-model selection
Which model fits your size / latency / quality / cost target. Qwen, Gemma, Llama, GLM, Kimi, Nemotron, DeepSeek, Mistral on the open-weights side; Claude, Gemini, GPT, Grok via the provider fine-tune APIs.
Training run
On our hardware infrastructure for open-weights, or via the provider's fine-tune API for cloud models.
Evaluation
Golden-set tests, A/B against the base model, regression tests for quality drift.
Deployment + retraining cadence
Onto your local-LLM hosting or the provider API. Schedule for keeping the model fresh as your data evolves.
Last lever, not first.
Most accuracy gains come from better prompting and retrieval. Fine-tuning is the lever you reach for when those have plateaued and the cost-benefit lines up.
- No training data preparation needed
- Updates instantly when you change the prompt
- Works across model versions automatically
- Solves ~80% of "the model is wrong" cases
- Cheap to maintain
- Domain vocabulary the base model never saw enough of
- Output formats prompting can't reliably enforce
- Latency budget that demands a smaller model
- High-volume generation where consistency compounds
- Distillation for inference-cost cuts
Five situations that genuinely justify it.
Domain-specific terminology
Legal documents in less-represented languages, niche industrial codes, sector-specific abbreviations and conventions the base model handles inconsistently.
Tone-of-voice at scale
Customer-facing copy at 1,000+ generated emails per day. Prompting works for 50/day; fine-tuning works for 1,000.
Structured outputs
The base model can't reliably produce your specific JSON shape, your specific Markdown layout, your sector's report format.
Latency requirements
Sub-second budget that needs a smaller model. A fine-tuned 7B can match a 70B base on a narrow task.
Distillation
Teaching a smaller, cheaper model what a larger one knows about your domain. Cuts inference cost 4-10×.
A vision-language fine-tune that recognises a decade of stage footage.
A vision-language model fine-tuned on a global events company's flagship events - recurring speakers, recurring stage layouts, recurring branding. Lifts recognition accuracy enough to make 119 TB of historical footage searchable by plain-English prompt. Hosted on a Mac Studio 512 GB; data stays inside the client's GDPR perimeter.
Three things people always ask.
Will fine-tuning reveal our training data?
Can we update it later?
What if the base model gets a major upgrade?
Tell us where prompting hit its ceiling.
30-min diagnostic call walks through your case and shows whether fine-tuning is the right next lever, or whether prompting and retrieval still have headroom. Free; written summary either way.