Model Serving

Il serving dei modelli consiste nell'ospitare un modello di machine learning addestrato dietro un endpoint di rete, di solito HTTP o gRPC, affinché le applicazioni possano inviare input e ricevere previsioni. Un sistema di serving carica i pesi una volta sola, li mantiene in memoria su CPU o GPU, accetta molte richieste simultanee, le raggruppa in batch, aggiunge o rimuove repliche al variare del traffico, sostituisce le versioni del modello e ne segnala lo stato. Google ha reso open source TensorFlow Serving nel febbraio 2016 per eseguire modelli TensorFlow in produzione; oggi il serving è la componente di runtime delle operazioni di machine learning (MLOps), tra il confezionamento del modello e il monitoraggio delle sue previsioni.

Come un sistema di serving gestisce le richieste#

Ogni richiesta passa per la convalida, la preelaborazione — per esempio, la decodifica e il ridimensionamento di un'immagine —, una coda, il modello stesso e la postelaborazione in un formato di risposta come JSON. La maggior parte delle decisioni di serving riguarda la coda. Il batching dinamico trattiene le richieste per alcuni millisecondi, così l'acceleratore elabora più input in un unico passaggio in avanti, aumentando la produttività con un lieve costo in termini di latenza di inferenza. Quando la coda è piena, il server rifiuta le nuove richieste con HTTP 429, inducendo i client a rallentare le richieste.

I team che gestiscono il serving monitorano i percentili di latenza, come p95 e p99, la produttività in richieste al secondo, l'utilizzo dell'acceleratore, il tasso di errori e il tempo di avvio a freddo, cioè il ritardo prima che una replica aumentata da zero possa rispondere. Le nuove versioni vengono distribuite gradualmente: un rilascio canary indirizza una piccola parte del traffico al nuovo modello, mentre una distribuzione shadow gli invia copie delle richieste in tempo reale senza restituirne le risposte.

Questa app FastAPI carica YOLO26 una volta all'avvio e restituisce i rilevamenti in formato JSON. TestClient di FastAPI invia una richiesta attraverso l'intero stack HTTP nello stesso processo, perciò l'esempio funziona senza avviare un server:

from fastapi import FastAPI
from fastapi.testclient import TestClient
from ultralytics import YOLO

app = FastAPI()
model = YOLO("yolo26n.pt")  # carica i pesi una volta, all'avvio del server


@app.get("/predict")
async def predict(url: str):
    """Detect objects in the image at `url` and return them as JSON."""
    results = model(url)
    return results[0].summary()


client = TestClient(app)
response = client.get("/predict", params={"url": "https://ultralytics.com/images/bus.jpg"})
print(response.status_code, response.json()[0])

L'output mostra lo stato 200 e il primo rilevamento sotto forma di dizionario con il nome della classe, la confidenza e le coordinate del riquadro, la struttura che summary() genera per ogni oggetto rilevato. Poiché l'handler è async def, FastAPI lo esegue in un unico loop di eventi, quindi il modello condiviso non gestisce mai due richieste contemporaneamente. I server che richiedono parallelismo eseguono più processi worker, ciascuno con il proprio modello caricato.

Modelli e software di serving#

Il modo in cui viene eseguito il serving di un modello dipende da quando servono le risposte: dall'inferenza in tempo reale sui flussi delle telecamere fino alle elaborazioni notturne:

• Serving online: Ogni richiesta riceve una risposta mentre chi l'ha inviata è in attesa, tramite REST o gRPC, come nelle app rivolte agli utenti e nei flussi in diretta delle telecamere.
• Serving batch: Un processo pianificato assegna punteggi offline a un grande dataset, per esempio elaborando ogni notte le immagini di un'intera giornata, e ottimizza la produttività anziché la latenza.
• Streaming: I risultati vengono inviati continuamente man mano che arrivano i fotogrammi video o le letture dei sensori.
• Edge AI: Il modello viene eseguito direttamente sul dispositivo, spesso dopo l'esportazione in un formato ottimizzato, senza round trip di rete.

I software di serving generici includono NVIDIA Dynamo-Triton, in precedenza Triton Inference Server, oltre a TensorFlow Serving, Ray Serve, BentoML e KServe su Kubernetes. TorchServe di PyTorch è in modalità di manutenzione limitata e non sono previsti ulteriori aggiornamenti. I server per LLM, come vLLM, SGLang e TensorRT-LLM, aggiungono il batching continuo e la gestione della cache KV paginata per la generazione token per token. La maggior parte di questi sistemi viene eseguita in container, così il modello, il runtime e le dipendenze vengono distribuiti come un'unica immagine.

Serving, distribuzione e motori di inferenza#

Il serving dei modelli è strettamente collegato ad alcuni termini correlati. La distribuzione del modello è il processo più ampio che porta un modello in produzione e comprende il confezionamento, l'infrastruttura e il rilascio; il serving è la parte che gestisce le richieste una volta che il modello è attivo. Un motore di inferenza, come TensorRT, ONNX Runtime o OpenVINO, esegue i calcoli del modello; un sistema di serving integra uno o più motori con rete, accodamento e scalabilità.

Ultralytics Platform esegue il serving dei modelli YOLO tramite endpoint dedicati, ciascuno un servizio con un solo tenant in una delle 42 regioni, con route /predict, /health e /docs generate. La dimensione predefinita si riduce a zero quando il servizio è inattivo e può impiegare circa un minuto ad avviarsi; la sostituzione del modello mantiene invariato l'URL dell'endpoint, mentre il modello precedente continua a fornire il servizio finché quello nuovo non è pronto.