01Supremacy LLM Training & Fine-Tuning
Models that speak your domain, not the internet’s
We fine-tune, align, and distil language models on your own data — LoRA and QLoRA through SFT, DPO, and evaluation — so you get frontier-grade behaviour on your tasks at a fraction of frontier cost.
Built for teams training models on data that cannot leave the building
01Overview
TrainingFine-tuning fails on data quality and evaluation far more often than on hyperparameters. We build the pipeline around those two first, then reach for the lightest training method that clears your bar.
01/ 02
Training
The full training pipeline, run properly
Fine-tuning fails on data quality and evaluation far more often than on hyperparameters. We build the pipeline around those two first, then reach for the lightest training method that clears your bar.
- 01
Datasets built before models
Extraction, deduplication, labelling, and held-out splits come first, with lineage on every example so any behaviour can be traced back to what taught it.
- 02
Parameter-efficient by default
LoRA adapters as the starting point, QLoRA with 4-bit quantisation when memory is the constraint, and full fine-tuning reserved for the rare cases that genuinely earn it.
- 03
Alignment matched to the task
Supervised fine-tuning sets the shape of the output, then DPO on preference pairs pins down tone, refusal behaviour, and format where they have to be exact.
- 04
Distillation for unit economics
A frontier model teaches a smaller one on your workload, so inference cost drops by an order of magnitude while task accuracy holds where it matters.
02/ 02
Evaluation & serving
A trained model is only half the delivery
The model still has to be measured, served, and retrained on a cadence. What we hand over is the harness and the serving stack, not a checkpoint file and a README.
- 05
Evaluation you can trust
Held-out task metrics, adversarial sets, and LLM-as-judge scoring on faithfulness, instruction-following, and tool-call correctness, run against every candidate before it is promoted.
- 06
Serving built for throughput
vLLM with continuous batching and hot-swappable LoRA adapters lets one deployment serve many tuned variants, instead of a GPU per team.
- 07
Regression caught before rollout
Each candidate is scored against the incumbent on the same golden set, so a model ships on measured lift or it does not ship.
- 08
Retraining on a cadence
Fresh data, drift signals, and production traces feed the next run, so the model tracks your business rather than the day its weights were frozen.
At a glance
Every capability, at a glance
8 figures, one per capability. Open any to read it in full.
How it runs
From first call to running unattended
Every engagement runs the same five steps, whatever the service.
- 01
Map the process
We sit with the people who do the work today and write down every step, exception and hand-off before anything is built.
- 02
Build against a golden set
A held-out set of real cases, agreed with you, is the bar each build has to clear before it goes anywhere near production.
- 03
Run beside the team
The system runs in parallel with the team for as long as it takes, and every disagreement between them is reviewed together.
- 04
Hand over the keys
The code, the prompts, the evaluation set and the runbooks are handed over in your accounts, under your keys.
- 05
Keep it running
We watch the runs, retrain and repair as the inputs drift, or train your own team to do the same.
Outcomes
What this looks like when it lands.
01 A support team cuts handling time with a tuned 8B model
Three hundred curated conversations were enough to teach a small open-weight model the company’s tone, escalation rules, and reply format, replacing a frontier API call on every ticket.
02 Distilling a frontier model to a tenth of the inference cost
A larger model generated training signal for a smaller one on the customer’s own classification workload, holding accuracy while moving the unit economics into a range the product could sustain.
03 A regulated insurer trains on data that was never allowed to leave
The full pipeline — curation, LoRA training, evaluation, and serving — ran inside the customer’s own VPC under their keys, so a model could finally be tuned on records that could not be sent to a provider.
Details
On the spec sheet.
- Service
- LLM Training & Fine-Tuning
- Group
- Models & intelligence
- Capabilities
- 8
- Engagement
- Map, build, run beside the team, hand over, keep running
- Ownership
- Your accounts, your keys, your region
FAQs
Asked before signing.
When is fine-tuning the right answer, and when is it not?
Fine-tuning fixes behaviour — format, tone, domain vocabulary, tool-call reliability, refusal boundaries. It does not fix missing knowledge; that is a retrieval problem. We test both against your task before recommending either, and often the answer is retrieval first and a small adapter after.
How much data do we need?
Less than most teams expect. A few hundred well-curated examples routinely beat tens of thousands of scraped ones. The work is in the curation, which is where the first phase of an engagement goes.
Which models do you train on?
Open-weight families — Llama, Qwen, Mistral, Gemma and their successors — plus managed fine-tuning on frontier providers where the licence and the data policy allow it. The base model is chosen against your evaluation set, not by reputation.
Where does training actually run?
In your cloud account or a dedicated GPU environment you control. Training data, checkpoints, and adapters stay under your keys, which is usually the whole reason a team comes to us rather than uploading to a provider.
What do we own at the end?
The adapter or checkpoint, the dataset and its lineage, the evaluation harness, the serving configuration, and a runbook for training the next version without us in the room.