LLM fine-tuning services: when fine-tuning beats prompting or RAG, and what the project really involves

What do LLM fine-tuning services actually deliver?

LLM fine-tuning services deliver a version of an existing language model, or a small adapter file on top of it, that has been trained on your examples to perform one job more consistently. A good engagement also delivers the cleaned dataset, the training scripts and an evaluation report showing how the tuned model compares with the untuned one.

Fine-tuning changes behaviour, not knowledge. Think of it as teaching a capable new hire your house style and your categories by showing them hundreds of worked examples, rather than handing them a library. The model learns patterns: how your replies are structured, which label a message deserves, which JSON fields to fill and how.

What it does not reliably do is memorise facts for accurate recall. If you fine-tune on your product catalogue, the model may still invent prices or mix up products. Facts belong in a retrieval layer the model reads at answer time. This single distinction saves more budgets than any technical choice.

At BtechWaleTech, another of us leads AI and ML work, with the third of us on data preparation and automation and one of us integrating the result into your software. You talk to the three of us directly.

• A baseline report: how well prompting and retrieval already do
• A cleaned, documented training and test dataset
• Adapter weights or a tuned model in your account
• Training and evaluation scripts you can rerun
• An evaluation report: baseline vs tuned, per task

Fine-tuning vs RAG vs prompting: which problem do you actually have?

Ask whether the model is failing because it lacks information or because it behaves the wrong way. Missing or changing information calls for RAG; inconsistent behaviour that a few examples in the prompt cannot fix calls for fine-tuning; most other problems are solved by better prompts.

Prompting is the cheapest lever and should always be exhausted first. A clear instruction, a handful of worked examples and a defined output format fix a surprising share of “the model is bad at this” complaints. It costs nothing to train and changes instantly.

Retrieval-augmented generation, or RAG, fetches the relevant passages from your documents and hands them to the model with each question. It is the right tool whenever answers depend on your policies, prices, manuals or anything that changes. Updating a document updates the answers the same day.

Fine-tuning earns its place when the behaviour you want is hard to describe but easy to demonstrate, when you need it thousands of times a day at lower cost, or when prompts have become so long that every call is slow and expensive. Often the final system combines all three: a tuned model for format and tone, RAG for facts and a short prompt for the task.

When is fine-tuning an LLM worth the money? Five signals

Fine-tuning is worth paying for when at least two or three of these signals are true at once. One alone is rarely enough to justify the dataset and evaluation work that LLM fine-tuning services require.

The first signal is a measured gap. You have a scored test set, strong prompts and still a clear shortfall on consistency. Without a number, you cannot know whether tuning helped. The second is data: hundreds of real input and output pairs already exist, in tickets, emails, labelled spreadsheets or edited drafts. The third is volume. At thousands of calls a day, a smaller tuned model can be cheaper and faster than a large model with a long prompt.

The fourth signal is a hard format. If downstream software breaks when a field is missing or a label is misspelt, tuning can raise compliance with the schema. The fifth is privacy or cost pressure to use a smaller open model on your own servers: tuning can bring a small model closer to a large one on a narrow task.

If none of these apply, spend the budget on prompts, retrieval and testing instead. We will tell you that plainly after the baseline study, and the study results remain useful whatever you decide.

• A measured gap after strong prompting
• Hundreds of real, good-quality examples
• High daily volume where cost or speed matters
• Strict output formats that software depends on
• A need to run a smaller model privately

When fine-tuning is the wrong answer

Fine-tuning is the wrong answer when you want the model to know your facts, when you have fewer than a few dozen good examples, or when nobody has defined what a correct output looks like. In those cases LLM fine-tuning services mostly produce an expensive model that is hard to update.

The most common mistake is “train it on all our documents so it knows our business”. Dumping manuals into a training run teaches style fragments, not reliable recall, and the model still hallucinates. When a policy changes, you would need to retrain. RAG handles this better at a fraction of the effort.

The second mistake is training on messy history. If past support replies were inconsistent, rude or wrong a fifth of the time, a model tuned on them will be inconsistent, rude or wrong a fifth of the time. Garbage in, fluent garbage out.

The third is tuning before defining success. If three managers disagree on the right label for a ticket, the model cannot learn a consistent rule. Write labelling guidelines, get agreement on a sample, and only then train.

Finally, be wary if a provider promises that fine-tuning will make a model “understand your business” or “never make mistakes”. Neither claim holds up, and both are warning signs.

Fine-tuning for consistent tone and brand voice

Tone is a classic job for LLM fine-tuning services because it is easier to show than to describe. A few hundred examples of your best-written replies can teach a model sentence length, formality, phrases you use and phrases you never use, more reliably than a page of style rules.

The raw material is usually already there: support replies your team is proud of, sales emails that worked, product descriptions a senior writer edited. We select the best, pair each with the input that prompted it, strip personal details and remove anything off-brand. Quality beats quantity; three hundred excellent pairs outperform three thousand mediocre ones.

Direct preference optimisation is another option here. OpenAI's fine-tuning documentation describes it as providing both a correct and an incorrect response to a prompt, and recommends it for tone and summarisation. The same idea works with open-model training libraries, and is useful when you can say “this reply, not that one” more easily than you can write a perfect reply.

Tone tuning still needs facts from elsewhere. The tuned model decides how to say something; retrieval or your system supplies what to say. We evaluate tone with blind side-by-side reviews by your staff, not just automatic scores.

Fine-tuning for classification: tickets, leads and documents

Classification means assigning each input to one of a fixed set of labels, and it is where LLM fine-tuning services most clearly pay off. A tuned small model can label support tickets, sort leads or tag documents with high consistency, at low cost per call, and its accuracy per label is easy to measure.

Typical tasks we see: routing emails to the right department, tagging support tickets by issue and urgency, scoring inbound leads as hot, warm or cold, flagging documents that need legal review, and detecting the intent behind WhatsApp messages. Each has a fixed label set and plenty of historical examples in your CRM or helpdesk.

The work that matters is label design. Labels must be mutually exclusive, clearly defined and backed by examples, including tricky boundary cases. We write a one-page guideline, have two of your staff label the same hundred items independently and check where they disagree. Disagreement at that stage predicts where the model will struggle.

We report precision and recall for each label, plus a confusion table showing which labels get mixed up. That tells you not only whether the tuned model is good overall but whether it fails on the categories that matter most, such as urgent complaints.

• Support tickets by issue, product and urgency
• Leads by fit and buying stage
• Emails by department or action needed
• Documents needing review or approval
• Messages by intent for chatbot routing

Fine-tuning for structured output and data extraction

Structured output, another common request for LLM fine-tuning services, means the model returns data in an exact format, usually JSON with fixed fields, so your software can use it without a human in between. Fine-tuning helps when prompting and built-in schema features still produce too many malformed or incomplete records at your volume.

Common examples: extracting invoice number, GSTIN, date, line items and totals from supplier invoices; turning free-text enquiry emails into CRM fields; converting call summaries into a fixed report template; pulling shipment details from lorry receipts or purchase orders.

Try the cheaper route first. Many hosted models now support schema-constrained output directly, and a clear schema plus a few examples may be enough. Fine-tuning becomes attractive when you need a small, cheap model to do extraction at high volume, when documents follow unusual layouts, or when field-level accuracy must climb beyond what prompting achieves.

Evaluation here is precise and satisfying: for each field, what share of test records came out exactly right? We also count records where the output was not valid JSON at all. Those two numbers, measured before and after tuning, answer the question of whether the investment worked. For invoice workflows specifically, see our invoice processing automation page.

How much training data do you need to fine-tune an LLM?

Start with around fifty to a hundred excellent examples to see whether fine-tuning helps at all, then scale up to several hundred or a few thousand for production. OpenAI's supervised fine-tuning guide sets a minimum of 10 examples, recommends beginning with 50 well-crafted ones, and notes that improvements typically appear at 50 to 100.

The right number depends on task difficulty and variety. A simple three-label classifier with clear definitions learns quickly. A tone model that must handle dozens of situations, or an extractor facing many invoice layouts, needs examples covering each variation. Coverage matters more than raw count: five hundred examples from one scenario teach less than two hundred spread across twenty.

Good LLM fine-tuning services work in rounds. Train on a first batch, evaluate, look at the failures, then collect or write examples targeting exactly those failures. This beats gathering a huge dataset up front, because you learn early whether the approach works and you spend labelling effort where it counts.

Always hold data back. A test set the model never sees during training, typically ten to twenty per cent of your examples, is the only honest way to measure improvement. OpenAI's guide makes the same point: build evaluations first, and keep holdout data as a control.

Dataset preparation: the real work in LLM fine-tuning services

Dataset preparation is usually the largest part of a fine-tuning project, and it decides the result more than the choice of model or method. It covers collecting examples, cleaning them, removing personal data, labelling, balancing and splitting into training and test sets.

Collection starts where your examples live: helpdesk exports, CRM notes, email folders, spreadsheets of past decisions, edited drafts. Cleaning removes duplicates, broken records, signatures, quoted email chains and replies that were later corrected. We check label balance too; if ninety per cent of tickets are “general”, the model may learn to say “general” for everything.

Personal data comes out before training. Names, phone numbers, email addresses, Aadhaar and PAN numbers, account numbers and addresses are masked or replaced. Under the Digital Personal Data Protection Act, 2023 your business remains responsible for personal data it processes, so we keep this step conservative and run training in your own cloud account.

Finally, the data is written in the format the training tool expects. For hosted tuning that is often JSONL in a chat structure, one example per line, as OpenAI's documentation describes; open-model libraries use similar formats. We document every cleaning rule so you can rebuild the dataset later.

• Collect from helpdesk, CRM, email and spreadsheets
• Remove duplicates, quoted chains and corrected replies
• Mask personal and financial identifiers
• Check label balance and fill gaps
• Split into training, validation and held-out test sets
• Document every rule for future rebuilds

LoRA on open models vs hosted fine-tuning: which should you choose?

In LLM fine-tuning services the method choice is simple to state: choose LoRA on an open model when you want to own the result, run it on your own servers or keep costs flat at high volume; choose a hosted provider's tuning service when you want the least infrastructure and are comfortable with the provider's terms and continuity. For many Indian businesses today, LoRA on an open model is the more durable choice.

LoRA, short for low-rank adaptation, freezes the original model and trains small extra matrices alongside it. The original paper by Microsoft Research reported that, compared with full fine-tuning of GPT-3 175B, LoRA cut trainable parameters by 10,000 times and GPU memory needs by three times. QLoRA went further, and its authors reported fine-tuning a 65-billion-parameter model on a single 48 GB GPU using 4-bit quantisation. In practice this means a 7–8 billion parameter model can be tuned on one rented cloud GPU.

Hosted tuning has a continuity risk worth knowing about. OpenAI's own fine-tuning documentation now states that it is winding down its fine-tuning platform: it is no longer accessible to new users, existing users can create training jobs for the coming months, and tuned models stay available until their base models are deprecated. Any hosted service can change like this, which is why we keep your dataset and evaluation suite portable.

With LoRA, the output is an adapter file, often a few hundred megabytes, that you store and version like any other asset. You can keep several adapters for different tasks on one base model.

Choosing a base model to fine-tune: Llama, Mistral, Qwen and others

The base model is the first technical decision in LLM fine-tuning services: choose the smallest one that reaches your target score after tuning, with a licence that fits your use and good handling of the languages your data contains. Bigger is not automatically better; a well-tuned 7B model often beats an untuned 70B one on a narrow task, and costs far less to run.

Licences differ and deserve a careful read. Mistral-7B-Instruct-v0.3 and Qwen2.5-7B-Instruct are published under Apache 2.0, according to their model cards. Meta's Llama 3.1 Community Licence allows commercial use but requires companies above 700 million monthly active users to request a separate licence, asks you to display “Built with Llama”, and requires derivative models to include “Llama” at the start of their name. None of this is legal advice; your counsel should review the licence for your case.

Language matters for Indian businesses. If your examples include Hindi or Hinglish, test the base model on those before tuning. Some models, including Indic-focused releases, handle romanised Indian languages much better than others, and tuning cannot fully fix a weak base. Our Hindi AI chatbot page covers language testing in detail.

We usually shortlist two base models, run the same small training round on both and compare on the held-out set. The cost of this extra round is small next to the cost of picking wrong.

How do you evaluate a fine-tuned model?

Evaluate a fine-tuned model on a held-out test set it never saw in training, compare it directly with the untuned baseline using the same prompt, and report task-specific scores plus a human review of a sample. If the tuned model does not clearly beat the baseline, it should not ship.

The metric depends on the task. Classification uses accuracy, precision and recall per label. Extraction uses exact-match rate per field and the share of valid JSON. Tone uses blind pairwise comparison by your staff: two replies, labels hidden, which one sounds like you? We also track speed and cost per thousand calls, because a tuned small model that matches a large one at a fraction of the cost is a win even with equal accuracy.

Watch for regressions outside the target task. A model tuned hard on ticket routing may get worse at following other instructions. If the model will do more than one job, the test set must cover all of them.

The evaluation suite is a deliverable, not a by-product. You keep the scripts and test data, so when a new base model appears next year, you can rerun the suite and decide in an afternoon whether to switch. That makes LLM fine-tuning services an asset rather than a one-off purchase.

• Held-out test set, never used in training
• Same prompt for baseline and tuned model
• Task metrics: per-label, per-field or blind pairwise
• Cost and latency per thousand calls
• Regression checks on other tasks the model handles

How much do LLM fine-tuning services cost in India?

With BtechWaleTech, LLM fine-tuning services start at ₹40,000 (US$600) for a single, well-defined task over 3–6 weeks, including the baseline study, dataset preparation, training, evaluation and handover. Programmes with several tasks, or tuned models built into a full application, start at ₹60,000.

The biggest cost driver is data. If you have clean, labelled examples, the project is mostly training and evaluation. If examples are scattered across inboxes and need labelling guidelines, staff review rounds and personal-data masking, preparation dominates the budget. The second driver is evaluation depth, especially human review for tone tasks. The third is integration: serving the tuned model behind an API your app calls.

Compute is billed by your cloud provider directly. LoRA training for a 7–8 billion parameter model typically runs on one rented GPU for hours, not weeks. For reference, AWS describes its G5 instances as carrying NVIDIA A10G GPUs with 24 GB of memory each, from one GPU on g5.xlarge to eight on g5.48xlarge. Inference costs depend on traffic and whether you self-host; we estimate both before training.

Quotes from other providers vary widely, largely because some include dataset work and evaluation while others quote only the training run. Ask what is included before comparing.

Risks and red flags when buying LLM fine-tuning services

The main risks are paying to tune when prompting would have worked, training on data you should not use, ending up without the weights, and having no honest measure of improvement. Each has a simple check you can make before signing.

Ask for the baseline. A provider of LLM fine-tuning services who will not test prompting and retrieval first has no way of proving that tuning added value. Ask where training runs and who owns the output. If training happens on the provider's machines, your data leaves your control and the weights may never reach you. Ask for the evaluation method in writing: which test set, which metrics, which baseline.

Check data rights. Customer emails and chat logs may contain personal data and third-party content. Masking, minimisation and a clear record of what was used matter, both for trust and for the DPDP Act. Check licences on the base model and any datasets added from outside.

Be cautious of guarantees. Nobody can promise a fixed accuracy before seeing your data, and a claim like “our tuned model will never hallucinate” is a red flag. What a provider can promise is a transparent process and a result you can measure yourself.

• No baseline test before training
• Training on the provider's own hardware
• Weights or adapters not handed over
• No held-out test set or written metrics
• Guaranteed accuracy before seeing data

Worked example: a hypothetical freight forwarder in Ahmedabad

To see how LLM fine-tuning services play out, say an Ahmedabad freight forwarder receives several hundred emails a day from shippers, carriers and customs brokers, and staff manually tag each one as a booking, a rate query, a document request, a complaint or an update, then copy key fields into their system. This is a hypothetical scenario to show how we would approach it, not a client story.

First, the baseline. We would take a few hundred historical emails, have two staff members label them using a one-page guideline, and test a strong prompt on a hosted model. Suppose it gets most labels right but confuses rate queries with bookings, and the field extraction misses container numbers in odd formats. And suppose volume is high enough that calling a large model on every email is costly.

That profile fits fine-tuning. We would clean and mask a few thousand past emails, train a LoRA adapter on a 7–8 billion parameter open model for classification and extraction together, and evaluate against the held-out set and the hosted baseline. If the tuned model matches or beats the baseline at lower cost per email, it goes behind an internal API in the forwarder's cloud account.

Complaints and low-confidence emails would still go to a person. A project like this would be quoted from ₹40,000, with integration into the forwarder's software quoted separately.

Fine-tuning readiness checklist and handover

Before commissioning LLM fine-tuning services, check that you can tick most of this list. If several items are open, the first phase of the project should close them, and that phase alone often answers whether tuning is needed.

At handover you receive the cleaned dataset with its documentation, the adapter weights or tuned model in your storage, training and evaluation scripts in your repository, the evaluation report and serving instructions. Two months of free maintenance follow, covering fixes and help rerunning the evaluation; ongoing care afterwards starts at ₹8,000/mo a month if you want it.

• A single task defined in one sentence
• A written definition of a correct output
• Baseline score with strong prompts, and RAG if facts are involved
• At least a hundred real examples, with more available
• Personal data masked or excluded
• Base model licence reviewed
• Cloud account ready in your name for training and serving
• A person who will review samples and approve results

LLM fine-tuning services for teams across India

We offer LLM fine-tuning services remotely to product teams and businesses across India. SaaS and product companies in Bengaluru and Hyderabad ask us for classification and extraction models that make their own features cheaper to run. Logistics and trading firms in Ahmedabad and Chennai want email and document sorting.

Insurance, lending and services businesses in Noida, Gurgaon and Kolkata often want tone-consistent drafting models with strict data handling. Teams in Thiruvananthapuram and Mangaluru ask about tuning smaller models they can run privately.

Location does not change the method: baseline first, data prepared in your accounts, training only when it earns its place, and a measured handover.