Amazon MLA-C01: Deployment del modello e inferenza — Guida allo studio

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

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

Endpoint in tempo reale, serverless, asincroni e batch — concetti fondamentali

L’inferenza in tempo reale in Amazon SageMaker è un modello di servizio stateful a bassa latenza in cui si crea un Model, un EndpointConfig e un Endpoint che alloca risorse di calcolo provisioned (tipi di istanza ml.*) e rimane disponibile per servire le richieste tramite l’API InvokeEndpoint. CreateEndpointConfig accetta ProductionVariants, e ogni ProductionVariant definisce ModelName, InitialInstanceCount, InstanceType e InitialVariantWeight; è possibile modificare il traffico e la capacità con UpdateEndpointWeightsAndCapacities o UpdateEndpoint. Per esigenze di bassa latenza prevedibile, gli endpoint in tempo reale provisioned sono l’opzione principale e supportano pipeline di inferenza multi-container per concatenare container di pre-elaborazione, del modello e di post-elaborazione.

L’inferenza Serverless elimina la gestione delle istanze ed è configurata a livello di endpoint con una ServerlessConfig che specifica MemorySizeInMB e MaxConcurrency per ogni ProductionVariant; SageMaker gestisce il provisioning dei container e scala a zero quando inattivo, rendendola ideale per carichi di lavoro con picchi (spiky) e a basso throughput. L’inferenza asincrona è ottimizzata per richieste che richiedono molto tempo per essere eseguite o dove il client non necessita di una risposta sincrona. Un endpoint asincrono viene creato con AsyncInferenceConfig in CreateEndpointConfig (OutputConfig con S3OutputPath, ClientConfig opzionale e MaxConcurrentInvocationsPerInstance) e i client chiamano InvokeEndpointAsync, fornendo un URI S3 di input; i risultati vengono scritti nella posizione di output S3 configurata. Batch Transform è un tipo di job separato (CreateTransformJob) per grandi carichi di lavoro di inferenza offline; l’API richiede TransformInput (S3DataSource con S3Uri e S3DataType), TransformOutput (S3OutputPath, Accept, AssembleWith) e TransformResources (InstanceType, InstanceCount). Batch Transform è la scelta migliore quando è importante il throughput ma non la latenza e supporta un elevato parallelismo su più set di dati.

Endpoint multi-modello, pipeline di inferenza, shadowing e test A/B — servizi e configurazioni chiave

Quando si ospitano molti modelli con un basso QPS per modello, i Multi-Model Endpoints (MME) di SageMaker consentono a un singolo container di ospitare da decine a migliaia di artefatti di modello archiviati in S3 e di caricarli on-demand. Si costruisce un container server per modelli che implementa il pattern del server multi-modello di SageMaker o si utilizza un’immagine di un framework supportato, si caricano i tarball dei modelli su S3 e si crea una risorsa Model che fa riferimento al container. Al momento dell’invocazione, si passa il nome del modello di destinazione tramite il parametro TargetModel dell’API InvokeEndpoint (o l’header X-Amzn-SageMaker-Target-Model) in modo che il server carichi quel modello da S3 in memoria. Gli MME consentono di risparmiare memoria e costi operativi per grandi flotte di modelli, ma aggiungono una latenza di caricamento a freddo (cold-load) per i modelli non ancora residenti nel runtime.

Le pipeline di inferenza sono implementate come modelli multi-container in cui la risorsa Model elenca i Containers in ordine; l’endpoint instrada i payload attraverso il primo container (pre-elaborazione), poi il container del modello, e infine il container di post-elaborazione. Si definisce ogni container con il proprio ModelDataUrl e le proprie variabili d’ambiente in CreateModel. Per test di tipo canary o blue/green, si utilizzano più ProductionVariants in un EndpointConfig e si controlla la suddivisione del traffico con InitialVariantWeight e successivamente tramite UpdateEndpointWeightsAndCapacities. Un deployment di tipo shadow può essere realizzato inviando una copia di ogni richiesta a livello di applicazione a un endpoint shadow (senza peso di traffico sull’endpoint di produzione) oppure creando una ProductionVariant con un peso basso in modo che l’infrastruttura dell’endpoint riceva parte del traffico specchiato; la duplicazione della richiesta a livello di applicazione offre un isolamento completo dell’esperimento e un’osservabilità indipendente.

Per il monitoraggio on-demand e continuo, si configura DataCaptureConfig durante la creazione di un endpoint per persistere i payload delle richieste e delle risposte su S3. I campi di interesse di DataCaptureConfig includono EnableCapture (true), InitialSamplingPercentage, DestinationS3Uri e CaptureOptions (REQUEST, RESPONSE). I dati catturati diventano la base per i controlli post-deployment di SageMaker Model Monitor e SageMaker Clarify; è possibile creare baseline con CreateMonitoringSchedule di Model Monitor ed eseguire job di Processing ad-hoc che utilizzano il container di monitoraggio del modello integrato per calcolare vincoli e metriche di drift.

Pattern di progettazione e compromessi

Scegliere gli endpoint in tempo reale con provisioning quando è necessaria una latenza da singola cifra a poche decine di millisecondi e ci si può permettere la capacità sempre attiva. Se il costo al minuto durante l’inattività è il vincolo principale e il traffico è intermittente, gli endpoint serverless riducono le operazioni: configurare

undefined

per ogni variante e lasciare che SageMaker esegua la scalabilità automatica. Per carichi di lavoro con inferenze a lunga esecuzione o pattern di scambio di payload pesanti, gli endpoint asincroni disaccoppiano il ciclo di vita del client dal calcolo; richiedono S3 per input/output e sono più appropriati quando i client possono effettuare il polling o ricevere notifiche S3 per il completamento.

Gli endpoint multi-modello riducono la duplicazione della memoria e la complessità della gestione degli oggetti S3, ma aggiungono una latenza di avvio a freddo (cold-start) per ogni modello e richiedono un server di modelli in grado di caricare da S3 on-demand e di gestire correttamente il ciclo di vita (eviction/LRU). Se la latenza per modello è critica, ospitare i modelli “caldi” (hot) su ProductionVariants dedicate e scaricare i modelli a basso traffico su un MME. Le pipeline di inferenza centralizzano la logica di pre-elaborazione e post-elaborazione più vicino al modello, riducendo il codice lato client e garantendo una trasformazione coerente tra addestramento e inferenza, ma aumentano la complessità di avvio dell’endpoint e richiedono una progettazione robusta del contratto del container (codec di input/output e tipi di contenuto).

L’A/B testing che utilizza i pesi delle ProductionVariant è semplice per la suddivisione del traffico e la raccolta di metriche offline, ma quando si desidera duplicare il traffico in modalità “shadow” senza influire sulle metriche di produzione, è preferibile il mirroring a livello di applicazione. Per rollout progressivi e automazione del rollback, integrare

undefined

in un flusso di lavoro (workflow) di CodePipeline o Step Functions che includa la valutazione automatica delle metriche tramite le metriche di CloudWatch, gli avvisi di Model Monitor e un’azione di approvazione manuale che controlla la promozione finale.

Errori comuni e criteri decisionali

Un errore operativo comune è presumere che Model Monitor rileverà problemi di disponibilità delle etichette; Model Monitor può rilevare la deriva nella distribuzione delle feature e violazioni della qualità dei dati dalle richieste catturate, ma per misurare il degrado delle metriche basate sulle etichette (F1, recall) è necessario fornire le etichette ground-truth nuovamente in S3 in un formato che i job di monitoraggio possano consumare e pianificare un job di monitoraggio che calcoli il confronto tra predizione e verità. Un altro errore è non dimensionare appropriatamente ServerlessConfig.MemorySizeInMB; una memoria sotto-provisionata causa throttling o crash del container, mentre un sovra-provisioning aumenta i costi. Per gli endpoint multi-modello, trascurare di impostare un layout e un ciclo di vita appropriati per gli oggetti S3 (prefissi, manifest dei modelli) rende i caricamenti a freddo (cold load) più lenti e complica le policy di rimozione (eviction).

Quando si gestisce lo sbilanciamento delle classi per il rilevamento di frodi, è preferibile utilizzare la ponderazione nativa dell’algoritmo rispetto a pipeline di campionamento pesanti per ridurre al minimo l’overhead operativo; ad esempio, XGBoost (il container SageMaker XGBoost) supporta l’iperparametro ‘scale_pos_weight’, che si calcola come negative_examples/positive_examples e si passa tramite la mappa degli iperparametri nella chiamata CreateTrainingJob. Per un controllo manuale del deployment (gating), utilizzare il SageMaker Model Registry: creare un ModelPackageGroup, chiamare CreateModelPackage per registrare un pacchetto modello e impostare lo stato del pacchetto su PendingManualApproval; un’azione di approvazione manuale esterna di CodePipeline o una conferma manuale tramite Step Functions + SNS possono quindi chiamare UpdateModelPackage per impostare ApprovalStatus = "Approved" prima che vengano eseguiti CreateModel o CreateEndpoint.

Problema Pratico: Scenario d’Uso

FraudDetectCo sta costruendo un sistema di rilevamento frodi online che deve consolidare i log delle transazioni in S3 e le tabelle dei profili cliente da un database MySQL on-premise, addestrare un modello XGBoost, distribuirlo con latenza quasi in tempo reale, imporre un gate di approvazione manuale per i rilasci in produzione e rilevare sia anomalie nel dataset che derive del modello (model drift) on-demand.

Aggregazione e pre-elaborazione dei dati: utilizzare AWS Database Migration Service (DMS) o il connettore JDBC di AWS Glue per replicare continuamente le tabelle MySQL on-premise in S3 (formato parquet) o in un data lake basato su Amazon RDS/Athena; catalogare con AWS Glue e registrare le feature nell’offline store di Amazon SageMaker Feature Store per fornire una ricerca delle feature coerente tra addestramento e inferenza online. Questo centralizza il lignaggio delle feature (feature lineage) e applica le policy di sicurezza di S3 e la governance di Lake Formation per l’isolamento.
Addestramento e gestione dello sbilanciamento delle classi: eseguire job di addestramento SageMaker utilizzando il container predefinito di SageMaker XGBoost. Calcolare il rapporto tra le etichette nel set di addestramento e impostare l’iperparametro di XGBoost “scale_pos_weight” nella mappa HyperParameters della chiamata CreateTrainingJob per gestire lo sbilanciamento delle classi con una pre-elaborazione minima. Utilizzare la modalità Pipe per il canale di addestramento (DataSource con S3DataSource e S3DataType impostato su S3Prefix, e abilitare “RecordWrapperType”:“None” se si usa la modalità Pipe) per ridurre il tempo di avvio e la latenza di download dei dati tra job consecutivi.
Registro dei modelli e approvazione manuale: registrare i modelli addestrati nel SageMaker Model Registry chiamando CreateModelPackage all’interno di un ModelPackageGroup. Impostare l’iniziale ApprovalStatus su PendingManualApproval, integrare una pipeline AWS CodePipeline che includa un’azione di approvazione manuale (AWS Manual Approval) e, dopo la conferma manuale, chiamare UpdateModelPackage con ApprovalStatus="Approved" prima di promuovere il ModelPackage in produzione tramite CreateModel e CreateEndpointConfig.
Deployment e topologia di inferenza: distribuire il modello su un endpoint real-time provisioned per ottenere uno scoring a bassa latenza. Se in futuro sarà necessario ospitare centinaia di modelli, valutare un Multi-Model Endpoint e utilizzare il parametro TargetModel di InvokeEndpoint per indirizzare la richiesta a modelli specifici archiviati in S3. Configurare DataCaptureConfig (EnableCapture=true, InitialSamplingPercentage=100, DestinationS3Uri=s3:///captures, CaptureOptions=['REQUEST','RESPONSE']) per raccogliere i payload di richiesta/risposta per analisi on-demand.
Monitoraggio e rilevamento di anomalie: pianificare baseline di SageMaker Model Monitor con CreateMonitoringSchedule per la qualità dei dati e la deriva delle feature (feature drift). Per il rilevamento di anomalie a livello di dataset e la visualizzazione, fornire i dati catturati in S3 ad Amazon Lookout for Metrics per rilevare automaticamente le anomalie e ad Amazon QuickSight per creare dashboard. Per la valutazione on-demand di bias e drift, eseguire job di elaborazione di SageMaker Clarify sui dati catturati o avviare un job di elaborazione ad-hoc di Model Monitor (tramite CreateProcessingJob) che applica i vincoli della baseline salvata e produce il report di confronto.

Motivazione: questo approccio centralizza le feature per un addestramento riproducibile e un’inferenza a bassa latenza, utilizza scale_pos_weight di XGBoost per lo sbilanciamento delle classi con una complessità minima della pipeline, impone un’approvazione manuale nel Model Registry integrato con CodePipeline, riduce la latenza di avvio dell’addestramento utilizzando la modalità Pipe per lo streaming dei dati di training e fornisce sia il rilevamento automatico delle anomalie (Lookout for Metrics) sia controlli on-demand di equità/deriva (Clarify + Model Monitor) utilizzando i dati di inferenza catturati.

← Valutazione e selezione del modello · Tutti i domini · MLOps e gestione del ciclo di vita del modello →

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