Servire feature online con Vertex AI Feature Store

In produzione, il modello ha bisogno delle feature al momento della prediction con la stessa definizione usata durante il training. Il Vertex AI Feature Store risolve questo problema offrendo un online serving a bassa latenza (lookup su chiave di entità in millisecondi) accanto a un layer offline per il training. Il valore chiave non è la comodità, ma la coerenza: calcolare una feature come una media mobile a 30 giorni con logica diversa fra pipeline di training e codice di serving è la causa numero uno di training-serving skew. Centralizzando le definizioni nel Feature Store, la stessa feature alimenta sia i batch di training sia le richieste online.

Criteri di scelta d’esame: usa l’online serving quando la request arriva con pochi identificatori (es. user_id) e devi arricchirla con centinaia di feature precalcolate senza ricalcolarle in tempo reale. Se le feature dipendono solo dal payload della richiesta, non serve un Feature Store. Se il fresh-data richiede aggiornamenti continui, valuta l’ingestion streaming verso l’online store.

Endpoint pubblici e privati

Con Vertex AI Prediction deployi il modello (versionato nel Model Registry) su un endpoint per l’inferenza online. La scelta ricorrente è fra:

  • Public endpoint: raggiungibile via internet con autenticazione IAM. Semplice, adatto a client esterni.
  • Private endpoint: accessibile solo dalla tua VPC (Private Service Connect / VPC peering). Da preferire quando i requisiti impongono che il traffico non attraversi la rete pubblica, per compliance o per latenza intra-VPC più bassa.

Un endpoint può ospitare più modelli con traffic split, che abilita A/B testing (confronto statistico fra due modelli su traffico diviso, es. 50/50) e canary deployment (nuova versione a una piccola quota, es. 5%, con rollback rapido se le metriche degradano). Ricorda: per l’inferenza batch su grandi volumi senza requisiti di latenza usi il batch prediction, non un endpoint online.

Hardware: CPU, GPU, TPU, edge

La scelta dell’acceleratore è un trade-off costo/latenza/throughput:

  • CPU: modelli piccoli, tabulari, tree-based o traffico modesto. Costo minimo, ma satura sotto carico deep learning.
  • GPU: general-purpose per deep learning, ottima per serving di modelli medio-grandi e per batch con parallelismo. Attaccabile ai container di serving quando la CPU non regge la latenza target.
  • TPU: pensata per il training su larga scala di reti profonde; in serving è giustificata solo per modelli e volumi molto specifici.
  • Edge: quando serve inferenza on-device (latenza vicino a zero, offline, privacy dei dati locali) si esportano modelli ottimizzati verso il dispositivo, non verso un endpoint cloud.

Autoscaling e tuning per throughput

Gli endpoint online scalano il numero di replica in base al carico. Configuri un range min/max di nodi e una metrica target (tipicamente utilizzo CPU o GPU); il backend aggiunge replica quando il throughput cresce e le rimuove quando cala. Impostare min-replicas a zero riduce i costi ma introduce cold start: da evitare se la latenza p99 è critica. Il container di serving (prebuilt o custom) va dimensionato per sfruttare il batching lato server e l’acceleratore.

Sul piano del modello, il tuning bilancia batch size, latenza e costo per prediction: batch più grandi migliorano il throughput e riducono il costo unitario ma aumentano la latenza per singola richiesta. Per il training di modelli grandi ricorda la distinzione: data parallelism (stessi pesi replicati, dati diversi per device) quando il modello entra in memoria; model parallelism (modello spezzato fra device) quando è troppo grande. In serving, monitora con Model Monitoring per intercettare training-serving skew e drift che degradano la qualità nel tempo.

Trappole tipiche d’esame

  • Feature calcolate diversamente in training e serving → Feature Store: centralizza le definizioni per eliminare il training-serving skew; non è un problema di scaling hardware.
  • Traffico che non deve uscire dalla rete pubblica → private endpoint: un public endpoint con IAM non soddisfa requisiti di isolamento di rete.
  • Rilascio nuova versione minimizzando il rischio → canary: piccola quota di traffico con rollback; l’A/B serve invece a confrontare statisticamente due modelli.
  • Milioni di prediction offline senza vincolo di latenza → batch prediction: non dimensionare un endpoint online con autoscaling elevato per un job batch.
  • Costo per prediction alto ma latenza tollerabile → aumenta batch size / valuta GPU: massimizza throughput; se la latenza p99 è critica, scegli l’opposto (batch piccolo, più replica).
  • Modello troppo grande per un singolo device → model parallelism: il data parallelism replica i pesi e non risolve il limite di memoria.