Inference Latency

La latence d’inférence est le temps qu’un modèle d’apprentissage automatique entraîné met à transformer une entrée — par exemple une image de caméra ou une consigne textuelle — en prédiction. Elle s’exprime généralement en millisecondes (ms) et détermine la rapidité de réaction d’un système : une caméra qui fonctionne à 30 images par seconde produit une nouvelle image toutes les 33,3 ms. Un détecteur qui nécessite plus de temps prend donc du retard sur le flux et ne peut plus assurer une inférence en temps réel. La latence est indiquée pour la passe avant seule ou de bout en bout, de l’entrée brute à la sortie exploitable. En production, les systèmes suivent des percentiles comme la médiane (p50) et le 99e percentile (p99), car quelques réponses lentes peuvent compter autant que la moyenne.

Ce qui contribue à la latence d’inférence#

Une prédiction passe par plusieurs étapes. Le prétraitement décode, redimensionne et normalise l’entrée. La passe avant exécute le réseau ; son coût augmente avec les FLOPs du modèle, la résolution d’entrée et la précision numérique, tandis que sa vitesse dépend du processeur : CPU, GPU ou unité de traitement neuronal (NPU). Le post-traitement convertit les sorties brutes en résultats : pour un détecteur, il décode les boîtes et applique la suppression non maximale (NMS). Une API cloud ajoute l’aller-retour réseau et le temps d’attente en file d’attente, ce qui explique pourquoi l’IA en périphérie exécute les modèles sur l’appareil qui capture les données. Le premier appel est également plus lent que les suivants, car les frameworks allouent la mémoire, chargent les poids dans les caches et sélectionnent les noyaux lors de la première utilisation.

Le matériel et l’environnement d’exécution peuvent multiplier le temps de propagation avant par un ordre de grandeur ou plus : Ultralytics YOLO26 nano prend en moyenne 38,9 ms par image COCO de 640 pixels avec ONNX sur un CPU, contre 1,7 ms avec TensorRT sur un GPU NVIDIA T4. Ultralytics YOLO enregistre les temps par étape de chaque prédiction dans l’attribut speed du résultat, et le mode benchmark répète la mesure pour chaque format d’exportation :

from ultralytics import YOLO

# Load the smallest YOLO26 detection model
model = YOLO("yolo26n.pt")

# Predict on one image
results = model("https://ultralytics.com/images/bus.jpg")
result = results[0]

# Per-image time in milliseconds for each stage of the pipeline
for stage, ms in result.speed.items():
    print(f"{stage}: {ms:.1f} ms")

La boucle affiche les temps de prétraitement, d’inférence et de post-traitement ; leur somme correspond à la latence du modèle pour cette image sur l’appareil actuel.

Mesurer la latence avec précision#

Les chiffres de latence ne sont comparables que s’ils sont mesurés de la même manière. Pour obtenir des mesures fiables, écarte quelques exécutions de préchauffage, chronomètre de nombreuses exécutions et indique la médiane ainsi qu’un percentile de queue plutôt qu’une seule mesure. Sur les GPU, le chronomètre doit attendre la fin du travail sur l’appareil, par exemple avec torch.cuda.synchronize(), car les noyaux sont lancés de façon asynchrone et une lecture trop précoce de l’horloge s’arrête avant la fin du calcul. La taille d’entrée, la taille de lot, la précision et l’appareil doivent correspondre au déploiement, car la latence d’un modèle sur un GPU de centre de données ne dit pas grand-chose de sa latence sur un téléphone. Les FLOPs estiment le coût sans tenir compte du matériel, mais des modèles ayant le même nombre de FLOPs peuvent fonctionner à des vitesses nettement différentes sur un même appareil.

Latence d’inférence et débit#

Le débit correspond au nombre d’entrées traitées par un système par unité de temps, par exemple en images ou en jetons par seconde ; il évolue souvent à l’inverse de la latence. Un lot plus grand occupe mieux le matériel et augmente donc le débit, mais chaque entrée du lot attend la fin du traitement complet, ce qui augmente le temps de réponse de chaque requête :

import time

import torch
import torchvision

# A ResNet-18 image classifier in inference mode on the CPU
model = torchvision.models.resnet18().eval()

for batch in [1, 2, 4, 8]:
    x = torch.randn(batch, 3, 224, 224)
    with torch.inference_mode():
        model(x)  # warmup run, not timed
        times = []
        for _ in range(20):
            start = time.perf_counter()
            model(x)
            times.append(time.perf_counter() - start)
    latency = sorted(times)[len(times) // 2]  # median seconds per batch
    print(f"batch {batch}: {latency * 1e3:5.1f} ms per batch, {batch / latency:4.0f} images/s")

Sur le CPU d’un ordinateur portable, passer d’un lot de taille 1 à un lot de taille 8 a fait passer le débit de 168 à 220 images par seconde, tandis que le temps nécessaire pour renvoyer un lot est passé de 6 ms à 36 ms. Les systèmes interactifs, comme l’assistance à la conduite et les assistants vocaux, fonctionnent donc avec une taille de lot de 1, tandis que les tâches hors ligne, comme l’indexation d’une archive vidéo, utilisent des lots volumineux. Les serveurs LLM utilisent le regroupement continu, qui ajoute et retire des requêtes d’un lot en cours d’exécution pour maintenir un débit élevé sans obliger chaque utilisateur à attendre la fin d’un lot complet.

Réduire la latence d’inférence#

Les gains les plus importants viennent généralement de la réduction des calculs : choisir une variante de modèle plus petite, réduire la résolution d’entrée ou diminuer le nombre de poids par élagage du modèle. La quantification du modèle en FP16 ou INT8 rend chaque opération restante moins coûteuse sur les matériels dotés d’unités rapides à faible précision. L’export vers un moteur d’inférence optimisé comme TensorRT, OpenVINO ou ONNX Runtime fusionne les couches et sélectionne les noyaux les plus rapides pour l’appareil. Exécuter le modèle directement sur l’appareil supprime l’aller-retour réseau, qui coûte souvent des dizaines de millisecondes sur une connexion mobile.

Situations où la latence compte#

• Grands modèles de langage (LLM) : les services de chat suivent le délai avant le premier token, qui détermine la réactivité ressentie par les utilisateurs, et le délai par token généré, qui définit la vitesse de diffusion. Le décodage spéculatif réduit le second en vérifiant plusieurs tokens proposés lors d’une seule propagation avant.
• Inspection industrielle : une caméra située au-dessus d’un convoyeur doit classer chaque pièce avant qu’elle n’atteigne la trappe de rejet ; la latence détermine donc la vitesse maximale de la ligne.
• Véhicules autonomes : la perception, la planification et le contrôle se partagent un budget de temps serré. À 100 km/h, une voiture parcourt 2,8 mètres pour chaque délai de 100 ms.