Baseten opens Serverless Loops for open-model post-training

By Marcus Bennett

Baseten opened Serverless Loops to all customers on November 6, 2026, with three open models each supporting a 262,144-token sequence. Baseten reports that NVIDIA post-trained Nemotron Super 3.5 VL on text and vision tasks, raising intent-classification accuracy from 76.8% to 94%.

Baseten's release gives teams a managed software development kit (SDK) for post-training, meaning additional adaptation of an existing model. It supports supervised fine-tuning and reinforcement learning on open models.

Baseten says its production inference stack serves more than 15 billion requests daily. The service bills per token during training and sampling and provides a direct path from checkpoints to Baseten Dedicated Inference.

For infrastructure teams, the release removes the need to assemble a distributed training stack for supported runs. It does not create fixed-cost training: serverless jobs use shared capacity, production endpoints retain GPU charges, and workspace limits can prevent provisioning. Baseten's documentation makes the trade-off explicit: economics change with run duration and deployment lifetime.

What does Serverless Loops run?

Serverless Loops divides responsibility between the customer and Baseten. Users supply the training signal; Baseten operates the graphics processing units (GPUs), kernels, model architectures and distributed-training backend, according to the company.

The Python SDK trains low-rank adaptation (LoRA) adapters while leaving base-model weights frozen. LoRA here means a small set of adapter weights trained beside a fixed base model, rather than changing every base-model parameter.

Users choose the base model, LoRA rank, learning rate, loss function, data or environment, and algorithm. Baseten runs the trainer, sampler, weight synchronization and supporting infrastructure. Supervised fine-tuning uses examples with known targets; reinforcement learning uses reward signals. The managed service supports both paths.

What changes for Tinker users?

Baseten's compatibility package preserves Tinker imports and core training and sampling calls for teams migrating existing scripts. The migration guide still requires these changes:

• Authentication switches to a Baseten application programming interface (API) key.
• Checkpoints return as paginated file URLs.
• Image inputs must be inline.
• LoRA module coverage is fixed by model family.

Compatibility covers the training API, but Baseten leaves several infrastructure-specific details for teams to adjust.

Which models fit the serverless catalog?

Baseten's serverless catalog contains exactly three models:

• Qwen/Qwen3.6-35B-A3B supports text and vision.
• zai-org/GLM-5.3-Flash supports text and vision.
• zai-org/GLM-5.3 supports text only.

Each supports a maximum sequence length of 262,144 tokens. The long-context configuration of zai-org/GLM-5.3 does not support cross_entropy or dpo losses.

Dedicated mode covers a wider model catalog, bills for GPU time and adds controls for replicas, warm reuse and spot capacity.

How does serverless handle capacity and billing?

Serverless runs use shared capacity without requiring GPU reservations. Baseten bills for tokens used in training and sampling. Time spent reading results, changing a reward function or sitting idle incurs no token charges, according to the company.

Under default mode selection, Baseten can fall back to dedicated capacity for an unsupported model, LoRA rank or sequence length. It can also fall back when a run reuses another run's deployments. Setting the scope to serverless makes an unsupported request fail instead.

Can model enablement guarantee a run?

Baseten's documentation states: “Model enablement does not guarantee provisioning.” Workspace-specific access, unavailable GPUs and organization trainer limits can still block a run, according to Baseten.

These conditions create practical capacity boundaries beyond the published catalog. A team can see a supported model in the catalog and still lack the access or available GPUs needed to start it.

How do checkpoints support training and sampling?

The quickstart exposes four core operations:

• forward_backward performs loss and gradient work.
• optim_step updates adapter weights.
• sample generates outputs.
• save_state preserves model and optimizer state for resumable training.

Publishing sampler weights creates a deployable checkpoint and a sampling client pinned to it. The first sampling request can take several minutes while serverless capacity starts, a practical consideration for short experiments.

How does a checkpoint reach production?

A sampler checkpoint deploys as the base model with the trained LoRA adapter loaded, according to Baseten's documentation. Checkpoints outlive their runs.

Teams can deploy them through the command-line interface (CLI), REST (Representational State Transfer) API or dashboard with a Hugging Face access token because deployment downloads the base weights.

The resulting OpenAI-compatible endpoint bills for its GPU while it remains live. Deleting the deployment stops that GPU charge without deleting the checkpoint. Deactivating the Loops run does not remove the deployment.

The production path includes autoscaling, deployment management and inference metrics. Users can download weights in Hugging Face Safetensors format.

What changed for general availability?

For general availability, Baseten says it improved handling of transient network errors and GPU failures. It also reduced startup overhead and accelerated weight transfers between trainers and samplers.

Baseten says those changes “support more concurrent customer workloads.” The company applies the production path to the same managed infrastructure used for its inference deployments.

How did Baseten validate the service?

Baseten says it validated Serverless Loops with numerical tests and end-to-end reinforcement-learning experiments using τ-bench tasks across retail, airline and banking. The company then evaluated those systems on held-out hard tasks.

The τ-bench project describes its benchmark as a test of whether agents can converse with users, call tools, retrieve knowledge and follow policy across enterprise domains. It checks outcomes against verifiable database results.

The NVIDIA work also reached 87% validation F1 for receipt extraction, a measure combining precision and recall. That project included reinforcement learning for visual object counting.

Which customers are using the workflow?

Baseten describes three customer workloads using the workflow before general availability:

• Datadog is using multi-turn agentic reinforcement learning to test training ideas for its site reliability engineering (SRE) agent.
• Ambience Healthcare post-trained models to correct clinical transcription errors and capture medical terminology and formatting accurately.
• LangChain Labs is post-training models on agent traces for LangSmith Engine.

LangChain's work includes reading a GitHub repository to diagnose an issue and drafting the prompt or code change for a pull request. The workflow can switch to a smaller open-weight model for classifying traces by failure mode and severity or mapping them to existing issues.

LangChain's workflow illustrates how application behavior becomes the training target. The company selects model size and task specialization around the job rather than applying one model to every trace.

Baseten says those customer accounts document use before the general-availability announcement and show an intended infrastructure loop. Application data becomes training input, checkpoints get evaluated, and selected models move toward production.

For infrastructure teams, Baseten documents a clear cost boundary. Supported serverless runs avoid GPU reservations and idle-time token charges. A live inference endpoint continues to bill for its GPU, while the serverless catalog and workspace capacity determine where the option applies.

Under Baseten's model, the next procurement test is operational and financial: teams must verify shared capacity, compatible loss settings and deployment lifetimes before treating serverless post-training as a predictable production path.