Batch e online inference: due mondi diversi

Il primo bivio d’esame è la modalità di serving. La batch inference serve grandi volumi di dati in modo asincrono, senza vincoli stretti di latenza: si dà in pasto un dataset (da Cloud Storage o BigQuery) a un job di Vertex AI batch prediction, che alloca risorse per la durata del lavoro e le rilascia al termine. È la scelta giusta quando il caso d’uso tollera minuti o ore di attesa — scoring notturno, arricchimento di tabelle, generazione periodica di raccomandazioni — e privilegia il costo per predizione.

La online inference serve richieste sincrone a bassa latenza esponendo il modello su un endpoint di Vertex AI Prediction sempre attivo, con autoscaling tra un numero minimo e massimo di repliche. È la scelta quando un’applicazione attende una risposta in tempo reale. Il trade-off ricorrente è latenza e disponibilità contro costo: un endpoint online tenuto caldo costa anche a traffico zero, un job batch no.

Sulla scelta del servizio: Vertex AI Prediction è il default gestito per modelli custom e AutoML; Model Garden dà accesso a modelli pre-addestrati (Gemini, Imagen, Veo, open models) da deployare o fine-tunare; Cloud Run è indicato per serving serverless leggero che scala a zero; GKE quando servono controllo fine, orchestrazione custom o Kubeflow.

Container prebuilt e custom

Vertex AI offre prebuilt containers per i framework più comuni (TensorFlow, scikit-learn, XGBoost, PyTorch): basta fornire l’artefatto del modello nel formato atteso, senza costruire immagini. Sono la via più rapida quando il modello è standard e non servono dipendenze particolari.

Il custom container serve quando occorrono librerie specifiche, una versione di runtime non coperta, oppure logica di preprocessing/postprocessing dentro il servizio (parsing dell’input, feature engineering leggero, formattazione dell’output). Il custom container deve rispettare il contratto dell’endpoint (route di health e di predict, porta di ascolto). Un’alternativa intermedia sono le custom prediction routines, che permettono di iniettare codice di pre/post elaborazione senza scrivere l’intero server. Regola pratica: prebuilt finché basta, custom quando il contratto standard non regge il tuo flusso di inferenza.

Model Registry: versioning e lineage

Il Vertex AI Model Registry è il catalogo centrale dei modelli: raccoglie modelli e le loro versioni sotto un’identità stabile, traccia il lineage e fa da punto di partenza per il deploy verso gli endpoint. All’esame conta capire che il Registry disaccoppia il versionamento dal serving: si registra e valuta una nuova versione, la si confronta con la precedente, e solo dopo la si promuove verso un endpoint. Gli alias (es. “default”) permettono di puntare a una versione senza cambiare i riferimenti a valle. Registry, evaluation e Model Monitoring formano la spina dorsale MLOps del ciclo di vita del modello.

Rollout: A/B testing e canary via traffic split

Il meccanismo chiave è il traffic split su un endpoint: si possono deployare più versioni di modello sullo stesso endpoint e ripartire il traffico in percentuali.

  • Canary deployment: si invia una piccola quota (es. 5-10%) alla nuova versione, si osservano latenza, errori e metriche di business, e si aumenta gradualmente se tutto regge; in caso di problemi si riporta il traffico alla versione stabile — rollback immediato senza redeploy.
  • A/B testing: si dividono percentuali comparabili tra due versioni per misurare quale performa meglio su metriche reali, non solo offline.

Entrambe le strategie vanno abbinate a Model Monitoring per intercettare training-serving skew e drift durante e dopo il rollout.

Trappole tipiche d’esame

  • Milioni di record da scorare ogni notte, nessun requisito di latenza → batch prediction: un endpoint online sempre attivo è spreco di costo; il job batch scala e si spegne a fine lavoro.
  • Risposta in tempo reale a bassa latenza → online endpoint con autoscaling: la batch prediction non serve richieste sincrone; imposta min/max repliche in base al traffico.
  • Confrontare due versioni in produzione → una versione unica su un endpoint con traffic split: non deployare due endpoint separati; canary e A/B vivono sullo stesso endpoint ripartendo il traffico.
  • Modello PyTorch o XGBoost standard senza dipendenze speciali → prebuilt container: costruire un custom container qui è complessità inutile.
  • Dipendenze particolari o pre/post-processing nel servizio → custom container o custom prediction routine: il prebuilt non copre logica arbitraria; rispetta il contratto health/predict.
  • Serve rollback rapido dopo un canary andato male → sposta il traffic split sulla versione stabile: non fare redeploy; basta riportare a 100% la versione precedente sull’endpoint.