{"notes":[{"id":"object-detection/rf-detr","category":"object-detection","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"RF-DETR","subtitle":"Entraîner d'abord, choisir la taille ensuite","author":"Z. Yuan","paperDate":"2025-11-12","publishedOn":"2026-05-12","paperTitle":"RF-DETR: Neural Architecture Search for Real-Time Detection Transformers","paperUrl":"https://arxiv.org/abs/2511.09554","bibliography":{"title":"RF-DETR: Neural Architecture Search for Real-Time Detection Transformers","authors":["Isaac Robinson","Peter Robicheaux","Matvei Popov","Deva Ramanan","Neehar Peri"],"url":"https://arxiv.org/abs/2511.09554","pdfUrl":"https://arxiv.org/pdf/2511.09554v2","codeUrl":"https://github.com/roboflow/rf-detr","preprint":{"id":"2511.09554","submittedOn":"2025-11-12","url":"https://arxiv.org/abs/2511.09554"},"publication":{"venue":"ICLR","year":2026,"kind":"conference","url":"https://iclr.cc/virtual/2026/poster/10007257"},"citation":"@misc{objectdetectionrfdetr2025,\n  title = {{RF-DETR: Neural Architecture Search for Real-Time Detection Transformers}},\n  author = {Isaac Robinson and Peter Robicheaux and Matvei Popov and Deva Ramanan and Neehar Peri},\n  year = {2025},\n  eprint = {2511.09554},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2511.09554}\n}\n","citationPath":"/content/papers/citations/object-detection/rf-detr.f78ec4489185.bib"},"thumbnail":{"src":"/content/papers/assets/10f93bab733752bf97f8b3ed5c86569a2c4d85840b99b338a6443431fb506555.png","width":1080,"height":775},"locale":"fr","path":"/content/papers/fr/object-detection/rf-detr.d2e97986e9d9.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"trop-finement-réglés-sur-coco","text":"Trop finement réglés sur COCO","depth":3},{"id":"une-taille-pour-un-seul-matériel","text":"Une taille pour un seul matériel","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"la-base-lw-detr","text":"La base, LW-DETR","depth":3},{"id":"cinq-boutons","text":"Cinq boutons","depth":3},{"id":"combien-de-tokens-voit-chaque-taille","text":"Combien de tokens voit chaque taille","depth":3},{"id":"choisir-après-lentraînement","text":"Choisir après l'entraînement","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"dabord-étalonner-la-règle-qui-mesure-la-latence","text":"D'abord étalonner la règle qui mesure la latence","depth":3},{"id":"coco","text":"COCO","depth":3},{"id":"rf100-vl","text":"RF100-VL","depth":3},{"id":"ablations-doù-viennent-les-2-ap-de-plus","text":"Ablations : d'où viennent les 2 AP de plus","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/detr","relation":"referenced","topic":""},{"id":"object-detection/deformable-detr","relation":"referenced","topic":""},{"id":"contrastive-learning/dinov2","relation":"referenced","topic":""}]},{"id":"object-detection/detr","category":"object-detection","legacyPath":"object-detection/2005-detr","legacySlug":"2005-detr","legacyPaths":[],"title":"DETR","subtitle":"Un pionnier entre deux domaines","author":"Z. Yuan","paperDate":"2020-05-26","publishedOn":"2024-06-04","paperTitle":"End-to-End Object Detection with Transformers","paperUrl":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php","bibliography":{"title":"End-to-End Object Detection with Transformers","authors":["Nicolas Carion","Francisco Massa","Gabriel Synnaeve","Nicolas Usunier","Alexander Kirillov","Sergey Zagoruyko"],"url":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php","pdfUrl":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/papers/123460205.pdf","codeUrl":"https://github.com/facebookresearch/detr","preprint":{"id":"2005.12872","submittedOn":"2020-05-26","url":"https://arxiv.org/abs/2005.12872"},"publication":{"venue":"ECCV","year":2020,"kind":"conference","url":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php"},"citation":"@misc{objectdetectiondetr2020,\n  title = {{End-to-End Object Detection with Transformers}},\n  author = {Nicolas Carion and Francisco Massa and Gabriel Synnaeve and Nicolas Usunier and Alexander Kirillov and Sergey Zagoruyko},\n  year = {2020},\n  eprint = {2005.12872},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2005.12872}\n}\n","citationPath":"/content/papers/citations/object-detection/detr.5258ffe0b9a0.bib"},"thumbnail":{"src":"/content/papers/assets/dd7e8441e6460ff562cf558374789924518fafaed7ecde0e3e35ee778c316330.jpg","width":1024,"height":266},"locale":"fr","path":"/content/papers/fr/object-detection/detr.5137ffe05d95.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"architecture-du-modèle","text":"Architecture du modèle","depth":3},{"id":"conception-de-la-perte","text":"Conception de la perte","depth":3},{"id":"jeu-de-données","text":"Jeu de données","depth":3},{"id":"détails-techniques","text":"Détails techniques","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"alors-ça-marche-cette-fois-","text":"Alors, ça marche cette fois ?","depth":3},{"id":"analyse-des-composants-du-modèle","text":"Analyse des composants du modèle","depth":3},{"id":"analyse-du-comportement-du-modèle","text":"Analyse du comportement du modèle","depth":3},{"id":"généralisation-à-un-nombre-dobjets-inédit","text":"Généralisation à un nombre d'objets inédit","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/deformable-detr","relation":"next","topic":"Prédiction d’ensembles et détection par attention"},{"id":"object-detection/smca-detr","relation":"comparison","topic":"Accélérer la convergence des détecteurs Transformer"}]},{"id":"object-detection/deformable-detr","category":"object-detection","legacyPath":"object-detection/2010-deformable-detr","legacySlug":"2010-deformable-detr","legacyPaths":[],"title":"Deformable DETR","subtitle":"Une attention déformable","author":"Z. Yuan","paperDate":"2020-10-08","publishedOn":"2024-09-20","paperTitle":"Deformable DETR: Deformable Transformers for End-to-End Object Detection","paperUrl":"https://arxiv.org/abs/2010.04159","bibliography":{"title":"Deformable DETR: Deformable Transformers for End-to-End Object Detection","authors":["Xizhou Zhu","Weijie Su","Lewei Lu","Bin Li","Xiaogang Wang","Jifeng Dai"],"url":"https://arxiv.org/abs/2010.04159","pdfUrl":"https://arxiv.org/pdf/2010.04159","codeUrl":null,"preprint":{"id":"2010.04159","submittedOn":"2020-10-08","url":"https://arxiv.org/abs/2010.04159"},"publication":{"venue":"ICLR","year":2021,"kind":"conference","url":"https://arxiv.org/abs/2010.04159"},"citation":"@misc{objectdetectiondeformabledetr2020,\n  title = {{Deformable DETR: Deformable Transformers for End-to-End Object Detection}},\n  author = {Xizhou Zhu and Weijie Su and Lewei Lu and Bin Li and Xiaogang Wang and Jifeng Dai},\n  year = {2020},\n  eprint = {2010.04159},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2010.04159}\n}\n","citationPath":"/content/papers/citations/object-detection/deformable-detr.df721a30472e.bib"},"thumbnail":{"src":"/content/papers/assets/36edfc5595a85c73fcdc9a4bbb9e1ca512e1f100676eb7c37203d71c84905c05.jpg","width":1224,"height":752},"locale":"fr","path":"/content/papers/fr/object-detection/deformable-detr.b9cc2a2d8b0f.md","headings":[{"id":"définition-du-problème","text":"Définition du problème","depth":2},{"id":"résolution-du-problème","text":"Résolution du problème","depth":2},{"id":"attention-déformable","text":"Attention déformable","depth":3},{"id":"calcul-multi-échelle","text":"Calcul multi-échelle","depth":3},{"id":"architecture-du-modèle","text":"Architecture du modèle","depth":3},{"id":"lecture-du-code","text":"Lecture du code","depth":3},{"id":"stratégie-dentraînement","text":"Stratégie d'entraînement","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"comparaison-avec-detr","text":"Comparaison avec DETR","depth":3},{"id":"étude-dablation","text":"Étude d'ablation","depth":3},{"id":"comparaison-avec-les-meilleures-méthodes","text":"Comparaison avec les meilleures méthodes","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/detr","relation":"background","topic":"Prédiction d’ensembles et détection par attention"},{"id":"object-detection/h-detr","relation":"next","topic":"Prédiction d’ensembles et détection par attention"},{"id":"object-detection/smca-detr","relation":"comparison","topic":"Accélérer la convergence des détecteurs Transformer"}]},{"id":"contrastive-learning/dinov2","category":"contrastive-learning","legacyPath":"contrastive-learning/2304-dinov2","legacySlug":"2304-dinov2","legacyPaths":[],"title":"DINOv2","subtitle":"Forger des caractéristiques visuelles généralistes","author":"Z. Yuan","paperDate":"2023-04-14","publishedOn":"2025-07-01","paperTitle":"DINOv2: Learning Robust Visual Features without Supervision","paperUrl":"https://arxiv.org/abs/2304.07193","bibliography":{"title":"DINOv2: Learning Robust Visual Features without Supervision","authors":["Maxime Oquab","Timothée Darcet","Théo Moutakanni","Huy V. Vo","Marc Szafraniec","Vasil Khalidov","Pierre Fernandez","Daniel Haziza","Francisco Massa","Alaaeldin El-Nouby","Mahmoud Assran","Nicolas Ballas","Wojciech Galuba","Russell Howes","Po-Yao Huang","Shang-Wen Li","Ishan Misra","Michael Rabbat","Vasu Sharma","Gabriel Synnaeve","Hu Xu","Hervé Jégou","Julien Mairal","Patrick Labatut","Armand Joulin","Piotr Bojanowski"],"url":"https://arxiv.org/abs/2304.07193","pdfUrl":"https://arxiv.org/pdf/2304.07193","codeUrl":"https://github.com/facebookresearch/dinov2","preprint":{"id":"2304.07193","submittedOn":"2023-04-14","url":"https://arxiv.org/abs/2304.07193"},"publication":{"venue":"Transactions on Machine Learning Research","shortVenue":"TMLR","year":2024,"kind":"journal","url":"https://openreview.net/forum?id=a68SUt6zFt"},"citation":"@misc{contrastivelearningdinov22023,\n  title = {{DINOv2: Learning Robust Visual Features without Supervision}},\n  author = {Maxime Oquab and Timothée Darcet and Théo Moutakanni and Huy V. Vo and Marc Szafraniec and Vasil Khalidov and Pierre Fernandez and Daniel Haziza and Francisco Massa and Alaaeldin El-Nouby and Mahmoud Assran and Nicolas Ballas and Wojciech Galuba and Russell Howes and Po-Yao Huang and Shang-Wen Li and Ishan Misra and Michael Rabbat and Vasu Sharma and Gabriel Synnaeve and Hu Xu and Hervé Jégou and Julien Mairal and Patrick Labatut and Armand Joulin and Piotr Bojanowski},\n  year = {2023},\n  eprint = {2304.07193},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2304.07193}\n}\n","citationPath":"/content/papers/citations/contrastive-learning/dinov2.e904e3854892.bib"},"thumbnail":{"src":"/content/papers/assets/9c68ef105804d4462aee8950a1bfd9f0929511f494b1a29690d857bf931da892.jpg","width":1224,"height":368},"locale":"fr","path":"/content/papers/fr/contrastive-learning/dinov2.39ef70247bb5.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"collecte-des-données","text":"Collecte des données","depth":2},{"id":"1-préparer-les-réservoirs-dimages","text":"1. Préparer les réservoirs d'images","depth":3},{"id":"2-retirer-les-doublons","text":"2. Retirer les doublons","depth":3},{"id":"3-retrouver-des-images-par-autosupervision","text":"3. Retrouver des images par autosupervision","depth":3},{"id":"échelle-et-efficacité-du-pipeline","text":"Échelle et efficacité du pipeline","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"aligner-les-caractéristiques-à-léchelle-de-limage","text":"Aligner les caractéristiques à l'échelle de l'image","depth":3},{"id":"prédire-à-léchelle-des-patchs","text":"Prédire à l'échelle des patchs","depth":3},{"id":"deux-heads-distincts","text":"Deux heads distincts","depth":3},{"id":"centrage-sinkhorn-knopp","text":"Centrage Sinkhorn-Knopp","depth":3},{"id":"régularisation-koleo","text":"Régularisation KoLeo","depth":3},{"id":"une-courte-phase-à-haute-résolution","text":"Une courte phase à haute résolution","depth":3},{"id":"mise-en-œuvre-technique","text":"Mise en œuvre technique","depth":2},{"id":"flashattention","text":"FlashAttention","depth":3},{"id":"regroupement-des-séquences","text":"Regroupement des séquences","depth":3},{"id":"profondeur-stochastique","text":"Profondeur stochastique","depth":3},{"id":"entraînement-distribué","text":"Entraînement distribué","depth":3},{"id":"distillation-des-modèles","text":"Distillation des modèles","depth":3},{"id":"études-dablation","text":"Études d'ablation","depth":2},{"id":"étapes-de-lentraînement","text":"Étapes de l'entraînement","depth":3},{"id":"données-de-préentraînement","text":"Données de préentraînement","depth":3},{"id":"contribution-des-fonctions-de-perte","text":"Contribution des fonctions de perte","depth":3},{"id":"effet-de-la-distillation","text":"Effet de la distillation","depth":3},{"id":"entraînement-à-haute-résolution","text":"Entraînement à haute résolution","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"classification-imagenet","text":"Classification ImageNet","depth":3},{"id":"classification-vidéo","text":"Classification vidéo","depth":3},{"id":"reconnaissance-dinstances","text":"Reconnaissance d'instances","depth":3},{"id":"segmentation-sémantique","text":"Segmentation sémantique","depth":3},{"id":"résultats-qualitatifs","text":"Résultats qualitatifs","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"contrastive-learning/dino","relation":"background","topic":"Auto-distillation des représentations visuelles"}]}],"text":"Pour choisir un détecteur d'objets temps réel, beaucoup commencent par le classement COCO et retiennent une famille de modèles au score flatteur ; ils cherchent ensuite, parmi les tailles N, S, M ou L, celle qui tourne assez vite sur leur GPU ; enfin, ils l'affinent sur leurs propres données.\n\nCet article trouve à redire à chaque étape. Un classement sur COCO ne tient pas forcément sur votre propre jeu de données ; les quelques tailles découpées à l'avance ne tombent pas forcément juste pour votre matériel ; quant à « tourner assez vite », les articles ne mesurent pas tous la latence de la même façon.\n\nSi vous ne connaissez pas Roboflow, un peu de contexte. C'est une entreprise américaine qui exploite une plateforme d'annotation, d'entraînement et de déploiement pour la vision par ordinateur ; les jeux de données que ses utilisateurs partagent publiquement sont regroupés sur son site Roboflow Universe. En mars 2025, elle a présenté sur son blog RF-DETR, un détecteur temps réel de la famille DETR. Il prend une image et produit directement la boîte, la classe et le score de confiance de chaque objet, sans NMS intermédiaire ; le code est publié en open source sous licence Apache 2.0. [Roboflow, 2025-03-20](https://blog.roboflow.com/rf-detr/)\n\nL'article n'est arrivé sur arXiv qu'en novembre 2025 ; ses auteurs viennent de Roboflow et de l'université Carnegie Mellon, et il a ensuite été publié à ICLR 2026. Il explique d'où vient cette série de tailles de modèles, à savoir la recherche d'architecture neuronale (neural architecture search, NAS) du titre. Roboflow exploite elle-même une plateforme d'entraînement de modèles et se trouve en concurrence directe avec Ultralytics, qui publie la série YOLO.\n\n## Définir le problème\n\n### Trop finement réglés sur COCO\n\nSelon les auteurs, les détecteurs spécialisés à classes fixes de ces dernières années ont été réglés sur COCO, de l'architecture à l'augmentation des données en passant par le calendrier du taux d'apprentissage. Sur un jeu de données dont le nombre d'objets par image, le nombre de classes et le volume diffèrent de COCO, ces choix ne conviennent plus forcément.\n\nYOLOv8 en est un exemple dans l'article. Selon les mesures des auteurs, en passant de N à M, YOLOv8 voit son AP sur COCO monter de 35,2 à 47,3 ; avec les mêmes tailles sur RF100-VL, elle ne monte que de 55,0 à 56,5, et reste à 56,5 même en passant à XL.\n\nRF100-VL est un benchmark constitué par ces mêmes auteurs en 2025. Il regroupe 100 jeux de données tirés de Roboflow Universe ; le modèle est affiné et évalué séparément sur chacun d'eux, puis on fait la moyenne des scores. Les auteurs s'en servent comme indicateur indirect du « transfert vers n'importe quel nouveau domaine ».\n\nUne autre voie passe par les modèles vision-langage à vocabulaire ouvert, comme GroundingDINO. Affinés sur les données cibles, ils obtiennent de très bons résultats, 62,3 AP sur RF100-VL, mais demandent 309,9 ms par image (GroundingDINO ne prend pas en charge TensorRT ; il s'agit de la latence sous PyTorch). Les auteurs notent aussi que l'affinage affaiblit sa capacité initiale à vocabulaire ouvert.\n\nLa recette d'entraînement porte elle aussi des hypothèses. Un calendrier cosinus du taux d'apprentissage suppose de connaître à l'avance le nombre total de pas d'entraînement, et l'augmentation des données présuppose l'apparence des données. Les auteurs prennent l'exemple d'un détecteur de piétons pour voiture autonome ; si l'entraînement utilise des retournements verticaux, le modèle risque de prendre aussi pour des piétons les reflets dans les flaques.\n\n### Une taille pour un seul matériel\n\nL'autre problème est la taille. Dans les familles de détecteurs existantes, par exemple D-FINE de N à X, chaque taille est conçue à la main et entraînée séparément. Si le matériel cible change, il ne reste qu'à choisir la taille existante la plus proche, ou à reconcevoir et réentraîner.\n\nLa NAS sert justement à trouver automatiquement différents compromis entre précision et latence. Les premières NAS sensibles au matériel devaient refaire la recherche et l'entraînement à chaque nouveau matériel ; en 2019, OFA (Once-for-All) a séparé entraînement et recherche, en entraînant dans un même réseau des milliers de sous-réseaux à poids partagés, parmi lesquels on choisit après coup selon les besoins. En détection d'objets, la NAS se limite le plus souvent à remplacer le backbone par un réseau trouvé par recherche, le reste du détecteur restant inchangé.\n\nCet article doit donc répondre à deux questions. Peut-on, avec un seul entraînement sur le jeu de données cible, obtenir toute une courbe précision-latence, puis y choisir un point selon le matériel ? Et comment mesurer la latence du point choisi pour pouvoir la comparer aux chiffres des autres ?\n\n## Résoudre le problème\n\n### La base, LW-DETR\n\nRF-DETR repose sur LW-DETR, proposé par Baidu en 2024. Celui-ci empile un encodeur ViT, un projecteur (projector) et un décodeur DETR très peu profond ; dans le ViT, l'attention par fenêtres alterne avec l'attention globale pour économiser du calcul.\n\n[![Architecture de RF-DETR. À gauche, l'image est découpée en patches, reçoit un encodage de position et entre dans le backbone ViT, composé de quatre blocs, chacun formé de deux couches d'attention par fenêtres et d'une couche d'attention globale ; les sorties des quatre blocs entrent dans le projecteur, passent par la Query Selection et sont additionnées aux embeddings de requête avant d'entrer dans le décodeur ; chaque couche du décodeur enchaîne auto-attention, cross-attention déformable et couche feed-forward, avec derrière les Decoder Group 1 à 13 empilés ; en haut à droite, la tête de détection et la tête de segmentation](/content/papers/assets/10f93bab733752bf97f8b3ed5c86569a2c4d85840b99b338a6443431fb506555.png)](/content/papers/assets/10f93bab733752bf97f8b3ed5c86569a2c4d85840b99b338a6443431fb506555.png)\n\n*Figure 2 de l'article, extraite de la [**page 4 du PDF v2**](https://arxiv.org/pdf/2511.09554v2#page=4), CC BY 4.0. À gauche le backbone ViT, au centre le décodeur, à droite la tête de segmentation, en haut les deux types de sortie.*\n\nPartons d'en bas à gauche. L'image est découpée en patches, reçoit un encodage de position et entre dans le backbone ViT. Sur la figure, le backbone compte quatre blocs ; chaque bloc applique d'abord deux couches d'attention par fenêtres, puis une couche d'attention globale. Les sorties des quatre blocs vont ensemble dans le projecteur, qui les met en forme en cartes de caractéristiques pour le décodeur.\n\nVient ensuite la Query Selection. Chaque position de la sortie du projecteur prédit d'abord ses propres scores de classe et une boîte candidate ; les 300 positions aux meilleurs scores deviennent le point de départ des requêtes du décodeur. C'est l'approche two-stage proposée par Deformable DETR.\n\nDans chaque couche du décodeur, les requêtes passent d'abord par une auto-attention entre elles, puis par une cross-attention déformable qui prélève quelques points autour de chaque boîte candidate sur la carte de caractéristiques, et enfin par un réseau feed-forward. La sortie de chaque couche est reliée à une tête de détection et a sa propre perte ; c'est sur ce point que repose le bouton de réduction du nombre de couches du décodeur, présenté plus loin.\n\nLes 13 décodeurs empilés à droite de la figure correspondent à Group DETR, repris de LW-DETR. À l'entraînement, on prépare 13 groupes de requêtes qui partagent les mêmes poids de décodeur ; chaque groupe fait son propre appariement un à un avec les annotations, si bien que chaque objet reçoit 13 positifs par itération. À l'inférence, un seul groupe est conservé, toujours sans NMS. Le code officiel utilise aussi 13 groupes par défaut.\n\nLa même architecture, augmentée d'une tête de segmentation légère, donne RF-DETR-Seg ; cette note ne traite que de la détection.\n\nRF-DETR apporte trois modifications principales à LW-DETR :\n\n- **Le backbone devient DINOv2**. LW-DETR utilisait CAEv2. DINOv2 est un ViT préentraîné de façon auto-supervisée par Meta ; les auteurs ont constaté qu'une initialisation avec ses poids améliore nettement la précision de détection sur les petits jeux de données. Le prix est la vitesse, car DINOv2 a 12 couches contre 10 pour CAEv2 ; la NAS se chargera ensuite de récupérer cette latence. Sur COCO, les tailles N à L utilisent ViT-S, et XL et 2XL ViT-B.\n- **LayerNorm dans le projecteur**. L'objectif est de pouvoir constituer de grands lots par accumulation de gradients, même sur des GPU grand public. Les statistiques de la BatchNorm ne voient que le petit lot réellement envoyé à chaque passe et deviennent inexactes avec l'accumulation de gradients.\n- **Une recette d'entraînement simplifiée**. Le taux d'apprentissage descend des 4e-4 de LW-DETR à 1e-4, sans calendrier du taux d'apprentissage ni warm-up. L'augmentation des données se limite au retournement horizontal et au recadrage aléatoire ; le redimensionnement multi-échelle s'applique désormais au lot entier à la fois, ce qui réduit les pixels de bourrage (padding).\n\n\n> [!TIP]\n> \n> Le décodeur de RF-DETR reprend l'appariement un à un de DETR et l'attention déformable de Deformable DETR, et son backbone est DINOv2 ; pour le contexte, vous pouvez consulter :\n> \n> - **[[20.05] DETR : un pionnier entre deux domaines](/blog/papers/object-detection/detr)**\n> - **[[20.10] Deformable DETR : une attention déformable](/blog/papers/object-detection/deformable-detr)**\n> - **[[23.04] DINOv2 : forger des caractéristiques visuelles généralistes](/blog/papers/contrastive-learning/dinov2)**\n\n\n### Cinq boutons\n\nUne fois la base fixée, les auteurs y ajoutent cinq boutons réglables. Chaque case de la figure porte une flèche, avec « plus rapide » à un bout et « plus précis » à l'autre :\n\n[![Cinq schémas de l'espace de recherche de la NAS ; a, la taille de patch, avec de petits patches 8×8 qui donnent plus de tokens et plus de précision, et de grands patches 32×32 plus rapides ; b, le nombre de couches du décodeur, moins de couches étant plus rapide et plus de couches plus précis ; c, l'abandon d'une partie des requêtes ; d, la résolution d'entrée ; e, le nombre de fenêtres, la grille de droite étant découpée en quatre fenêtres de couleurs différentes](/content/papers/assets/f0e8bf4f9ecad4cb2f090117a18034f54eab8bc3e901414f94864de103d3425a.png)](/content/papers/assets/f0e8bf4f9ecad4cb2f090117a18034f54eab8bc3e901414f94864de103d3425a.png)\n\n*Figure 3 de l'article, extraite de la [**page 5 du PDF v2**](https://arxiv.org/pdf/2511.09554v2#page=5), CC BY 4.0. Les cinq boutons sont la taille de patch, le nombre de couches du décodeur, le nombre de requêtes, la résolution et le nombre de fenêtres.*\n\n- **Taille de patch** (a). Plus le patch est petit, plus il y a de tokens, et plus le modèle est précis, mais aussi lent. À l'entraînement, la méthode de FlexiViT redimensionne un même jeu de poids d'embedding de patch à différentes tailles.\n- **Nombre de couches du décodeur** (b). Chaque couche a sa propre perte ; à l'inférence, on peut retirer autant de couches qu'on veut en partant de la fin. On peut même toutes les retirer ; il ne reste alors que les 300 boîtes candidates choisies par la Query Selection, et le modèle devient un détecteur à une étape sans NMS.\n- **Nombre de requêtes** (c). Les requêtes sont triées selon le score donné par la Query Selection ; à l'inférence, on abandonne simplement celles de plus faible score. Le nombre de requêtes est aussi le nombre maximal d'objets que le modèle peut produire par image.\n- **Résolution** (d). Plus la résolution est élevée, plus les petits objets sont faciles à reconnaître, et plus le modèle est lent. L'encodage de position est d'abord préparé sous forme d'une table complète selon « résolution maximale ÷ plus petit patch », et les autres combinaisons sont interpolées à partir de cette table.\n- **Nombre de fenêtres** (e). Avec l'attention par fenêtres, les tokens ne se voient qu'au sein d'une même fenêtre. Plus on découpe de fenêtres, plus on économise de calcul, et plus l'information a du mal à circuler d'une fenêtre à l'autre.\n\nÀ l'entraînement, chaque pas tire uniformément une configuration dans la grille et l'utilise pour une passe avant et une mise à jour des gradients. La grille d'entraînement de l'annexe A couvre les résolutions de 320 à 960 par pas de 64, les patches de 8, 10, 12, 16, 20, 24 et 32, et 1, 2 ou 4 fenêtres. Le nombre de couches du décodeur et le nombre de requêtes sont fixés à l'entraînement, à 6 couches et 300 requêtes, et ne sont réduits qu'à l'inférence.\n\nLes auteurs comparent cet entraînement à la vision du dropout comme ensemble ; chaque pas ne met à jour qu'un sous-réseau, et des milliers de sous-réseaux apprennent ensemble. Ils constatent aussi que changer d'architecture au hasard a en soi un effet régularisant, d'où le nom d'« augmentation d'architecture » (architecture augmentation). Les ablations, plus loin, en apportent la preuve.\n\n\n> [!TIP]\n> \n> Pour voir comment un même jeu de poids s'adapte à différentes tailles de patch, vous pouvez consulter notre note sur FlexiViT :\n> \n> - **[[22.12] FlexiViT : la liberté des tailles de patches](/blog/papers/vision-transformers/flexivit)**\n\n\n### Combien de tokens voit chaque taille\n\nLa Table 7 de l'annexe liste les configurations finalement retenues sur COCO. Calculons combien de tokens chacune envoie réellement dans le ViT.\n\nLa Table 7 indique 2 fenêtres. Le code officiel interprète ce nombre comme le nombre de découpes par côté, ce qui donne en réalité 2×2 = 4 fenêtres, comme les quatre cases dessinées dans la Figure 3(e).\n\n```python\n# Table 7 : configurations de Pareto pour la détection sur COCO (résolution, patch, fenêtres par côté)\nconfigs = {\n    \"N\": (384, 16, 2), \"S\": (512, 16, 2), \"M\": (576, 16, 2),\n    \"L\": (704, 16, 2), \"XL\": (700, 20, 1), \"2XL\": (880, 20, 2),\n}\nfor name, (res, patch, win) in configs.items():\n    side = res // patch\n    tokens = side * side\n    print(f\"{name:>3}: {res}/{patch} = {side:>2}, soit {tokens:>4} tokens, \"\n          f\"en {win * win} fenêtre(s) de {tokens // (win * win):>4} tokens\")\n\n# Annexe L : résolution fixée à 640, seul le patch change, pour un nombre de cases par côté proche\nfor name, patch in [(\"N\", 27), (\"S\", 21), (\"M\", 18)]:\n    print(f\"640/{patch} = {640 / patch:.1f} (contre {configs[name][0] // configs[name][1]} pour {name})\")\n\n# Encodage de position préparé selon « résolution maximale ÷ plus petit patch » (grille d'entraînement de l'annexe A)\nprint(\"Grille de l'encodage de position :\", 960 // 8, \"×\", 960 // 8)\n# Annexe A : nombre de combinaisons énumérées à l'inférence\nprint(\"Combinaisons :\", 11 * 7 * 7 * 3 * 4)\n```\n\n```text\n  N: 384/16 = 24, soit  576 tokens, en 4 fenêtre(s) de  144 tokens\n  S: 512/16 = 32, soit 1024 tokens, en 4 fenêtre(s) de  256 tokens\n  M: 576/16 = 36, soit 1296 tokens, en 4 fenêtre(s) de  324 tokens\n  L: 704/16 = 44, soit 1936 tokens, en 4 fenêtre(s) de  484 tokens\n XL: 700/20 = 35, soit 1225 tokens, en 1 fenêtre(s) de 1225 tokens\n2XL: 880/20 = 44, soit 1936 tokens, en 4 fenêtre(s) de  484 tokens\n640/27 = 23.7 (contre 24 pour N)\n640/21 = 30.5 (contre 32 pour S)\n640/18 = 35.6 (contre 36 pour M)\nGrille de l'encodage de position : 120 × 120\nCombinaisons : 6468\n```\n\nRegardons d'abord les six premières lignes. Dans l'article, N à L sont quatre points sur la courbe d'un même entraînement DINOv2-S ; leur patch est toujours de 16, et ils diffèrent surtout par la résolution, qui passe de 24 à 44 cases par côté, le décodeur passant aussi de 2 à 4 couches. Ces tailles ont donc des nombres de paramètres très proches, 30,5 M pour N et 33,7 M pour M, alors que la latence passe de 2,3 à 4,4 ms (Table 2). RF-DETR reprend l'habitude de LW-DETR de définir les tailles par la latence, et non par le nombre de paramètres.\n\nL et 2XL ont autant de tokens, 1 936 chacun ; 2XL passe au backbone DINOv2-B, avec un patch de 20 et une résolution de 880. XL n'a qu'une fenêtre, ce qui revient à une attention globale dans toutes les couches.\n\nDécouper plus de fenêtres n'est pas toujours mieux. DINOv2 s'appuie sur le token CLS pendant son préentraînement, et RF-DETR en fait une copie par fenêtre ; plus il y a de fenêtres, plus il y a de copies, ce qui finit par peser sur la vitesse. L'annexe L indique que la plupart des configurations retenues s'arrêtent à 2 fenêtres par côté, contre 4 pour LW-DETR.\n\nLes trois lignes du milieu reprennent une expérience de l'annexe L. Les auteurs ont constaté que la précision suit le « nombre de cases par côté », et que ni la résolution ni le patch, pris seuls, ne permettent de la prédire. Ils ont donc fixé la résolution à 640 et utilisé des patches de 27, 21 et 18 pour approcher le nombre de cases de N, S et M ; les résultats sont presque identiques à ceux des configurations d'origine, alors que les patches de 27 et de 18 n'ont jamais été vus à l'entraînement.\n\nLa ligne de l'encodage de position est déduite de la grille d'entraînement de l'annexe A ; avec une résolution maximale de 960 et un plus petit patch de 8, il faut préparer 120×120 positions. La dernière ligne donne le nombre de combinaisons à énumérer à l'inférence, avec 11 résolutions, 7 patches, 7 profondeurs de décodeur (0 à 6 couches), 3 nombres de fenêtres et 4 nombres de requêtes (50, 100, 200, 300), soit 6 468 au total.\n\n### Choisir après l'entraînement\n\nUne fois l'entraînement terminé sur le jeu de données cible, les auteurs font tourner les 6 468 configurations sur l'ensemble de validation, mesurent précision et latence, et gardent le front de Pareto, c'est-à-dire les points les plus précis à latence égale. Pour déployer, on fixe une latence maximale et on prend le point le plus précis de la courbe. Pour RF100-VL, les auteurs fixent d'abord une latence cible pour chaque taille de N à 2XL, puis cherchent sur chaque jeu de données une configuration dont la latence est à moins de 10 % de la cible.\n\nL'entraînement NAS prend environ 2 à 4 fois le temps d'un entraînement classique à taille unique, selon le jeu de données ; pour la recherche elle-même, les auteurs estiment le coût à environ 10 000 heures GPU (200 T4 pendant 48 heures). En échange, toutes les tailles proviennent d'un seul entraînement, alors que sans NAS, chaque taille supplémentaire demande un nouvel entraînement.\n\nUne fois la configuration choisie, on peut l'affiner une fois de plus. Sur COCO, cela n'aide presque pas, au plus +0,4 AP selon la taille (Table 15) ; sur RF100-VL, le gain est un peu plus grand, par exemple de 57,8 à 58,6 pour N. Les auteurs l'expliquent par le fait que 100 époques sur de petits jeux de données ne suffisent pas à faire converger l'augmentation d'architecture.\n\n## Discussion\n\n### D'abord étalonner la règle qui mesure la latence\n\nComparer des latences est délicat par nature. Chaque nouvel article remesure les modèles précédents sur sa propre machine, et les chiffres concordent rarement. Les auteurs en donnent plusieurs raisons au §4 :\n\n1. **La latence de YOLO exclut souvent la NMS**. La comparer à celle de détecteurs de bout en bout sans NMS n'est pas équitable. RT-DETR l'avait déjà signalé en 2023.\n2. **Les modèles de segmentation YOLO s'arrêtent aux prototypes**. On mesure le temps d'un produit intermédiaire, qui n'est pas encore assemblé en masques directement utilisables pour chaque objet.\n3. **Le GPU réduit sa fréquence**. En inférence continue, le GPU chauffe, son horloge baisse et la latence mesurée dérive. Les auteurs insèrent une pause de 200 ms entre deux passes avant.\n4. **Latence en FP16, précision en FP32**. Beaucoup d'articles mesurent la vitesse sur un modèle FP16 et la précision sur un modèle FP32. Une quantification directe fait parfois chuter lourdement la précision ; D-FINE converti directement en FP16 tombe à 0,5 AP, et ne retrouve son niveau qu'une fois exporté avec ONNX opset 17. Les auteurs défendent l'idée de mesurer précision et latence sur le même fichier de modèle.\n5. **La NMS de validation peut différer de celle d'inférence**. Les auteurs ne parviennent pas à reproduire sous TensorRT les mAP publiées pour YOLOv8 et YOLO11, et l'attribuent au fait que ces modèles sont validés avec une NMS multi-classe, où une boîte peut conserver plusieurs classes à la fois, alors que l'inférence réelle n'utilise qu'une NMS mono-classe.\n\nDans cette méthode, YOLO est toujours suivi de la NMS, avec un seuil de confiance de 0,01 ; le matériel est une T4, avec TensorRT 10.4 et CUDA 12.4. La Table 1 met côte à côte, pour plusieurs modèles de taille M, les chiffres publiés dans leurs articles d'origine et ceux de cette méthode :\n\n| Modèle | AP publiée | Latence publiée | AP FP32 | Latence FP32 | AP FP16 | Latence FP16 |\n| --- | ---: | ---: | ---: | ---: | ---: | ---: |\n| YOLOv8-M | 50,2 | 5,86 | 49,3 | 14,8 | 47,3 | 5,4 |\n| YOLO11-M | 51,5 | 4,7 | 49,7 | 18,7 | 48,3 | 5,2 |\n| RT-DETR-R18 | 49,0 | 4,61 | 49,0 | 12,2 | 49,0 | 4,4 |\n| LW-DETR-M | 52,5 | 5,6 | 52,6 | 26,8 | 52,6 | 4,4 |\n| D-FINE-M | 55,1 | 5,62 | 55,1 | 13,9 | 55,0 | 5,4 |\n| RF-DETR-M | – | – | 54,8 | 20,5 | 54,7 | 4,4 |\n\n*Tableau : Table 1 de l'article, latences en ms. Les quatre dernières colonnes utilisent la méthode avec une pause de 200 ms entre deux passes avant ; le FP16 de D-FINE est mesuré après correction de l'export.*\n\nEn passant de FP32 à FP16, les deux YOLO perdent 2,0 et 1,4 AP, les quatre modèles de type DETR au plus 0,1. Les chiffres publiés s'écartent aussi des mesures FP32 des auteurs, de 0,9 pour YOLOv8-M et de 1,8 pour YOLO11-M. Les latences de la colonne FP32 vont de 12,2 à 26,8 ms, soit 2,6 à 6,1 fois celles en FP16.\n\nEn septembre 2025, avant même la sortie de l'article, un utilisateur a ouvert une issue sur le GitHub de RF-DETR pour signaler que les chiffres de YOLO11 qui y figuraient étaient erronés. Le premier auteur a répondu qu'ils avaient été réellement mesurés avec la NMS fusionnée de TensorRT, en FP16 et avec pycocotools ; Ultralytics valide avec une NMS multi-étiquette, ce qui, d'après leur expérience, gonfle la mAP COCO d'environ 1, et publie des vitesses FP16 sans NMS. [rf-detr #350](https://github.com/roboflow/rf-detr/issues/350) Le §4 de l'article transforme ce même argument en méthode de mesure.\n\nQuel est l'effet de cette pause de 200 ms ? La Table 20 compare les mêmes modèles M ; l'écart de latence entre aucune pause et une pause de 200 ms va de 0 à 0,3 ms, et une pause plus longue ne la change pas de plus de 0,1 ms. Les auteurs reconnaissent aussi que cette méthode mesure la latence d'une image isolée sur un GPU qui n'a pas surchauffé, et qu'elle n'est pas faite pour mesurer un débit soutenu ; si votre service fait de l'inférence continue, les chiffres du tableau correspondent plutôt à un GPU encore frais. Chaque compilation TensorRT peut aussi varier de 0,1 ms, d'où des latences données à une seule décimale dans l'article.\n\nLe choix de la méthode influe aussi sur le classement. Les auteurs activent systématiquement les CUDA graphs dans TensorRT, ce qui met d'avance en file les kernels du GPU, sans que le CPU ait à les lancer un par un. Cela aide RT-DETR, LW-DETR et RF-DETR, mais pas D-FINE ; les auteurs écrivent eux-mêmes qu'avec cette option, LW-DETR et D-FINE se retrouvent sur la même courbe précision-latence.\n\nLes seuils de la NMS changent aussi les chiffres. Avec cette méthode, YOLOv8-N a une latence totale de 2,1 ms NMS comprise, pour 35,2 AP (Table 2). Le même YOLOv8-N affiche 6,16 ms de latence totale avec la méthode de l'article de YOLOv10, dont seulement 1,77 ms pour le modèle lui-même ; YOLOv10 utilise le réglage NMS de validation de chaque modèle, qui laisse bien plus de boîtes candidates. Devant un chiffre du type « la NMS coûte tant de millisecondes », cherchez d'abord où sont fixés les seuils.\n\n\n> [!TIP]\n> \n> Pour la méthode de bout en bout qui inclut la NMS dans la latence, et les chiffres du même YOLOv8-N selon la méthode de mesure, vous pouvez consulter :\n> \n> - **[[23.04] RT-DETR : le chrono, NMS comprise](/blog/papers/object-detection/rt-detr)**\n> - **[[24.05] YOLOv10 : adieu, NMS](/blog/papers/object-detection/yolov10)**\n\n\n### COCO\n\nCommençons par le coin supérieur gauche de la Figure 1 :\n\n[![Courbes précision-latence de la détection d'objets sur COCO ; en abscisse la latence sur T4, d'environ 1,5 à 20 ms, en ordonnée l'AP50:95, de 35 à 60 ; RF-DETR (DINOv2-S) en violet et RF-DETR (DINOv2-B) en rose sont des courbes continues, tandis que YOLOv8, YOLO11, D-FINE, RT-DETR et LW-DETR sont des lignes brisées reliant des marqueurs N à XL](/content/papers/assets/5d7dc32c6480e109cfe21fc73d7a8f9fbc1a7218232165cc360266eb0d5c9849.png)](/content/papers/assets/5d7dc32c6480e109cfe21fc73d7a8f9fbc1a7218232165cc360266eb0d5c9849.png)\n\n*Figure 1 de l'article, sous-figure en haut à gauche, extraite de la [**page 3 du PDF v2**](https://arxiv.org/pdf/2511.09554v2#page=3), CC BY 4.0. En abscisse la latence (ms), en ordonnée l'AP50:95 sur COCO.*\n\nLes autres familles sont des lignes brisées reliant quelques tailles, alors que les deux tracés de RF-DETR sont des courbes continues. La violette correspond à un seul entraînement avec le backbone DINOv2-S, la rose à un seul entraînement avec DINOv2-B ; chaque point d'une courbe utilise les mêmes poids avec une autre configuration.\n\nÀ l'extrémité basse latence, la courbe violette passe au-dessus de toutes les familles. Plus à droite, vers L, le D-FINE brun la rattrape, puis la dépasse nettement en XL ; la courbe rose ne franchit 60 que vers 17 ms.\n\nComparons quelques lignes :\n\n| Modèle | Paramètres | Latence (ms) | AP |\n| --- | ---: | ---: | ---: |\n| YOLOv8-N | 3,2 M | 2,1 | 35,2 |\n| LW-DETR-T | 12,1 M | 1,9 | 42,9 |\n| D-FINE-N | 3,8 M | 2,1 | 42,7 |\n| RF-DETR-N | 30,5 M | 2,3 | 48,0 |\n| YOLOv8-M | 25,9 M | 5,4 | 47,3 |\n| LW-DETR-M | 28,2 M | 4,4 | 52,6 |\n| D-FINE-M | 19,2 M | 5,4 | 55,0 |\n| RF-DETR-M | 33,7 M | 4,4 | 54,7 |\n| D-FINE-XL | 62 M | 11,5 | 59,3 |\n| RF-DETR-XL | 126,4 M | 11,5 | 58,6 |\n| RF-DETR-2XL | 126,9 M | 17,2 | 60,1 |\n\n*Tableau : d'après les Tables 2 et 12 de l'article, toutes deux mesurées par les auteurs avec la même méthode.*\n\n1. **C'est en N que l'écart est le plus grand**. RF-DETR-N dépasse D-FINE-N de 5,3 AP pour 0,2 ms de latence en plus ; ses 48,0 dépassent aussi les 47,3 de YOLOv8-M, avec moins de la moitié de la latence.\n2. **À partir de M, les résultats sont partagés**. D-FINE-M a 0,3 AP de plus que RF-DETR-M, mais il est plus lent de 1,0 ms ; en XL, les deux sont à 11,5 ms, et c'est D-FINE qui a 0,7 de plus.\n3. **2XL dépasse 60**. 60,1 AP à 17,2 ms, soit 0,8 de plus que D-FINE-XL pour 5,7 ms de latence en plus. Selon les auteurs, c'est à leur connaissance le premier détecteur temps réel à dépasser 60 AP sur COCO.\n\nOutre DINOv2, RF-DETR a aussi été préentraîné sur Objects365 ; c'est aussi le cas de D-FINE de S à XL, mais pas de D-FINE-N, comme les auteurs le précisent eux-mêmes en annexe. RF-DETR a en outre beaucoup plus de paramètres, 30,5 M pour N contre 3,8 M pour D-FINE-N, soit huit fois plus, ce qui est à prendre en compte sur les appareils limités en mémoire ou en stockage. Le « temps réel » de l'article désigne moins de 40 ms sur T4 ; l'annexe présente aussi une version Max à 61,8 AP, mais qui demande 98 ms, hors de cette plage.\n\nDans son article d'annonce de mars 2025, Roboflow présentait déjà RF-DETR comme le premier modèle temps réel à dépasser 60 mAP, en se fondant alors sur les 60,5 de l'ancien RF-DETR-large en résolution 728 ; dans l'article, ce sont désormais les 60,1 du 2XL qui soutiennent cette affirmation.\n\n### RF100-VL\n\nPassons à RF100-VL, avec là encore quelques lignes :\n\n| Modèle | Latence (ms) | AP | Réaffinage après NAS |\n| --- | ---: | ---: | ---: |\n| YOLOv8-N | 2,6 | 55,0 | – |\n| YOLO11-M | 5,1 | 57,0 | – |\n| D-FINE-N | 2,0 | 58,2 | – |\n| RF-DETR-N | 2,5 | 57,8 | 58,6 |\n| D-FINE-M | 5,6 | 60,6 | – |\n| RF-DETR-M | 4,6 | 61,7 | 62,0 |\n| GroundingDINO-T (affiné) | 309,9 | 62,3 | – |\n| RF-DETR-2XL | 15,6 | 63,3 | 63,5 |\n\n*Tableau : d'après la Table 4 de l'article, moyenne sur les 100 jeux de données. La latence de GroundingDINO est mesurée sous PyTorch, les autres sous TensorRT.*\n\nCôté YOLO, quelle que soit la taille, on plafonne entre 55 et 57. À la plus petite taille, les 58,2 de D-FINE-N dépassent même RF-DETR-N sans réaffinage ; en M, RF-DETR mène de 1,1 AP avec 1,0 ms de latence en moins. Le 2XL dépasse GroundingDINO affiné de 1,0 AP (1,2 après réaffinage), avec environ un vingtième de sa latence, mais les deux n'utilisent pas le même moteur d'inférence.\n\nL'écart entre YOLO et les modèles de type DETR se concentre surtout sur les petits objets. L'AP_S de YOLO, toutes tailles confondues, ne va que de 4,7 à 7,3, alors que les modèles de type DETR dépassent tous 30 ; l'article n'en analyse pas la cause. Les auteurs précisent aussi que YOLO garde ici le seuil de confiance de 0,01, qui ne convient pas forcément à chaque jeu de données ; les chiffres de latence ne reflètent donc peut-être pas YOLO au meilleur de sa forme.\n\nL'annexe I contient aussi une expérience où les configurations choisies sur COCO sont reprises telles quelles sur RF100-VL, sans nouvelle recherche sur ce jeu de données. N, S et M obtiennent 57,7 ; 60,2 et 61,2, contre 57,8 ; 60,9 et 61,7 pour les configurations recherchées sur RF100-VL, soit 0,1 à 0,7 AP d'écart ; pour L, la configuration fixe est même meilleure de 0,2, au prix de 0,6 ms de latence en plus. Les configurations fixes dépassent déjà toutes LW-DETR de même taille.\n\n### Ablations : d'où viennent les 2 AP de plus\n\nLa Table 5 part de LW-DETR-M et le transforme pas à pas en RF-DETR-M :\n\n| Étape | Latence (ms) | AP |\n| --- | ---: | ---: |\n| LW-DETR-M | 4,4 | 52,6 |\n| + hyperparamètres plus doux | 4,4 | 51,6 |\n| + backbone DINOv2 | 4,7 | 53,6 |\n| + préentraînement Objects365 prolongé | 4,7 | 54,3 |\n| + NAS à poids partagés (configuration inchangée) | 4,7 | 54,6 |\n|  patch à 16, résolution à 640 | 4,7 | 54,4 |\n|  résolution réduite à 576 | 4,0 | 53,6 |\n|  fenêtres par côté 4 → 2 | 4,3 | 54,3 |\n|  décodeur de 3 → 4 couches | 4,4 | 54,6 |\n\n*Tableau : d'après la Table 5 de l'article, COCO.*\n\nAvec des hyperparamètres plus doux (taux d'apprentissage plus faible, LayerNorm, etc.), l'AP perd d'abord 1,0 ; selon les auteurs, la LayerNorm coûte un peu de précision, mais sans elle, impossible d'entraîner sur du matériel grand public. Avec DINOv2, l'AP remonte de 2,0, pour 0,3 ms de latence en plus.\n\nLa configuration de la cinquième étape utilise un patch de 14 et une résolution de 560, et le patch 14 ne figure même pas dans la grille d'entraînement. Le simple fait d'entraîner le modèle avec la NAS fait gagner 0,3 AP à cette même configuration ; c'est la preuve de l'augmentation d'architecture évoquée plus haut.\n\nLes quatre dernières étapes tournent les boutons pour ramener la latence à 4,4 ms. On finit à 54,6 AP, soit 2,0 de plus que LW-DETR-M à latence égale.\n\nLa comparaison des backbones figure dans la Table 6. À réglages égaux, DINOv2 ViT-S obtient 54,3, CAEv2 52,3 et SigLIPv2 50,4 ; le Hiera-S de SAM2 atteint 53,6, mais avec 11,2 ms de latence, plus de deux fois les 4,7 ms de DINOv2. (SigLIPv2 et SAM2 donnent de très mauvais résultats une fois convertis en FP16 ; ces deux lignes reportent la précision FP32, qui correspond à leur limite haute.)\n\n## Conclusion\n\nRF-DETR remplace le backbone de LW-DETR par DINOv2, s'entraîne une seule fois sur le jeu de données cible avec une NAS à poids partagés, puis énumère plus de six mille configurations sur l'ensemble de validation pour choisir un point selon la latence. Voici ce qu'on peut retenir de l'article :\n\n1. **La taille peut se choisir après coup**. Un seul entraînement donne toute une courbe précision-latence, et chaque matériel y choisit son point. En contrepartie, l'entraînement prend 2 à 4 fois plus de temps, et la recherche demande en plus de l'ordre de dix mille heures GPU.\n2. **Regarder un autre benchmark que COCO**. Sur COCO, YOLO progresse avec la taille, mais sur RF100-VL il ne bouge presque plus ; le classement entre D-FINE et RF-DETR s'inverse aussi selon le jeu de données. RF100-VL reste toutefois un benchmark constitué par les auteurs eux-mêmes.\n3. **Mesurer la latence en précisant les conditions**. NMS comptée ou non, seuils, FP16 ou FP32, GPU refroidi ou non ; si un seul de ces points diffère, les chiffres des tableaux ne sont plus directement comparables.\n\nLe code de la NAS n'est pas publié ; dans une issue de décembre 2025, le premier auteur explique que le code GitHub sert à affiner les configurations fixes trouvées par la NAS, et que lancer la NAS sur ses propres données passe par la plateforme de Roboflow. [rf-detr #483](https://github.com/roboflow/rf-detr/issues/483) D'après les chiffres de l'annexe I, les configurations fixes de COCO appliquées à RF100-VL restent à 0,7 AP au plus des configurations recherchées à nouveau, sans réaffinage. Côté licences, les modèles de détection N à L sont sous Apache 2.0, alors que ceux de taille XL et 2XL relèvent de la PML 1.0 propre à Roboflow, et un auto-hébergement commercial est payant. [rf-detr README](https://github.com/roboflow/rf-detr)\n\nLe nombre de requêtes ne peut que diminuer ; son plafond est celui de l'entraînement, 300. Pour des scènes de plusieurs centaines d'objets par image, le premier auteur conseille de découper les grandes images en tuiles avant de les envoyer au modèle. [rf-detr #350](https://github.com/roboflow/rf-detr/issues/350) Par ailleurs, le post-traitement officiel aplatit les scores « requête × classe » et en garde les 300 meilleurs, si bien qu'une même boîte peut apparaître avec deux classes. Des utilisateurs ont signalé des boîtes qui se chevauchent ; le premier auteur a répondu qu'avec assez de données, le modèle devrait apprendre de lui-même à les éviter, tandis qu'un ingénieur de Roboflow a conseillé d'ajouter directement une NMS en sortie. [rf-detr #187](https://github.com/roboflow/rf-detr/issues/187)\n\nLa prochaine fois qu'un détecteur se dira plus rapide que YOLO, allez d'abord voir la section où il mesure sa latence ; regardez les seuils de la NMS et vérifiez si la vitesse et la précision sont mesurées sur le même fichier de modèle. Pour voir comment le côté YOLO traite la NMS, vous pouvez enchaîner avec [YOLO26](/blog/papers/object-detection/yolo26) d'Ultralytics.\n","imageSizes":{"/content/papers/assets/10f93bab733752bf97f8b3ed5c86569a2c4d85840b99b338a6443431fb506555.png":{"width":1080,"height":775},"/content/papers/assets/f0e8bf4f9ecad4cb2f090117a18034f54eab8bc3e901414f94864de103d3425a.png":{"width":1005,"height":653},"/content/papers/assets/5d7dc32c6480e109cfe21fc73d7a8f9fbc1a7218232165cc360266eb0d5c9849.png":{"width":788,"height":555}}}