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

There is no fixed number, but most successful instruction fine-tuning projects use somewhere between a few hundred and about ten thousand high-quality examples, with data quality and diversity mattering more than raw volume. Research such as the LIMA study showed that as few as one thousand carefully curated, diverse examples can align a base model's behavior almost as well as much larger noisy datasets, because the pretrained model already holds most of the required knowledge and fine-tuning mainly teaches format and style. Narrow tasks like classification or a single structured output schema can work with a few hundred labeled examples, while broad instruction following or multi-turn conversation ability typically needs several thousand examples covering varied phrasing, edge cases and difficulty levels. Continued pretraining for new domain knowledge or a new language is different and usually needs millions of tokens of raw text rather than instruction pairs. Teams should hold out fifty to a few hundred examples for evaluation before scaling up collection. Nanobase AI helps clients audit existing support tickets, documents and logs to estimate how much usable training data they already have before writing new examples.

Data requirements are task-shaped, not a single number

Asking "how much data" without specifying the task type is like asking how much rope is needed without saying for what. The honest answer splits sharply by what the model is being asked to learn, and treating all fine-tuning as one category is the most common reason teams either over-collect data they did not need or under-collect and get disappointing results.

The task type determines the order of magnitude needed far more than any general rule about fine-tuning dataset size.

How to tell you have enough before scaling up collection

Rather than guessing at a target number upfront, the more reliable approach is to train on progressively larger slices of available data and watch the validation metric. Plotting evaluation score against training set size, at intervals such as 25, 50, 75, and 100 percent of collected data, reveals whether the curve has flattened, meaning more data would yield diminishing returns, or is still climbing steeply, meaning more collection is worth the effort.

1. Split off a fixed held-out evaluation set of 50 to 300 examples before any scaling experiment begins.
2. Train separate runs on 25 percent, 50 percent, and 100 percent of the remaining data with identical hyperparameters.
3. Plot the evaluation metric against dataset size for each run.
4. If the curve is still rising steeply at 100 percent, prioritize more data collection before further hyperparameter tuning.
5. If the curve has flattened, redirect effort toward data quality and edge-case coverage instead of volume.

A learning curve built from your own data answers the sizing question far more reliably than any published rule of thumb.

Quality signals that matter more than count

A dataset of a thousand carefully reviewed, diverse examples routinely outperforms ten thousand noisy or repetitive ones, because fine-tuning is mostly teaching the model format and behavior it can already approximate, and redundant examples add little beyond what the first few hundred already taught. The examples that move the needle most are the ones covering genuine edge cases: ambiguous inputs, unusual formatting requests, and the hard 10 percent of cases that a model gets wrong, rather than more instances of the easy majority case it already handles.

Deduplication is worth doing explicitly, since near-identical examples inflate apparent dataset size without adding signal, and mixed formatting conventions across examples teach the model that inconsistency is acceptable. Diversity and correctness across the full range of expected inputs matter more than raw count for every task type in the table above.

What continued pretraining needs instead

Domain adaptation through continued pretraining operates on a completely different scale because it uses the same self-supervised next-token objective as original pretraining, just on domain-specific raw text rather than labeled instruction pairs. This typically requires hundreds of millions to billions of tokens for the model to genuinely absorb a domain's vocabulary and style, which is why continued pretraining is usually reserved for cases where the domain gap is severe, such as adapting a model to a low-resource language or a highly technical field, rather than being a default first step.

Confirm the task is genuinely a knowledge gap before budgeting for the much larger token counts continued pretraining requires.

Frequently asked questions

Can we fine-tune successfully with fewer than 500 examples?

Yes, for narrow tasks like single-schema structured output or a two-class classification problem, provided the examples cover the input variation the model will see in production. Broader instruction-following tasks generally need more.

Does more data always improve fine-tuning results?

No. Past the point where the learning curve flattens, additional data with the same characteristics as existing examples adds little value, and low-quality additions can actively hurt performance by introducing noise or inconsistency.

How much of our dataset should be held out for evaluation?

A common range is 5 to 15 percent, or 50 to 300 examples, whichever gives a statistically meaningful sample for your metric. Held-out data must never leak into training, since even small leakage silently inflates measured quality.

Should we combine real and synthetic examples?

Usually yes. Real examples anchor the dataset in actual usage patterns, while synthetic examples generated from a larger model can fill gaps in phrasing diversity or rare edge cases at lower collection cost.

How Nanobase AI helps

Nanobase AI, a Silicon Valley enterprise AI engineering company, audits existing support tickets, documents, and logs to estimate how much usable training data a client already has before recommending new data collection, and builds the learning-curve evaluation described here into every project. This keeps data collection effort proportional to what the task actually needs rather than an arbitrary target. See our solutions or the RAG versus fine-tuning guide for related architecture decisions.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.