AWS announced Amazon SageMaker AI training session APIs on October 22, 2026, giving developers control over the Python training loop while SageMaker AI manages GPU-backed operations. You write the algorithm and session setup; the service keeps the model loaded across calls and handles GPU provisioning and distributed execution.
What the APIs let you control
The APIs let you compose training operations into a custom procedure instead of submitting a complete training script or choosing a preset fine-tuning workflow. The SageMaker Python SDK organizes the work through three clients: ServiceClient starts and manages sessions, TrainingClient handles training and checkpoint operations, and SamplingClient handles generation and scoring.
A loop can call sample() to generate responses, run your own reward or scoring logic, then call forward_backward() and optim_step() to update the model. The Python loop and reward logic run on the developer’s machine; SageMaker AI runs GPU-bound sampling, gradient updates and checkpoint operations. The model stays loaded across API calls.
This division suits teams that need a custom loss, reward function or training sequence but do not want to select and operate a GPU cluster. It still requires Python code, data, algorithm logic, an IAM role and an output location.
What a direct CreateTrainingSession request needs
The low-level CreateTrainingSession API requires five fields: LoraConfig, ModelConfig, OutputConfig, RoleArn and TrainingSessionName. On success, it returns a TrainingSessionArn. The IAM role must be able to access the output S3 path and model package group. ModelPackageGroupArn, Tags and VpcConfig are optional request fields.
These are the service API’s request fields, distinct from the SDK convenience flow that creates a LoRA training client through ServiceClient. The CreateTrainingSession API reference defines the direct request contract.
Check model and Region eligibility
AWS lists four base models, each with its own supported Region set:
| Base model | AWS Regions listed |
openai/gpt-oss-20b | us-east-1, us-west-2, ap-south-1 |
google/gemma-4-31B-it | us-west-2, ap-south-1 |
Qwen/Qwen3.6-27B | us-west-2, ap-south-1 |
Qwen/Qwen3.8-27B | us-west-2 |
The model-to-Region pairing matters when planning an experiment: a model on this list is not thereby available in every listed Region. AWS also sets the default maximum at two concurrent fine-tuning sessions. The quota is adjustable. The training session APIs guide lists the current model and Region combinations and quota.
How token billing is divided
AWS identifies three billing dimensions: prefill tokens processed as input, sample tokens generated during sampling, and train tokens processed for model updates. In AWS’s description, reward scoring done locally does not consume GPU time while that local work runs. A workload with substantial local scoring therefore has a different GPU-use pattern from one that spends the same time running GPU-bound operations.
How training sessions compare with other SageMaker options
AWS positions training sessions between highly managed customization and options that leave more infrastructure decisions to the user. The practical difference is how much of the training algorithm you write and how much infrastructure you operate.
| SageMaker option | Control over training loop | Infrastructure model |
| Serverless Model Customization managed APIs | Choose a model, available hyperparameters and data | Serverless; no instance selection |
| Training session APIs | Write the loop and call training operations | Serverless GPU sessions; no cluster management or instance selection |
| SageMaker Training Jobs | Full training control within a submitted job | Managed, ephemeral jobs; you select the instance type |
| SageMaker HyperPod | Full training control | Managed, persistent clusters with advanced fault recovery |
If you need to define the algorithm but want SageMaker AI to manage the GPUs, training sessions occupy that middle ground. Training Jobs give you control within a submitted job while requiring an instance-type choice; HyperPod uses persistent managed clusters.
What AWS’s examples report
AWS’s GSM8K supervised fine-tuning and reinforcement-learning walkthrough reports that 10 training steps on 40 problems raised held-out accuracy from 56% to 75%.
For its competitive-programming Code RL example, AWS reports a 50-step GPT-OSS 20B run using a rank-32 LoRA adapter, 128 problems per step, eight responses per problem, two turns and a staleness bound of k=3. The reported reward rose from 0.46 to 0.60, while accuracy on 200 held-out problems rose from 40% to 50.5%.
