Real-time Inference
L'inferenza in tempo reale restituisce ogni predizione prima che arrivi l'input successivo, ad esempio entro 33 ms per fotogramma a 30 FPS. Include budget di latenza e tecniche di accelerazione.
L'inferenza in tempo reale consiste nell'eseguire un modello addestrato su input dal vivo e restituire ogni predizione prima che arrivi l'input successivo, così il sistema può agire mentre le informazioni sono ancora aggiornate. Con una telecamera che trasmette a 30 fotogrammi al secondo (FPS), restano 33.3 millisecondi per fotogramma per tutte le operazioni, dalla lettura dell'immagine alla produzione del risultato finale; a 60 FPS, il budget scende a 16.7 ms. Ogni applicazione ha una propria scadenza: una pipeline di percezione di un'auto, una telecamera di ispezione su nastro trasportatore e un filtro dello sfondo per videochiamate operano tutti in tempo reale, ma con budget diversi.
Il budget di latenza#
Il tempo che conta è la latenza di inferenza end-to-end: acquisizione del fotogramma, preelaborazione tramite ridimensionamento e normalizzazione, passaggio in avanti del modello e postelaborazione, ad esempio la decodifica dei riquadri e la soppressione dei non massimi (NMS). Quando il tempo totale supera l'intervallo tra i fotogrammi, i fotogrammi non elaborati si accumulano e l'output resta sempre più indietro rispetto alla scena in diretta, quindi le pipeline in tempo reale in genere scartano i fotogrammi obsoleti e lavorano sempre sul più recente. Il calcolo in tempo reale distingue i sistemi hard real-time, in cui il mancato rispetto di una scadenza equivale a un guasto, come nel caso di una centralina per airbag, dai sistemi soft real-time, che tollerano il mancato rispetto occasionale di una scadenza. La maggior parte delle applicazioni di visione artificiale è di tipo soft real-time: un fotogramma perso riduce per un istante la qualità dell'output, che si ripristina con il fotogramma successivo.
Questo frammento di codice trasmette un video registrato a un piccolo rilevatore e confronta il tempo medio per fotogramma con il budget per 30 FPS:
from ultralytics import YOLO
model = YOLO("yolo26n.pt")
video = "https://github.com/ultralytics/assets/releases/download/v0.0.0/decelera_portrait_min.mov"
# stream=True yields each frame's result as soon as it is ready
frame_times = []
for result in model(video, stream=True):
# Preprocess, inference, and postprocess time for this frame, in milliseconds
frame_times.append(sum(result.speed.values()))
mean_ms = sum(frame_times) / len(frame_times)
print(f"{mean_ms:.1f} ms per frame ({1000 / mean_ms:.0f} FPS); a 30 FPS camera allows 33.3 ms")Una media inferiore a 33.3 ms significa che il modello riesce a stare al passo con una telecamera a 30 FPS sull'hardware su cui è stato eseguito.
Inferenza in tempo reale e inferenza batch#
- Inferenza in tempo reale (online): elabora ogni input non appena arriva, di solito un'immagine alla volta, e viene valutata in base alla latenza di ogni singola predizione. Ne dipendono i sistemi di assistenza alla guida, il controllo dei robot e l'analisi video dal vivo.
- Inferenza batch (offline): raccoglie numerosi input e li elabora insieme; viene valutata in base al throughput in input al secondo e al costo. La reindicizzazione notturna di un archivio fotografico e l'analisi delle riprese del mese scorso sono attività batch; batch più grandi mantengono la GPU più occupata, ma ogni input attende più a lungo il risultato.
I server che gestiscono molti flussi video spesso si collocano tra questi due approcci: raggruppano in piccoli batch i fotogrammi di telecamere diverse, aumentando il throughput senza superare il budget di fotogrammi di ciascun flusso.
Applicazioni nel mondo reale#
- Veicoli autonomi: a 100 km/h un'auto percorre 2.8 metri ogni 100 ms, quindi la latenza di percezione si aggiunge direttamente alla distanza di arresto.
- Ispezione manifatturiera: le telecamere sopra un nastro trasportatore rilevano i difetti su ogni pezzo e devono attivare il meccanismo di scarto prima che il pezzo difettoso lo superi.
- Robotica: il rilevamento degli ostacoli e la stima della posa vengono eseguiti nel ciclo di controllo di un robot; una percezione più lenta impone movimenti più lenti.
- Effetti video e realtà aumentata: la sfocatura dello sfondo nelle videochiamate e gli elementi sovrapposti di AR eseguono segmentazione o tracciamento a ogni fotogramma; qualsiasi ritardo fa sì che l'elemento sovrapposto resti indietro rispetto alla persona in movimento.
Rendere un modello abbastanza veloce#
- Modello o dimensione dell'input più piccoli: una variante più piccola del modello esegue meno operazioni per immagine; poiché il calcolo delle convoluzioni cresce all'incirca con il numero di pixel, dimezzare larghezza e altezza dell'input lo riduce a circa un quarto, a scapito di una parte dell'accuratezza sugli oggetti piccoli.
- Quantizzazione del modello: memorizzare pesi e attivazioni in FP16 o INT8 invece che in FP32 riduce il traffico di memoria e sfrutta unità aritmetiche più veloci. In genere INT8 richiede un set di immagini di calibrazione per contenere la perdita di accuratezza.
- Motori di inferenza: un runtime progettato per una famiglia di hardware fonde i livelli e sceglie kernel ottimizzati per il dispositivo, come TensorRT per le GPU NVIDIA o Core ML per i dispositivi Apple.
- AI edge: eseguire il modello sulla telecamera o su un modulo integrato elimina il viaggio di andata e ritorno in rete di una chiamata al cloud, che con una connessione lenta può superare l'intero budget per fotogramma.
Il runtime e l'hardware modificano la latenza di oltre un ordine di grandezza: il modello YOLO26 nano impiega 38,9 ms per immagine da 640 pixel su una CPU con ONNX e 1,7 ms su una GPU NVIDIA T4 con TensorRT. La modalità di esportazione di Ultralytics converte un modello YOLO26 addestrato in TensorRT, OpenVINO, LiteRT e altri formati, e il suo argomento quantize=16 o quantize=8 genera pesi FP16 o INT8 per il dispositivo di destinazione.










