Amazon MLS-C01: Addestramento, addestramento distribuito e ottimizzazione degli iperparametri — Guida allo studio

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Fa parte della AWS Machine Learning Specialty MLS-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Processi di training, container e transizione al training nel cloud con modifiche minime al codice

Quando si spostano i carichi di lavoro di training su SageMaker, l’obiettivo di progettazione principale è evitare di riscrivere il codice del modello, garantendo al contempo che il runtime del container esponga le variabili d’ambiente e i percorsi dei canali previsti da SageMaker. Utilizzare lo Script Mode di SageMaker con l’Estimator specifico per il framework (PyTorch, TensorFlow, XGBoost) in modo che lo stesso script di training possa essere eseguito in locale e nel cloud con modifiche minime: leggere i dati da SM_CHANNEL_TRAIN, scrivere il modello in SM_MODEL_DIR e rispettare SM_NUM_GPUS/SM_HOSTS/SM_CURRENT_HOST. Per ambienti personalizzati, creare un’immagine Docker che estenda i container ufficiali AWS Deep Learning Containers (o il SageMaker training toolkit) e caricarla su Amazon ECR; assicurarsi che l’entry point del container rispetti il contratto di training di SageMaker. Selezionare i tipi di istanza in base al profilo di calcolo: processi CPU-bound sulle famiglie ml.c5/m5, training su GPU su istanze ml.p3, ml.p4d, g4dn o g5; scegliere la dimensione dell’istanza in base alla memoria e al rapporto GPU/CPU. Le trappole comuni includono percorsi di file locali hard-coded, l’assunzione di un singolo host (che causa problemi nei processi distribuiti) e la mancata dichiarazione della modalità di input del training (Pipe vs File), che influisce sulle prestazioni di I/O. Per la riproducibilità e la prevedibilità dei costi, abilitare il managed spot training solo dopo aver aggiunto un checkpointing robusto e aver impostato max_wait > max_run per consentire le interruzioni delle istanze Spot.

Pattern di training distribuito, modalità di input dei dati e scelte di storage

Il deep learning distribuito richiede un bilanciamento tra parallelismo del modello, parallelismo dei dati e architettura di I/O. Per il training multi-GPU su singolo host e multi-host, utilizzare le primitive native dei framework — torch.distributed o la MultiWorkerMirroredStrategy di TensorFlow — oppure sfruttare le librerie smdistributed di SageMaker: smdistributed.dataparallel per la scalabilità tramite parallelismo dei dati e smdistributed.modelparallel o DeepSpeed per modelli transformer molto grandi. Utilizzare S3 come storage canonico per dataset di grandi dimensioni, ma evitare un numero elevato di piccole richieste GET a S3: consolidare i file in un numero minore di archivi, usare file partizionati in formato RecordIO/TFRecord o collegare un filesystem POSIX. Scegliere la modalità Pipe per lo streaming dei dati di training direttamente da S3 per dataset di grandi dimensioni, al fine di ridurre l’uso del disco locale e il tempo di avvio; usare la modalità File quando il training richiede accesso casuale (random-access) o quando è necessario l’intero dataset su un volume EBS. Per un throughput elevato e semantica POSIX su più istanze, montare Amazon FSx for Lustre o Amazon EFS; FSx è migliore per letture parallele ad alte prestazioni. Gli errori comuni includono la mancata partizione (sharding) dei dati tra gli host (causando duplicati), la sovrastima del throughput di S3 per istanza e l’ignorare le regole di scaling per batch-size e learning-rate quando si aumenta il parallelismo.

Training Spot, checkpointing e strategie di ottimizzazione dei costi

Il Managed Spot training può ridurre drasticamente i costi se la progettazione del training tollera le interruzioni. Configurare il managed spot tramite l’Estimator di SageMaker (use_spot_instances=True), oltre al checkpointing: fornire un checkpoint_s3_uri persistente e una checkpoint_dir locale, e salvare i checkpoint con una frequenza sufficiente a limitare il tempo di rilavorazione. Impostare max_wait in modo che sia significativamente superiore a max_run, così che il processo possa ritentare l’esecuzione su istanze interrotte all’interno della finestra spot. Per i framework, implementare scritture atomiche dei checkpoint e una logica di ripresa robusta che ispezioni l’ultimo checkpoint su S3, ripristini lo stato dell’ottimizzatore e dello scheduler, e quindi continui il training. La frequenza dei checkpoint dovrebbe bilanciare l’overhead di scrittura e il potenziale spreco di risorse di calcolo; per epoche lunghe o modelli molto grandi, effettuare il checkpoint a metà epoca utilizzando snapshot dell’accumulo di gradienti o salvataggi basati sugli step. Le trappole di costo includono dimenticare di rendere persistenti i checkpoint su S3 (causando un riavvio completo in caso di interruzione), fare affidamento sullo storage effimero dell’istanza e impostare max_wait uguale a max_run, il che impedisce i tentativi di riesecuzione. Combinare le istanze spot con la precisione mista (AMP) per ulteriori risparmi di calcolo e con payload di checkpoint più piccoli (salvando solo pesi e ottimizzatore) per ridurre i costi di scrittura su S3 e la latenza di ripresa.

Ottimizzazione degli iperparametri, strategie di tuning e criteri decisionali pratici

Un’efficace HPO (Hyperparameter Optimization) combina strategia di ricerca, allocazione delle risorse ed early-stopping. L’HyperparameterTuner di SageMaker supporta la ricerca Random e Bayesiana, con intervalli configurabili di tipo ContinuousParameter, IntegerParameter e CategoricalParameter; per spazi di ricerca ampi, iniziate con una ricerca casuale per un’esplorazione ampia, quindi eseguite un’ottimizzazione Bayesiana per sfruttare le aree più promettenti. Utilizzate metodi di early-stopping come Hyperband o l’early stopping integrato di SageMaker per risparmiare budget, e usate il tuning di tipo warm-start per riutilizzare i risultati tra esperimenti correlati. Scegliete attentamente le metriche obiettivo (AUC di validazione per task con dati sbilanciati, F1 per il rilevamento di frodi con classi sbilanciate, metriche personalizzate ponderate sul costo per scenari di esaurimento scorte). Le trappole più comuni includono intervalli troppo ampi che causano il fallimento di molti processi, l’uso di una codifica categorica per iperparametri essenzialmente continui e la mancata scalabilità di un’HPO consapevole delle risorse: processi di sondaggio brevi su istanze più piccole per trovare aree approssimative, seguiti da esecuzioni più lunghe su istanze GPU a piena dimensione. Per il training distribuito, ottimizzate sia gli iperparametri algoritmici (learning rate, batch size) sia i parametri a livello di sistema (passi di accumulazione del gradiente, numero di shard di dati). Strumentate il codice con SageMaker Debugger e usate le metriche di CloudWatch per rilevare misurazioni rumorose; quando è presente un’alta varianza, aumentate le ripetizioni per configurazione o usate una selezione basata sulla mediana.

Problema Pratico: Scenario d’Uso

Scenario: FinRetailer esegue migliaia di previsioni della domanda a 30 giorni per ogni SKU in SageMaker; archivia anni di file CSV giornalieri in S3 e richiede un’elevata accuratezza per gli articoli a domanda sporadica (tail-demand), mantenendo al contempo una latenza di inferenza accettabile nei processi di scoring batch.

Sfida: Prevedere migliaia di serie storiche con cronologie lunghe e importanza sbilanciata (l’esaurimento scorte costa più dell’eccesso di magazzino), minimizzando i costi di calcolo e preservando al contempo l’accuratezza su eventi rari di alta domanda.

Approccio Consigliato:

1. Utilizzare l’algoritmo integrato DeepAR di SageMaker o un modello temporale personalizzato in PyTorch (basato su Transformer) pacchettizzato in un Estimator in Script Mode; archiviare i dati di training come file partizionati (sharded) in formato RecordIO/TFRecord e utilizzare la modalità File con FSx for Lustre per un training multi-istanza ad alto throughput.
2. Iniziare con un training distribuito su istanze più piccole (smddp o Horovod) per ottimizzare l’architettura del modello e gli iperparametri, utilizzando HyperparameterTuner con ricerca Bayesiana ed early stopping; definire l’obiettivo come una quantile loss ponderata che penalizza più pesantemente la sotto-previsione.
3. Abilitare il training gestito con istanze Spot con checkpoint_s3_uri e checkpoint frequenti basati sul numero di passi (step); impostare max_wait > max_run per tollerare le interruzioni e riprendere dall’ultimo checkpoint salvato in S3.
4. Per l’inferenza in produzione, eseguire lo scoring in batch utilizzando endpoint multi-modello o processi di trasformazione batch asincroni su istanze ottimizzate per il calcolo; applicare regole di business in fase di post-elaborazione e una soglia calibrata che tenga conto dei costi di esaurimento scorte.

Motivazione: L’uso di architetture DeepAR/transformer gestisce in modo efficiente un gran numero di serie storiche; i formati binari partizionati (sharded) e FSx riducono i colli di bottiglia I/O per il training distribuito, l’HPO Bayesiana con un obiettivo su misura concentra la ricerca sulle metriche di costo operativo e il training con istanze Spot e checkpoint riduce i costi senza sacrificare i progressi.

← Serie temporali e previsione · Tutti i domini · Deployment →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →