how to fine tune an llm

What fine-tuning actually changes

Fine-tuning changes a model's habits. It can teach a model to return the same schema every time, follow a specialized workflow, recognize domain-specific patterns, use tools more reliably, or imitate the behavior of a stronger model.

Think of a capable new hire. A prompt is one set of instructions for today's task. Retrieval gives the person a binder of current reference material. Fine-tuning is repeated coaching with marked examples until the desired response pattern becomes a habit. The binder and the coaching solve different problems.

LoRA, short for Low-Rank Adaptation, makes that coaching practical. Instead of rewriting the base model's entire memory, LoRA adds small trainable correction layers while freezing most of the original model. Mistral's open fine-tuning code says those added weights are roughly 1 to 2 percent of the model. The result is an adapter, a compact set of learned changes that can be kept separate or merged into the base model.

Mistral's August 4 release of Shieldstral shows the modern pattern in a real system. The team fine-tuned with LoRA, saved distinct checkpoints, then merged a checkpoint calibrated on public safety data, another trained for finer policy discrimination, and the base instruction model. A checkpoint is simply a saved version of the model at a particular point in training, like a numbered draft you can test before choosing the final one.

The six-step workflow that keeps a fine-tune honest

The training command is the easy part. The hard part is deciding what should change, building examples that represent that behavior, and proving that the chosen checkpoint improved the right thing without breaking something else.

1. Define one behavior and one launch test

Write the failure in observable terms. "Make the model better at support" is not testable. "Given a support message, return one valid category, a priority, and the next approved action" is.

Create the evaluation before the training set. Include ordinary cases, edge cases, and examples that should remain unchanged. Mistral's customization guidance makes the same point: decide how the application will be evaluated first, then use those criteria to shape the training data.

2. Prove that prompting or retrieval is not enough

Use a prompt when the behavior can be stated clearly and changes often. Use retrieval-augmented generation, or RAG, when the model needs fresh facts from documents or databases. Fine-tune when the recurring problem is behavior: format, classification boundaries, tool selection, tone, or a specialized decision pattern.

The cleanest test is a three-way baseline on the same held-out examples:

If the prompt already passes the launch test, stop. Training adds cost, versioning, and regression risk without creating value.

3. Choose a base model you can actually operate

Pick the smallest model that already performs the core task reasonably well and whose license, language coverage, context window, and deployment options fit the product. A fine-tune should specialize a capable base, not rescue a model that fundamentally cannot do the job. If you are choosing among open weights, this current open-source LLM comparison is a useful starting map.

Hardware is part of the choice. Mistral recommends A100 or H100 GPUs for maximum efficiency in its repository, although it says one GPU can be enough for smaller models such as 7B. A model that trains successfully but cannot be served within your latency and memory budget is the wrong base.

4. Build three separate datasets

Prepare training, validation, and test data. Training examples update the adapter. Validation examples help compare progress during the run. The test set stays sealed until checkpoint selection so it remains an honest measure.

Mistral's code expects JSONL, one JSON object per line. Conversational records use messages, and the training loss is applied to assistant responses. A minimal record looks like this:

{"messages":[{"role":"user","content":"Classify: I was charged twice"},{"role":"assistant","content":"{\"category\":\"billing\",\"priority\":\"high\"}"}]}

Quality beats bulk. Remove duplicates, contradictions, private data you lack permission to use, and examples that accidentally reveal the test set. Cover different lengths, tones, edge cases, and acceptable variations. Then run a schema validator before spending GPU time. Mistral ships a validate_data utility specifically to catch formatting errors and estimate a run before it starts.

5. Train a LoRA adapter and save checkpoints

Set the base-model path, sequence length, batch size, maximum steps, learning rate, LoRA rank, random seed, evaluation frequency, and checkpoint frequency. Mistral's repository recommends a LoRA rank of 64 or less, but there is no universal best configuration. The right values depend on the model, dataset, context length, and hardware.

Save checkpoints often enough to compare them. Training loss tells you whether the model is fitting the examples it sees. It does not tell you whether a saved checkpoint is the best product. A later checkpoint can memorize phrasing or lose useful general behavior even while training loss continues to fall.

6. Pick the checkpoint with held-out evaluations

Run the untouched test set against the base model and every serious checkpoint. Measure the product outcome: valid schemas, correct tool calls, classification precision and recall, refusal behavior, latency, and any safety boundaries that matter. Add human review where the judgment cannot be reduced to a reliable metric.

Deploy the adapter or merge it only after one checkpoint beats the baseline on the launch test and stays acceptable on regression tests. Version the model, adapter, dataset, configuration, and evaluation together. That lineage is what makes rollback possible when a new dataset or model version performs worse.

Eight use cases, ranked by who gains the most

The best fine-tuning use cases have high repetition, stable rules, and a measurable error. They are less about making a model broadly smarter and more about making one narrow behavior dependable.

1. Support operations with strict routing and actions

A software support team can train on approved examples that map each customer message to a category, priority, allowed action, and response shape. The model can learn the recurring routing pattern without carrying a long policy prompt into every ticket. The payoff is consistent automation at the point where invalid categories or invented actions currently create manual cleanup.

2. Policy-specific moderation for text and images

A marketplace, community app, or children's product can evaluate prompts, responses, images, and image-plus-text posts against its own policy language. Shieldstral is a useful starting point because it accepts one natural-language yes/no policy question and emits a confidence score from a yes/no token.

The 3B model fits in 16GB of VRAM in BF16 and was trained within a 32k-token range. It can change policy questions at inference time without retraining, so a team should first test that capability directly. Fine-tune it only when labeled, domain-specific edge cases reveal a stable gap. The payoff is not zero human review. It is a smaller, auditable first-pass filter whose decisions can be tested against the product's actual policy.

3. Claims and document extraction with a fixed schema

An insurer or back-office processor can train on documents paired with approved structured outputs: claim type, dates, amounts, missing evidence, and escalation reason. Retrieval can supply policy documents, while the fine-tune teaches the extraction and decision format. The payoff is fewer broken records entering downstream systems and a measurable exception queue.

4. Agents that choose the right tool and arguments

An internal operations agent can learn from successful examples of when to search, create a ticket, ask a clarifying question, or stop. Function-calling conversations are a supported data type in Mistral's open code. The payoff comes from reducing malformed calls and needless tool use, not from giving the agent new facts.

5. A small private model distilled from a stronger one

A product team with a narrow, repetitive task can collect reviewed outputs from a stronger reference model and train a smaller open model to imitate that behavior. This can make sense when the smaller model must run in a private environment or when inference latency dominates. The payoff is a deployable specialist, provided the evaluation proves the smaller model retained the required behavior.

6. Domain terminology and classification

A cybersecurity team can pair alerts, identity events, and incident notes with the categories and next steps its analysts use. An industrial team can do the same with engineering terms and fault codes. The model learns the organization's recurring labels and decision patterns. The payoff is faster triage, while current source material should still come from retrieval rather than training memory.

7. Brand-constrained generation at scale

A content operation can train on approved input-output pairs that demonstrate tone, length, prohibited claims, and exact formatting. The gain appears when the same constraints repeat across thousands of outputs and prompt instructions have become long or inconsistent. This is a poor fit when the brand voice is still changing or approval examples are sparse.

8. Refusal and escalation behavior

A health, finance, or youth-facing application can train examples that distinguish an allowed answer, a refusal, and a handoff to a human. The workflow should include adversarial and ambiguous test cases before deployment. The payoff is a consistent escalation boundary, but the fine-tune remains one control inside a wider safety system.

Three products worth building around the workflow

The opportunity is not cheap GPU access. Managed LoRA training for models up to 16B is listed at $0.48 per 1 million training and validation tokens on Together AI and $0.50 per 1 million training tokens on Fireworks, before hosting and the work around the run. The valuable layer is deciding whether to train, repairing the data, and proving which checkpoint is safe to ship.

Best bet: a fine-tuning readiness and dataset QA workbench

Build a product that accepts a task definition, a prompt baseline, and example conversations, then checks schemas, duplicates, contradictions, sensitive data, class balance, and train-test contamination. It should create the three splits, run a baseline evaluation, and recommend prompt, RAG, or LoRA with reasons.

The demand is broad enough to support education and a paid workflow: "fine tune llm" gets about 1,300 Google searches a month, while the explicitly commercial "llm fine tuning services" gets 30 with a $10.58 CPC. The real search question, "Is finetuning an LLM worth it?", is the product request in plain language.

The smallest sellable version is a local or private upload, a validator, a scored readiness report, and exports for one training stack. The catch is trust. Teams will not upload proprietary conversations unless privacy and deletion are clear, and a generic checker cannot decide whether a domain expert's answer is correct. The moat has to become model-specific validators plus a growing library of evaluation patterns, not a thin wrapper around a training API.

A policy-adaptive moderation starter kit

Package Shieldstral behind a policy editor, text and image endpoint, threshold controls, review queue, and audit log. A marketplace or community product pays for a deployable moderation layer it can adapt to its own rules without replacing the model every time policy wording changes.

"AI content moderation" gets about 170 commercial-intent Google searches a month at a $21.30 CPC, and people ask AI assistants about it roughly 30 times a month. The MVP can support one deployment target, a handful of policies, a test-set uploader, and side-by-side threshold results.

The catch is consequential: Mistral reports uneven language and domain coverage, residual label noise, and weaker reliability on obfuscated inputs and very long documents. A serious product needs human review, appeals, policy tests, and monitoring. Selling it as an automatic final judge would be irresponsible.

A checkpoint scorecard for small-model teams

Build a focused evaluation console that runs one sealed test set across the base model and saved adapters, then compares schema validity, task metrics, latency, safety regressions, and human ratings. It should attach every result to the exact model, dataset, seed, and configuration.

"AI model training tools" gets about 90 commercial-intent searches a month with keyword difficulty 3. That is small but unusually reachable demand from people already looking for software. The MVP needs one task template, one training provider, CSV or JSONL upload, and a clear pass-or-fail release report.

The catch is evaluation credibility. A polished dashboard cannot rescue weak test cases, and an LLM judge can reproduce the biases of the model it scores. The product becomes defensible only when it combines deterministic checks, domain rubrics, blinded human review, and regression history.

What fine-tuning does not solve

Fine-tuning does not keep facts current. If prices, policies, inventory, or documentation change, retrieve them at request time. It does not grant permission to train on private or copyrighted data. It does not make evaluation optional, and it does not guarantee that improvements on one task will preserve every other capability.

It also does not eliminate infrastructure. You still need compatible hardware, a serving path, monitoring, rollback, and a process for new data. Managed training prices can look tiny while labeling, evaluation, deployment, and always-on hosting dominate the bill.

There is a Mistral-specific trap here. Its legacy hosted fine-tuning API documentation is explicitly marked deprecated and no longer actively supported. For a current Mistral path, use the open mistral-finetune code for a self-managed LoRA run, use the Axolotl route documented for Shieldstral, or speak to Mistral about Forge for an enterprise lifecycle. Do not copy an old hosted-API notebook and assume it represents the current product.

The honest rule is simple: fine-tune only when a stable, repeated behavior fails a measured baseline and you possess enough high-quality examples to teach it. Anything looser is an expensive way to hide an unclear product requirement.

If you want a fine-tuned model and evaluation pipeline built for a real production workload, see the AI production systems service.