Model Deployment

La distribuzione dei modelli è il processo di messa in produzione di un modello di apprendimento automatico addestrato, in cui le applicazioni gli inviano nuovi dati e agiscono in base alle sue predizioni. Comprende la scelta dell'ambiente in cui eseguire il modello, la conversione in un formato eseguibile dal runtime di destinazione, il collegamento agli input e agli output tramite un'API o un'app, il rilascio sicuro di nuove versioni e il monitoraggio del comportamento quando gli utenti reali iniziano a dipenderne. Un modello con buoni risultati in un notebook resta un esperimento finché non viene distribuito; la distribuzione è la fase delle operazioni di apprendimento automatico (MLOps) in cui la data science incontra i vincoli dell'ingegneria del software, come latenza, costi, disponibilità e sicurezza.

Dove vengono distribuiti i modelli#

• Distribuzione nel cloud: il modello viene eseguito su server accessibili tramite un endpoint REST o gRPC, di solito con un sistema di serving dei modelli che raggruppa le richieste in batch e scala le repliche in base alla domanda. È adatta ai modelli grandi e al traffico variabile; ogni richiesta comporta un round trip di rete.
• Distribuzione edge: il modello viene eseguito sul dispositivo che acquisisce i dati, come un telefono, una fotocamera, un robot o un modulo NVIDIA Jetson. Gli input non lasciano mai il dispositivo, a tutela della privacy, e il modello continua a funzionare offline; tuttavia, la memoria e la potenza limitate richiedono di solito un modello compresso.
• Distribuzione serverless: la piattaforma avvia istanze su richiesta e le riduce a zero quando sono inattive, accettando un ritardo di avvio a freddo alla prima richiesta in cambio di nessun costo quando non arrivano richieste.
• Distribuzione batch: un processo pianificato assegna punteggi a un grande dataset tutto in una volta, ad esempio per i consigli sui prodotti ogni notte, dove la velocità effettiva conta più della rapidità di ogni singola richiesta.

Ultralytics Platform distribuisce un modello YOLO addestrato su un endpoint dedicato in una qualsiasi delle 42 regioni, ognuna con un URL e un monitoraggio propri; gli endpoint con la dimensione di risorse predefinita si riducono a zero quando sono inattivi. La scelta della destinazione dipende da alcune domande sull'applicazione, analizzate nel dettaglio nella lezione di Ultralytics Academy Scegliere una destinazione di distribuzione:

Preparazione di un modello per la produzione#

I framework di addestramento sono progettati per essere flessibili, quindi i modelli destinati alla produzione vengono di solito esportati in un formato eseguito in modo efficiente da un motore di inferenza, come ONNX per la portabilità, TensorRT per le GPU NVIDIA, OpenVINO per l'hardware Intel oppure LiteRT e Core ML per i telefoni. La quantizzazione del modello e il pruning del modello lo riducono ulteriormente quando la destinazione è un dispositivo di piccole dimensioni. Il modello esportato e il relativo codice di preprocessing vengono poi distribuiti insieme a dipendenze bloccate, in genere in un container Docker che funziona allo stesso modo su un laptop, un server o un cluster Kubernetes. L'esportazione di un rilevatore addestrato e il caricamento del file esportato per un rapido controllo prima del rilascio si svolgono così:

from ultralytics import YOLO

# Load a trained model (replace with your own best.pt)
model = YOLO("yolo26n.pt")

# Export to ONNX, a portable format that many inference engines run
path = model.export(format="onnx")
print(f"Deployable model: {path}")

# Smoke-test the exported file with the same API before shipping it
onnx_model = YOLO(path)
results = onnx_model("https://ultralytics.com/images/bus.jpg")
results[0].save(filename="bus_onnx.jpg")

La chiamata di esportazione restituisce il percorso del nuovo file yolo26n.onnx e l'immagine salvata conferma che il file esportato si carica e produce rilevazioni. I team confrontano anche precisione e velocità del modello esportato con quelle dell'originale su un set di validazione, perché la conversione del formato e la riduzione della precisione possono modificare leggermente gli output.

Rilascio di nuove versioni del modello#

Una nuova versione del modello viene archiviata in un registro dei modelli e rilasciata gradualmente, perché le metriche offline non coprono tutte le condizioni di produzione. In una distribuzione shadow, il nuovo modello riceve una copia del traffico live mentre quello attuale continua a rispondere agli utenti, così è possibile confrontarli senza rischi. Una versione canary indirizza poi una piccola parte del traffico reale alla nuova versione e la aumenta solo finché i tassi di errore, la latenza e la qualità delle predizioni restano soddisfacenti; i test A/B misurano l'impatto sui risultati aziendali. Mantenere distribuibile la versione precedente permette di eseguire un rollback modificando la configurazione, anziché ricostruire tutto in emergenza:

Distribuzione dei modelli e termini correlati#

• Addestramento del modello: apprende i pesi del modello a partire da un dataset. La distribuzione parte dai pesi già addestrati.
• Serving del modello: il livello di runtime che risponde alle richieste di predizione. È una parte della distribuzione, che comprende anche pacchettizzazione, rilascio e monitoraggio.
• Latenza di inferenza: il tempo impiegato dal modello distribuito per calcolare ogni singola predizione, uno dei requisiti principali che una distribuzione deve soddisfare.

Monitoraggio dopo la distribuzione#

Un modello distribuito si degrada senza dare segnali quando il mondo cambia. Il monitoraggio del modello tiene traccia di segnali operativi come latenza, throughput, tassi di errore e uso dell'hardware, spesso con strumenti come Prometheus e Grafana, oltre che delle statistiche degli input e delle predizioni. Quando il monitoraggio segnala un problema, i team etichettano i nuovi casi di errore, riaddestrano il modello e sottopongono la nuova versione allo stesso processo di rilascio. Le statistiche degli input forniscono il primo avvertimento: il data drift, ovvero un cambiamento nella distribuzione degli input, per esempio una fotocamera spostata a una nuova angolazione o il passaggio all'illuminazione invernale, si manifesta giorni o settimane prima che arrivino le etichette ground truth dei dati di produzione necessarie per misurare la precisione.