How many examples are enough to fine-tune an LLM? A precise answer is tempting: 50, 500, perhaps 5,000. But row count is usually the least informative thing about a training dataset.
A thousand near-duplicates may teach less than one hundred examples that cover ordinary cases, awkward edges, refusals, several output formats, and failures that cost the business money. What matters is not how quickly the dataset grows, but whether it represents the behavior the model must learn.
Here is the useful starting answer: for supervised fine-tuning, 50 carefully reviewed examples can be enough to test one narrow behavior when the base model is already close. A task with several case families often needs hundreds. Broad, multilingual, or high-risk behavior may need thousands, but collecting that many before running an evaluation is usually a mistake.
Those are starting ranges, not production guarantees. The useful number depends on what the model must learn, how well the base model already performs, and whether the dataset covers the cases that matter.
This article focuses on supervised fine-tuning with input and desired-output examples, whether you update the full model or use a parameter-efficient method such as LoRA. Preference tuning and reinforcement fine-tuning use different data and should be estimated separately.
A practical starting range
Use these ranges to budget a first experiment, not a final production dataset.
| Goal | First experiment | What must be true |
|---|---|---|
| Stable format, tone, or label set | About 50 examples | The base model is usually correct but inconsistent |
| Extraction or classification with several recurring case types | 50 to 100 examples | Important classes and boundary cases are represented |
| Several related behaviors, formats, or production languages | 100 to 300 examples | Each condition has enough distinct examples to evaluate separately |
| Broad judgment or a multi-step workflow | Decompose it first | One total hides several tasks and failure modes |
| Current facts or changing company knowledge | Zero training examples | Use retrieval, a database query, or a tool instead |
Stable format, tone, or label set
First experiment
About 50 examples
The base model is usually correct but inconsistent
Extraction or classification with several recurring case types
First experiment
50 to 100 examples
Important classes and boundary cases are represented
Several related behaviors, formats, or production languages
First experiment
100 to 300 examples
Each condition has enough distinct examples to evaluate separately
Broad judgment or a multi-step workflow
First experiment
Decompose it first
One total hides several tasks and failure modes
Current facts or changing company knowledge
First experiment
Zero training examples
Use retrieval, a database query, or a tool instead
The 50-example checkpoint is not arbitrary. OpenAI’s supervised fine-tuning documentation says improvements often appear with 50 to 100 examples and recommends beginning with 50 well-crafted demonstrations, then evaluating the result. That is evidence for a starting experiment, not a universal minimum. OpenAI supervised fine-tuning guide
Published experiments show why the range cannot be copied blindly. One controlled question-answering study found useful results with 60 training points under its specific conditions. A translation study found that fine-tuning Llama 3 8B Instruct on 1,000 or 2,000 examples performed worse than the baseline. The task, model, data, and evaluation determine what the count means. Question-answering study Translation study
First check whether fine-tuning is the right tool
Sometimes the answer is zero.
If an internal assistant gives outdated product prices, training on the latest catalogue puts changing facts inside model weights. Retrieval or a database lookup is a better fit because the source can change without another training run.
Fine-tuning makes more sense when the gap is stable behavior: a fixed response format, a classification scheme, organization-specific terminology, or a response policy that the model follows inconsistently. Even then, test a stronger prompt and a few examples in context first. A training project should solve a measured problem that prompting or deterministic code did not solve well enough.
Write the target as something you can score. “Understand our company” is not useful. “Assign each request to one of six categories and return this schema” is. If experts cannot agree on the expected answer, the dataset is not ready, regardless of its size.
Four factors determine how much data you need
1. Task breadth
A four-label classifier is much narrower than a system that reads a conversation, applies a contract, drafts a reply, and decides whether a person must approve it. Count the decisions and the conditions that change the correct output. A broad project may need to become several smaller fine-tuning tasks before any estimate is credible.
An example count also hides token volume. Fifty short classification records do not contain the same amount of training material as 50 multi-turn conversations with tool calls and structured outputs. Budget rows for coverage, but use tokens when estimating training cost.
2. Coverage
Historical data repeats common cases. A random sample of support logs may contain hundreds of delivery updates and almost no disputed charges, ambiguous cancellations, policy conflicts, or requests the model should refuse. Average accuracy can improve while the risky cases remain untouched.
Duplicates create the same problem. Copies, template variations, and several exports of one conversation increase the row count without adding a new behavior. One hundred distinct and reviewed examples can teach more than thousands of repetitive records.
Use the map below to see whether your dataset has coverage or merely volume.
A larger dataset can cover less
Compare three illustrative ways to sample the same task.
Choose a dataset to compare
Volume, not coverage
Most rows repeat the common path. The cases that define safe behavior barely appear.
Next: Collect refusals, costly failures, and missing format or language cases.
These distributions illustrate the coverage problem. They are not benchmark recommendations.
3. Base-model capability
Fine-tuning adapts an existing model. If the model already gives a nearly correct answer, a small dataset may make the behavior consistent. If it regularly misunderstands the input or lacks a prerequisite capability, more demonstrations may produce fragile improvements that do not transfer to new cases.
Run the same held-out evaluation against a few plausible base models before funding a large annotation effort. A stronger model may need less data. A smaller model may still win if it learns the narrow task and costs less to operate.
4. Label consistency and risk
Conflicting examples do not average into a sensible policy. They teach uncertainty. Review disagreements, write down the resolution rule, and include examples near the boundary.
Risk changes the standard too. A low-stakes formatting task can move forward after a modest evaluation. A workflow that affects money, access, safety, or legal obligations needs more coverage and stronger tests. There is no example count that converts weak evidence into safety.
Reserve evaluation data before training
If you have 200 reviewed cases, you do not have 200 training examples. Some must remain unseen.
The held-out set tells you whether the model learned a behavior that transfers beyond the demonstrations. Split related records as a group. Messages from one conversation, pages from one document template, or synthetic variations of one seed should not appear on both sides of the split.
This matters because contamination can create convincing but false progress. One study found that exposure to evaluation templates and answers raised performance on the affected benchmark by more than 45 percent without a matching improvement on a separate evaluation. ACL 2024
Your evaluation should test the target behavior and regressions. Check what should improve, but also check what the model should not lose, such as general instruction following or correct refusals. For high-risk work, report results by case family instead of relying on one average score.
Find your number with a learning curve
Start with a small, representative set. Train once and measure it against the untouched evaluation cases. If the important failures improve, add another batch selected from weak coverage areas and observed errors. Train again under comparable settings.
The resulting learning curve makes the next decision clearer:
- If results improve sharply, another targeted batch may be worthwhile.
- If progress slows, compare the expected gain with the cost of annotation and training.
- If the result stays flat, revisit the task, labels, prompt, or base model instead of buying more rows.
Stop when the model meets the defined acceptance criteria, when another batch no longer produces worthwhile improvement, or when error analysis points to a different solution. Dataset size is an experimental result, not a procurement target.
The estimator below turns the main conditions into a sensible first checkpoint. It deliberately refuses to give a range when the project is not ready for one.
How large should your first training set be?
A short quiz for choosing the first experiment.
1 of 5
Question 1
Next question
What should the model learn?
Choose the main change you want from fine-tuning.
The short answer
Begin with about 50 strong examples for one narrow supervised fine-tuning task when the base model is already close. Use 100 to 300 when several case families, formats, or languages need coverage. For broad tasks, split the work before estimating it.
Keep evaluation cases out of training, measure each important failure type, and add data in targeted batches. You have enough when the held-out results meet your acceptance criteria and another batch is no longer the best way to improve them.