Real-time Inference

L’inférence en temps réel consiste à exécuter un modèle entraîné sur une entrée en direct et à renvoyer chaque prédiction avant l’arrivée de l’entrée suivante, afin que le système puisse agir tant que l’information est encore à jour. Pour une caméra diffusant à 30 images par seconde (FPS), il reste 33.3 millisecondes par image pour tout faire, de la lecture de l’image à la production du résultat final ; à 60 FPS, le budget tombe à 16.7 ms. Chaque application impose son propre délai : la chaîne de perception d’une voiture, une caméra d’inspection sur un convoyeur et un filtre d’arrière-plan pour visioconférence fonctionnent toutes en temps réel, mais avec des budgets différents.

Le budget de latence#

Le temps à prendre en compte est la latence d’inférence de bout en bout : capture de l’image, prétraitement par redimensionnement et normalisation, passe avant du modèle et post-traitement, comme le décodage des boîtes et la suppression des non-maxima (NMS). Lorsque le total dépasse l’intervalle entre les images, les images non traitées s’accumulent et la sortie prend de plus en plus de retard sur la scène en direct ; les pipelines en temps réel abandonnent donc généralement les images périmées et traitent toujours la plus récente. Le calcul en temps réel distingue les systèmes temps réel stricts, où dépasser un délai constitue une défaillance, comme dans le cas d’un contrôleur d’airbag, des systèmes temps réel souples, qui tolèrent des dépassements occasionnels. La plupart des applications de vision par ordinateur relèvent du temps réel souple : une image perdue dégrade brièvement la qualité de la sortie, puis l’image suivante la rétablit.

Cet extrait diffuse une vidéo enregistrée à travers un petit détecteur et compare son temps moyen par image au budget de 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")

Une moyenne inférieure à 33.3 ms signifie que le modèle suit le rythme d’une caméra à 30 FPS sur le matériel utilisé pour l’exécution.

Inférence en temps réel et inférence par lots#

• Inférence en temps réel (en ligne) : traite chaque entrée dès son arrivée, généralement une image à la fois, et s’évalue en fonction de la latence de chaque prédiction. L’aide à la conduite, le contrôle robotique et l’analyse vidéo en direct en dépendent.
• Inférence par lots (hors ligne) : regroupe plusieurs entrées pour les traiter ensemble ; elle s’évalue selon le débit, en entrées par seconde, et le coût. La réindexation nocturne d’une archive de photos ou l’analyse des vidéos du mois dernier sont des traitements par lots ; des lots plus importants sollicitent davantage le GPU, mais chaque entrée attend plus longtemps son résultat.

Les serveurs qui gèrent de nombreux flux de caméras se situent souvent entre les deux approches : ils regroupent des images provenant de différentes caméras en petits lots pour augmenter le débit tout en respectant le budget de chaque flux.

Applications concrètes#

• Véhicules autonomes : à 100 km/h, une voiture parcourt 2.8 mètres en 100 ms ; la latence de perception augmente donc directement la distance d’arrêt.
• Inspection industrielle : les caméras placées au-dessus d’un convoyeur détectent les défauts de chaque pièce et doivent déclencher le mécanisme de rejet avant que la pièce défectueuse ne le dépasse.
• Robotique : la détection des obstacles et l’estimation de pose s’effectuent dans la boucle de contrôle du robot ; une perception plus lente impose des mouvements plus lents.
• Effets vidéo et réalité augmentée : le flou d’arrière-plan des appels vidéo et les incrustations de réalité augmentée exécutent une segmentation ou un suivi à chaque image ; tout retard se manifeste par une incrustation qui suit la personne en mouvement avec un décalage.

Accélérer suffisamment un modèle#

• Modèle plus petit ou résolution d’entrée réduite : une variante plus petite du modèle effectue moins d’opérations par image ; comme le calcul des convolutions augmente approximativement avec le nombre de pixels, diviser par deux la largeur et la hauteur de l’entrée le réduit à environ un quart, au prix d’une certaine perte d’exactitude sur les petits objets.
• Quantification de modèle : stocker les poids et les activations en FP16 ou INT8 au lieu de FP32 réduit le trafic mémoire et permet d’utiliser des unités arithmétiques plus rapides. L’INT8 nécessite généralement des images d’étalonnage pour limiter la perte d’exactitude.
• Moteurs d’inférence : un environnement d’exécution conçu pour une famille de matériels fusionne les couches et choisit des noyaux optimisés pour l’appareil, comme TensorRT pour les GPU NVIDIA ou Core ML pour les appareils Apple.
• IA en périphérie : exécuter le modèle sur la caméra ou un module embarqué élimine l’aller-retour réseau d’un appel au cloud, qui peut dépasser tout le budget par image lorsque la connexion est lente.

L’environnement d’exécution et le matériel font varier la latence de plus d’un ordre de grandeur : le modèle nano YOLO26 prend 38,9 ms par image de 640 pixels sur un CPU avec ONNX, contre 1,7 ms sur un GPU NVIDIA T4 avec TensorRT. Le mode d’exportation Ultralytics convertit un modèle YOLO26 entraîné en TensorRT, OpenVINO, LiteRT et d’autres formats ; son argument quantize=16 ou quantize=8 produit des poids FP16 ou INT8 pour l’appareil cible.