LLM Fine-Tuning
I fine-tune open-weight language models for one job: your domain, your output format, your tools. The result is a model you own, small enough to run on your own hardware or behind your own API, that behaves the same way every time because nobody else is updating it.
Fine-tuning open-weight LLMs for a specific task
A frontier model behind an API is general by design. A fine-tuned model is specific by design.
Prompting a large model gets you a long way, and it is where I start. Fine-tuning earns its place when the task is narrow and repeated at volume, when the output has to match a schema exactly, when the data can't leave your network, or when the per-call cost and the dependency on someone else's model have become the problem.
Supervised fine-tuning (SFT) on a few thousand good examples teaches a smaller model the patterns a large one had to be told about in every prompt: your terminology, your house style, your categories, your JSON shape. The model stops needing a long system prompt and starts doing the job directly.
I apply the same approach as in my ASR fine-tuning work, where small speech models trained on targeted data measurably cut errors on published, held-out test sets without degrading ordinary speech.
What LLM fine-tuning is good for
Tasks where a smaller, specialised model does the job more consistently and more cheaply.
Domain adaptation
Teaching a model the vocabulary, abbreviations and conventions of your field, so it reads your documents the way your staff do and writes in the register your readers expect.
Structured output and JSON
Models trained on your schema to return valid, complete JSON every time, with the right field values, not just the right shape. Fewer retries and less validation code downstream.
Tool-calling reliability
Fine-tuning on examples of correct tool calls for your own tools and MCP servers, so an agent picks the right tool and fills its arguments correctly instead of improvising.
Distillation into a small model
Using a frontier model to generate and label training data, then distilling that behaviour into a 1B–14B parameter model that handles the task at a fraction of the cost per call.
Instruction tuning and house style
Instruction tuning for a consistent tone, length and format in generated text: summaries, reports, replies and extractions that follow your template without being reminded.
Private and on-premises LLMs
A model that runs entirely inside your infrastructure, for organisations with data residency, confidentiality or sovereignty requirements that rule out sending data to an external API.
Base models and training methods
The base model and the method are chosen for the task, the data you have and where the model has to run.
Open-weight base models
Llama, Qwen, Mistral, Gemma and Phi families, picked on licence, size, language coverage and how well the base model already does the task before any training.
LoRA, QLoRA and PEFT
Parameter-efficient fine-tuning trains small adapter weights instead of the whole model. It needs far less GPU memory, trains in hours rather than days, and lets one base model serve several adapters.
Supervised fine-tuning (SFT)
Training on input and output pairs that show exactly what good looks like. For most business tasks this is the step that does the most work.
Preference tuning (DPO)
Direct Preference Optimisation on pairs of better and worse answers, to push the model towards the responses your reviewers prefer once SFT has taught it the task.
Synthetic training data
Where real examples are scarce or sensitive, a larger model generates candidate examples from your specifications, and a person reviews them before they go into training. See datasets and training.
Evaluation before deployment
A held-out test set and task-specific metrics, comparing the fine-tuned model against the base model and the API it replaces. See evals and benchmarks.
Quantisation and serving
A fine-tuned model is only useful once it is running where your pipelines can reach it.
After training, I quantise the model to fit the hardware it will run on: GGUF for CPU and llama.cpp or Ollama deployments, AWQ and similar formats for GPU serving. Quantisation shrinks memory use and speeds up inference, and I check the quantised model against the same test set so you know what, if anything, it cost in accuracy.
Serving options depend on volume and where the data has to stay: vLLM for high-throughput GPU serving with an OpenAI-compatible API, Ollama or llama.cpp for smaller and on-premises setups, or serverless GPU inference for spiky workloads. The model can sit behind an internal API, run as a step in a pipeline, or be exposed to your agents through an MCP server.
When fine-tuning is not the answer
Part of the job is saying when a prompt or retrieval will do.
Fine-tuning changes how a model behaves. It is a poor way to give a model facts that change, such as your product catalogue, your policies or this week's prices. That is what retrieval is for: retrieval-augmented generation (RAG) looks the facts up at query time, so they stay current without retraining.
If the volume is low, the task changes every few weeks, or a frontier model with a well-written prompt and output validation already does it well, fine-tuning adds a model to maintain for little gain. In those cases I'll recommend building it with prompting and RAG first, as part of my agentic AI work, and revisiting fine-tuning once there is real usage data to train on.
Hiring me for LLM Fine-Tuning
An open-weight model trained for one job, small enough to run on your hardware or behind your own API, with an eval that shows it beats the prompt-only baseline before it ships.
Who it's for
- Teams paying per call for a frontier model to do one narrow, repetitive task
- Pipelines that break when the model's JSON or tool calls drift
- Organisations that need an LLM on-premises or offline
- Teams with a house style or output format a prompt can't hold
What you get
- Fine-tuned weights (or LoRA adapter) on an open-weight base you own
- Quantised builds for your serving target
- An eval report: base model, prompt-only baseline and fine-tune on your task
- The training data, configs and recipe for retraining
- Serving setup and integration into your pipeline or agent
What I need from you
- Examples of inputs and the outputs you want (or logs from the current system)
- The output format or tool schema the model must follow
- Where the model will run, and any hardware limits
- One person who can judge whether an output is right
How it runs
Typically 4–8 weeks, mostly driven by the training data.
- Week 1
Task and baseline
Define the task and score the current model or prompt on your examples.
- Week 1–2
Base model and method
Pick the base model and method (LoRA, SFT, DPO, distillation) for the task and the hardware.
- Weeks 2–4
Training data
Clean and format your examples; add synthetic data where it helps.
- Weeks 3–6
Train and evaluate
Train, then compare against the baseline on a held-out set.
- Weeks 5–8
Quantise and serve
Quantise, deploy behind your API or on-premises, and hand over.
Training work has no public price list. Each model is scoped after a short call and quoted as a fixed price, paid against milestones.