AWS SageMaker training sessions: write your own RL loop, billed per token

On 22 October 2026 AWS announced the general availability of training sessions in Amazon SageMaker AI serverless model customization. According to AWS's announcement, you write and coordinate the training loop yourself, including custom loss functions and reward signals, while SageMaker AI handles GPU allocation, distributed execution, fault recovery and checkpoint storage. Training sessions are available today for four open-weight base models: gpt-oss-20b, gemma-4-31B-it, Qwen3.6-27B and Qwen3.8-27B.

What you write and what AWS runs

AWS's technical post says the API "abstracts away the compute" rather than the algorithm. Operations such as forward_backward(), optim_step() and sample() become SageMaker API calls against a live session where the model stays loaded on the GPUs. Your Python process, on your own machine, loads the data, samples responses, scores them with a verifier, reward model or test harness, and sends the scores back.

The same primitives cover supervised fine-tuning, preference optimisation and reinforcement learning with ppo, importance_sampling or cispo losses. An active session also serves an OpenAI-compatible chat completions endpoint, so existing client code can sample from it. Training uses Low-Rank Adaptation (LoRA) adapters; the sample code sets rank 32.

How it is billed

AWS says usage is billed per token processed and that the meter stops while your reward function runs on your side. Its example: if scoring a batch takes 10 seconds on your machine, no GPU time is billed during that time. AWS argues this removes idle-GPU cost and makes spend easier to forecast. Both posts say there is no capacity to reserve.

Neither post states a price per token, so a team cannot yet estimate a run from the announcement alone. AWS also notes the saving is largest for workloads with heavy local computation, such as complex reward models, multi-tool agent rollouts or human-in-the-loop evaluation; a cheap reward function gains little.

The results AWS reports

• GSM8K, about 8,500 grade-school maths problems: in AWS's sample run, 10 training steps on 40 problems with GRPO took held-out accuracy for gpt-oss-20b from 56% to 75%.
• Code RL recipe: 50 steps of 128 problems and 8 responses each, with two turns and a staleness bound of 3 steps, lifted training reward from 0.46 to 0.60 and accuracy on 200 held-out test problems from 40% to 50.5%.
• Customer comments quoted by AWS: ImagineSoftware describes building a healthcare claim-denial triage model, and Karini AI says it fine-tuned gpt-oss-20b for multi-turn tool calling against an Amazon Neptune knowledge graph. Neither gives a measured result.

These are AWS's own demonstrations on small public datasets, run by the authors of the product. They show the loop works; they do not show what a custom reward earns on a company's real task.

Controls and operational notes

Each session uses an IAM execution role you create, and you can add your own KMS key and VPC configuration. AWS says data and checkpoints stay in your S3 buckets in the Region you choose and that it does not use your data or customised weights to train other models. Before deployment you can evaluate for accuracy, bias and safety, then apply guardrails and monitor with Amazon CloudWatch.

Two practical details from the technical post: a running session counts against your concurrent-session quota until you call stop() or it expires, so stop it in error paths too; and the SDK needs Python 3.10 to 3.12 on Linux or macOS. Supported Regions and quotas are in the documentation rather than the posts.

What the posts leave out

Both posts are vendor-published. They omit a per-token price, Region availability, quota numbers, and any comparison of cost or quality against hourly-billed training jobs. For most teams the harder part is the one AWS leaves to you: writing a reward function that scores real work correctly.