Distribuisci modelli di ML in produzione con auto-scaling

Il divario nella distribuzione in produzione: perché la maggior parte dei modelli di ML non lascia mai il notebook

Un modello addestrato in un notebook e un modello che risponde a richieste live sono problemi ingegneristici diversi. Il secondo è un ambiente di distribuzione con requisiti di disponibilità, latenza e scaling, ed è dove la maggior parte dei modelli di machine learning in produzione si blocca.

Cosa serve per servire un modello su larga scala (cluster, ingresso, autoscaling, monitoraggio)

La selezione e l'addestramento del modello sono problemi a monte. Il percorso classico per servire i modelli in produzione è un processo separato, un processo che richiede un cluster, un controller di ingresso, una policy di scaling, uno stack di monitoraggio e una pipeline di rilascio. Ognuna è una decisione che richiede un responsabile. Un data scientist che ha terminato lo sviluppo del modello ora ha bisogno di networking di cluster, regole di bilanciamento del carico e un backend di metriche prima che un utente veda una previsione.

La checklist: un runtime di container, regole di ingresso, policy di scaling, gestione di segreti e dati, invio di log, pipeline di rilascio, più una catena di strumenti per mantenere ciascuno di essi. Ogni elemento è essenziale, richiede una responsabilità tecnica e nessuno di questi strumenti migliora il modello.

Per un piccolo team si tratta di settimane di lavoro prima che appaia qualsiasi valore aziendale, e non si ferma al lancio. Il risultato è familiare: lo sviluppo del modello ha successo, la distribuzione si blocca e l'artefatto attende un'infrastruttura che nessuno ha il tempo di costruire.

Perché il fai-da-te con VM + Flask + nginx si blocca sotto traffico reale

La scorciatoia è una VM che esegue un'app Flask dietro nginx. Funziona nei test e fallisce in produzione. Un server è un punto di errore. Nessun autoscaling significa che un picco di carico mette in coda le richieste finché la latenza non diventa inaccettabile. L'assenza di una rolling release significa che ogni nuova versione comporta tempi di inattività.

Nasconde inoltre un problema di costi: l'istanza viene eseguita continuamente, indipendentemente dal fatto che l'endpoint serva mille richieste al giorno o nessuna, e qualcuno deve comunque aggiornare il sistema operativo e rinnovare i certificati. Efficiente da configurare, costoso da mantenere.

Il costo nascosto delle istanze GPU inattive sugli endpoint dei grandi provider cloud

Gli endpoint di inferenza gestiti sui grandi hyperscaler risolvono il problema della disponibilità, ma mantengono l'istanza di calcolo in esecuzione 24 ore su 24. Un endpoint GPU dimensionato per un picco diurno viene fatturato anche alle 3 del mattino senza nulla da servire, e il tempo di inattività occupa gran parte della giornata.

L'utilizzo è la metrica che conta. Un endpoint che serve alcune migliaia di richieste al giorno su una GPU dimensionata per il picco può utilizzare una piccola frazione di ciò che paga, ogni giorno, per mesi. Le istanze GPU cloud hanno senso quando il carico è costante, ma un'istanza a tariffa oraria è l'unità di misura sbagliata per una domanda che arriva a picchi.

Fatturazione per replica e per minuto invece di istanze sempre attive

La fatturazione è per replica, al minuto. Un deployment che mantiene una replica durante la notte e otto a mezzogiorno costa la somma dei minuti in cui ogni replica è rimasta attiva, non otto istanze per 24 ore. La fatturazione dell'autoscaling viene calcolata sul numero minimo di repliche definito, con capacità di picco solo durante l'esecuzione. La previsione è semplice: la base è il minimo moltiplicato per il tempo, tutto ciò che eccede segue la domanda e la fattura del software mantiene la forma della curva di carico.

Tariffe indicative: CPU solo a partire da 0,04 € per core all'ora per modelli classici come scikit-learn o XGBoost; GPU L4 a partire da 0,91 € per replica all'ora per inferenza 7B, visione e classificazione; GPU A100 da circa 1,52 € a 1,85 € per modelli da 7B a 30B; GPU H100 PCIe a partire da 3,10 € per modelli più grandi e finestre di contesto lunghe. Conferma le tariffe attuali sulla pagina dei prezzi.

Ridimensionamento a zero quando il traffico diminuisce, aumento in caso di picchi reali

Il ridimensionamento a zero è generalmente disponibile: un deployment scende automaticamente a zero repliche quando non viene chiamato, e il costo di inattività diventa zero. Questa è la differenza economica chiave tra un endpoint gestito scalabile e un'istanza fissa che gestisci tu stesso. Comporta un compromesso onesto. Il ripristino da zero comporta un avvio a freddo mentre il container si avvia e carica i pesi, quindi la prima richiesta dopo l'inattività è lenta. Per un job batch o uno strumento interno è accettabile. Per un'applicazione rivolta all'utente con un budget di latenza, mantieni almeno una replica e accetta il costo minimo.

Ridimensionamento statico vs autoscaling (CPU/RAM) vs autoscaling basato su metriche personalizzate

Tre strategie di ridimensionamento, e la scelta segue l'andamento del tuo traffico.

Probe di prontezza e aggiornamenti progressivi a zero downtime

Un readiness probe è un percorso HTTP che la piattaforma interroga prima di inviare traffico a una replica. È il modo in cui ti assicuri che il modello sia pronto: puntalo sulla tua rotta /health e l'endpoint non instrada alcuna richiesta finché il modello non è caricato. Senza di esso, una replica accetta una richiesta mentre i pesi vengono caricati e restituisce un errore che il tuo client vede come una richiesta fallita.

Gli aggiornamenti progressivi utilizzano lo stesso controllo. Pubblica una nuova versione e applica l'aggiornamento, e le nuove repliche superano il controllo di prontezza prima che quelle vecchie vengano ritirate. Gli utenti non vedono alcuna richiesta fallita e una versione che fallisce il proprio probe non riceve mai traffico. Ogni versione è indirizzabile, quindi i rilasci quotidiani e un rollback di emergenza condividono un unico meccanismo.

Monitoraggio in tempo reale di GPU, CPU e rete per replica

Il dashboard espone un set di metriche in tempo reale per replica: una metrica GPU, una metrica di memoria e una metrica di rete, ciascuna limitata a una replica anziché mediata, insieme ai log dell'applicazione nel Pannello di controllo.

Quel set risponde se la distribuzione è integra, se la metrica di scalabilità si sta attivando e dove si colloca la latenza. Non risponde se le previsioni sono ancora corrette. Per questo avete bisogno di una metrica dell'applicazione che definite voi, l'accuratezza su un campione etichettato è la scelta abituale. I team che mantengono modelli in produzione solitamente condividono un unico dashboard tra data science e ingegneria della piattaforma, così entrambi vedono gli stessi numeri. Questa funzionalità di monitoraggio è standard su ogni app.

Step 1: Pacchettizzate il modello in un'immagine Docker (o utilizzatene una predefinita)

La containerizzazione è un prerequisito, non un extra opzionale. L'immagine del container può provenire da Docker Hub, da Managed Private Registry o da GitHub Packages. Tre requisiti sono importanti: creare la directory dell'area di lavoro nel Dockerfile, puntare a linux/amd64 e servire sulla porta 8080 a meno che non ne dichiariate un'altra esplicitamente, come fa vLLM sulla 8000.

I team senza esperienza con i container possono iniziare dal catalogo OVHcloud di immagini predefinite con PyTorch, TensorFlow, HuggingFace o FastAI già installati. Ciò riduce il lavoro; non elimina il requisito. Distribuire il machine learning in questo modo è un'impostazione predefinita efficiente per la maggior parte delle applicazioni, e distribuire modelli ML direttamente da un'immagine del catalogo è ancora più veloce, e l'esperienza di mantenere il proprio livello di base raramente ne vale la pena all'inizio.

Step 2: Configura risorse, scalabilità e accesso tramite Pannello di controllo, API o CLI ovhai

Create la distribuzione dal Pannello di controllo, dall'API o dalla CLI ovhai. Scegliete le vostre risorse di calcolo, impostate la strategia di scalabilità, puntate il probe di prontezza al vostro percorso e porta di integrità, quindi impostate come viene raggiunto l'endpoint.

Per l'accesso, una regola: un endpoint pubblico è solo per i test. Le distribuzioni in produzione utilizzano un accesso limitato, con credenziali utente di AI Platform o un token, e policy di accesso che gestisci tu stesso. Ogni endpoint si trova inoltre dietro una protezione DDoS nativa e ogni endpoint conserva le proprie credenziali.

ovhai app run --gpu 1 --default-http-port 8080 \
  --probe-path /health \
  --unsecure-http false \
  my-registry/my-model-server:v2

Step 3: Scegli la strategia di scalabilità giusta per il tuo modello di traffico

Abbina la policy al carico di lavoro. Punteggio interno costante: statico, una o due repliche, un'impostazione predefinita efficiente per applicazioni interne e strumenti a basso volume. Un'API rivolta al cliente con picchi giornalieri: autoscaling basato su una metrica di utilizzo, minimo una replica per evitare avvii a freddo. Punteggio batch occasionale: autoscaling con riduzione a zero. Il lavoro batch è dove questa decisione è più semplice, perché nessuno guarda una barra di avanzamento. Ogni esecuzione batch è un costo che hai già calcolato.

Imposta il massimo deliberatamente. Limita contemporaneamente il throughput e la fattura, e il tetto è di 10 repliche per app.

Step 4: Monitora l'inferenza con la dashboard e l'architettura di riferimento MKS.

Inizia con la dashboard integrata per le metriche delle risorse e i log. Per i percentili di latenza, il throughput o l'accuratezza a livello di modello, aggiungi uno stack esterno: Servizio Kubernetes gestito che esegue Prometheus e Grafana, analizzando il tuo endpoint. OVHcloud pubblica questo documento come architettura di riferimento.

Due cose da monitorare continuamente: i segnali dell'infrastruttura che ti dicono se lo scaling funziona e le prestazioni del modello in produzione, che ti dicono se il modello svolge ancora il suo lavoro. Il monitoraggio delle prestazioni sul secondo è ciò che rileva una regressione silenziosa, e le metriche di prestazione da un dataset di addestramento non ti avviseranno al riguardo. Il drift si manifesta nel secondo molto prima del primo. Esporta una settimana di metriche online in un file prima di ottimizzare una soglia, assicurandoti che la modifica segua il carico osservato. Imposta un avviso su ciascuno per assicurarti che una regressione emerga dalle tue analisi piuttosto che da un cliente, assicurati che la soglia sia basata su una baseline reale e assicurati che abbia un responsabile.

Step 5: Esegui il push di una nuova versione con un aggiornamento rolling a zero downtime.

Costruisci ed esegui il push della nuova versione, quindi esegui ovhai app update o applica la modifica dal Pannello di Controllo. La piattaforma avvia nuove repliche, attende la prontezza, sposta il traffico e ritira le vecchie. Nessun tempo di inattività, nessuna finestra di manutenzione.

Il Dockerfile è codice: conservalo nel controllo di versione e mantieni aggiornata la base, poiché un layer di base obsoleto è una causa comune di fallimento del rollout. Mantieni i tag versionati invece di riutilizzare latest. Il controllo di versione su ogni release è ciò che rende il rollback un'operazione a comando singolo invece di un'indagine.

Perché CPU/RAM sono un pessimo proxy per il carico LLM.

L'inferenza di deep learning è un carico di lavoro computazionale con una coda, non un ciclo vincolato alla CPU, quindi la pratica standard di scalare sull'hardware non funziona. Un server LLM raggruppa le richieste simultanee sulla GPU. L'utilizzo della CPU rimane basso mentre la coda cresce, quindi quella soglia si attiva in ritardo o mai. Il segnale che ti interessa è quante richieste sono in corso, e una metrica hardware non può vederlo.

Scalabilità su vllm:num_requests_running con Prometheus e Grafana su MKS

vLLM espone vllm:num_requests_running sul suo endpoint di metriche. Eseguine lo scraping con Prometheus ed effettua l'autoscaling su quel valore invece che su un proxy hardware. Le repliche arrivano quando la concorrenza reale aumenta e se ne vanno quando la coda si svuota, mantenendo la latenza entro il budget senza sovra-provisioning.

Generalmente disponibile e documentato come architettura di riferimento. Richiede Prometheus e Grafana insieme al tuo deployment, quindi consideralo come l'approccio avanzato, non quello predefinito.

Tempo di configurazione, costi di inattività e competenza operativa

L'autogestione dell'inferenza comporta il provisioning del cluster, dei pool di nodi, di un controller di ingresso e di un autoscaler orizzontale, solitamente da una a due settimane, oltre a competenze DevOps e MLOps per mantenerlo operativo. Sei responsabile delle politiche di scalabilità, delle pipeline di deployment, dei file manifest e delle strategie di monitoraggio, e continui ad esserlo dopo il lancio. Le migliori pratiche nel settore sono documentate e gli strumenti sono maturi, ma in questo campo una pratica documentata non è un sistema operativo robusto. Il nodo GPU solitamente è sempre attivo, anche in assenza di traffico.

AI Deploy richiede un'immagine e un comando. La configurazione richiede meno di un'ora, è sufficiente la sola competenza MLOps e la scalabilità a zero elimina completamente i costi di inattività.

I prezzi e le cifre sono indicativi. Conferma le tariffe in tempo reale sulla pagina dei prezzi di OVHcloud prima della pubblicazione.

Nessuna esposizione al CLOUD Act sui dati di inferenza

I dati di addestramento non sono l'unico input sensibile. Ogni richiesta a un endpoint di produzione trasporta dati utente o aziendali, ogni richiesta viene registrata da qualche parte, ogni richiesta è un input che non hai scelto e il traffico dell'endpoint è continuo piuttosto che un trasferimento una tantum. Se l'endpoint è eseguito su un provider con sede negli Stati Uniti, tali dati ricadono sotto la giurisdizione statunitense, indipendentemente dalla regione che li ospita.

OVHcloud è europea, senza società madre statunitense e senza esposizione strutturale al CLOUD Act. I dati di inferenza rimangono sotto la giurisdizione dell'UE, in conformità con la legge dell'UE.

GDPR, HDS e ISO 27701 per carichi di lavoro regolamentati

OVHcloud detiene le certificazioni ISO 27001, ISO 27017, ISO 27018 e ISO 27701, è certificata SOC 2 e possiede la certificazione HDS per i dati sanitari in Francia, rilevante per l'inferenza medica. L'elaborazione all'interno dell'UE semplifica una valutazione di impatto sulla protezione dei dati (DPIA) e gli impegni di privacy dei dati presi nei confronti dei propri utenti diventano più semplici da dimostrare. Il supporto può rispondere a una domanda sulla privacy senza dover inoltrare la richiesta.

Un limite da dichiarare chiaramente: AI Deploy fornisce un'infrastruttura di servizio sovrana. Gli obblighi dell'EU AI Act a livello di modello, le schede del modello, i log di audit e il rilevamento dei bias rimangono una tua responsabilità in quanto sviluppatore del sistema. L'infrastruttura sovrana supporta la conformità; non la garantisce.