Can You Train or Fine-Tune Models on Baseten?

Updated

Yes. Baseten is a platform for both model inference and training, and its documentation states that you can train models and serve the resulting checkpoints. Two paths are documented: fine-tuning with Loops, or running your own training code with Training Jobs. Training runs on production GPU infrastructure, and the checkpoints you produce can then be served through Baseten's inference paths.

The two documented training paths

Loops (fine-tuning)

Use Loops when you want to fine-tune rather than write a training loop from scratch. The overview lists it as the fine-tuning option alongside Training Jobs. The documentation does not, in the material available here, spell out Loops' supported base models, dataset formats, or hyperparameters — check the Loops section of the docs before committing to it.

Training Jobs (your own code)

Use Training Jobs when you want to run your own training code on Baseten's GPU infrastructure. This is the more flexible path: you bring the training script, and Baseten provides the compute. As with Loops, the specifics of job configuration and artifact output are not detailed in the overview excerpt, so treat the Training Jobs docs as the source of truth for setup.

How training results get served

The overview states plainly that you can "train models and serve the resulting checkpoints." The serving side works through the same inference options Baseten offers generally:

Serving path What it is When it fits
Model APIs Hosted endpoints for a curated set of models, using the OpenAI Chat Completions API (and Anthropic Messages API in beta) A supported model fits your application and you want to start with an API call
Dedicated inference Your open-source model, private checkpoint, or custom model on dedicated GPUs You need control over the model, hardware, autoscaling, and release lifecycle

A trained checkpoint is a private artifact, so serving it points toward dedicated inference rather than Model APIs — Model APIs expose a curated set of hosted models, not arbitrary checkpoints. On the dedicated side, you define the model in one of three ways:

  • config.yaml — for supported architectures, defines the model, hardware, and inference engine without custom serving code
  • Python model class — when you need custom preprocessing, postprocessing, or dependencies
  • Custom Docker server — when you need full control over server behavior

Deployment is done with the Baseten CLI. Dedicated deployments also give you stable environments for development, staging, and production, plus control over autoscaling settings and the release lifecycle.

What Baseten manages for you

Across both inference and training, Baseten handles model containers, GPU capacity across clouds and regions, scaling, and observability. Its inference engines optimize supported model architectures for production traffic. That means the training-to-serving handoff does not require you to stand up your own container or GPU fleet — but it also means supported architectures matter: config.yaml-based deployment depends on the architecture being supported, which is why custom serving code exists as a fallback.

Practical starting order

  1. Decide whether you need fine-tuning (Loops) or full control over training code (Training Jobs).
  2. Run the training job and produce a checkpoint.
  3. Choose a serving definition — config.yaml if your architecture is supported, otherwise a Python model class or custom Docker server.
  4. Deploy with the Baseten CLI and verify with an inference call.

For pricing and usage limits on training and inference, see the "Pricing and limits" and "Billing and usage" pages in the docs; the overview excerpt does not include rates or quotas.