La corsa all’AI generativa e ai modelli personalizzati spinge team tecnici e business a una domanda concreta: quanto costa davvero mettere in produzione un modello in cloud? L’etichetta “TCO” – total cost of ownership – è spesso confusa con il solo prezzo delle GPU ma la realtà include training, inferenza, storage, trasferimento dati e il ricorso al transfer learning. Una stima solida richiede una procedura chiara, numeri tracciabili e un foglio di calcolo che mostri l’impatto dei trade-off architetturali.
Questa guida propone una procedura pratica per costruire un modello di costo che permetta di confrontare GPU dedicate, stack serverless e ottimizzazioni come quantizzazioneLoRA e distillazione. L’obiettivo è ottenere un TCO comparabile per scenari diversi, così da supportare decisioni d’investimento e scelte tecniche con una base quantitativa consistente.
Definire lo scope: modello, obiettivo e vincoli
Prima dei fogli di calcolo, serve definire il perimetro. Identificare il modello (dimensione in parametri, licenza), il livello di qualità attesa (metriche come accuracy, latency, throughput), la finestra temporale (mesi di esercizio) e i vincoli di compliance e residenza dati. Stabilire se si punta a addestramento fullfine-tuning o adapter-based (es. LoRA), se si prevede inferenza real-time o batch e la stagionalità della domanda. Precisare i SLO latenza p95, tasso di errore, disponibilità. Questi elementi determinano risorse, pattern di scalabilità e quindi la struttura dei costi lungo il ciclo di vita.
Foglio di calcolo: parametri chiave per il TCO
Un foglio unico con schede per traininginfernza e storage permette di iterare rapidamente. Parametri consigliati:
- Modello parametri, precisione (fp32/fp16/int8), memoria attiva per replica.
- Dati dimensione dataset, crescita mensile, ingressi/uscite, egress tra region.
- Training numero di step/epoche, batch size, throughput per GPU, ore di GPU, checkpointing.
- Inferenza richieste/giorno, token medi in/out, p95 latenza, concurrent sessions, autoscaling minimo/massimo.
- Storage modelli, dataset, feature store, retention, classi di archiviazione.
- Rete egress inter-region, CDN, VPC endpoint, traffico verso clienti.
- Servizi orchestrazione (Kubernetes/Functions), logging, observability sicurezza.
- Ottimizzazioni quantizzazione, distillazione, LoRA, caching dei token, batching.
- Capex/Opex riserva GPU (1-3 anni) vs on-demand, spot/preemptible, SLA richiesto.
Per ogni scheda, il foglio calcola costi unitari e totali e integra un scenario manager per confrontare baseline, ottimizzato e picchi stagionali. Le celle sensibili includono prezzi cloud per famiglia GPU, tariffe serverless per invocazione, storage per classe e costi egress; vanno aggiornate periodicamente.
Training: stima ore GPU e impatto delle ottimizzazioni
La parte di training incide in modo diverso a seconda della strategia. Nel full training, il driver è il prodotto tra step totali e tempo per step per replica, diviso il throughput. Nel fine-tuning con LoRA o adapters il tempo si riduce drasticamente e il consumo di memoria cala. Il foglio dovrebbe calcolare: ore-GPU = (epoche × dimensione dataset / throughput per GPU) × fattore di parallelismo; aggiungere overhead per checkpoint validazione e retry. Inserire scenari con mixed precisiongradient checkpointing e ZeRO-style sharding: ogni tecnica abbassa ore-GPU o memoria, ma può aumentare complessità operativa. Considerare costi di storage per checkpoint e snapshot, oltre al egress se i dati risiedono in region diverse dalla compute.
Inferenza: throughput, latenza e costo per 1.000 richieste
L’inferenza è spesso il peso ricorrente del TCO. Definire un profilo di carico con richieste/giorno, token medi e p95 latenza. Con GPU dedicate, il foglio calcola costo come (istanze × ore × prezzo/h) diviso le richieste servite, tenendo conto di batching e KV cache. In serverless il driver è costo per invocazione × durata × memoria/compute allocata, più eventuale egress. Integrare un modello di autoscaling minimi garantiti per SLO stringenti, zero-to-one per carichi elastici. Prevedere ottimizzazioni: quantizzazione int8/ggml, distillazione verso modelli più piccoli, compressione del prompt e caching a livello applicativo. Il foglio deve esporre il costo per 1.000 richieste e la sensibilità ai token medi e alla latenza target.
Storage e dati: classi, lifecycle e spostamenti
Lo storage pesa su tempo lunghi. Mappare oggetti: dataset crudi, feature store, embedding, modelli, log e tracciamento esperimenti. Assegnare a ciascuno classe (hot, standard, infrequent access, archive) e lifecycle policy. Il foglio deve includere: GB-mese per classe, richieste PUT/GET, costi di transizione, e soprattutto egress tra region o verso internet. Per i pipeline, stimare I/O parallelo e throughput richiesto per non allungare il training. Considerare compressione, formati colonnari e deduplica degli embedding. Se il transfer learning prevede copie multi-region per DR o latenza, modellare il raddoppio dei costi e l’impatto delle repliche cross-region.
GPU, serverless o ottimizzazioni: trade-off numerici
Con i parametri a foglio, emergono tre scenari tipo: 1) GPU dedicate per training + serving costante: costi prevedibili, alta efficienza sotto carico stabile, ma rischio di overprovisioning nei periodi di bassa domanda; 2) serverless per inferenza: ottimo per carichi bursty e prototipi, costo unitario più alto sotto carico continuo, cold start da gestire; 3) ottimizzazioni aggressive: quantizzazione e distillazione riducono memoria e latenza, abbassando costo per richiesta; LoRA taglia ore-GPU di training, ma richiede governance sui checkpoint. Il foglio deve mostrare curve di costo mensile al variare del throughput e report come costo/1000 richieste, costo per epoca, GB-mese per dataset, con e senza ottimizzazioni.
Trasfer learning: quando conviene davvero
Il transfer learning sposta gran parte del valore dal compute ai dati e alla qualità della personalizzazione. Nel foglio, confrontare tre approcci: prompt engineering + RAG (nessun training, costi su indicizzazione e inferenza), fine-tuning leggero (LoRA/adapters, costi contenuti di training e storage di adapter), fine-tuning pieno (costi elevati di compute e MLOps). Inserire metriche di qualità attesa per associare costo a beneficio: se un adapter porta il 90% del guadagno a un decimo del costo, il TCO si comprime nettamente. Considerare anche costi di data labeling pulizia, test set e sicurezza: spesso superano il puro compute.
Checklist finale: celle da non dimenticare
Per evitare sorprese, il foglio deve includere voci ricorrenti spesso trascurate: monitoring e log retention, cifratura e KMS, scansioni di sicurezza, backup e snapshot, costo dei pipelines CI/CD, traffico di health-check, licenze di framework/commercial models, supporto enterprise e costi di uscita (egress verso on-prem o cloud diversi). Inserire un margine di contingenza (10-20%) e una tabella di sensibilità che vari domanda, prezzi GPU/serverless e dimensione token, per esporre la banda di rischio e supportare decisioni più robuste.
