Amazon AIF-C01: Ottimizzazione dei Costi e Pricing per AI/ML — Guida allo studio

By Laurynas Brazys · 30 July 2026 · #amazon #aif-c01 #certification #exam-prep #study-guide

Fa parte della AWS AI Practitioner AIF-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Fattori di costo e modelli di prezzo in Bedrock, SageMaker ed EC2

La tariffazione per i carichi di lavoro AI/ML si suddivide tra calcolo, storage, rete e misurazioni specifiche del servizio. L’accesso ai modelli fondamentali tramite Amazon Bedrock è tipicamente misurato per richiesta o per token per i carichi di lavoro testuali e al secondo per le API di streaming; SageMaker addebita le ore di istanza per l’addestramento e l’hosting multi-tenant, oltre al trasferimento dati e allo storage. L’hosting basato su EC2 comporta il costo grezzo per ora di istanza, con costi aggiuntivi per lo storage EBS, EFS o FSx e per l’egress dalla VPC. I principali fattori di costo sono la dimensione del modello (modelli più grandi aumentano il lavoro matematico/sui token e l’impronta di memoria), il throughput di inferenza (le chiamate sincrone sensibili alla latenza costano di più quando vincolate a GPU costose) e lo spostamento dei dati per la retrieval-augmented generation (RAG), dove le ricerche di embedding e le ricerche vettoriali possono moltiplicare le chiamate. Tra le trappole comuni per gli operatori vi sono la sottostima dei costi degli embedding per sistemi RAG ad alto QPS, il lasciare in esecuzione più endpoint SageMaker inattivi e l’ignorare l’egress tra regioni diverse quando si mantengono le PII all’interno della regione. I criteri decisionali dovrebbero quindi considerare il volume di richieste, la tolleranza alla latenza per richiesta, se il modello debba essere sottoposto a fine-tuning o possa rimanere standard, e se l’inferenza gestita dal provider (endpoint Bedrock/SageMaker) o le istanze EC2/GPU self-hosted offrano un TCO migliore, tenendo conto dell’overhead di gestione e scalabilità.

Selezione delle istanze, istanze Spot e modelli di ottimizzazione del calcolo

La scelta delle istanze influisce sia sulle prestazioni che sui costi. Per l’addestramento, utilizzare Trainium (trn1) o cluster di GPU (p4/p5) quando è essenziale un throughput matriciale su larga scala; per l’inferenza, preferire Inferentia/Inf2 (inf1/inf2) o l’inferenza su CPU basata su Graviton per modelli più piccoli al fine di ridurre i costi. Servizi gestiti come SageMaker Managed Spot Training e SageMaker Distributed Training integrano il checkpointing e recuperano automaticamente la capacità spot per ridurre sostanzialmente i costi di addestramento; tuttavia, le istanze spot sono una trappola per ambienti di produzione a bassa latenza, a meno che non siano abbinate a solidi meccanismi di fallback. I pattern architetturali che riducono la spesa includono l’elaborazione asincrona in batch, l’autoscaling con protezioni dal cold-start, gli endpoint multi-modello per consolidare molti piccoli modelli su un singolo host e l’uso di precisione mista e quantizzazione per ridurre le esigenze di memoria e throughput. Utilizzare framework come DeepSpeed o ZeRO per ridurre l’impronta di memoria durante l’addestramento di modelli di grandi dimensioni e valutare il fine-tuning efficiente dei parametri (LoRA/adapter) per evitare il riaddestramento completo del modello. Un errore frequente è utilizzare GPU di fascia alta per carichi di lavoro pesanti in termini di embedding, dove istanze CPU o Inferentia offrirebbero un rapporto prezzo/prestazioni di gran lunga migliore.

Compromessi nella selezione del modello e strategie attente ai costi

La scelta del modello è un compromesso tra costo, latenza, accuratezza e sensibilità dei dati. I modelli fondamentali in Bedrock offrono scalabilità gestita, strumenti di sicurezza e iterazione rapida, ma comportano costi per chiamata o per token che possono diventare predominanti su larga scala; i modelli open-source ospitati su SageMaker o EC2 possono ridurre la spesa per inferenza se si ammortizza l’overhead di hosting e operativo. Le architetture ibride funzionano bene: eseguire un modello piccolo ed economico per la maggior parte delle richieste e passare a un modello più grande per le query complesse, oppure utilizzare la retrieval-augmented generation dove il contesto pesante è servito da un vector store (OpenSearch, un database vettoriale basato su Amazon QLDB o di terze parti) e solo prompt concisi vengono inviati all’LLM. Le decisioni sul fine-tuning dovrebbero considerare metodi efficienti dal punto di vista dei parametri (LoRA, adapter) e coppie prompt-completamento in formato JSONL per compiti text-to-text, al fine di limitare l’uso di dataset e risorse di calcolo. Tra le trappole comuni vi sono l’eseguire il fine-tuning di modelli inutilmente grandi invece di usare il prompt engineering, il trascurare l’aumento della lunghezza dei prompt in token e il non mettere in cache o deduplicare le risposte per query ad alta ripetizione.

Storage, località dei dati, governance e osservabilità per il controllo dei costi

Le scelte di storage influenzano sia i costi mensili sia la conformità legale. Utilizzare S3 con policy di lifecycle, Intelligent-Tiering e formati compressi (Parquet/TFRecord) per i set di dati; posizionare i dati di training attivi in tier ad alto throughput e archiviare gli asset grezzi su Glacier. Per i dati PII e la residenza dei dati, mantenere i bucket S3, le chiavi KMS e le risorse di calcolo nella Regione AWS richiesta e controllare l’accesso tramite endpoint VPC, policy IAM e networking privato per prevenire l’egress accidentale tra regioni. Le pipeline di recupero per RAG dovrebbero collocare i vector store (Amazon OpenSearch Service o un embedding store su EC2/EBS) insieme al livello di inferenza per evitare costi di trasferimento e latenza. Strumenti di osservabilità e spiegabilità come SageMaker Clarify, Debugger e Model Monitor forniscono governance e rilevamento precoce del drift, ma aggiungono costi: implementare monitor basati su campionamento per controllare la spesa. Minimizzare l’impronta ambientale e i costi scegliendo chip efficienti (Inferentia/Trainium) e utilizzando il batching; un errore comune è abilitare il logging completo e il monitoraggio continuo del modello senza soglie di campionamento, il che aumenta sia i costi sia il rumore fornendo al contempo un valore incrementale minimo.

Problema Pratico: Scenario d’Uso

Scenario: Acme Retail gestisce uno stack AI su AWS utilizzando Amazon Bedrock per l’accesso agli LLM, Amazon SageMaker per il training e l’hosting dei modelli, S3 per i dati e Amazon OpenSearch per l’indicizzazione dei prodotti. Devono generare migliaia di descrizioni di prodotto, lunghe un paragrafo, ogni giorno, con una brand voice coerente, requisiti PII stringenti all’interno della regione e un obiettivo di costo rigoroso.

Sfida: Fornire descrizioni di alta qualità e brandizzate su larga scala, minimizzando al contempo il costo per descrizione e garantendo che i dati dei clienti non lascino mai la Regione AWS designata.

Approccio Consigliato:

1. Utilizzare una pipeline di inferenza a due livelli: instradare tutte le richieste prima a un modello leggero (quantizzato) ospitato localmente su SageMaker o EC2 per gestire SKU comuni e descrizioni semplici; inoltrare i casi complessi o a bassa confidenza a un modello di base su Bedrock.
2. Archiviare gli embedding e gli indici di recupero in Amazon OpenSearch all’interno della regione; utilizzare un contesto recuperato conciso per mantenere basso l’utilizzo di token di Bedrock e memorizzare nella cache le risposte comuni in ElastiCache.
3. Eseguire il fine-tuning di un piccolo modello specializzato utilizzando metodi efficienti in termini di parametri (LoRA) su SageMaker Managed Spot Training con checkpoint su S3, mantenendo raro il retraining completo del modello.
4. Applicare controlli sui confini della regione: bucket S3 e chiavi KMS in-region, endpoint VPC per Bedrock/SageMaker e monitoraggio basato su campionamento con Model Monitor + Clarify per limitare i costi di monitoraggio.

Motivazione: La combinazione di un modello di base economico con un’escalation selettiva minimizza i costi per token e per istanza di ogni descrizione, mentre RAG e caching riducono le chiamate a Bedrock. Il Managed Spot Training e il fine-tuning efficiente in termini di parametri riducono le spese di training e l’overhead di storage, mentre i controlli in-region soddisfano i requisiti PII e di conformità.

← MLOps e Deployment · Tutti i domini

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

Sfoglia Amazon →