Le API delle sessioni di addestramento di Amazon SageMaker AI permettono di costruire un ciclo Python personalizzato, chiamando singole operazioni mentre AWS gestisce le GPU. Così il team mantiene il controllo dell’algoritmo senza scegliere o amministrare un cluster GPU. AWS ha annunciato le API il 22 ottobre 2026.
Il ciclo di addestramento resta nel codice
Con queste API lo sviluppatore compone il ciclo di addestramento con operazioni come sample(), forward_backward() e optim_step(). Il modello resta caricato sulle GPU tra una chiamata e l’altra; SageMaker AI gestisce l’esecuzione distribuita, la sincronizzazione dei gradienti e l’infrastruttura GPU.
Nel flusso del SageMaker Python SDK, ServiceClient crea il client di addestramento TrainingClient, che può a sua volta creare un SamplingClient. Il primo gestisce la sessione, il secondo espone le operazioni di training e quello di sampling si occupa della generazione. Lo sviluppatore continua a fornire il codice Python e, per i flussi di reinforcement learning, i dati, l’ambiente, l’algoritmo e la logica delle ricompense.
Gli esempi di AWS mostrano come si combinano queste parti. Nel caso GSM8K, AWS ha usato Group Relative Policy Optimization (GRPO) e un adattamento a basso rango (LoRA) di GPT-OSS 20B; dopo 10 passaggi su 40 problemi, riferisce un’accuratezza sui problemi tenuti da parte salita dal 56% al 75%.
Per il Code RL, AWS descrive un ciclo in cui un container SandboxFusion esegue il codice generato contro test unitari sul computer dell’utente. La ricompensa è 1 se tutti i test passano, 0 altrimenti, con una penalità di 0,1 quando il modello non restituisce un blocco di codice. Nella prova riportata, con GPT-OSS 20B e LoRA di rank 32, AWS ha usato 50 passaggi, 128 problemi per passaggio, 8 risposte per problema, due turni e una soglia di obsolescenza k=3. L’azienda riferisce che la ricompensa è passata da 0,46 a 0,60 e l’accuratezza su 200 problemi tenuti da parte dal 40% al 50,5%.
Sono risultati riferiti da AWS per i suoi esempi, non valori da applicare ad altri modelli o cicli di addestramento.
Che cosa richiede CreateTrainingSession
La chiamata diretta CreateTrainingSession richiede cinque campi: LoraConfig, ModelConfig, OutputConfig, RoleArn e TrainingSessionName. Se la richiesta riesce, l’API restituisce un TrainingSessionArn. Il ruolo IAM deve poter accedere al percorso S3 di output e al gruppo di pacchetti modello. ModelPackageGroupArn, Tags e VpcConfig sono campi facoltativi. Il riferimento ufficiale dell’API CreateTrainingSession descrive il contratto della richiesta.
Questo contratto è distinto dal flusso semplificato dell’SDK: il metodo create_lora_training_client crea un client di training, mentre CreateTrainingSession specifica i campi richiesti dal servizio. Per preparare un prototipo, conviene quindi distinguere il codice con cui si compone il ciclo dai dati e dai permessi necessari per aprire la sessione.
Modelli, regioni e sessioni simultanee
AWS elenca queste combinazioni di modello e regione:
| Modello | Regioni AWS elencate |
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 |
Le regioni AWS sono specifiche per ciascun modello e non corrispondono al Paese in cui si trova chi sviluppa. La quota predefinita è di due sessioni di fine-tuning simultanee; AWS la rende modificabile. Una sessione attiva continua a occupare la quota finché non viene arrestata o scade.
Come vengono conteggiati i token
AWS indica tre dimensioni di fatturazione:
prefill: token di input forniti al modello prima della generazione, come prompt, cronologia della conversazione e contesto;sample: token generati durante il campionamento delle risposte;train: token elaborati durante il passaggio di calcolo che aggiorna i pesi del modello.
Nel caso in cui la logica delle ricompense venga eseguita localmente, AWS afferma che quel lavoro locale non consuma tempo GPU mentre è in corso. Questo consente di separare il calcolo svolto dal codice dell’utente dalle operazioni eseguite sulle GPU gestite.
Quale opzione SageMaker scegliere
Le opzioni descritte da AWS distribuiscono diversamente il controllo sul ciclo e la gestione dell’infrastruttura:
| Opzione | Controllo sul ciclo di addestramento | Infrastruttura |
| API gestite Serverless Model Customization | Si scelgono modello, iperparametri e dati entro il flusso gestito | Serverless; AWS gestisce le risorse e non si seleziona un’istanza |
| API delle sessioni di training | Si scrive il ciclo e si chiamano le singole operazioni | Sessioni GPU serverless gestite da AWS, senza amministrare un cluster |
| SageMaker Training Jobs | Si controlla il training all’interno del job inviato | Job gestiti e temporanei; chi lo invia sceglie il tipo di istanza |
| SageMaker HyperPod | Controllo completo del training | Cluster persistenti gestiti, con recupero avanzato dagli errori |
Se l’obiettivo è definire la logica dell’algoritmo senza gestire un cluster, le sessioni collocano il controllo nel codice e l’infrastruttura nelle mani di AWS. I Training Jobs richiedono invece di scegliere il tipo di istanza; HyperPod offre cluster persistenti. Le API gestite Serverless Model Customization lasciano più decisioni sul ciclo al flusso predefinito.
