Skip to main content
Use the Loops Python SDK to create a LoRA training run, save a checkpoint, generate text from those weights, and list the checkpoint from both Python and the HTTP API. The base model throughout is Qwen/Qwen3.5-2B, one of the supported base models. The trainer and sampler bill for their GPUs while they run; the final step shuts them down.

Prerequisites

  • A workspace API key, set as BASETEN_API_KEY.
  • Python 3.12+ and uv to install the SDK and run the script.
  • The Baseten CLI to manage and shut down the run.

Install

Install baseten-loops into a uv project. Create one first if you don’t have it:
Verify the install by running uv run python train_loops.py:
The printed class path and resolved version confirm your project uses the Loops SDK.

Provision a trainer

The SDK creates the run, so you don’t need to run truss loops push first. A Loops session pairs a trainer (forward, backward, and optimizer steps) with a sampler (generates from current weights). Constructing a ServiceClient and calling create_lora_training_client() provisions the trainer and returns a TrainingClient; the sampler comes later, when you first create a sampling client. The call blocks until the trainer is ready, which takes several minutes for a small base model like this one and can reach tens of minutes for the largest supported models. The SDK gives up waiting after an hour. Replace the contents of train_loops.py with the provision step:
train_loops.py
You’ll append the training, sampling, and listing steps to this same file in the next three sections, then run the whole thing once at the end. The trainer and sampler run on GPUs in your workspace and keep running after your script exits, so plan to finish with the shut down step.
For more training throughput, scale the trainer with replicas. Loops shards each batch across replicas automatically; the preset node count applies to every replica. For unattended work, run the client with baseten loops exec when a laptop or third-party host can’t provide stable outbound connectivity.

Run a training round trip

The smallest complete round trip is one forward pass, one backward pass, one optimizer step, and one weight save. The block below mirrors the canonical supervised fine-tuning (SFT) example: it tokenizes a prompt-and-answer pair, masks the prompt positions from the loss, runs the round trip, and saves a named checkpoint. Append to train_loops.py:
train_loops.py
forward_backward() is the first training operation you submit after provisioning. save_weights_for_sampler() publishes a sampler checkpoint under sampler_weights/ that you can deploy to inference. This checkpoint omits optimizer state, so you can’t resume training from it; use save_state() when you need a resumable checkpoint.

Sample from the tuned weights

You can generate from the checkpoint you saved without deploying anything. create_sampling_client() takes the bt:// URI that save_weights_for_sampler() returned and binds a SamplingClient to those weights. The first call on a run provisions the run’s paired sampler, so your first sample() waits through its cold start; later calls reuse it. To hide that cold start behind training steps, see Overlap trainer and sampler startup. Append to train_loops.py:
train_loops.py
One optimizer step barely changes a 2B model, so the completion reads like base-model output. Still, the sampler served the step-1 weights your trainer published seconds earlier, without a restart or a deploy step in between. In a longer run, this same call is how you evaluate checkpoints mid-training.

List checkpoints

Every save_weights_for_sampler() call creates a checkpoint. The bound TrainingClient lists them with list_checkpoints(), no arguments needed. Append to train_loops.py:
train_loops.py
Now run the full script. Output values vary, but a successful run prints a session ID, run ID, loss, optimizer metrics, saved checkpoint URI, a sampled completion, and one listed checkpoint:
You might also see warnings from transformers about PyTorch being unavailable and from the Hugging Face Hub about unauthenticated requests. Both are harmless here: the client only uses transformers for tokenization, and the tokenizer download works without a token. For resource management outside the training process, use the Baseten CLI or REST API. Use the run_id your script printed when provisioning.
The REST API returns the following shape. The CLI returns the same checkpoint fields but omits optional fields whose value is null.
REST API output
Both interfaces identify checkpoints with the same fields, including the globally unique id and the checkpoint name. Use the ID to inspect the checkpoint files:
Output
Both interfaces return short-lived download URLs. The CLI follows every page. For REST requests, pass next_page_token back as the page_token query parameter until next_page_token is null; each page contains up to 1,000 files by default. To download the weight files from either S3 or a Baseten volume, call download_checkpoint() with the globally unique id value as the checkpoint_id argument:
From a separate Python session where training_client isn’t in scope, construct a ServiceClient() and call the same method on it. To work with presigned URLs for an S3-backed checkpoint instead, call get_checkpoint_archive_url().

Skip the cold start on re-runs

Your first run provisioned a trainer and sampler. The second run doesn’t have to. Grab the run_id your script printed (run_id=run123 in the example output above), point the next run at it, and Loops reuses the same trainer and sampler:
You can also pass the ID directly in code, which wins if both the kwarg and the environment variable are set:
Reuse by session ID (reuse_from_session_id, LOOPS_REUSE_FROM_SESSION_ID) still works but is deprecated in favor of the run ID. From the HTTP API, send reuse_from_session_id in the body of POST /v1/loops/trainers or POST /v1/loops/samplers. Reuse is best-effort. If the prior trainer is stopped, failed, or unhealthy, Loops provisions a fresh one and your script still runs.

Shut down the session

The trainer and sampler bill for their GPUs until you deactivate them. While a TrainingClient is open, it keeps the training session warm with a background health-check ping, so close the client (or exit the script) when you finish training. Then check what’s live and shut it down:
baseten loops run list automatically excludes runs with status.name set to INACTIVE and shows one row per remaining run, with its run ID, base model, and status. The REST API returns inactive runs too, so the example uses jq to apply the same filter. Both interfaces deactivate the trainer and its paired sampler while preserving your checkpoints. You can still list checkpoints, fetch their files, and deploy them to inference after shutdown.

Next steps

  • Deploy a checkpoint: Serve step-1 as a dedicated inference deployment and call it over the OpenAI-compatible route.
  • Train on your data: Replace the single example with a batched loop, resumable checkpoints, and mid-training evals.
  • Loops concepts: Sessions, trainers, samplers, checkpoints, and how weight sync works.
  • Loops API reference: Every HTTP route, for scripting session lifecycles and CI pipelines.