Fine-tuning (module rail → Fine-tuning) adapts an existing model to your language, formats and domain by training it on examples of the behaviour you want. Use it when prompting and knowledge bases aren't enough — for example a model that must always produce your company's report structure or use your technical vocabulary naturally.
Before you start
Fine-tuning is the most expensive way to improve a model. Work up the ladder of effort first:
| Order | Technique | Try when |
|---|---|---|
| 1 | Better prompt / system prompt | Output style or format is wrong. |
| 2 | Knowledge base | Answers lack your facts. |
| 3 | Model choice / comparison | Current model is too weak. |
| 4 | Fine-tuning | You need consistent behaviour, format, or style that prompting can't hold. |
You also need data: typically several hundred to several thousand example pairs (an instruction and the ideal answer).
The three areas
- Train Now — configure and launch a training run.
- History — past runs, their progress, metrics and results.
- Settings — defaults that apply to your training jobs.
Create a training run
Name it
Give the run a recognisable name (with an optional run-name suffix) so history stays searchable.
Choose the base model
Select the model to adapt. Filter by base model in the history list to compare variants of the same base.
Select the method
Pick the training method offered by your deployment. Lightweight methods (adapter/LoRA-style) train quickly and produce a small add-on to the base model; full methods are heavier. Follow your administrator's recommendation — see Training (Admin).
Provide the data
Supply training data (the examples to learn from) and, ideally, validation data (held-back examples used to detect over-training). Datasets you have uploaded appear in the dataset selector; each shows the number of examples.
Set the parameters
Start from the defaults and change only what you understand. The most important are below.
Launch and monitor
Submit the job. Watch progress in History — status, ETA, and live metrics — while the job occupies GPU capacity. See GPU Monitoring.
Key parameters
| Parameter | Meaning | Practical guidance |
|---|---|---|
| Epochs | How many passes over the whole dataset. | Start small (1–3). More is not better — it over-fits. |
| Learning rate | How big each adjustment is. | Defaults are sensible. Too high makes the model erratic or worse. |
| Batch size | Examples processed per step. | Larger is faster/steadier but needs more memory. Use what your cluster supports. |
| Seed | Randomness starting point. | Fix it to reproduce a good run; vary to explore. |
| Validation split | Data reserved for checking generalisation. | Keep some — validation loss tells you when to stop. |
Reading the metrics
| Metric | What it means | Healthy pattern |
|---|---|---|
| Training Loss | Error on the training examples. | Falls steadily, then flattens. |
| Eval Loss | Error on held-back data. | Falls alongside training loss, then flattens. |
| Grad Norm | Size of each update step. | Smooth, decreasing trend; erratic spikes suggest the learning rate is too high. |
| ETA / Job ID / Run ID | Progress and identifiers for reference. | — |
| Spend | Resource consumption for the run. | Compare across runs to control cost. |
Over-fitting sign: training loss keeps falling while validation loss rises. Your model is memorising, not learning — reduce epochs or add data.
Settings that save time
Training Settings holds workspace/user defaults, typically:
- Notify when training completes — get told instead of refreshing History.
- Auto-retry failed runs — recover from transient failures automatically.
- Archive stale checkpoints — reclaim storage from old intermediate results. See Cluster Manager → Storage.
Deploying the result
When a run completes, the tuned model becomes selectable as a model in your workspace. Validate before rollout:
- Chat with it on real tasks.
- Run a scored Comparison against the base model.
- Record the verdict with Evaluations.
- Attach a system prompt, tags and prompt suggestions so teams use it correctly. See Models Overview.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| Output repeats phrases from training data | Too many epochs / too little data. |
| Model got worse overall | Learning rate too high, or data quality problems. |
| Job failed | Capacity or transient error — check event details, enable auto-retry, ask admin about GPU availability. |
| No improvement visible | Data doesn't actually demonstrate the change you want; make examples clearer and more varied. |