Open-weight model adaptation

Fine-tune open models on your own data, on your own hardware

Open-weight models are general by design. Adapting one to your domain, your formats and your language gives you a model specialised for the work you actually do, and unlike a hosted fine-tune, you keep the training data, the resulting weights and the right to run them anywhere.
  • Training data never leaves your environment
  • You own the resulting weights
  • Licence terms checked before training
run-07 · site-safety-detector (sample)
Illustrative run
2,260 images140 near-duplicates removed
Train 1,582Val 339Test 339

Labelled instances per class

  • person4,200
  • hard hat3,100
  • hi-vis vest2,700
  • forklift380

forklift: under 1,000 examples, collect more

1/4Images are de-duplicated, balanced and split before anyone labels them. Classes with too few examples are flagged early.

First, the honest question

Fine-tuning is often not what a team actually needs

The two techniques get used interchangeably and they solve different problems. Getting this wrong is the most expensive mistake in a private AI project, because fine-tuning costs real money and has to be repeated as your data changes.

If the goal is for a model to answer from documents that change, you want a private knowledge assistant built on retrieval. Fine-tuning earns its cost when behaviour, format or domain fluency is the gap.

TopicRetrieval (RAG)Fine-tuning
What it changesWhat the model can see at question timeHow the model behaves and writes
New informationAvailable as soon as it is indexedRequires retraining
CitationsEvery answer can name its sourceNo inherent provenance
Cost profileMostly build and storageGPU time, repeated on each update
Best forFacts, documents, anything that changesFormat, tone, task specialisation, thin domains

Where adaptation pays

Cases where a general model is genuinely not enough

These are the gaps retrieval cannot close, because the problem is not what the model can see but how it behaves with what it sees.

  • Languages and scripts with thin coverage

    Open models carry broad multilingual coverage, but it is uneven. Where a language, dialect or script is underrepresented, adapting on your own material closes a gap no amount of retrieval will.
  • Domain vocabulary

    Clinical shorthand, legal drafting conventions, engineering part nomenclature and internal product names are frequently absent from public training data and constant in your work.
  • Strict output formats

    When output has to be valid structured data, or follow a template a downstream system parses, fine-tuning is far more reliable than prompt instructions repeated on every call.
  • Task specialisation

    A model doing one narrow job well can be considerably smaller than a general model doing it adequately, which directly lowers the hardware it needs.
  • Smaller models, cheaper inference

    Specialising a smaller model is often the cheapest route to a latency target, because inference cost is paid on every request while training is paid once.
  • Behaviour under your rules

    Where a model has to consistently refuse, escalate or flag in ways your policy defines, that behaviour can be trained rather than hoped for.

How we do it

The data work is the project

Most of the effort in a fine-tuning project goes into assembling, cleaning and grading the training set. The training run itself is usually the short part, and it is not where projects fail.

We measure the base model on your evaluation set before training anything. Without that baseline there is no way to tell whether a fine-tune improved the model or simply changed it.

  1. Stage 1

    Decide whether to fine-tune at all

    We test whether better retrieval or better prompting closes the gap first. If it does, that is the recommendation, and it costs you far less to run.
    A clear build recommendation
  2. Stage 2

    Select a base model and check its licence

    Candidates are shortlisted on capability in your domain, the hardware you have, and licence terms for your intended commercial use. Licence review happens before training, not after.
    Base model with licence cleared
  3. Stage 3

    Build and grade the training set

    Examples are assembled from your own material, cleaned, deduplicated and checked for consistency, with a held-out split reserved for evaluation. This is where most of the project's time goes.
    Training and evaluation splits
  4. Stage 4

    Baseline the untrained model

    The base model is measured on your evaluation set so there is a number to beat, and so you can see whether adaptation was needed at all.
    Measured baseline
  5. Stage 5

    Train on your infrastructure

    Training runs on your own GPUs or inside your cloud account, so the training set never leaves your environment. Parameter-efficient methods keep the cost down and make iterating practical.
    Adapted model weightsParameter-efficient fine-tuningYour GPUs or VPC
  6. Stage 6

    Evaluate, quantize, hand over

    We check gains on the target task and that general behaviour has not degraded, quantize for your serving hardware, then hand over weights, training pipeline and runbooks so you can retrain yourselves.
    A model you own and can retrain

What you end up with

Weights, pipeline and the right to run them

A hosted fine-tune leaves you with an endpoint that works while you keep paying. Adapting an open model on your own infrastructure leaves you with artifacts.

  • The fine-tuned weights, as files you hold
  • The training pipeline, so your team can retrain as data changes
  • The evaluation set, so future changes can be measured
  • Freedom to deploy on-premises, at the edge or in your own cloud

For vision workloads the same approach applies through our model training service, and managed services can run monitoring and retraining if you would rather not.

Where training and inference run

  • Both on your infrastructure

    Training and serving on your own GPUs, with the training set never leaving the building.
  • Train in cloud, serve on-premises

    Burst GPU capacity in your own cloud account for training, with inference kept on local or edge hardware.
Compare deployment options

Getting started

From data review to a model you can retrain

  1. Step 1: Data review

    Feasibility first

    We look at the material you have, whether it can form a usable training set, and whether retrieval or prompting would get you there more cheaply.

    • NDA on request
    • Honest build-or-skip answer
  2. Step 2: Proof of concept

    4–6 weeks

    Base model baselined, training set built, a first adaptation trained and measured on your own evaluation set.

    • Measured against a baseline
    • Trained on your infrastructure
  3. Step 3: Production

    Serve, monitor, retrain

    We quantize for your serving hardware, deploy into your environment and hand over the pipeline so retraining is something your team does.

    • You own the weights
    • Retraining runbook included

FAQ

Questions about fine-tuning

  • Fine-tuning changes how a model behaves: the format it answers in, the vocabulary it uses, the task it is specialised for, and how well it handles a domain that is thinly represented in public training data. It does not reliably teach a model new facts, and facts change. If your goal is for the model to know what is in your documents today, retrieval is the cheaper and more maintainable answer, and it can cite its sources. We often build retrieval first and fine-tune afterwards, once it is clear what retrieval alone cannot fix.

Book a strategy session

Discuss a fine-tuning project

Tell us the task, roughly what training material you hold, and where training and inference need to run. An engineer will reply within one business day, under NDA if you need it.

  • Send the form, it takes 2 minutes
  • We reply within 1 business day, under NDA if you need it
  • A 30-minute call to scope feasibility and next steps

Tell us about your project

By submitting, you agree to our Privacy Policy. We never share your details.