You've hit a wall with prompting. The model is nearly right but inconsistent, or too slow, or too expensive per call at your volume — or your data simply cannot be sent to someone else's API.
We fine-tune open-weight language models for a specific task and deploy them where you need them: your cloud, your data centre, or the device itself. We also tell you when fine-tuning is the wrong answer, which is often.
Fine-Tune, Retrieve, or Just Prompt?
This is the decision that decides the budget, and most teams get it backwards. The honest order to try things in:
1. Prompt properly first
A careful prompt with good few-shot examples solves more than people expect, and it costs a day rather than a quarter. If that clears your bar, stop — there is nothing to buy here.
2. Retrieve, if the issue is knowledge
If the model doesn't know your documents, policies, or product, that's RAG, not fine-tuning. Retrieval keeps answers current and lets you cite sources; retraining every time a document changes does not.
3. Fine-tune, if the issue is behaviour
Consistent format and tone, a narrow task done the same way every time, refusals in the right places, or a small model matching a large one's quality on your task at a fraction of the latency and cost.
Often: both
Fine-tune the behaviour, retrieve the facts. The two solve different problems, and the strongest systems we build use each for what it's actually good at.
The trap worth naming: fine-tuning is a poor way to teach a model new facts. It teaches behaviour well and knowledge badly — and what it does learn is frozen at training time and awkward to correct. Teams routinely spend a quarter fine-tuning their way toward a problem retrieval would have solved in a fortnight.
What We Fine-Tune, and Where It Runs
Open-weight models
Llama, Mistral, Qwen and others — LoRA and QLoRA for most work, full fine-tuning when the task justifies it. Vendor-neutral: we resell nothing, so the base model is chosen on your constraints.
Your infrastructure
Deployed in your VPC or on-premises, so sensitive data never leaves your environment. The usual answer for healthcare, legal, finance, and anything under a data-residency rule.
On-device
Quantised and optimised to run on phones and edge hardware, where there is no network round-trip and no data leaving the device at all. See Simulum, our own research on this.
An evaluation harness
Built before training starts, because otherwise nobody can tell improvement from a good demo. Accuracy on your task, latency, and cost per call — measured against a well-prompted baseline.
Private and On-Device Is the Part We're Known For
Plenty of firms can call a fine-tuning API. Fewer have shipped a model that runs inside a hospital's network or on a handset with a fixed memory budget, where quantisation, latency, and battery are the actual engineering problem.
- Privacy-critical healthcare: fine-tuned an LLM for a medical software company where patient data never leaves their infrastructure — delivered as a working POC integrated with their product.
- On-device language models: LLMs optimised to run on phones — the research behind our Simulum lab project.
- Our own products: we run Labs — on-device model research and voice model pipelines of our own. We eat what we cook.
Bring your use case and your constraints — we'll tell you which of the three approaches fits.
AI POC Sprint ~4 weeks · fixed scope
The usual way to start. In about four weeks you get:
- An evaluation set built from your task, and an honest baseline from a well-prompted off-the-shelf model
- A fine-tuned model measured against that baseline on accuracy, latency, and cost per call
- A deployment plan for where it actually has to run — your VPC, on-premises, or on-device
If the baseline wins, you've learned that in four weeks for a fixed price, and you've still got the evaluation set — which you needed either way.
When Not to Fine-Tune
We'd rather say this now than bill you to find out:
- Your problem is knowledge, not behaviour. Use retrieval. Fine-tuning facts is expensive and goes stale.
- You have no way to measure success. Build the evaluation set first; without it, fine-tuning is a vibe.
- Your requirements are still moving. Fine-tuning freezes behaviour. Fix the specification before you bake it into weights.
- A good prompt already clears the bar. Then you're buying a maintenance burden — a model to retrain, host, monitor, and eventually migrate.
- You need the frontier. On the broadest open-ended reasoning, the largest commercial models are still ahead. Fine-tuning wins on narrow tasks, privacy, latency, and cost.
How It Works
1. Intro call
30 minutes, free, with a senior engineer. Your task, your data, your constraints — and an honest read on whether prompting, retrieval, or fine-tuning is the right tool.
2. POC Sprint
~4 weeks: evaluation set, baseline, fine-tuned model, measured numbers, and a deployment plan for your environment.
3. Production
Serving, monitoring, cost control, and a retraining pipeline your team can run — then handover. You own the weights, the data, and the pipeline.
Not sure the problem is a model problem at all? Start with an AI Opportunity Scan. Want the broader build picture? See Custom AI Development.
FAQ
Does fine-tuning teach the model new facts?
Mostly no, and this is the most common and most expensive misunderstanding we see. Fine-tuning reliably teaches a model how to behave — format, tone, structure, task-specific reasoning patterns, when to refuse. It is an unreliable and costly way to teach it what is true, and facts learned that way are frozen at training time and hard to correct. If your problem is "the model doesn't know our documents", the answer is retrieval. If it's "it knows, but answers in the wrong shape", that's fine-tuning.
How much training data do we need?
Less than most teams expect, and quality dominates quantity. A few hundred to a few thousand genuinely representative examples usually beats tens of thousands of noisy ones scraped from a ticket system. What matters more than volume is that the examples show the behaviour you actually want, including the hard and ambiguous cases. If you don't have data yet, designing how to collect or synthesise it is the first part of the work.
Can a fine-tuned model run entirely on our own infrastructure?
Yes — this is one of our specialties. We fine-tune open-weight models that run in your VPC, on-premises, or on-device, so sensitive data never leaves your environment. We've done this for privacy-critical healthcare work, and we've optimised language models to run on phones. Nothing has to be sent to a third-party API.
How do we know the fine-tuning actually worked?
Because we build the evaluation set before we train anything. Without one you cannot tell improvement from a good demo day — and "it feels better" is not a result you can take to a board. We measure accuracy on your task, latency, and cost per call against the honest baseline of a well-prompted off-the-shelf model. Sometimes that baseline wins, and we tell you.
Which base model do you start from?
Whatever fits the constraints. Open-weight families such as Llama, Mistral and Qwen when you need ownership, privacy, or on-device deployment; commercial APIs when you don't. We're vendor-neutral and resell nothing, so the choice is driven by your latency, cost, privacy and quality requirements rather than by a partnership.
Who owns the fine-tuned model weights?
You do. The weights, the training and evaluation data, the pipeline, and the documentation are all yours, and we hand over everything needed to retrain without us. Subject to the licence of whichever base model you choose, which we'll walk you through before training starts.
What does LLM fine-tuning cost?
It depends on the state of your data and how tight the quality bar is, so we scope and price on the intro call once we understand the problem. Most engagements start as a fixed-scope AI POC Sprint of about four weeks, so the first commitment is small and judged on delivered work. If fine-tuning isn't the right approach, we say so on that call — before you spend.
Not sure fine-tuning is your answer?
That's exactly what the free 30-minute call is for. Bring the task and the constraints; we'll tell you whether to prompt, retrieve, or train — and we have no incentive to say train.
No pitch deck, no obligation. If AI is the wrong answer for your problem, we'll tell you that too.