Baseten Loops: Serverless SFT and RL Training, Billed Per Token (What the Docs Confirm)

Baseten's Loops product trains LoRA adapters on open-weight base models using supervised fine-tuning or reinforcement learning from a Python SDK, CLI or REST API, billing serverless runs per token trained and sampled rather than per GPU hour, according to Baseten's documentation. Three models train in serverless mode — Qwen3.6-35B-A3B, GLM-5.3-Flash and GLM-5.3, each with a 262,144-token maximum sequence — while all listed models, including Qwen3.8-27B, Kimi-K3 and Nemotron 3 Ultra, train in dedicated mode, which bills GPU time including time between operations. A secondhand report said Baseten planned general availability for November 6, 2026, but no official Baseten announcement was found.

Baseten Loops lets you train an open-weight model with supervised fine-tuning or reinforcement learning from a short Python script, and pay per token instead of per GPU hour. A secondhand report says Baseten planned to make Loops generally available on November 6, 2026 . We could not find an official announcement, so this article is built from Baseten's own documentation: what the product does, which models it supports, and how it bills. Sources: the Baseten docs on availability modes https://docs.baseten.co/loops/availability-modes/overview?ref=explainx , concepts https://docs.baseten.co/loops/concepts?ref=explainx , supported models https://docs.baseten.co/loops/supported-models?ref=explainx and the quickstart https://docs.baseten.co/loops/quickstart?ref=explainx . TL;DR | Question | Answer from the docs | |---|---| | What does it train? | LoRA adapters on open-weight base models, with SFT or RL | | How do you use it? | Python SDK baseten-loops , CLI or REST API | | Serverless models | Qwen3.6-35B-A3B, GLM-5.3-Flash, GLM-5.3 | | Dedicated models | All listed, including Qwen3.8-27B, Kimi-K3, Nemotron 3 Ultra and others | | Serverless billing | Tokens trained and sampled; no charge while idle | | Dedicated billing | GPU time, including time between operations | | GA status | Reported for Nov 6; not confirmed by Baseten in what we read | How does a Loops run work? The concepts page describes a run as the training state for a base model and its LoRA adapter. Your Python process, local or remote, sends forward, backward and optimizer operations to the trainer, then publishes weights for a sampler to generate from. The parts: - Session: groups runs, samplers and checkpoints under a training project. Creating a ServiceClient creates a session. - Trainer: owns the adapter and optimizer state, applies steps and saves checkpoints. - Sampler: generates from a base model or published checkpoint. A paired sampler belongs to a run; a standalone sampler is independent. - Checkpoints: paths of the form bt://loops:<run id /... . Use save state for recovery and save weights for sampler to publish weights for sampling and inference deployment. - Weight sync: in serverless mode the sampling client is pinned to the published checkpoint; in dedicated mode it sets a minimum policy version and the sampler loads later weights without restarting. For debugging, setting LOOPS REQUEST LOG makes the SDK append one JSON line per request and response so you can replay a failed run. What does the quickstart show? The quickstart trains a LoRA adapter on Qwen3.6-35B-A3B with RL on serverless Loops, samples from the published weights, saves resumable state and deploys the tuned model. The toy task is a one-answer question: "I am thinking of either Doom or Quake. Name it. Reply with the title only." A reply of Quake scores 1.0, anything else 0.0. Each step samples 16 replies. A reply's advantage is its reward minus the mean of the 16, so correct replies become more likely. If all 16 score the same, advantages are zero and the step samples again. The script runs five steps at LoRA rank 8 and a learning rate of 2e-5, and prints mean reward per step. The point of the toy task is mechanics: you write the reward function, build datums with target tokens, sampler logprobs and advantages, and Loops handles the GPUs. For a real job, the docs example is a support-ticket classifier where the reward is the correct category. Which models can you train? The supported models page says every model trains in dedicated mode and three also train serverless. | Model | Mode | Max sequence | Vision | |---|---|---|---| | Qwen/Qwen3.6-35B-A3B | Serverless and dedicated | 262,144 | Yes | | zai-org/GLM-5.3-Flash | Serverless and dedicated | 262,144 | Yes | | zai-org/GLM-5.3 | Serverless and dedicated | 262,144 | No | | Qwen/Qwen3.8-27B | Dedicated | 262,144 | Yes | | Qwen/Qwen3.5 family 0.8B to 397B-A17B | Dedicated | 131,072 to 262,144 | Yes | | deepseek-ai/DeepSeek-V4-Flash | Dedicated | 131,072 | No | | google/gemma-4 26B-A4B, 31B | Dedicated | 65,536 to 131,072 | No | | moonshotai/Kimi-K3 | Dedicated | 262,144 SFT , 131,072 RL | No | | nvidia Nemotron 3 Ultra 550B-A55B NVFP4 | Dedicated | 262,144 | No | | meta-models Muse-Spark-Open-816B-A42B | Dedicated | 262,144 SFT only | No | That is a partial list; the page shows 31 entries. One caveat from the page: GLM-5.3's long-context configuration does not support the cross entropy or dpo losses. Your workspace may not have every model enabled. The docs show a capabilities endpoint loops/capabilities?use case=rl or sft that returns the models and sequence lengths your workspace can use. What should you watch for in the reward design? RL jobs fail more often on the reward than on the infrastructure, and the quickstart hints at why. Its group-relative setup only learns when the 16 sampled replies differ in score. If all replies are right or all are wrong, every advantage is zero and the step samples again. The script even caps this: after 20 unusable groups in a row it stops with an error instead of burning tokens. That cap matters for billing. On serverless you pay for sampled tokens, so a reward that is too hard nothing scores or too easy everything scores wastes money without teaching anything. Test your reward on a few samples from the base model first. Aim for a mix of passes and fails. If you see none, simplify the task or add partial credit. Two further habits follow from the docs. Keep the maximum reply length small while you iterate, as the quickstart does with 16 tokens. And evaluate saved checkpoints with a standalone sampler, which serves a base model or saved checkpoint without an active trainer, so you do not keep a trainer running just to score results. Serverless or dedicated: which should you pick? A small shape reaching for a green token at the end of a path, showing reward-driven reinforcement learning in Baseten Loops | | Serverless | Dedicated | |---|---|---| | What you manage | Your training code only | Your code plus trainer and sampler deployments: replica counts, capacity type, reuse | | Billing | Tokens you train and sample | GPU time while trainer and sampler run, including time between operations | | Models | The three listed | Every model in the catalog | | Ending a run | Deactivate; an idle run incurs no token charges | Deactivate, or it ends after 15 minutes of inactivity by default | | Capacity | Shared; nothing to reserve | Deployments belong to the run for its whole duration | | Scaling | Not controllable | Add trainer replicas for update throughput, sampler replicas for rollouts, spot capacity for interruptible runs | The docs say serverless fits experimentation: "time spent reading results or revising a reward function between steps costs nothing." Dedicated fits scaling out a run, especially asynchronous RL, models serverless does not support, and planned sustained runs. By default a run uses serverless when it supports the model, LoRA rank and sequence length; otherwise it uses dedicated. If you want to avoid surprise GPU billing, set scope="serverless" . The request then fails instead of falling back. The scope values are default , serverless and deployment . What does serverless bill for? Per the serverless page, runs bill for prefill, cached prefill, sample and train tokens at per-model rates listed under "Serverless Loops token pricing." Those rates are separate from Model API token rates for the same base model. We did not extract the rate table, so we give no prices here. Two details to know: baseten loops usage reports dedicated GPU allocations but not serverless token usage or spend, so track spend elsewhere, and saved checkpoints remain available to download, deploy or restart from. What is the GA claim, and what is verified? | Item | Status | |---|---| | Loops SDK, docs, quickstart exist | Verified in Baseten docs | | Serverless and dedicated modes, billing rules | Verified in Baseten docs | | Three serverless models | Verified in Baseten docs | | GA on November 6, 2026 | Reported via a secondhand summary of an X post from Baseten's team; no official notice found | | Per-token prices | Not extracted here; see Baseten's pricing section | The Digg-style summary we saw says Loops had been in public preview and that Baseten said it planned to make it generally available on November 6. That is a plan reported by an aggregator. Before you build a project on it, check Baseten's changelog. How does Loops compare with other training services? Serverless training for open models is a crowded space now. See our coverage of Snowflake Cortex Training https://explainx.ai/blog/snowflake-cortex-training-preview-serverless-sft-rl-open-weight-models-aws-what-we-know-2026 , Together's post-training platform and Tinker migration https://explainx.ai/blog/together-post-training-b200-9-dollars-gpu-hour-first-eight-weeks-sft-rl-tinker-migration-minimax-m3-1-flash-2026 , and our basic explainer on what fine-tuning is https://explainx.ai/blog/what-is-fine-tuning-llm-complete-guide-2026 . The differences we can state from docs alone: - Baseten: per-token billing on three models, GPU billing on the rest; training SDK with explicit forward, backward and optimizer calls, so you control the loop. - Others: see the linked posts for their pricing and limits; we do not compare numbers across vendors without a shared source. For more on Baseten's other recent products, see its Grid router claim https://explainx.ai/blog/baseten-grid-router-72-percent-coding-cost-cut-opus-5-5-claimed-vs-verified-2026 and Sandboxes https://explainx.ai/blog/baseten-sandboxes-agent-environments-standby-30-seconds-free-until-november-16-10-sandbox-limit-what-to-check-2026 . Should you try it? A green fitted collar around a cream core, a picture of a LoRA adapter on a base model for Baseten Loops Try it if you already have a task with a measurable reward, such as classification, tool-call correctness or a unit-test pass rate, and want to run RL on an open model without renting a cluster. A sensible first run: 1. Pick a serverless model: Qwen3.6-35B-A3B if you need vision, GLM-5.3-Flash for a lighter text and vision option. 2. Set scope="serverless" so a config mismatch fails loudly. 3. Start with the quickstart's five-step loop to confirm rewards rise. 4. Replace the toy reward with your own and keep group size at 16 or more so advantages are not all zero. 5. Save state regularly with save state and deploy the checkpoint only after you have evaluated it. Do not use it if you need a model outside the three serverless ones and cannot afford idle dedicated GPUs. Dedicated billing continues between operations until you deactivate the run or the 15-minute inactivity timeout ends it. Bottom line Loops gives a clean answer to a real problem: RL on open models is hard to run, and token billing makes experiments cheap to stop and restart. The docs back that up for three models. The GA date and the price table are the two things to confirm with Baseten before you plan around them. Details come from Baseten docs read on November 6, 2026 and may change.