Ultralytics YOLO27 :
Get Started

YOLOv7 vs RTDETRv2#

Le domaine de la vision par ordinateur continue d’évoluer rapidement, sous l’influence marquée de la compétition entre les réseaux neuronaux convolutifs (CNN) et les Transformers visuels (ViT). Cette comparaison technique se penche sur deux architectures majeures : YOLOv7, un détecteur d’objets basé sur un CNN très optimisé, et RTDETRv2, un Transformer de détection en temps réel de pointe.

En analysant leurs différences architecturales, leurs indicateurs de performance et leurs scénarios de déploiement idéaux, les développeurs peuvent prendre des décisions éclairées lorsqu’ils intègrent ces modèles d’IA visuelle à leurs pipelines de production.

YOLOv7 : l’architecture CNN « bag of freebies »#

YOLOv7 a introduit plusieurs optimisations structurelles qui changent la donne dans la famille YOLO traditionnelle, repoussant les limites de la détection d’objets en temps réel grâce à une série de « bag of freebies » entraînables.

Caractéristiques principales :

Architecture et points forts#

YOLOv7 s’appuie sur l’architecture de réseau d’agrégation de couches efficaces étendu (E-ELAN). Cette conception structurelle permet au modèle d’apprendre des caractéristiques plus diverses sans détruire le chemin de gradient d’origine. De plus, il intègre des convolutions reparamétrées planifiées, qui optimisent la vitesse d’inférence sans dégrader la précision. Son approche de « bag of freebies » entraînable lui permet d’obtenir un compromis impressionnant entre vitesse et précision, ce qui la rend particulièrement adaptée aux tâches de détection d’objets en temps réel sur des GPU de qualité serveur.

YOLOv7 est également très polyvalent. Au-delà de la détection classique par boîtes englobantes, le dépôt propose des branches dédiées à l’estimation de pose et à la segmentation d’instances, ce qui démontre son adaptabilité.

Limites#

Comme de nombreux anciens modèles CNN, YOLOv7 s’appuie sur la suppression non maximale (NMS) pour le post-traitement. La NMS entraîne une latence variable, en particulier dans les scènes encombrées, ce qui peut compliquer le respect de garanties strictes de temps réel sur les appareils en périphérie.

En savoir plus sur YOLOv7

RTDETRv2 : faire progresser les Transformers en temps réel#

RTDETRv2 s’appuie sur le framework RT-DETR d’origine et confirme que les Transformers peuvent rivaliser avec les architectures YOLO en matière de latence en temps réel, tout en conservant une grande précision spatiale.

Caractéristiques principales :

Architecture et points forts#

RTDETRv2 représente une avancée majeure pour les Transformers visuels. Il exploite un processus flexible de sélection des requêtes et un encodeur hybride efficace pour traiter rapidement les caractéristiques multi-échelles. En introduisant un nouveau « bag of freebies » spécialement conçu pour les Transformers de détection (DETR), il repousse les limites du raisonnement spatial. Comme il est nativement dépourvu de NMS, il garantit des temps d’inférence déterministes, un atout essentiel pour les applications de ville intelligente exigeantes et la conduite autonome.

Limites#

Malgré ses avancées, RTDETRv2 conserve les inconvénients habituels des architectures basées sur les Transformers. Il nécessite beaucoup plus de mémoire CUDA pendant l’entraînement et l’inférence que les CNN. De plus, sa convergence à l’entraînement est sensiblement plus lente et nécessite de grandes quantités de données annotées de haute qualité (comme le jeu de données COCO) ainsi que d’importantes ressources de calcul.

En savoir plus sur RTDETRv2

Comparaison des performances#

Pour évaluer ces modèles, nous devons examiner l’ensemble des critères : précision, vitesse d’inférence brute et empreinte de calcul. Voici un tableau comparatif direct.

Modèletaille
(pixels)
mAPval
50-95
Vitesse
CPU ONNX
(ms)
Vitesse
T4 TensorRT10
(ms)
paramètres
(M)
FLOPs
(B)
YOLOv7l64051.4-6.8436.9104.7
YOLOv7x64053.1-11.5771.3189.9
RTDETRv2-s64048.1-5.032060
RTDETRv2-m64051.9-7.5136100
RTDETRv2-l64053.4-9.7642136
RTDETRv2-x64054.3-15.0376259
Interprétation des benchmarks

RTDETRv2-x revendique le mAPval le plus élevé, à 54,3 %, mais nécessite 259 milliards de FLOPs. À l’inverse, les architectures YOLOv7 constituent une excellente référence, mais souffrent de la surcharge de la NMS héritée, qui n’est pas entièrement prise en compte dans les mesures de latence du réseau seul.

L’avantage d’Ultralytics : écosystème et évolution#

YOLOv7 et RTDETRv2 offrent des fonctionnalités robustes, mais leur déploiement dans des environnements de production révèle souvent des difficultés logistiques. C’est là que l’écosystème Ultralytics excelle. Conçu pour une intégration fluide de bout en bout, le framework Ultralytics fournit aux développeurs une API unifiée qui masque les complexités habituelles des pipelines de vision par ordinateur.

Polyvalence inégalée et efficacité mémoire#

Contrairement aux modèles Transformer rigides qui consomment énormément de VRAM, les modèles Ultralytics YOLO restent très économes en mémoire. Cela permet un entraînement rapide des modèles sur du matériel accessible. L’écosystème prend nativement en charge plusieurs tâches de vision par ordinateur depuis une seule base de code, notamment la classification d’images et la détection de boîtes englobantes orientées (OBB), offrant une flexibilité qui fait actuellement défaut à RTDETRv2.

Déploiement fluide#

Passer de la recherche à la production nécessite des options de déploiement robustes. L’API Ultralytics gère nativement l’exportation de modèles en un clic vers des formats standards du secteur. Que tu vises ONNX pour la compatibilité multiplateforme ou TensorRT pour tirer le maximum de l’accélération GPU, le pipeline est entièrement automatisé et fiable.

La mise à niveau ultime : Ultralytics YOLO26#

Pour les développeurs qui hésitent entre YOLOv7 et RTDETRv2, la voie optimale est en fait le nouveau standard de l’IA visuelle : Ultralytics YOLO26. Lancé en janvier 2026, YOLO26 comble l’écart entre la vitesse des CNN et les capacités de raisonnement sophistiquées des Transformers, tout en éliminant complètement leurs faiblesses respectives.

YOLO26 apporte des innovations révolutionnaires conçues pour les déploiements sur serveur comme en périphérie :

  • Conception de bout en bout sans NMS : Introduite pour la première fois dans YOLOv10, YOLO26 propose une tête native sans NMS (nms=False) qui élimine le post-traitement par NMS. Elle garantit ainsi une latence déterministe comparable à celle de RTDETRv2, sans la lourde surcharge de calcul d’un Transformer.
  • Optimiseur MuSGD : Inspiré des techniques d’entraînement des grands modèles de langage (comme Kimi K2 de Moonshot AI), YOLO26 utilise une approche hybride combinant SGD et Muon. Elle offre une stabilité d’entraînement sans précédent et une convergence nettement plus rapide que les implémentations standard d’AdamW utilisées par les ViT.
  • ProgLoss + STAL : Ces fonctions de perte avancées améliorent notablement la reconnaissance des petits objets et rivalisent directement avec les avantages des caractéristiques multi-échelles de RTDETRv2, ce qui est essentiel pour l’automatisation robotique.
  • Optimisation pour les appareils en périphérie et suppression de DFL : En supprimant Distribution Focal Loss (DFL), YOLO26 rationalise sa tête de sortie et accélère jusqu’à 43 % l’inférence sur CPU, ce qui le rend infiniment plus facile à déployer sur des appareils en périphérie que les modèles Transformer lourds.

Exemple d’entraînement avec Ultralytics#

La simplicité de l’API Python Ultralytics te permet d’entraîner le modèle YOLO26 de pointe avec seulement quelques lignes de code :

from ultralytics import YOLO

# Charger le modèle YOLO26 small très efficace
model = YOLO("yolo26s.pt")

# Entraîner le modèle sur le jeu de données COCO8
# Le framework gère automatiquement l’augmentation des données et le choix de l’optimiseur
results = model.train(data="coco8.yaml", epochs=100, imgsz=640, device="0")

# Exporter facilement vers TensorRT pour le déploiement
model.export(format="engine", dynamic=True)

Cas d’utilisation idéaux#

Le choix de la bonne architecture dépend fortement des contraintes de déploiement et du matériel disponible :

Quand envisager YOLOv7 :

  • Projets de recherche existants où YOLOv7 sert de référence établie.
  • Environnements disposant d’une grande puissance d’accélération GPU brute et où une variation de la latence NMS est acceptable.

Quand envisager RTDETRv2 :

  • Déploiements sur des serveurs haut de gamme nécessitant le mAP maximal absolu.
  • Scénarios exigeant strictement une latence d’inférence déterministe (sans NMS), à condition de disposer de suffisamment de VRAM pour prendre en charge son backbone Transformer.

Quand choisir Ultralytics YOLO26 :

  • Presque toujours. Il offre le déterminisme sans NMS de RTDETRv2, dépasse YOLOv7 en vitesse et en précision, utilise beaucoup moins de VRAM et est entièrement intégré à l’Ultralytics Platform pour simplifier la gestion des jeux de données, l’entraînement et le déploiement.
Découvrir d’autres modèles

Tu veux savoir comment se comparent les autres architectures ? Découvre nos analyses détaillées des générations précédentes, comme YOLO11 et YOLOv8, ou apprends à tirer parti du réglage des hyperparamètres pour maximiser la précision de ton projet.

Commentaires