Compliance-first delivery
When LLM fine-tuning services are worth paying for
LLM fine-tuning services are worth paying for when evaluation results show that better prompts and retrieval cannot reach your target, and the gap is about behaviour rather than knowledge: a consistent output format, a house style, a narrow classification at high volume, or moving a task to a smaller model that is cheaper or can run on your own servers. For knowledge that changes, retrieval is usually better. Most projects should prove the need with evals first.
Most teams asking for fine-tuning need better retrieval or a test set first
Fine-tuning is the most requested and least needed technique in applied AI. A team’s assistant gives wrong answers, someone suggests training the model on company documents, and weeks later the model sounds more like the company but is no more accurate, and is now out of date the moment a document changes. That is a retrieval problem dressed as a training problem.
Fine-tuning earns its cost in a narrower set of cases: when you need the model to behave in a particular way every time, at a scale or a price a large model cannot meet, or on infrastructure you control. Even OpenAI’s own guidance says to write evaluations and iterate on prompts first, and to fine-tune only when that is not enough. We agree, and our LLM fine-tuning services start the same way.
A note on our own experience, because it matters: the AI in Radiatus’s products runs on the Claude API with prompting and retrieval, and we do not run a fine-tuned model in production ourselves. Our fine-tuning work is for clients, built on the same evaluation discipline as our AI and data engineering and generative AI practices. Many of our fine-tuning assessments end with a recommendation not to fine-tune, and a cheaper fix.
Prompting, retrieval, fine-tuning or distillation?
| Approach | Fixes | Does not fix | Typical effort |
|---|---|---|---|
| Better prompts and examples | Instructions, tone, simple formats, many accuracy problems | Strict formats at scale, cost at very high volume | Days, with an eval set |
| Retrieval (RAG) | Answers from your documents, data that changes, citations | Behaviour and style, structured output consistency | Weeks; mostly data and search quality |
| Fine-tuning | Consistent format and behaviour, narrow tasks, domain phrasing | Fresh facts, poor data, unclear tasks | Weeks; mostly data preparation and evaluation |
| Distillation (fine-tuning a small model on a large model’s outputs) | Cost and latency at high volume, self-hosting | Tasks the large model itself gets wrong | Weeks, plus generating and checking training data |
The approaches combine. A common production design is retrieval for knowledge plus a fine-tuned small model for the formatting or classification step, checked by the same eval set.
Fine-tuning methods, in plain terms
- Supervised fine-tuning (SFT): train on input and ideal-output pairs. The workhorse for formats, extraction and style.
- LoRA and QLoRA: train a small set of extra weights instead of the whole model, so tuning fits on modest GPUs and several adapters can share one base model. QLoRA does this on a compressed copy of the model to save memory.
- Preference tuning (DPO): train on pairs of a better and a worse answer, to shift tone, helpfulness or safety behaviour without writing perfect answers.
- Reinforcement fine-tuning: score the model’s outputs with a grader and train towards higher scores. Useful for tasks with checkable answers; it needs a reliable grader.
- Distillation: generate high-quality outputs with a large model, check them, and fine-tune a smaller model on them.
Which platforms offer fine-tuning in November 2026?
This changes often, and frontier models are frequently not tunable at all. What the vendors’ own documentation lists today:
| Platform | What can be tuned | Methods |
|---|---|---|
| OpenAI API | GPT-4.1, GPT-4.1 mini and nano; GPT-4o for vision; o4-mini for reinforcement fine-tuning, per its model optimisation guide | Supervised, DPO, vision, reinforcement |
| Amazon Bedrock | Amazon Nova models and Meta Llama models; reinforcement fine-tuning extended to open-weight models such as GPT-OSS and Qwen in February 2026 (supported models) | Supervised, reinforcement, continued pre-training on some models |
| Google Vertex AI | Gemini 3.5 Flash, Gemini 3.1 Flash-Lite and the Gemini 2.5 family, plus open models such as Gemma (Gemini tuning) | Supervised, preference tuning |
| Azure AI Foundry | Selected OpenAI and open models, varying by region | Check the current model and region table |
| Open-weight on your infrastructure | Llama, Qwen, Gemma, Mistral, GPT-OSS and others | Anything: SFT, LoRA, QLoRA, DPO, reinforcement |
Claude models are not listed for fine-tuning in Bedrock’s current documentation. The newest flagship models from most vendors are usually not tunable when first released.
Open-weight models: licences matter
Fine-tuning an open-weight model gives you a model you can host anywhere, but the licence travels with it. Meta’s Llama models use the Llama Community License, which allows commercial use with conditions, including a separate licence for very large services, and an acceptable-use policy. Many Qwen models and OpenAI’s GPT-OSS models are released under Apache 2.0. Google’s Gemma models use the Gemma Terms of Use. Mistral releases some models under Apache 2.0 and others under its own licences. Read the licence on each model card before choosing a base model, and keep a record with the fine-tuned weights.
Data: where fine-tuning projects are won or lost
- Define the task precisely. One task, one output format, written down with examples of good and bad outputs.
- Collect real examples. From your own records, not invented ones. Hundreds of good examples beat thousands of noisy ones.
- Label consistently. Two people should produce the same answer for the same input. Measure their agreement; disagreement means the task definition needs work.
- Remove personal data you do not need. Mask names, phone numbers, account numbers and anything else the task does not require. Under India’s DPDP framework, training on personal data needs a lawful basis and a clear purpose; see our DPDP checklist.
- Split properly. Separate training, validation and a held-back test set, with no near-duplicates leaking between them.
Evaluating a fine-tuned model
A fine-tune is only better if it is better on your held-back test set, by the measure you agreed before training. We report task accuracy against the untuned base model and the best prompted frontier model; format validity; regressions on general behaviour the task still needs, because tuning on a narrow task can erode broader abilities; latency and cost per request; and failure examples, read by a person. If the fine-tune does not beat the prompted baseline clearly, we say so and do not deploy it.
Compute and hosting in India
LoRA fine-tuning of small and mid-sized open models fits on a single modern GPU or a few, for hours rather than weeks. Options in India include GPU instances from the major clouds and Indian GPU providers. The government’s IndiaAI Mission runs a compute portal offering subsidised GPU access to eligible Indian startups, researchers and institutions through empanelled providers; check its current eligibility and rates. For serving, vLLM can host a base model with several LoRA adapters at once, so one GPU deployment can serve multiple fine-tuned tasks.
Mistakes we see in fine-tuning projects
- Training on documents to teach facts. The model picks up style, not reliable knowledge, and the facts go stale. Use retrieval.
- No baseline. Without measuring the best prompted model first, nobody can say whether the fine-tune helped.
- Test examples leaking into training. Near-duplicates in both sets make results look far better than they are.
- Ignoring the licence. A base model whose terms do not fit your use becomes a legal problem after launch.
- Forgetting the base model will be retired. Hosted tuned models are tied to their base; plan and budget for re-tuning.
Questions to ask an LLM fine-tuning company
- What baseline will you measure before training, and on what test set?
- How will you prepare and label our data, and how much of our experts’ time will it need?
- Which base model and platform do you propose, and what does its licence allow?
- Where will training data, weights and logs be stored, and who owns them?
- What does serving cost per month, and who runs it?
- What happens when the base model is retired or our data changes?
- Will you tell us if fine-tuning is not worth it?
What drives the cost of LLM fine-tuning?
- Data preparation, nearly always the largest line: collecting, cleaning, labelling and checking examples, including your experts’ time.
- Evaluation: building the test set and running comparisons before and after.
- Training compute: often small for LoRA on open models; hosted platforms charge per training token.
- Serving: hosted fine-tuned models may carry higher per-token prices; self-hosting means GPU cost and operations work every month.
- Maintenance: re-tuning when the base model is retired or your data changes, and re-running evals each time.
We do not publish rates; the first step is a short assessment that tells you whether fine-tuning is likely to pay at all.
LLM fine-tuning services we provide
Five pieces of work. The first one decides whether the others are needed.
Fine-tuning readiness assessment
The problem
Someone has proposed fine-tuning, and nobody knows whether it will beat a better prompt or retrieval.
How we do it
We define the task, build an evaluation set from your data, measure the best prompted and retrieval-based baselines, and estimate what fine-tuning could add. You get a clear recommendation, including “do not fine-tune” when that is the answer.
What you get
- Task definition and eval set
- Prompted and RAG baselines measured
- Go or no-go recommendation
- Cost estimate if go
Training data preparation
The problem
You have records, tickets or documents, but not a clean, consistently labelled dataset.
How we do it
We extract and clean examples, design labelling guidelines, run labelling with your experts, measure agreement, mask personal data and build proper training, validation and test splits.
What you get
- Labelling guidelines
- Cleaned, labelled dataset
- Agreement measurements
- PII masking and data record
Hosted fine-tuning
The problem
You want a tuned model without running GPUs, on a platform you already use.
How we do it
We run supervised or preference tuning on OpenAI, Amazon Bedrock, Vertex AI or Azure, in your own account, compare it against the baselines and deploy it behind your application with the eval suite in CI.
What you get
- Tuning job in your account
- Before-and-after evaluation report
- Deployment and rollback plan
- Model version pinning
Open-weight fine-tuning and serving
The problem
Data rules, cost or latency mean the model has to run on infrastructure you control.
How we do it
We choose a base model with a licence that fits, fine-tune with LoRA or QLoRA, evaluate it, and deploy it on vLLM or similar on your cloud, an Indian GPU provider or on-premises, with monitoring and an upgrade path.
What you get
- Base model and licence review
- LoRA or QLoRA fine-tune
- Serving with vLLM
- Monitoring and upgrade plan
Distillation to a smaller model
The problem
A large model does the task well but costs too much or responds too slowly at your volume.
How we do it
We generate and check outputs from the large model, fine-tune a smaller model on them, and prove on your test set that quality holds while cost and latency fall.
What you get
- Checked training set from the large model
- Small-model fine-tune
- Quality, cost and latency comparison
- Fallback to the large model for hard cases
Tools we fine-tune and serve with
Chosen per project and pinned. Versions and platform support checked November 2026.
Hugging Face TRL and PEFT
Supervised fine-tuning, DPO and LoRA adapters on open-weight models, in typed, tested Python.
Unsloth and Axolotl
Faster, memory-efficient LoRA and QLoRA training on modest GPUs.
OpenAI, Bedrock, Vertex AI, Azure
Managed tuning jobs in your own account when you would rather not run GPUs.
vLLM
High-throughput serving, including several LoRA adapters on one base model.
Eval harness in CI
Held-back test sets, regression checks and reports on every change.
Python data pipelines
Extraction, labelling support, PII masking and dataset versioning. See our Python development page.
Tools we use alongside it
- PyTorch
- Hugging Face Transformers
- TRL
- PEFT
- Unsloth
- Axolotl
- vLLM
- Weights & Biases or MLflow
- Docker
- Kubernetes
Facts, versions and vendor details checked November 2026.
From question to tuned model
Stages, not a fixed calendar: the assessment often ends the project, and that is a good outcome.
Assessment
Task definition, evaluation set, prompted and retrieval baselines, and a recommendation on whether to fine-tune.
Data
Labelling guidelines, cleaned and labelled examples, personal data removed, proper splits.
Train and compare
One or more tuning runs, each compared with the baselines on the held-back test set.
Deploy and monitor
Serving, rollback plan, monitoring for drift and a schedule for re-evaluation and re-tuning.
Guides and related pages
Guides
Questions about LLM fine-tuning services
Fine-tune when the problem is behaviour: a strict output format, a consistent style, a narrow classification at high volume, or moving a task to a smaller model you can afford or host. Use retrieval when the problem is knowledge, especially knowledge that changes. Many systems use both, and an evaluation set should decide.
It depends on the task, but quality matters more than quantity. A narrow format or classification task can improve with a few hundred to a few thousand consistent, well-labelled examples. Noisy or inconsistent labels waste training runs, so we measure labelling agreement before training.
As of November 2026, OpenAI offers fine-tuning on the GPT-4.1 family, vision tuning on GPT-4o and reinforcement fine-tuning on o4-mini, not on its newest flagship models. Claude models are not listed for fine-tuning in Amazon Bedrock’s current documentation. Open-weight and some Gemini and Nova models are also tunable.
LoRA trains a small set of additional weights instead of changing the whole model, which makes fine-tuning faster and cheaper and lets several task-specific adapters share one base model. QLoRA does the same on a compressed version of the model to reduce memory needs further.
Yes, with an open-weight base model whose licence allows your use. We fine-tune with LoRA or QLoRA and serve the model with vLLM or similar on your cloud account, an Indian GPU provider or on-premises hardware. Eligible Indian startups and researchers can also apply for subsidised compute through the IndiaAI Mission.
Personal data used for training needs a lawful basis and a clear purpose under India’s DPDP framework, and should be minimised. In practice we mask or remove personal data the task does not need, keep a record of the training data, and keep processing in India where required. Your legal team confirms the basis.
Data preparation and evaluation are usually the largest costs, then serving, then training compute. We do not publish rates. A short readiness assessment tells you whether fine-tuning is likely to beat better prompts or retrieval before you spend on data and training.
No. Radiatus’s own products use the Claude API with prompting and retrieval. Our fine-tuning work is for clients, built on the same evaluation discipline, and we often recommend against fine-tuning when evaluation shows a cheaper approach works.
Wondering whether fine-tuning will actually help?
Describe the task, the model you use today, how it falls short and the data you have. We will reply with whether fine-tuning is likely to pay and what we would test first.