Comprendre la détection de bout en bout dans Ultralytics YOLO26#

YOLO26 entraîne à la fois une tête one-to-many et une tête one-to-one. Par défaut, la prédiction et la validation utilisent la tête one-to-many avec la suppression non maximale (NMS). Cette approche privilégie la précision avec les mêmes poids entraînés. Définis nms=False pour utiliser à la place la tête one-to-one, plus rapide et sans NMS.

Un seul argument détermine le choix pour la prédiction, la validation, le suivi, l’exportation et l’évaluation comparative :

None signifie qu’aucun post-traitement facultatif n’est intégré au modèle. Cela ne supprime pas le traitement habituel qui convertit les sorties du modèle en résultats de prédiction ou en métriques de validation. La classification, la segmentation sémantique, la profondeur et les modèles sans tête de détection sélectionnable conservent leur comportement natif.

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
results = model.predict("image.jpg")  # one-to-many + NMS
metrics = model.val(data="coco.yaml")  # one-to-many + NMS
results = model.predict("image.jpg", nms=False)  # activer l’inférence sans NMS
results = model.predict("image.jpg", nms=None)  # revenir à one-to-many + NMS

model.export(format="onnx")  # sorties brutes one-to-many
model.export(format="onnx", nms=True)  # intégrer NMS
model.export(format="onnx", nms=False)  # sorties one-to-one sans NMS

Fonctionnement de la détection de bout en bout#

Les deux têtes partagent le backbone et le neck et sont optimisées pendant l’entraînement. La tête one-to-many fournit plusieurs prédictions candidates par objet ; NMS supprime les détections qui se chevauchent. La tête one-to-one apprend à produire une seule prédiction par objet. Le choix du chemin d’inférence ne désactive pas la supervision à deux têtes. La validation pendant l’entraînement utilise la tête d’inférence sélectionnée : le choix des checkpoints et l’arrêt anticipé reposent donc sur les mêmes prédictions que le déploiement.

Ici, N correspond à la taille du lot, nc au nombre de classes, et 8400 au nombre de candidats pour imgsz=640. Les lignes de détection one-to-one contiennent [x1, y1, x2, y2, confidence, class_id]. Les autres tâches de détection comportent des sorties supplémentaires :

La fusion supprime les branches d’inférence inutilisées et replie les couches Conv et BatchNorm. Conserve le checkpoint d’entraînement d’origine si tu dois changer de tête : la fusion ne peut pas reconstruire une branche déjà supprimée. Un modèle auquel il ne reste que sa tête one-to-one conserve ce chemin disponible.

Sorties exportées#

Par défaut, les modèles de détection YOLOv8, YOLO11 et YOLO26 exportent des prédictions brutes one-to-many. Exporte YOLO26 avec nms=False pour obtenir des détections sans NMS.

nms=True produit également des détections traitées, mais utilise la tête one-to-many et intègre le NMS traditionnel. Cette option est utile si tu veux que ton environnement d’exécution de déploiement reçoive des détections sans avoir à implémenter lui-même la suppression.

Le graphe d’un modèle exporté détermine ses sorties. Le fait de transmettre nms lors du chargement ne reconstruit pas le graphe ; exporte le checkpoint source avec la valeur nms souhaitée pour sélectionner son chemin de sortie. Ultralytics utilise les métadonnées de l’artefact pour éviter d’appliquer le NMS deux fois.

Compatibilité des formats d’exportation#

ONNX, TensorRT, CoreML, OpenVINO et plusieurs autres formats prennent en charge les exportations sans NMS. NCNN, RKNN, PaddlePaddle, ExecuTorch, IMX, Edge TPU et Qualcomm QNN utilisent le chemin one-to-many lorsque leurs opérateurs ne prennent pas en charge les sorties de bout en bout. Les avertissements de format expliquent ce repli.

• NMS intégré : nms=True est soumis aux restrictions propres à chaque format concernant les tâches, la précision et les formes dynamiques. Les formats qui ne prennent pas en charge le NMS intégré exportent les sorties natives pour un traitement externe.
• CoreML : Le NMS intégré prend en charge la détection, la segmentation et la pose avec des formes statiques. Utilise nms=True pour les modèles de détection qui nécessitent le pipeline NMS de Xcode Preview.
• MNN : Le NMS intégré prend en charge la détection et la pose avec dynamic=False.
• IMX : La détection, la segmentation d’instances et la pose nécessitent un NMS intégré, sélectionné automatiquement.
• Hailo : YOLO26 utilise des tenseurs bruts avec le NMS côté hôte par défaut ; nms=False sélectionne son chemin one-to-one. La détection YOLOv8/YOLO11 utilise le NMS de HailoRT.
• Quantification : Les versions de TensorRT antérieures à 8.5.0, TensorRT 10.3.0 INT8 sur JetPack 6 et LiteRT INT8 ou w8a16 utilisent les sorties one-to-many.

Consulte les guides d’intégration propres à chaque matériel pour connaître la configuration requise. Pour obtenir des tenseurs de sortie FP16 complets, utilise nms=None ; les indices de classe de bout en bout peuvent maintenir les tenseurs de sortie en FP32 même lorsque le modèle est quantifié.

Compromis entre précision et vitesse#

Les résultats publiés de YOLO26 sur COCO montrent que la tête one-to-many améliore le mAP de détection de 0,6 à 0,8 point sur les cinq échelles : par exemple, 40,9 contre 40,1 pour YOLO26n et 57,5 contre 56,9 pour YOLO26x. La tête one-to-one évite l’étape NMS et privilégie la latence. Ces résultats justifient le choix par défaut, mais ne garantissent pas un gain sur chaque jeu de données.

Les mesures de vitesse publiées pour l’inférence sans NMS utilisent nms=False. Compare la précision et la latence en gardant la même sélection de tête, la même taille d’image, la même précision et le même matériel.

FAQ#