07 - Cloud e intelligenza artificiale

Cloud e intelligenza artificiale: dove vivono dati e modelli, e quanto costa farli vivere lì

Corso Machine Learning Engineer · Modulo 00 · Mindset data-driven · Lezione 7

Obiettivo. Dare al lettore una definizione precisa di cloud (quella normativa, non quella di marketing), le tre famiglie di servizio con la loro divisione di responsabilità, e due calcoli per ragionare sui costi: l'elasticità contro la capacità fissa, e il punto di pareggio tra possedere e noleggiare hardware (tipicamente GPU). Alla fine il lettore sa decidere dove far girare un modello e perché.

Falso mito. «Il cloud costa meno.» A volte sì, a volte no: dipende dall'utilizzo. Il codice di questa lezione lo mostra con i numeri.

Introduzione

I modelli di machine learning hanno tre esigenze: dati (da archiviare), calcolo (spesso GPU, per l'addestramento) e disponibilità (per servire le previsioni a chi le chiede). Il cloud è un modo di soddisfare queste esigenze pagando a consumo anziché comprando in anticipo. Non è l'unico modo, e non sempre il migliore.

Roadmap. (1) Cos'è, con la definizione NIST. (2) IaaS, PaaS, SaaS: chi gestisce cosa. (3) Elasticità: il primo calcolo. (4) Comprare o noleggiare: il secondo calcolo. (5) Cloud e dati personali. (6) Business intelligence e dati analitici. (7) Dove, per un ML engineer, il cloud aiuta davvero.

Cos'è, perché esiste, quando NON usarlo

La definizione che conta

Il documento NIST SP 800-145 (2011) definisce il cloud come un modello per ottenere accesso di rete, on-demand, a un insieme condiviso di risorse di calcolo configurabili (reti, server, archiviazione, applicazioni, servizi) che possono essere rapidamente allocate e rilasciate con minimo sforzo di gestione. Lo caratterizza con cinque caratteristiche essenziali:

1. On-demand self-service: ottieni risorse da solo, senza telefonare a nessuno.
2. Broad network access: ci arrivi via rete, da dispositivi diversi.
3. Resource pooling: il fornitore serve molti clienti dallo stesso insieme di risorse (multi-tenancy).
4. Rapid elasticity: le risorse si espandono e si riducono in fretta, spesso in automatico.
5. Measured service: l'uso è misurato, e si paga quello.

Le cinque caratteristiche descrivono il rapporto tra cliente e fornitore più che la tecnologia: le prime due dicono come ottieni le risorse, le ultime tre come il fornitore le gestisce e te le fattura. Se manca la misurazione o l'autoservizio, il documento NIST non lo considera cloud, e il test pratico nel paragrafo seguente ne è la traduzione.

Poi tre modelli di servizio (SaaS, PaaS, IaaS) e quattro modelli di diffusione (privato, comunitario, pubblico, ibrido).

Test pratico: se un servizio non ha misurazione dell'uso e non si può ottenere da soli on-demand, probabilmente è «hosting» con un'etichetta cloud.

Analogia: la casa

Più sali, meno responsabilità hai e meno libertà. Non è una scala di qualità: è uno spostamento del confine.

Quando NON usare il cloud pubblico

Preparazione

pip install numpy

I prezzi nei codici sono inventati: servono a mostrare il metodo. Prima di decidere, inserisci i prezzi reali del fornitore che stai valutando, che cambiano nel tempo.

IaaS, PaaS, SaaS e la responsabilità condivisa

Il modello di responsabilità condivisa formalizza la divisione: il fornitore è responsabile della sicurezza del cloud (edifici, hardware, virtualizzazione); tu sei responsabile della sicurezza nel cloud (configurazione, accessi, dati). Dove passa la linea dipende dal modello di servizio: in IaaS tu gestisci anche il sistema operativo; in SaaS quasi nulla. Un bucket di archiviazione lasciato pubblico per errore è, per costruzione, una responsabilità del cliente. I dettagli specifici stanno nella documentazione del fornitore, che va letta.

Per il machine learning

Primo calcolo: l'elasticità

L'idea

La domanda di un servizio varia nel tempo (picchi serali, giorni feriali, campagne). Con capacità fissa devi dimensionare per il picco, e per il resto del tempo molta capacità resta inutilizzata. Con capacità elastica paghi in ogni istante circa ciò che serve. Armbrust et al. (2010) lo descrivono come trasferimento del rischio di sovra- e sotto-provisioning dall'azienda al fornitore.

Analogia: il ristorante. Un ristorante con 80 coperti a disposizione per il picco della domenica sera e 20 clienti il martedì a pranzo paga lo stesso affitto tutti i giorni. Se potesse far comparire e sparire i tavoli, pagherebbe solo quelli occupati.

Codice

Generiamo la domanda oraria di una settimana (una base, un picco serale, rumore) e confrontiamo i costi. Il prezzo per unità di capacità e ora (0.10) è inventato.

import numpy as np

rng = np.random.default_rng(5)
ore = np.arange(24 * 7)
ora_del_giorno = ore % 24
domanda = 20 + 60 * np.exp(-((ora_del_giorno - 20) ** 2) / 8) + rng.normal(0, 3, ore.size)
domanda = np.clip(domanda, 5, None)

capacita_picco = np.ceil(domanda.max())
prezzo_ora_unita = 0.10                     # INVENTATO: sostituisci con il prezzo reale

costo_fisso = capacita_picco * len(ore) * prezzo_ora_unita
costo_elastico = np.ceil(domanda).sum() * prezzo_ora_unita
utilizzo_fisso = domanda.sum() / (capacita_picco * len(ore))

print("picco", capacita_picco, "| medio", round(float(domanda.mean()), 1))
print("costo fisso", round(float(costo_fisso), 1), "| elastico", round(float(costo_elastico), 1))
print("utilizzo con capacità fissa", round(float(utilizzo_fisso), 3))

# Output (Python 3.14.4, NumPy 2.3.5, seme 5, due esecuzioni identiche):
# picco 82.0 | medio 31.7
# costo fisso 1377.6 | elastico 541.3
# utilizzo con capacità fissa 0.387

Come leggere il codice. ore conta le 168 ore di una settimana e ora_del_giorno = ore % 24 le riporta all'ora del giorno (0-23). domanda è la somma di tre ingredienti: una base di 20 unità, un picco serale a forma di campana centrato sulle 20 (exp(-((ora - 20)**2)/8) vale 1 alle 20 e si spegne in poche ore), e un rumore casuale con deviazione standard 3; np.clip(..., 5, None) evita valori troppo bassi. capacita_picco è l'arrotondamento per eccesso del massimo: con capacità fissa devi acquistare il picco, sempre. costo_fisso moltiplica quella capacità per le 168 ore e per il prezzo; costo_elastico paga invece, ora per ora, solo ciò che serve (np.ceil(domanda).sum()). L'utilizzo è il rapporto tra la capacità realmente usata e quella pagata: se vale 0.39, il 61% di ciò che paghi resta inattivo.

Output ottenuto (seed 5): picco 82, domanda media 31.7; costo fisso 1377.6, elastico 541.3; utilizzo con capacità fissa 0.387.

Come leggerlo. Con capacità fissa usi il 39% di ciò che paghi. L'elasticità ridurrebbe il costo del 61% in questo scenario. Il risultato dipende interamente dalla forma della domanda: quanto più il picco supera la media, tanto più l'elasticità conviene. Una domanda piatta darebbe un vantaggio quasi nullo.

Cosa il modello semplifica: assume che la capacità si adatti istantaneamente e che il prezzo unitario elastico sia uguale a quello fisso. Nella realtà la capacità elastica ha spesso un prezzo unitario più alto e granularità di fatturazione minime; e l'adattamento ha latenza. Il calcolo serve a capire l'ordine di grandezza, non a prevedere la fattura.

Un secondo esempio, contrastante: quando l'elasticità non conviene

Il vantaggio dell'elasticità dipende dalla forma della domanda e dal prezzo unitario. Confrontiamo due domande, una con picco serale e una piatta, e due ipotesi di prezzo: uguale oppure con un sovrapprezzo del 40% per la capacità elastica (più realistico: la flessibilità di solito si paga).

import numpy as np

def domanda(forma, seme=5):
    rng = np.random.default_rng(seme)
    h = np.arange(24 * 7) % 24
    if forma == "con picco serale":
        d = 20 + 60 * np.exp(-((h - 20) ** 2) / 8) + rng.normal(0, 3, h.size)
    else:
        d = 20 + rng.normal(0, 3, h.size)
    return np.clip(d, 5, None)

prezzo = 0.10
print(f"{'domanda':<18} {'picco/media':>11} {'fisso':>8} {'elastico a pari prezzo':>24} {'elastico +40%':>15}")
for forma in ("con picco serale", "piatta"):
    d = domanda(forma)
    fisso = np.ceil(d.max()) * d.size * prezzo
    elastico = np.ceil(d).sum() * prezzo
    print(f"{forma:<18} {d.max() / d.mean():>11.2f} {fisso:>8.1f} {elastico:>24.1f} {elastico * 1.4:>15.1f}")

Output ottenuto:

domanda            picco/media    fisso   elastico a pari prezzo   elastico +40%
con picco serale          2.58   1377.6                    541.3           757.8
piatta                    1.39    470.4                    339.2           474.9

Come leggere il codice. domanda genera due profili con lo stesso seme: uno con il picco serale, l'altro piatto (20 più rumore). Per ciascuno si calcola il rapporto picco/media, il costo con capacità fissa, il costo elastico a pari prezzo e il costo elastico con sovrapprezzo del 40%. Il ragionamento è semplice e si può derivare: con capacità fissa paghi picco × ore × prezzo; con capacità elastica paghi media × ore × prezzo × (1 + s), dove s è il sovrapprezzo. L'elasticità conviene quando media × (1 + s) < picco, cioè quando

picco / media > 1 + s.

Con la domanda a picco serale il rapporto è circa 2.6: conviene anche con un sovrapprezzo del 40% (1.4). Con la domanda piatta il rapporto è circa 1.4 (1.39): a pari prezzo l'elasticità fa risparmiare (339 contro 470), ma con il +40% il costo elastico (475) supera quello fisso (470): non conviene più. La conclusione per l'ingegnere è operativa: prima di scegliere un'architettura elastica, misura il rapporto picco/media della tua domanda reale.

Secondo calcolo: comprare o noleggiare

Il problema

Hai bisogno di una GPU per addestrare modelli. Puoi noleggiarla a ore (tariffa r per ora) oppure possederla, con un costo mensile O che comprende ammortamento (prezzo di acquisto diviso per i mesi di vita utile), energia e manutenzione. Per quanto tempo al mese devi usarla perché possederla convenga?

Derivazione

Costo mensile noleggiando, con h ore di uso: C_nolo(h) = r · h. Costo mensile possedendo: C_proprio = O (costante: lo paghi anche se non la usi).

Pareggio: r · h* = O, quindi

h* = O / r

Se usi la macchina per più di h* ore al mese, possederla costa meno; se meno, noleggiare costa meno. La frazione del mese al pareggio è h* / 730 (un mese medio ha circa 730 ore, 8760/12).

costo_mensile_proprio = 900.0      # INVENTATO: ammortamento + energia + manutenzione
tariffa_nolo_ora = 2.0             # INVENTATO

h_pareggio = costo_mensile_proprio / tariffa_nolo_ora
print("ore di pareggio al mese:", h_pareggio)
print("frazione del mese:", round(h_pareggio / 730, 3))

# Output:
# ore di pareggio al mese: 450.0
# frazione del mese: 0.616

Output: ore di pareggio al mese: 450.0, frazione 0.616. Con questi numeri inventati, se la GPU lavora meno del 62% del tempo conviene noleggiare.

Il numero che conta si chiama utilizzo. Quasi nessuno addestra modelli 24 ore su 24. Un addestramento è un picco: ore o giorni intensi, poi niente. Per questo, a basso utilizzo, il noleggio vince quasi sempre. A utilizzo alto e costante (un servizio di previsione in linea che gira sempre) il conto si inverte.

Il costo per ora effettivamente usata

Per il pareggio tra comprare e noleggiare c'è un modo più intuitivo di leggere il risultato: il costo per ora di uso effettivo. Se possiedi la macchina e la usi per h ore al mese, ogni ora ti costa O/h (il costo fisso diviso per le ore usate); noleggiandola ti costa sempre r. Il possesso vince quando O/h < r.

import math

print(f"{'O (€/mese)':>10} {'r (€/ora)':>10} {'ore di pareggio':>16} {'frazione del mese':>18}")
for O in (300, 600, 900, 1500):
    for r in (1.0, 2.0, 4.0):
        h_star = O / r
        print(f"{O:>10} {r:>10.1f} {h_star:>16.0f} {h_star / 730:>18.1%}")

print()
O, r = 900, 2.0
for ore_uso in (50, 150, 300, 450, 600, 730):
    print(f"uso {ore_uso:>3} ore/mese: proprio {O / ore_uso:6.2f} €/ora usata | noleggio {r:.2f} €/ora")

Output ottenuto:

O (€/mese)  r (€/ora)  ore di pareggio  frazione del mese
       300        1.0              300              41.1%
       300        2.0              150              20.5%
       300        4.0               75              10.3%
       600        1.0              600              82.2%
       600        2.0              300              41.1%
       600        4.0              150              20.5%
       900        1.0              900             123.3%
       900        2.0              450              61.6%
       900        4.0              225              30.8%
      1500        1.0             1500             205.5%
      1500        2.0              750             102.7%
      1500        4.0              375              51.4%

uso  50 ore/mese: proprio  18.00 €/ora usata | noleggio 2.00 €/ora
uso 150 ore/mese: proprio   6.00 €/ora usata | noleggio 2.00 €/ora
uso 300 ore/mese: proprio   3.00 €/ora usata | noleggio 2.00 €/ora
uso 450 ore/mese: proprio   2.00 €/ora usata | noleggio 2.00 €/ora
uso 600 ore/mese: proprio   1.50 €/ora usata | noleggio 2.00 €/ora
uso 730 ore/mese: proprio   1.23 €/ora usata | noleggio 2.00 €/ora

Come leggere il codice. La prima tabella mostra come cambia il pareggio h* = O/r al variare dei due parametri: se la macchina costa il doppio (a parità di tariffa) servono il doppio delle ore per ammortizzarla; se il noleggio costa il doppio, ne bastano la metà. Con i numeri inventati O = 900 e r = 2 il pareggio è a 450 ore, il 61.6% del mese. La seconda parte mostra lo stesso fatto da un'altra angolazione: a 50 ore di uso la macchina propria costa 18 euro per ogni ora usata, nove volte il noleggio; a 730 ore (sempre accesa) costa 1.23 euro all'ora, meno del noleggio. Il costo fisso si «ammortizza» sulle ore d'uso: più usi, meno ti costa ogni ora. È la stessa logica per cui un abbonamento annuale conviene a chi usa molto il servizio.

Cosa il modello ignora (e che devi aggiungere): il costo di chi gestisce l'hardware; il rischio di obsolescenza; i costi di trasferimento dati; gli sconti per impegni a lungo termine; la disponibilità effettiva di GPU nel momento in cui ne hai bisogno.

Trade-off complessivo.

Mettere insieme i pezzi: una piccola matrice di decisione

I due calcoli non bastano da soli: la scelta di dove far vivere un sistema ML mette insieme costo, vincoli sui dati e capacità di gestione. Un modo ordinato per decidere è scrivere una matrice con le opzioni sulle righe e i criteri sulle colonne, e riempirla per iscritto:

Non esiste una colonna «vincente»: la risposta cambia con il tuo caso. L'utilità della matrice è obbligare a scrivere i criteri e il peso che hanno per te, in modo che la decisione sia discutibile e rivedibile (se tra due anni l'utilizzo cambia, si riapre la matrice, non si riparte da zero).

Che cosa c'è in una fattura cloud

Chi imposta un progetto ML dovrebbe saper distinguere i quattro capitoli di costo, perché si controllano in modi diversi. Calcolo: ore di macchine virtuali o di GPU; si governa con lo spegnimento automatico e con il dimensionamento giusto. Archiviazione: byte conservati nel tempo; si governa con regole di scadenza (cancellare i dati temporanei) e con classi di archiviazione più economiche per ciò che si legge raramente. Trasferimento in uscita: dati che lasciano il fornitore, spesso a pagamento; si governa calcolando vicino ai dati. Servizi gestiti: database, code, funzioni; si governa leggendo come sono fatturati (per richiesta, per ora, per volume). Una buona abitudine è assegnare a ogni capitolo un responsabile e un allarme: la sorpresa in fattura di solito viene dal capitolo di cui nessuno si sentiva responsabile.

Cloud e dati personali

Mettere dati nel cloud di un fornitore non toglie la responsabilità: ai sensi del GDPR il titolare del trattamento resta tu. Punti da verificare, documentando le risposte:

• Dove risiedono fisicamente i dati e dove possono essere trattati (capo V del GDPR sul trasferimento verso paesi terzi).
• Chi è responsabile del trattamento e se esiste un accordo scritto con il fornitore.
• Cifratura a riposo e in transito, e chi custodisce le chiavi.
• Cancellazione: come si ottiene davvero, anche dalle copie di sicurezza.
• Registrazione degli accessi: chi ha letto che cosa.

Per i modelli esiste una scelta in più: inviare i dati a un servizio ospitato da terzi (comodo, ma i dati escono dal tuo perimetro) oppure far girare il modello nella tua infrastruttura (più lavoro, controllo totale). Per dati sensibili la seconda opzione è spesso quella che rende la valutazione di conformità più semplice. Non è una regola: dipende dal contratto, dal tipo di dato e dalle tue risorse.

Business intelligence e analisi dei dati

Due famiglie di sistemi, con compiti opposti:

Un errore frequente è far girare analisi pesanti sul database transazionale in produzione: rallenta gli utenti. La soluzione standard è copiare i dati su un sistema analitico separato. La business intelligence (cruscotti, report) vive su quest'ultimo. Il machine learning di solito lo attinge da lì, non dal database operativo.

Un vocabolario minimo

• Cloud: accesso on-demand, misurato e condiviso a risorse di calcolo.
• IaaS / PaaS / SaaS: infrastruttura, piattaforma, software come servizio.
• Responsabilità condivisa: il fornitore protegge il cloud, tu proteggi ciò che ci metti.
• Elasticità: capacità che segue la domanda.
• Utilizzo: quota della capacità pagata che si usa davvero.
• Pareggio: punto in cui due opzioni costano uguale (h* = O/r).
• Lock-in: difficoltà di cambiare fornitore.
• OLTP / OLAP: sistemi per registrare operazioni / per analizzare molti dati storici.

Le otto voci si raggruppano in tre temi: che cosa è il cloud (cloud, IaaS/PaaS/SaaS, responsabilità condivisa), come si ragiona sui costi (elasticità, utilizzo, pareggio, lock-in) e dove si prendono i dati (OLTP/OLAP). In una discussione di architettura, la parola più utile da pretendere è «utilizzo»: senza quel numero nessun confronto di costo è valido.

Errori tipici

Best practice

• Etichetta ogni risorsa (progetto, responsabile, scadenza).
• Imposta limiti e allarmi di spesa prima di lanciare il primo carico.
• Infrastruttura come codice: descrivi l'ambiente in file versionati (modulo 11).
• Principio del privilegio minimo negli accessi.
• Separa gli ambienti (sviluppo, prova, produzione).
• Fai il conto di utilizzo prima di impegnarti su contratti a lungo termine.

Le prime tre regole prevengono le sorprese di fattura e di configurazione, la quarta e la quinta quelle di sicurezza, l'ultima quelle contrattuali. Se parti da zero, imposta gli allarmi di spesa: sono il controllo che costa meno e che ha evitato più incidenti nei casi che la lezione cita.

Mini-progetto

1. Modifica il codice dell'elasticità: sostituisci il picco serale con una domanda piatta (20 + rumore). Misura il vantaggio dell'elasticità. Cosa dimostra?
2. Aggiungi un sovrapprezzo del 40% per l'unità elastica (prezzo_elastico = 1.4 * prezzo_ora_unita). Con quale rapporto picco/media l'elasticità smette di convenire?
3. Per il pareggio h*, produci una tabella con O ∈ {300, 600, 900, 1500} e r ∈ {1, 2, 4}.
4. Scrivi cinque righe di raccomandazione per un caso a tua scelta (addestramento mensile di 40 ore; servizio sempre acceso; sperimentazione irregolare).

I quattro punti usano il codice della lezione come laboratorio: i primi due ripetono l'elasticità con una domanda piatta e con il sovrapprezzo, il terzo il pareggio, il quarto ti obbliga a trasformare i numeri in una raccomandazione scritta. Il quarto è il vero prodotto del lavoro.

Challenge

• Easy. Classifica in IaaS / PaaS / SaaS cinque servizi che usi.
• Medium. Aggiungi al pareggio il costo di una persona a metà tempo che gestisce l'hardware proprio. Come si sposta h*?
• Hard. Modella la domanda con picchi settimanali e stagionali; calcola il vantaggio dell'elasticità con granularità di fatturazione oraria contro al minuto.
• Expert. Aggiungi lo sconto per impegno (paghi l'80% della tariffa se ti impegni per tutto il mese) e trova il nuovo punto di pareggio tra noleggio a ore, noleggio impegnato e possesso.
• Enterprise. Redigi un design record per un sistema ML della tua organizzazione: dove vivono dati, addestramento e servizio, con motivazione economica e di conformità.

Easy e Medium si fanno in dieci minuti con il codice dato, Hard ed Expert estendono i modelli con granularità e sconti, Enterprise li porta nel tuo contesto. Expert è la più utile: aggiunge lo sconto per impegno, che nei listini reali cambia il pareggio più di qualunque altro parametro.

Recap

Mappa mentale. Cloud = cinque caratteristiche NIST. Tre servizi (IaaS/PaaS/SaaS) = tre confini di responsabilità. Elasticità vince quando picco ≫ media. Pareggio h* = O/r. Dati personali: dove, chi, cifratura, cancellazione.

3 concetti: responsabilità condivisa; elasticità; utilizzo. 3 errori: risorse dimenticate; dati pubblici per errore; confronto senza utilizzo. 3 best practice: etichette e allarmi di spesa; privilegio minimo; infrastruttura come codice. 1 esercizio: il mini-progetto di questa lezione.

Fine del modulo 00. Hai il modo di pensare: cosa è l'IA, quali rischi misurare, come tradurre un problema in decisione, come sperimentare, dove far girare. Prossimo modulo (01): gli attrezzi, cioè Python per i dati.

Nella stessa serie trovi anche: 06 - Test and learn: esperimenti controllati e A/B test (la lezione precedente), 08 - Python per i dati 1: ambiente e fondamenti (la lezione successiva).

Argomento lasciato fuori in questa lezione: la blockchain, presente nei sillabi di molti corsi introduttivi. Non è un prerequisito del machine learning e non verrà usata nei moduli seguenti; non la tratto per non diluire il percorso.