Amazon MLS-C01: Deployment, inferenza ed erogazione (Implementazione e operazioni di ML) — 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.

Pattern di deployment e opzioni di serving

Le scelte per il serving dei modelli bilanciano latenza, costo, throughput e complessità operativa. Gli endpoint SageMaker in tempo reale (provisioned o serverless) forniscono latenze da meno di 100 ms a qualche secondo, adatte per API interattive; scegli famiglie di istanze come ml.c5/m5 per modelli CPU, ml.g4dn o ml.p3 per modelli GPU, o ml.inf1 per l’inferenza a basso costo e alto throughput con Inferentia. L’inferenza asincrona e Batch Transform sono adatti per casi d’uso con batch di grandi dimensioni o latenza variabile: Batch Transform è ideale per grandi processi offline (dividi oggetti S3 di grandi dimensioni in shard e usa istanze ml.m5/c5 o GPU secondo necessità), mentre SageMaker Asynchronous Inference supporta payload più grandi con accodamento per batch quasi in tempo reale. Gli endpoint multi-modello ospitano molti modelli dietro un unico container, riducendo l’overhead di storage caricando i modelli on-demand; funzionano meglio quando i modelli sono piccoli, hanno costi di cold-start modesti e i pattern di accesso sono sparsi. Scegli SageMaker Serverless Inference per carichi di lavoro imprevedibili e a basso throughput per evitare la gestione delle istanze; fai attenzione ai cold start e al runtime limitato. I criteri decisionali chiave includono gli SLO di latenza, il costo per invocazione, il pattern di concorrenza, la dimensione del modello e la tolleranza al cold-start. Una trappola comune è usare endpoint in tempo reale per carichi di lavoro batch a volume estremamente elevato: è costoso; usa invece Batch Transform, Async Inference, o invoca gli endpoint tramite batching e worker concorrenti.

Scaling, traffic shaping e ottimizzazione dei costi

L’autoscaling, il traffic shifting e il controllo dei costi devono essere co-progettati con la topologia di deployment. Usa Application Auto Scaling per scalare le varianti degli endpoint SageMaker con policy di target-tracking basate su metriche di invocazione o metriche personalizzate di CloudWatch; definisci capacità min/max e cooldown sensati per evitare il thrashing. Per i deployment blue/green e i rollout canary, usa endpoint multi-variante o aggiornamenti di EndpointConfig con percentuali di suddivisione del traffico e aumenti graduali; integra con AWS CodeDeploy per automatizzare il traffic shifting. Le ottimizzazioni dei costi includono il pruning del modello, la quantizzazione (FP16 o int8), la compilazione con SageMaker Neo o AWS Neuron per Inf1 e lo spostamento di carichi di lavoro non sensibili alla latenza su Batch Transform o inferenza serverless. Le istanze Spot riducono i costi di training ma non sono applicabili per gli endpoint in tempo reale; invece, dimensiona correttamente i tipi di istanza (cpu vs gpu vs inferentia) e consolida i modelli con endpoint multi-modello dove appropriato. Fai attenzione a trappole come il sovradimensionamento (over-provisioning) quando si usa il target-tracking senza comprendere il throughput per istanza, o presumere che gli endpoint multi-modello eliminino i limiti di memoria: il caricamento del modello richiede comunque memoria e può aumentare la latenza. Inoltre, comprimi gli artefatti del modello (ONNX, TF SavedModel con gz) e usa strategie di lazy-loading per ridurre i tempi di storage e di cold-start.

Edge, inferenza a bassa latenza e posizionamento del pre/post-processing

Per ambienti a bassissima latenza o disconnessi, esegui il deploy dei modelli su AWS IoT Greengrass (v2) o usa SageMaker Edge Manager per pacchettizzare e monitorare i modelli su dispositivi edge; compila con SageMaker Neo o componenti AWS IoT Greengrass e usa la quantizzazione per rispettare i vincoli di memoria/CPU. Posiziona il pre-processing e l’estrazione delle feature dove si minimizzano la latenza end-to-end e i costi: filtri semplici possono essere eseguiti nel firmware del dispositivo o in una Lambda su Greengrass, mentre il batching e le trasformazioni pesanti appartengono a un gateway edge o al cloud. Per finestre di eventi in streaming (es. finestre mobili di 10 minuti), acquisisci i dati con Amazon Kinesis Data Streams o Amazon MSK, usa Kinesis Data Analytics o Flink/Apache Spark per il windowing e l’aggregazione, e inoltra le feature riassunte a un endpoint SageMaker o a un modello leggero on-edge: questo riduce l’egress di rete e la frequenza di invocazione del modello. Fai attenzione a trappole come ignorare il versioning dei modelli sui dispositivi edge, o non riuscire a provisionare storage sufficiente sul dispositivo per gli artefatti del modello. Per i microservizi lato server, colloca il pre-processing insieme al servizio (API Gateway + Lambda o ALB + Fargate) per evitare l’overhead delle chiamate a freddo e ridurre le dimensioni del payload inviato al modello.

Monitoraggio, auditing, governance e gestione dei dati

L’ML operativo richiede un monitoraggio continuo dello stato di salute del modello e la governance dei dati. Utilizzare SageMaker Model Monitor per creare una baseline dei dati di addestramento con un DataQualityJob e configurare il monitoraggio continuo per rilevare data drift, regressioni nella qualità del modello, valori mancanti e vincoli personalizzati; abilitare DataCaptureConfig sugli endpoint per catturare input/output su S3 e avviare i job di Model Monitor. Per il lineage e l’auditing a livello di feature, utilizzare Amazon SageMaker Feature Store (store online e offline) in combinazione con AWS Glue Data Catalog e CloudTrail per tracciare l’accesso e le trasformazioni dei set di dati; Amazon Macie e i job di Glue/SageMaker Processing possono individuare e oscurare le PII prima dell’addestramento. Le insidie della crittografia includono SSE-KMS: quando gli oggetti S3 sono crittografati con una CMK gestita dal cliente, assicurarsi che il ruolo di esecuzione di SageMaker disponga delle autorizzazioni kms:Decrypt e kms:GenerateDataKey e che la policy della CMK conceda l’accesso; assicurarsi inoltre che le policy dei bucket S3 e gli endpoint VPC non blocchino l’accesso. Per oggetti S3 di grandi dimensioni su base giornaliera (ad es. 100 GB), evitare l’ingestion di un singolo file: partizionare in molti oggetti più piccoli, archiviare in formato Parquet e comprimere, e utilizzare Athena/Glue per il rilevamento dello schema. Le trappole comuni includono pianificazioni di monitoraggio insufficienti, la mancata generazione di una baseline adeguata per Model Monitor e la dimenticanza di concedere l’accesso a KMS a tutti i service principal (SageMaker, Glue, Lambda) che necessitano della decrittografia.

Problema Pratico: Scenario d’Uso

Scenario: Streamlytic Media gestisce una piattaforma di analisi di podcast su AWS. Utilizzano Kinesis Data Streams per l’ingestion degli eventi utente, archiviano le feature aggregate in S3 e ospitano modelli in SageMaker per la previsione dell’engagement in tempo reale. I dati contengono occasionalmente PII e sono crittografati con una chiave gestita dal cliente SSE-KMS.

Sfida: Fornire previsioni a bassa latenza su una finestra mobile di eventi di 10 minuti, oscurare le PII prima dell’addestramento del modello, garantire che SageMaker possa leggere i dati crittografati da S3 e implementare un monitoraggio continuo per il feature drift.

Approccio Raccomandato:

Creare un Kinesis Data Stream per l’ingestion degli eventi, eseguire Kinesis Data Analytics (Flink) per mantenere finestre mobili di 10 minuti ed emettere le feature aggregate su S3 in formato Parquet con partizioni orarie.
Rilevare e oscurare le PII utilizzando Amazon Macie per l’individuazione e un job di SageMaker Processing (o un job di AWS Glue) per applicare l’oscuramento/tokenizzazione deterministica; archiviare i risultati in uno store offline di Feature Store per l’addestramento.
Concedere al ruolo di esecuzione di SageMaker le autorizzazioni kms:Decrypt e kms:GenerateDataKey sulla CMK, aggiungere il ruolo alla policy della chiave CMK e assicurarsi che la policy del bucket S3 o l’endpoint VPC consentano l’accesso a SageMaker.
Distribuire il modello come endpoint in tempo reale di SageMaker su istanze ml.inf1, abilitare DataCaptureConfig, creare una baseline di Model Monitor dai dati di addestramento e configurare il monitoraggio continuo con avvisi su CloudWatch.

Logica: L’aggregazione in streaming con Kinesis + Flink minimizza il volume degli eventi e la latenza; l’oscuramento in fase di elaborazione preserva la privacy e la conformità; le autorizzazioni KMS esplicite prevengono i fallimenti di accesso; gli endpoint basati su Inferentia e Model Monitor bilanciano un basso costo di inferenza con l’osservabilità operativa.

← Addestramento · Tutti i domini · Sicurezza →

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