Scegliere l’opzione di inferenza SageMaker

Una volta addestrato il modello, il passo successivo è renderlo accessibile per le predizioni. Amazon SageMaker offre quattro modalità principali, e la domanda d’esame ruota quasi sempre attorno a quale scegliere dato un pattern di traffico, un vincolo di latenza o una dimensione di payload.

Il real-time endpoint è un’istanza (o più) sempre accesa dietro un HTTPS endpoint persistente. È la scelta quando serve bassa latenza costante e traffico prevedibile e continuo: paghi l’istanza finché è attiva, anche a zero richieste. È il default per applicazioni interattive online.

La serverless inference elimina la gestione delle istanze: SageMaker provisiona la capacità on demand e scala a zero quando non arrivano richieste, facendoti pagare solo per la compute effettivamente usata. È ideale per traffico sporadico o intermittente con periodi di inattività, dove non vuoi pagare un’istanza ferma. Il rovescio della medaglia è il cold start: la prima richiesta dopo un periodo di inattività paga la latenza di avvio, quindi non è adatta a SLA di latenza rigidissimi e costanti.

L’asynchronous inference mette le richieste in una coda interna e restituisce la risposta su Amazon S3 quando è pronta. È la scelta per payload grandi (fino a 1 GB) e tempi di inferenza lunghi, dove il chiamante non può restare in attesa di una risposta sincrona. Può anch’essa scalare a zero quando la coda è vuota, ottimizzando i costi tra i picchi.

Batch transform vs endpoint

Quando non serve un endpoint online ma devi generare predizioni su un intero dataset già disponibile in S3, la risposta è batch transform. È un job offline che avvia le istanze, elabora l’intero dataset, scrive i risultati su S3 e spegne le risorse al termine — non c’è nessun endpoint persistente da mantenere. È la scelta corretta per scoring periodico, backfill o pipeline schedulate. La trappola classica: se lo scenario dice “nessun endpoint always-on”, “scoring notturno” o “dataset completo in S3”, quasi sempre la risposta è batch transform, non un real-time endpoint sottoutilizzato.

Multi-model endpoint e auto scaling

Un multi-model endpoint (MME) ospita molti modelli dietro un singolo endpoint e una singola flotta di istanze, usando lo stesso container/framework. I modelli risiedono in S3 e vengono caricati in memoria on demand alla prima invocazione (specificando il target model nella richiesta), poi mantenuti in cache. È la soluzione ottimale quando hai molti modelli simili con traffico individuale basso o intermittente (es. un modello per cliente o per regione): abbatti i costi rispetto a un endpoint dedicato per ciascuno. Il primo hit su un modello non ancora caricato paga una latenza extra di caricamento.

L’auto scaling su un endpoint real-time si configura con una target-tracking policy, tipicamente sulla metrica SageMakerVariantInvocationsPerInstance: SageMaker aggiunge o rimuove istanze per mantenere le invocazioni per istanza vicino al target. È il meccanismo per assorbire picchi di traffico senza sovradimensionare a priori.

Deployment guardrails

Le deployment guardrails governano come una nuova versione del modello va in produzione, riducendo il rischio di un rollout difettoso. Le modalità principali sono:

  • Blue/green con all-at-once, canary (una piccola frazione di traffico va prima sulla nuova fleet, e solo se è sana si sposta il resto) o linear (traffico spostato a incrementi costanti).
  • Auto-rollback su allarmi Amazon CloudWatch: se le metriche superano una soglia durante il rollout, SageMaker riporta automaticamente il traffico alla versione precedente.

L’obiettivo è limitare il blast radius: se qualcosa va storto, solo una piccola percentuale di utenti è colpita e il ripristino è automatico.

Trappole tipiche d’esame

  • Traffico intermittente con lunghe pause, minimizzare i costi → serverless inference: scala a zero e paghi solo la compute usata; accetta il cold start. Non scegliere un real-time endpoint sottoutilizzato.
  • Payload molto grandi o inferenze lunghe (minuti) → asynchronous inference: coda interna e risultato su S3, payload fino a 1 GB. Real-time e serverless hanno limiti stringenti di dimensione e timeout.
  • Scoring su un intero dataset in S3, nessun endpoint persistente → batch transform: avvia, elabora, spegne. Un endpoint always-on qui è spreco e risposta sbagliata.
  • Centinaia di modelli piccoli, stesso framework, traffico basso ciascuno → multi-model endpoint: un solo endpoint, modelli caricati on demand. Un endpoint dedicato per modello esplode i costi.
  • Aggiornare il modello riducendo il rischio, con ripristino automatico → deployment guardrails (canary/linear + auto-rollback su CloudWatch): non un deploy all-at-once senza rete di sicurezza.
  • Assorbire picchi di traffico su un endpoint real-time → auto scaling con target su SageMakerVariantInvocationsPerInstance: non aumentare manualmente il numero di istanze in modo statico.