Amazon MLA-C01: Ottimizzazione dei costi per carichi di lavoro ML — 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.

Concetto fondamentale: da dove derivano i costi e le leve a tua disposizione

Il costo per i carichi di lavoro di machine learning è determinato da tre categorie fondamentali: la capacità di calcolo (compute) per il training e l’inferenza, lo storage e il trasferimento dati per i dataset e i checkpoint, e l’overhead operativo derivante da infrastruttura sottoutilizzata o mal dimensionata. Il training è spesso la singola voce di spesa più importante quando si addestrano modelli di grandi dimensioni o si eseguono molti esperimenti. Il costo dell’inferenza diventa predominante quando si servono modelli su larga scala o si richiede bassa latenza per applicazioni interattive. Le leve di ottimizzazione principali sono la scelta della famiglia e della dimensione dell’istanza, le opzioni di acquisto (on‑demand vs Spot vs Savings Plans), i modelli del ciclo di vita del modello (batch vs realtime vs serverless) e le ottimizzazioni a runtime come la compilazione del modello, il caching e il consolidamento delle istanze.

Le tecniche operative traducono queste leve in pratica. Utilizza il training gestito con istanze Spot (managed Spot training) con checkpointing per ridurre i costi di calcolo per il training fino al 70% rispetto all’on-demand, ma abbinalo al checkpointing (parametro CheckpointConfig → S3Uri di CreateTrainingJob) e al flag EnableManagedSpotTraining di CreateTrainingJob impostato su true in modo che i processi possano riprendere dopo le interruzioni. Dimensiona correttamente le istanze (right-sizing) profilando l’utilizzo effettivo di CPU/GPU/IO (metriche CloudWatch come GPUUtilization, HostCPUUtilization e le tracce del profiler da SageMaker Debugger), quindi passa a famiglie di calcolo che corrispondono alle caratteristiche del carico di lavoro (ml.c5/ml.c6 per CPU, ml.g5/ml.p4 per GPU, ml.r5 per carichi pesanti in termini di memoria). Per l’inferenza, preferisci modelli a costo proporzionale: usa l’inferenza serverless (variante di produzione di CreateEndpointConfig con ServerlessConfig → MemorySizeInMB e MaxConcurrency) per carichi di lavoro con picchi e basso throughput; usa endpoint multi-modello o la compilazione del modello (SageMaker Neo) per ridurre i requisiti delle istanze per molti modelli di piccole dimensioni; e sposta i carichi di lavoro di grandi dimensioni o non sensibili alla latenza su trasformazioni asincrone o batch (AsyncInferenceConfig e Batch Transform).

Servizi e configurazioni chiave

Amazon SageMaker espone controlli espliciti per la gestione dei costi. Per ridurre i costi di training, utilizza il training gestito con istanze Spot: nell’API CreateTrainingJob imposta EnableManagedSpotTraining=true, includi CheckpointConfig.S3Uri e imposta MaxWaitTimeInSeconds > MaxRuntimeInSeconds per consentire l’acquisizione di capacità Spot. Nell’SDK Python di SageMaker puoi impostare estimator.use_spot_instances=True, estimator.max_wait e estimator.checkpoint_s3_uri sulla posizione S3 del checkpoint. Per una bassa latenza riproducibile tra processi di training consecutivi, mantieni i container “caldi” (warm) sfruttando SageMaker Processing o addestrando i container su un’infrastruttura provisioned persistente quando la cadenza della sperimentazione lo richiede; altrimenti, riduci il tempo di avvio del container utilizzando immagini più piccole, container pre-costruiti di SageMaker o riutilizzando un’istanza di training persistente in un ambiente di sviluppo.

Per il controllo dei costi di inferenza, CreateEndpointConfig/UpdateEndpointConfig supporta molteplici strategie. Usa ServerlessConfig in ProductionVariants per lasciare che SageMaker gestisca lo scaling e la fatturazione per invocazione e memoria anziché per ore intere di istanza; ServerlessConfig richiede i valori MemorySizeInMB e MaxConcurrency. Per carichi di lavoro stabili e ad alto throughput, utilizza istanze Provisioned e applica policy di target tracking di Application Auto Scaling all’endpoint per evitare il sovradimensionamento. Gli endpoint multi-modello riducono i costi quando si ospitano molti modelli usati di rado, condividendo un singolo container e caricando gli artefatti del modello da S3 on demand. Per raccomandazioni sul dimensionamento del modello, chiama CreateInferenceRecommendationsJob in Inference Recommender, che fornisce indicazioni su tipo di istanza, dimensione del batch e latenza/throughput.

Gli impegni di fatturazione (billing commitment) sono gestiti al meglio con i SageMaker Savings Plans o gli AWS Compute Savings Plans. Acquista un Savings Plan tramite la console AWS Billing per impegnarti a un certo ammontare di $/ora per un periodo di 1 o 3 anni; questo sconta l’utilizzo di capacità di calcolo on-demand di SageMaker (training e hosting) su tutte le famiglie di istanze. Nota che i Savings Plans si applicano all’utilizzo on-demand e non alle istanze Spot, quindi combina le strategie: acquista Savings Plans per l’utilizzo di base stabile e usa le istanze Spot per il training con picchi di carico o sperimentale.

Pattern di progettazione e compromessi

Il pattern con istanze Spot gestite e checkpointing è la scelta ideale per esecuzioni di training distribuito lunghe o di grandi dimensioni. Richiede modifiche minime al codice: abilitare EnableManagedSpotTraining, fornire CheckpointConfig.S3Uri e impostare un MaxWaitTimeInSeconds appropriato per tollerare la schedulazione delle istanze Spot. Il compromesso è una maggiore complessità di riavvio e un tempo di esecuzione effettivo (wall-clock time) leggermente più lungo se le interruzioni delle istanze Spot sono frequenti; il vantaggio è una drastica riduzione dei costi. Per la sperimentazione iterativa in cui la latenza di avvio tra processi consecutivi è importante, si consiglia di mantenere un ambiente di sviluppo “caldo” (warm): utilizzare istanze provisioned più piccole, come ml.m5 o ml.c5, con dati precaricati su cache locale/NVMe, oppure eseguire molti esperimenti come processi di elaborazione locale sulla stessa istanza utilizzando SageMaker Processing o i notebook di Studio. Questo aumenta il costo di base ma riduce il tempo di ciclo totale.

Per l’inferenza, scegliere tra endpoint serverless e provisioned a seconda del profilo di traffico. L’inferenza serverless (ServerlessConfig) elimina la pianificazione della capacità ed è la soluzione più economica per traffico intermittente e imprevedibile, poiché si paga per invocazione e per l’allocazione di memoria. Il compromesso è la latenza di avvio a freddo (cold start) e i limiti di dimensione; per SLA con requisiti di bassa latenza stringenti, preferire istanze provisioned con autoscaling e considerare l’ottimizzazione del modello con SageMaker Neo per ridurre il numero di istanze. Laddove è necessario ospitare molti modelli ma il traffico per singolo modello è basso, gli endpoint multi-modello consolidano l’utilizzo del disco e della memoria e riducono il costo per modello, a scapito di un caricamento a freddo (cold-start) leggermente più lento per un modello non ancora caricato.

Il dimensionamento corretto (right-sizing) dovrebbe basarsi sull’osservazione, non su congetture. Utilizzare il profiling di SageMaker Debugger e CloudWatch per raccogliere metriche come GPUUtilization e DiskReadOps; quindi, eseguire un processo di Inference Recommender (CreateInferenceRecommendationsJob) per convalidare la classe/tipo di istanza e le prestazioni. Se i requisiti di latenza del modello sono stringenti, considerare la quantizzazione del modello o la compilazione con SageMaker Neo, oppure l’uso di acceleratori Elastic Inference per associare capacità di inferenza GPU frazionata a istanze CPU; Elastic Inference consente di collegare un piccolo acceleratore a un’istanza CPU, riducendo il costo rispetto a istanze GPU complete per determinati modelli.

Errori comuni e criteri decisionali

Un errore frequente è applicare una singola strategia di ottimizzazione dei costi a tutti i carichi di lavoro. I Savings Plans sono efficaci per un utilizzo di base costante, ma dovrebbero essere combinati con le istanze Spot per i carichi di lavoro sperimentali e con il serverless per l’inferenza con picchi di traffico. Non dare per scontato che le istanze Spot siano gratuite: richiedono checkpointing e una logica di training tollerante alle interruzioni; configura i parametri

undefined

e EnableManagedSpotTraining, e calcola un MaxWaitTimeInSeconds che rifletta per quanto tempo sei disposto ad accettare un avvio ritardato. Un altro errore è trascurare la telemetria: senza profilazione (con SageMaker Debugger, CloudWatch e Inference Recommender) si rischia il sovradimensionamento (over-provisioning) o la scelta di una famiglia di istanze con caratteristiche di CPU, GPU e memoria non allineate. Infine, l’inferenza serverless semplifica i costi ma può introdurre avvii a freddo (cold start) imprevedibili; misura la latenza end-to-end quando usi ServerlessConfig e ricorri a endpoint con provisioning e autoscaling per SLA rigorosi.

Problema pratico: Scenario d’uso

Azienda: FinSight Analytics. Sfida: FinSight deve creare una pipeline di rilevamento frodi che esegua training frequenti su log di transazioni e profili cliente archiviati in S3, mantenga i dati isolati, supporti la governance delle versioni del modello con approvazione manuale prima del deployment in produzione, riduca i costi di training per il retraining notturno, minimizzi la latenza di avvio per ogni processo durante la sperimentazione rapida e fornisca un endpoint in tempo reale a bassa latenza con sensibilità ai costi per il traffico con picchi.

Registro centralizzato e sicuro per dati e modelli. Archiviare i dati in un bucket S3 protetto con crittografia predefinita e policy del bucket che limitano l’accesso al ruolo di esecuzione di SageMaker. Registrare i modelli in SageMaker Model Registry; utilizzare lo step RegisterModel di SageMaker Pipelines per creare pacchetti di modelli con ModelApprovalStatus impostato di default su “PendingManualApproval”. Implementare il flusso di lavoro umano di approvazione manuale creando una SageMaker Pipeline che emette un pacchetto di modello e uno step di approvazione manuale; quando i revisori autorizzati terminano la validazione, chiamano

undefined

per consentire il deployment. Motivazione: Model Registry fornisce un versioning centralizzato e ModelApprovalStatus si integra direttamente con le API di SageMaker, richiedendo operazioni personalizzate minime.

Retraining notturno efficiente in termini di costi. Utilizzare il training gestito con istanze Spot (managed Spot training) creando processi di training con EnableManagedSpotTraining=true, includere CheckpointConfig.S3Uri per rendere persistente lo stato dell’ottimizzatore e impostare MaxRuntimeInSeconds e MaxWaitTimeInSeconds in modo appropriato affinché i processi possano riprendere in caso di interruzioni delle istanze Spot. Combinare questo approccio con l’acquisto di un Savings Plan di base, dimensionato per coprire le ore medie di training/inferenza on-demand per ridurre i costi stabili, e usare le istanze Spot per la sperimentazione dove le interruzioni sono tollerabili. Motivazione: il managed Spot training riduce i costi di calcolo con modifiche minime al codice; i Savings Plans si applicano all’utilizzo di base on-demand per ridurre le spese prevedibili.
Ridurre la latenza di avvio per la sperimentazione. Per i cicli di sperimentazione interattivi, mantenere un profilo di istanza di sviluppo persistente (una ml.c5 o ml.m5) in SageMaker Studio o una piccola Notebook Instance dedicata con dataset precaricati su EBS/NVMe e riutilizzare tale ambiente per molte esecuzioni di training rapide. Per i processi notturni di produzione, continuare a usare il managed Spot training con checkpointing. Motivazione: un ambiente persistente evita gli avvii a freddo (cold start) dei container e migliora la velocità di iterazione, preservando al contempo i risparmi sui costi per le esecuzioni più pesanti.
Servizio in tempo reale a bassa latenza e sensibile ai costi. Eseguire il deployment del modello approvato su un endpoint con provisioning (provisioned endpoint) per una bassa latenza di base e associare una policy di Application Auto Scaling all’endpoint per ridurre le risorse durante le ore non di punta. Per picchi di traffico imprevedibili, prevedere un’opzione di inferenza Serverless per i modelli a basso volume o utilizzare l’inferenza asincrona (AsyncInferenceConfig con S3 OutputConfig) per attività pesanti di scoring batch non in tempo reale. Applicare la compilazione con SageMaker Neo al modello prima del deployment per ridurre il suo footprint su CPU/GPU. Motivazione: la combinazione di provisioning e autoscaling offre una bassa latenza stabile e controllo dei costi; gli endpoint serverless o asincroni gestiscono i carichi di lavoro con picchi o in batch in modo più efficiente dal punto di vista dei costi, e Neo riduce i requisiti dell’istanza.

Questo approccio combina EnableManagedSpotTraining con CheckpointConfig per la riduzione dei costi di training, SageMaker Model Registry e UpdateModelPackage per le approvazioni manuali, un’istanza di sviluppo persistente per una latenza di avvio ridotta e un mix di modelli con provisioning, serverless e compilati per ottimizzare i costi di inferenza.

← IA generativa e modelli fondazionali · Tutti i domini · Visione artificiale →

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