When should I fine-tune instead of using RAG?

Fine-tune when the problem is style, tone, or task format, not knowledge. RAG is better for questions that require up-to-date or proprietary factual information. Fine-tuning is better for classification tasks, consistent output formatting, and domain vocabulary adaptation. If you need the model to know things, use RAG. If you need the model to behave consistently in a specific way, fine-tuning is the right tool.

Which base models do you support?

We work with Llama 4 (8B and 70B), Mistral, Qwen 2.5, and Phi-4. We select the base model after benchmarking on your task, not based on popularity. The right model depends on your latency requirements, hardware constraints, and task difficulty.

How much training data do I need?

For classification tasks: 500+ labeled examples per class for LoRA fine-tuning to be meaningfully better than few-shot prompting. For generation tasks: 1,000+ input-output pairs for consistent style and format adaptation. Fewer than 500 examples total is not enough. We will tell you that upfront rather than run a training job that produces marginal gains.

Do I own the fine-tuned weights?

Yes. The fine-tuned weights and the training scripts are yours. We transfer everything at project close. The only constraint is the license of the base model: Llama 4, Mistral, and Qwen have commercial-use licenses that we review with you at project start.

How long does a fine-tuning project take?

Most fine-tuning engagements run three to six weeks. The training run itself is often the shortest part; the time goes into the data audit, base-model benchmarking, hyperparameter search, and building the evaluation pipeline that proves the result. If your data needs cleaning or labeling before it is usable, that adds time, and we scope it explicitly during the data audit rather than discovering it mid-project.

Where does the fine-tuned model run after delivery?

Wherever the economics and your data policy point. We can deliver the weights for self-hosting on your own GPUs, set you up on a managed fine-tuning endpoint from a cloud provider, or run a hybrid where sensitive workloads stay in-house. We benchmark serving cost and latency for your expected volume and hand over the inference setup so you can run the model the day the engagement closes, with no dependency on us.

Service

Fine-tuning when RAG won't solve it.

RAG solves knowledge problems. Fine-tuning solves behavior problems. If your model needs to answer questions from your documents, use RAG. If your model needs to reliably classify, extract, or generate in a specific format and style, fine-tuning will outperform prompt engineering at scale.

We fine-tune open-weight models using LoRA, QLoRA, or full fine-tuning depending on your data, task, and hardware constraints. We benchmark before we train and we measure after, so you get a model card that shows exactly what improved and by how much.

This is not a black-box service. You understand what we did, why we chose the approach, and what the trade-offs are. The weights are yours at handoff.

How we work

Tell us what you're building.

What we fine-tune for.

Four categories of task where fine-tuning meaningfully outperforms prompting general-purpose models.

Classification and intent models

Fine-tuned models for your specific label set: support ticket routing, document classification, intent recognition, sentiment scoring. Faster and cheaper at inference than a general-purpose frontier model for the same task.

Domain-adapted generation models

When your product needs to generate text in a specific tone, style, or format consistently (legal summaries, clinical notes, technical reports) a fine-tuned model produces more consistent output than prompt engineering alone.

Instruction-tuned task models

Models fine-tuned to follow your specific task format: extract a structured JSON from a document, convert a brief into a proposal, transform a transcript into a summary. Task-specific fine-tuning outperforms few-shot prompting when you need reliability at scale.

Evaluation pipelines

Fine-tuning without measurement is guesswork. We build evaluation pipelines that measure the delta between your base model and the fine-tuned version on your actual task: precision, recall, BLEU, or human-preference scores depending on the task type.

How it works.

We do not run training jobs without a baseline and an eval set. Every run is measured against defined criteria.

Task definition and data audit

We define exactly what the model should do, what counts as correct output, and how we will measure improvement. Then we audit your training data for size, quality, label consistency, and class balance before committing to a training run.

Base model selection

We benchmark two or three base models on your task using few-shot prompting to establish a baseline. The model with the best baseline performance is usually the best candidate for fine-tuning. We pick based on data, not preference.

Fine-tuning and hyperparameter search

We run LoRA or QLoRA for efficiency unless the task requires full fine-tuning. We tune learning rate, LoRA rank, and training epochs with a held-out eval set. We do not ship the first run. We ship the run that beats the baseline on your eval metrics.

Evaluation and delivery

We deliver the fine-tuned weights, a model card documenting performance on your eval set, and an inference setup you can run immediately. If the model does not beat the baseline meaningfully, we tell you before charging for delivery.

Base models we work with.

We select the base model after benchmarking on your task, not based on what's popular this week.

Llama 48B and 70B variants; strong instruction following baseline

Mistral / MixtralEfficient for classification and generation tasks

Qwen 2.5Strong multilingual and coding task performance

Phi-4High performance per parameter; good for edge/on-premise

When fine-tuning pays off, and what it really costs.

A fine-tuned model is an asset you own, with an up-front cost and a maintenance tail. It earns its keep in a specific situation, and we would rather you know the whole picture than just the upside.

The payback is volume. A fine-tuned small model can match a frontier model on a narrow task at a fraction of the per-call cost. That spread only pays back the project when the task runs at real volume, so we model the break-even during scoping. At low volume, prompting a frontier model is usually cheaper all-in, and we will say so.

The data is the project.Most of the work, and most of what determines the result, is the training data: enough examples, consistent labels, and balanced classes. We audit your data before committing to a run, and where it is thin we can often bootstrap it from a frontier model's validated outputs rather than abandoning the idea.

It needs re-evaluation, not just training. A fine-tune is a snapshot. When your task shifts or the inputs drift, performance degrades quietly. We hand over the evaluation pipeline alongside the weights, so your team can measure the model on new data and decide when a refresh is worth it, rather than trusting a number from launch day indefinitely.

Serving is part of the cost. An open-weight model you host has its own footprint: GPU capacity, a serving stack, and the engineering attention they need. For some teams a managed fine-tuning endpoint is the better trade; for others, self-hosting wins on cost or data policy. We price both paths so the deployment decision is made on numbers, not defaults.

Who this isn't for.

Fine-tuning is the right tool for specific problems. Here is when it is not.

Teams who want to add knowledge to a model
Fine-tuning does not reliably inject factual knowledge. It bakes in behaviors and styles. If you need the model to answer questions from your documents, use RAG. We can build that too.
Teams with fewer than 500 labeled examples
Below that threshold, few-shot prompting a frontier model will usually outperform a fine-tuned smaller model. We will tell you this at the data audit stage rather than take your money on a training run that won't beat your baseline.
Teams who need OpenAI-grade general reasoning
If your task requires strong general reasoning, complex multi-step analysis, broad world knowledge, nuanced judgment: GPT-5 or Claude Sonnet 5 will outperform any fine-tuned open-weight model. Fine-tuning trades general capability for task-specific performance.

Frequently asked questions.

When should I fine-tune instead of using RAG?: Fine-tune when the problem is style, tone, or task format, not knowledge. RAG is better for questions that require up-to-date or proprietary factual information. Fine-tuning is better for classification tasks, consistent output formatting, and domain vocabulary adaptation. If you need the model to know things, use RAG. If you need the model to behave consistently in a specific way, fine-tuning is the right tool.
Which base models do you support?: We work with Llama 4 (8B and 70B), Mistral, Qwen 2.5, and Phi-4. We select the base model after benchmarking on your task, not based on popularity. The right model depends on your latency requirements, hardware constraints, and task difficulty.
How much training data do I need?: For classification tasks: 500+ labeled examples per class for LoRA fine-tuning to be meaningfully better than few-shot prompting. For generation tasks: 1,000+ input-output pairs for consistent style and format adaptation. Fewer than 500 examples total is not enough. We will tell you that upfront rather than run a training job that produces marginal gains.
Do I own the fine-tuned weights?: Yes. The fine-tuned weights and the training scripts are yours. We transfer everything at project close. The only constraint is the license of the base model: Llama 4, Mistral, and Qwen have commercial-use licenses that we review with you at project start.
How long does a fine-tuning project take?: Most fine-tuning engagements run three to six weeks. The training run itself is often the shortest part; the time goes into the data audit, base-model benchmarking, hyperparameter search, and building the evaluation pipeline that proves the result. If your data needs cleaning or labeling before it is usable, that adds time, and we scope it explicitly during the data audit rather than discovering it mid-project.
Where does the fine-tuned model run after delivery?: Wherever the economics and your data policy point. We can deliver the weights for self-hosting on your own GPUs, set you up on a managed fine-tuning endpoint from a cloud provider, or run a hybrid where sensitive workloads stay in-house. We benchmark serving cost and latency for your expected volume and hand over the inference setup so you can run the model the day the engagement closes, with no dependency on us.

Have a fine-tuning project in mind?

Tell us the task, your dataset size, and the performance target. We'll reply within one business day with a data audit plan and a rough scope.