Skip to main content
The Training API is currently in private preview. Request access before running this guide.
Dedicated training provisions trainer and deployment resources for your run. Use it when you need broader model or method support, full-parameter training, DPO, sustained RL, explicit checkpoint resume, or control over rollout and evaluation deployments. If LoRA SFT or RL on the shared pool is sufficient, compare this path with Serverless Training before provisioning resources.
Start from the cookbook. Clone fw-ai/cookbook, then fork the closest recipe under training/recipes/. Recipes own provisioning, checkpoints, reconnect, and sampling where applicable. Cleanup is configuration-specific; review and set each recipe’s cleanup flags before launch.

​
What you can run

SFT, DPO, and ORPO

Use cookbook recipes with LoRA or full-parameter configurations supported by the selected training shape.

RL and RFT

Run synchronous or asynchronous rollouts with custom rewards, losses, environments, and deployment sampling.

Distillation

Provision student and teacher resources for sampled reverse KL, top-k forward KL, and related workflows.

Custom loops

Use the Tinker-compatible training client directly when a maintained recipe does not express the required behavior.

​
Dedicated training steps

​
Step 1: Install the SDK and cookbook

Check the SDK requirement declared by your cookbook revision:

​
Step 2: Choose the closest recipe

Fork the recipe and change only the task-specific data, loss, reward, rollout, evaluation, or configuration. For a complete bounded SFT smoke using the bundled text-to-SQL dataset:
This command creates paid trainer resources. Replace <shape>, then review the model, shape, parameters, cost ceiling, and cleanup flags before running it.

​
Step 3: Choose the model and training shape

Use the live Training Shapes catalog. Pass the full shared shape ID and let the SDK resolve its validated version and linked deployment shape. Do not copy accelerator type, GPU count, image tag, or deployment-shape details into the config when the training shape owns them.

​
Step 4: Configure stable run outputs

Record:
  • cookbook commit and installed SDK version;
  • account, base model, recipe, and dataset;
  • complete configuration, including defaults;
  • training shape and linked deployment shape;
  • stable trainer, output-model, and deployment IDs where the API exposes them;
  • checkpoint cadence and resume policy;
  • cost ceiling, success metric, and teardown policy.

​
Step 5: Provision the SDK-managed service

Cookbook recipes provision through the SDK-managed service. If you are writing a direct loop, follow the exact FiretitanServiceClient.from_firetitan_config(...) quickstart. Provisioning happens on the first client creation. Capture service.trainer_job_id and every rollout or evaluation deployment ID immediately.

​
Step 6: Train and monitor

Run the forked recipe. Monitor:
  • trainer state and real optimizer-step progress;
  • recipe metrics and W&B when configured;
  • rollout success, reward distribution, and sampler latency for RL;
  • checkpoints and deployment weight-sync state;
  • quota, billing, and capacity separately.
State alone is not proof of progress. Use a bounded no-progress interval and preserve IDs and timestamps for escalation.

​
Step 7: Save, sample, and evaluate

Save weights for the sampler, create or refresh the SDK-managed sampler, and evaluate the base and tuned policy on the same held-out set. For checkpoint and sampler details, see Saving and Loading and Training and Sampling.

​
Step 8: Promote the selected checkpoint

List checkpoints from the control plane, choose a row marked promotable, validate the output model ID, and promote the full checkpoint resource name. Do not choose a winner from training loss alone. Use the agreed held-out metric or evaluator.

​
Step 9: Deploy and prove serving

Create the final on-demand deployment, wait for READY, then send a real request. READY without a successful response is not serving proof. Fine-tuned LoRA adapters are served through an on-demand deployment, not the shared serverless inference catalog.

​
Step 10: Tear down

Set the recipe’s cleanup flags explicitly. Close the SDK-managed service in try/finally, then verify every trainer and deployment reached the requested final state. Resources are not deleted or scaled down unless the configuration requests it. Use the complete Cleanup and Teardown contract. Checkpoint storage and promoted models can remain after compute teardown. Report them separately from billable trainer and deployment resources.

​
Compare infrastructure

For the canonical decision rules and comparison table, see Choose Serverless or Dedicated Training.

​
Next steps