# Train (https://docs.inference.net/platform/train/overview)
**Enterprise required.** Training is available on Enterprise plans. [Contact us](https://inference.net/meet-with-us/) to enable it for your team.
You do not have to manage the training loop yourself. [AutoTrainer](/platform/train/autotrainer) collects samples from your live traffic, trains a distilled model, and moves your traffic to it automatically. It is in open beta and available to all users.
Fine-tuning takes a small open-source model and trains it on your data so it gets really good at one specific task. The result is a model that's smaller, faster, and cheaper to run than the general-purpose model it replaces, while being more accurate for your workload. You don't need to be an ML engineer to use it.
Training is one optimization lever, not the only one. Many teams get massive value from [observability](/platform/gateway/overview) + [AutoEvals](/platform/eval/auto-evals/run-an-auto-eval) + prompt tuning alone. Fine-tuning is for when you've confirmed via evals that off-the-shelf models aren't good enough for a specific task, and you have the data to prove it.
## Prerequisites [#prerequisites]
Training requires two things before you start:
1. **A training dataset** - the data the model learns from. Build it from [captured traffic](/platform/datasets/build-from-traffic) or [upload your own](/platform/datasets/upload-a-dataset).
2. **An eval dataset** - measures learning progress. Must have **zero overlap** with training data.
## Key concepts [#key-concepts]
| Concept | Description |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Recipe** | A pre-configured training setup with a vetted base model, optimized parameters, and compute config. You pick by task difficulty, the platform handles the ML complexity. |
| **Training dataset** | The data the model learns from. Diversity and quality matter most. Build from captured traffic or upload your own. |
| **Eval dataset** | A separate dataset that measures learning progress. Must have zero overlap with training data to prevent overfitting. |
| **Rubric** | The quality criteria that guide training. Mid-training evals score the model against it. If the rubric is wrong, the model optimizes for the wrong thing. |
| **Mid-training evals** | Periodic quality checks during training run on a fixed schedule. They give you visibility into whether training is working — if scores degrade, you spot it and stop the run yourself. |
## Why fine-tune [#why-fine-tune]
* **Reduce latency** - a smaller, task-specific model responds faster than a general-purpose one
* **Reduce cost** - smaller models cost less to serve at scale
* **Improve accuracy** - a model trained on your data is optimized for exactly what you need
* **Maintain ownership** - you own the model artifact and control where it runs
## What makes good training data [#what-makes-good-training-data]
The quality of your trained model depends directly on the quality of your data. A few principles:
* **Diversity matters most.** Training data should cover the range of inputs the model will see in production — different phrasings, edge cases, varying complexity. A narrow dataset produces a narrow model.
* **Real traffic beats synthetic data.** Production inputs reflect what users actually send. [Build datasets from live traffic](/platform/datasets/build-from-traffic) when possible.
* **Scope to a single task.** A dataset built from mixed traffic teaches the model many things poorly. Use [task tags](/platform/gateway/tasks) to filter for one objective at a time.
* **More is generally better**, but quality trumps volume. A thousand clean, diverse examples outperform ten thousand repetitive ones.
For eval data, the goal is different: pick a small, stable set of hard examples that stress-test the model. Don't change your eval dataset often — it's your benchmark. See [Datasets](/platform/datasets/overview) for more on building both types.
## Next steps [#next-steps]
Pick a pre-configured training setup for your task.
End-to-end flow from datasets to queued job.
Distill a task onto a smaller model automatically from your live traffic.
Track progress, graphs, and logs during training.
Ship your model to a dedicated GPU.