How to Fine-Tune an LLM

To fine-tune an LLM, you take a pretrained model and keep training it on a set of your own labeled examples so it learns your task, format, or domain. You define the task, collect clean training data, pick a base model, choose a method like LoRA or full fine-tuning, train, evaluate, and deploy. The goal is a model that behaves the way you want by default, without long prompts.

Fine-tuning is not always the right move. Prompt engineering and retrieval (RAG) solve most problems faster and cheaper. Fine-tuning earns its keep when you need a consistent style, a strict output format, or judgment that lives in your own data and not on the public web.

This guide walks through the full workflow. You will learn what fine-tuning is, when to use it, how to prepare data, how the main methods differ, which tools and platforms to use, what drives the cost, and the mistakes that waste time and money.

What Is LLM Fine-Tuning?

Fine-tuning an LLM means training a pretrained model further on your own labeled examples so it specializes in a task. The base model already understands language. You are teaching it your specific behavior, tone, or domain.

Think of it like hiring a skilled writer and giving them your style guide. They already know how to write. You show them hundreds of examples of the exact output you want. Over time, they produce it without being told each step.

The result is a new version of the model with adjusted internal weights. It answers in your format, uses your vocabulary, and follows your rules by default. You no longer need to pack every instruction into the prompt.

Fine-tuning changes behavior, not knowledge freshness. It is strong at teaching a model how to respond. It is weak at feeding it new facts that change often. For live facts, retrieval is the better tool.

When to Fine-Tune (and When Not To)

Fine-tune an LLM when you need consistent behavior that prompts alone cannot hold. If you have tried strong prompts and retrieval and still miss the mark, fine-tuning is the next step.

Most teams reach for fine-tuning too early. In practice, better prompts or a retrieval layer solve a large share of cases at a fraction of the cost. Start there, then fine-tune what remains.

For the full decision framework, see our guide on fine-tuning vs RAG. The short version is below.

• Fine-tune when you need a strict output format (JSON, a fixed template, a house style) every single time.
• Fine-tune when the task depends on expert judgment held in your own labeled data, not public knowledge.
• Fine-tune to shrink prompts, cut latency, and lower per-call cost on a high-volume task.
• Use RAG instead when the model needs current or private facts that change often, like docs or records.
• Use prompt engineering first when a clear instruction or a few examples already get you close.
• A hybrid often wins: fine-tune for behavior and tone, then use RAG to supply live facts.

How to Fine-Tune an LLM: Step by Step

You fine-tune an LLM by moving through eight clear steps, from defining the task to monitoring the model in production. Each step feeds the next, so getting the early ones right saves rework later.

Do not skip evaluation. A model that looks good in a demo can still fail on edge cases you never checked.

• 1. Define the task. Write down exactly what good output looks like, with real input and output pairs. A sharp definition drives every later choice.
• 2. Collect and clean training data. Gather labeled examples that match the task. Remove duplicates, errors, and anything sensitive you should not train on.
• 3. Pick a base model. Choose an open-weights model like Qwen, Llama, or Mistral, or a closed model's fine-tuning API. Match model size to task difficulty.
• 4. Choose a method. Decide between full fine-tuning and a parameter-efficient method like LoRA or QLoRA. Most teams start with LoRA.
• 5. Train. Run the job on a platform or your own GPUs. Set a few key hyperparameters like learning rate, epochs, and LoRA rank.
• 6. Evaluate. Test the tuned model against a held-out set and your own task metrics. Compare it to the base model to prove it improved.
• 7. Deploy. Serve the model or its adapter behind an API. For LoRA, you load the small adapter on top of the base model.
• 8. Monitor. Watch quality and cost in production. Retrain when your data or the task drifts over time.

Preparing Your Training Data

Good training data is the single biggest driver of a successful fine-tune. Quality matters far more than raw volume. A few hundred clean, well-labeled examples often beat tens of thousands of noisy ones.

How many examples do you need? It depends on the task. Simple classification or extraction can work with a few hundred examples. Content generation usually needs a few hundred to a couple thousand. Complex, multi-step domain tasks may need several thousand.

Format your data consistently. Most fine-tuning uses input and output pairs, often as prompt and completion or as chat messages. Every example should look like a real request the model will see in production.

Guard against data leakage. Keep a held-out test set that the model never trains on. If test examples sneak into training, your scores will look great and real performance will disappoint.

Balance and coverage matter too. Include the hard cases, edge cases, and the formats you care about. If a pattern is not in the data, the model will not learn it.

Fine-Tuning Methods: Full vs LoRA/QLoRA

The two main ways to fine-tune an LLM are full fine-tuning and parameter-efficient fine-tuning, and LoRA is the most popular parameter-efficient method. The right choice depends on your budget, hardware, and how much you need the model to change.

Full fine-tuning updates every weight in the model. It is the most powerful option and can shift behavior deeply. It is also the most expensive, needs the most GPU memory, and carries the highest risk of catastrophic forgetting.

LoRA (Low-Rank Adaptation) freezes the base model and trains small add-on layers called adapters. You update a tiny fraction of the parameters, so training is far cheaper and faster. The adapter is small and easy to swap or store.

QLoRA goes further by loading the base model in 4-bit precision, then training LoRA adapters on top. This cuts memory so much that you can fine-tune sizable models on a single GPU. QLoRA is the sensible default for most teams in 2026.

Use full fine-tuning when you have the budget and need a deep behavior change across a large dataset. Use LoRA or QLoRA for most projects, where you want strong results at a fraction of the cost and hardware.

For an open-weights-specific walkthrough, see our deep dive on fine-tuning open-weights models. This guide stays general, so it applies whether you pick an open or closed model.

Tools and Platforms to Fine-Tune an LLM

You can fine-tune an LLM through a managed cloud API or with open-source frameworks on your own GPUs. Managed platforms hide the infrastructure. Self-hosted tools give you the most control and often the lowest cost at scale.

Pick based on your team's skills. If you want to write no training code, start with a managed service or a no-code UI. If you have ML engineers and GPUs, self-hosted frameworks unlock speed and savings.

• Tinker — Thinking Machines Lab's cloud fine-tuning API. It handles the training infrastructure while giving you low-level control, and it powered the Bridgewater finance model built on Qwen3.
• Together AI — Fully managed fine-tuning as a service. You upload a dataset, set training parameters, and get a hosted, ready-to-serve model back, with strong open-weights support.
• OpenAI fine-tuning — A managed API for tuning OpenAI's own models. It is the simplest path if you already build on ChatGPT-family models, though it keeps you inside their ecosystem.
• Hugging Face AutoTrain — The fastest route for a beginner. It fine-tunes small models for tasks like classification through a simple interface, with little or no code.
• Self-hosted (Axolotl / Unsloth) — Open-source frameworks you run on your own GPUs. Axolotl configures training in a simple YAML file, while Unsloth's custom kernels train two to five times faster with less memory.

How Much Does It Cost to Fine-Tune an LLM?

The cost to fine-tune an LLM is driven by four things: model size, dataset size, the method you choose, and the GPU hours you use. Prices vary widely by provider, so treat any single number as a rough guide, not a quote.

Model size is the biggest lever. A small 7B or 8B model is cheap to tune. A very large model needs far more memory and compute, which raises the bill quickly.

Method is the next lever. Full fine-tuning is the most expensive because it updates every weight and needs top-tier GPUs. LoRA and QLoRA cut cost dramatically by training only small adapters, often on a single GPU.

Dataset size and training length add up as GPU hours. More examples and more passes over the data mean more compute time. This is why clean, focused data saves money as well as improving quality.

A worked example of the drivers: tuning a small open model with QLoRA on a few hundred to a few thousand curated examples is an inexpensive, single-GPU job that can finish in hours. Swap in a much larger model or full fine-tuning and both the hardware tier and the runtime climb, so the total can rise by orders of magnitude. Confirm current rates with your chosen provider before you commit.

The payoff can be large. In July 2026, Bridgewater Associates and Thinking Machines Lab reported that a fine-tuned open model, built on Qwen3 with Tinker, beat GPT-5 and Claude Opus on a niche set of finance tasks while running at roughly 13 times lower cost per task. Those figures come from the two companies' own testing and have not been independently verified, but they show why a specialized small model can outperform a giant general one on the right job.

Common Fine-Tuning Pitfalls

Most failed fine-tunes trace back to a handful of avoidable mistakes. Knowing them before you start saves wasted GPU hours and disappointing results.

The biggest trap is fine-tuning at all when a better prompt or a retrieval layer would have done the job. Always rule those out first.

• Overfitting — training too long or on too little data, so the model memorizes examples and fails on new inputs. Watch your held-out scores and stop early.
• Catastrophic forgetting — the model loses general ability while learning your task. Benchmark before and after; a large drop on general tests is a red flag.
• Bad or leaky data — errors, duplicates, or test examples mixed into training. Clean your data and keep a strict, unseen test set.
• Fine-tuning when RAG would do — burning budget to teach facts that change, instead of retrieving them live. Use RAG for knowledge, fine-tuning for behavior.
• No evaluation plan — shipping on a demo that looks good. Define task metrics and a test set before you train, not after.
• Wrong method for the goal — reaching for full fine-tuning when LoRA or QLoRA would deliver the same result far cheaper.