Skip to main content

Fine-tuning

Fine-tuning takes a checkpoint that already understands your data and adapts it to a specific task — fraud detection, credit risk, churn, demand. It is the second half of the model lifecycle, and it lives in its own section of Studio, separate from Pre-training.

Internally a fine-tuning run is a POST_TRAINING run. Everything about statuses, scheduling, monitoring and checkpoints works exactly as it does for Pre-training — see Pre-training for that shared behaviour. This page covers what is different.

What makes a fine-tuning run different​

It starts from a base checkpoint​

A Pre-training run starts from raw datasets. A fine-tuning run starts from a base checkpoint produced by an earlier run. Selecting it is a required step: you search the available checkpoints by name or ID and confirm one before the run can be created.

Choosing the base checkpoint is the highest-leverage decision in the flow. Pick it from the Leaderboard rather than by recency — a checkpoint from the middle of a Pre-training run frequently beats its final one.

Its design is task-shaped​

A fine-tuning run still requires a Published Model Design, but the design is usually narrower: a primary target aimed at the task, the metrics that task is actually judged on, and a training window relevant to it.

It has its own leaderboard​

Fine-tuning runs are ranked separately from Pre-training runs, because they are not comparable — they are optimizing for different things. The Leaderboard tab inside Fine-tuning shows only fine-tuning results.

Typical loop​

  1. Pre-train once to get a foundation checkpoint over your data.
  2. Publish a task-shaped design for the task you care about.
  3. Fine-tune from the best foundation checkpoint.
  4. Compare fine-tuning runs on the Leaderboard.
  5. Deploy the winning checkpoint to an Inference Server.

Steps 2–4 repeat per task. You do not re-run Pre-training for each new task; that is the point of separating them.

Next steps​