AWS Makes SageMaker Training Session APIs Generally Available for Custom Post-Training Loops

AWS launched an operation-level post-training API on October 22

On October 22, 2026, AWS made SageMaker AI training session APIs generally available. The product keeps a supported model loaded on managed GPUs while a team’s Python process decides what happens next. Instead of handing SageMaker a complete script or selecting only a predefined recipe, developers call operations such as sample(), forward_backward() and optim_step() and compose supervised fine-tuning, preference optimization or reinforcement learning loops around them.

This is available now through the sagemaker-train package and SageMaker Python SDK workflow, not a roadmap promise. AWS also published an Apache-2.0 cookbook with chat SFT, GSM8K RL, competitive-programming RL and KTO preference recipes. The launch does not make arbitrary training code serverless: the local process still owns data loading, algorithm control, reward computation, agent environments, evaluation logic and error handling.

The live contract covers four models and three Regions

The documentation lists four exact base-model identifiers. openai/gpt-oss-20b is available in us-east-1, us-west-2 and ap-south-1. google/gemma-4-31B-it and Qwen/Qwen3.6-27B are listed in us-west-2 and ap-south-1. Qwen/Qwen3.8-27B is listed only in us-west-2. That is the verified launch matrix; a model being open-weight elsewhere does not imply it can be attached to this service.

The default adjustable quota is two concurrent fine-tuning training sessions. An active session continues to consume that quota until stop() is called or the session expires, so cleanup belongs in normal and error paths. Teams also need an eligible Region, model access, a caller identity, an execution role, a model package group and S3 output configuration before they can treat the feature as available in their own account.

AWS manages GPUs, but the team still owns the algorithm

ServiceClient holds platform configuration and creates a session. TrainingClient handles forward, backward, optimizer and checkpoint operations; SamplingClient handles generation and token log probabilities. Calls return futures, so a loop can queue sampling or ordered training work. AWS says it handles GPU allocation, model and LoRA loading, distributed execution, gradient synchronization, tenant isolation, fault recovery and checkpoint storage.

The customer still defines prompts, data, loss choice, reward function, advantage computation, rollout environment and stopping criteria. An active session also exposes an OpenAI-compatible chat-completions endpoint for sampling. That can ease integration, but it is a session-scoped training surface rather than proof of production inference compatibility, latency or availability.

Checkpointing and access controls are part of the operating contract

The documented workflow trains LoRA adapters. Every saved checkpoint is registered as a model package in a SageMaker model package group; resumable state can include weights and optimizer state, while merged or adapter checkpoints can move toward a SageMaker real-time endpoint. Frequent sampler refreshes can also create model-package versions, so retention, naming and cleanup need explicit ownership.

AWS provides one managed policy for callers and another for the execution role. The caller must be able to pass the role to training-session.sagemaker.amazonaws.com, while the execution role needs access to training data, checkpoints, hub content and model packages. Optional customer-managed KMS keys and VPC mode create additional permissions and networking work. AWS says customer data and customized weights are not used to train another model; buyers should still verify account, Region, encryption, logging and retention requirements against their own controls.

Billing follows tokens, not the session wall clock

AWS separates charges into prefill tokens, sample tokens and train tokens. Prefill covers inputs such as prompts and conversation history, sample covers generated rollout tokens, and train covers the backward-pass work that updates weights. AWS says GPU billing stops while a reward function scores a batch in the customer’s environment and that no capacity reservation is required.

That boundary can avoid paying for managed GPUs during slow local grading, but token billing is not automatically cheap. Multi-turn RL multiplies prompts, history, responses, group samples and repeated updates; failed or low-value rollouts still consume tokens. The dedicated public pricing tab did not render model-specific numeric rates during this review. Confirm rates in the intended Region, forecast all three token dimensions, add S3, registry, evaluation and deployment costs, and set a hard experiment budget before execution.

The launch results are examples, not independent benchmarks

AWS reports that a 10-step GPT-OSS 20B GSM8K example moved held-out accuracy from 56% to 75%. Its code-RL recipe used 50 steps, 128 problems per step, eight responses per problem, two turns and a LoRA rank of 32; AWS reports training reward rising from 0.46 to 0.60 and accuracy on 200 held-out problems rising from 40% to 50.5%. The cookbook also publishes reference results for SFT and KTO recipes.

AccessAllGPT did not reproduce those runs. The results do not establish statistical uncertainty, transfer to another task, total tokens, final cost, comparison with a training job or HyperPod, or safety under a reward function that can be gamed. They demonstrate API use and an AWS-observed learning signal. A buyer should evaluate accepted task outcomes, severe failures, reward hacking, regression, reproducibility and complete cost on a frozen local set.

What AI training teams should do next

Trial the service when a supported model and Region fit, a fixed managed recipe is too restrictive, and operating a GPU cluster would distract from the training algorithm. Start with one cookbook recipe, pin the SDK and repository revision, establish a no-training baseline, cap sample and train tokens, and save enough traces and checkpoints to explain both progress and regressions. Keep held-out evaluation outside the reward loop.

Adopt only if repeat runs beat the accepted baseline at a tolerable full cost and the IAM, network, data and checkpoint controls pass review. Constrain access while quotas, spend controls or reward behavior are immature. Wait when the required model, Region or numeric rate is unavailable. Reject the path when a managed recipe is sufficient, the task needs unsupported full-model training, or a team cannot safely own the algorithm, evaluator and session lifecycle.

Disclosures

AccessAllGPT received no AWS account, credits, model access, SDK access beyond public files, training data, private briefing, benchmark results, review, payment or compensation for this article. AWS, OpenAI, Google, Qwen and cookbook dataset or tool providers did not sponsor, review or endorse it. AccessAllGPT did not test, score, rank or deploy the service or supported models. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with Amazon Web Services or organizations cited. Publication-wide relationships are listed on the disclosures page.