{"notes":[{"id":"classic-cnns/rdnet","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"RDNet","subtitle":"Concaténer plutôt qu'additionner","author":"Z. Yuan","paperDate":"2024-03-28","publishedOn":"2026-01-14","world":"external/rdnet","paperTitle":"DenseNets Reloaded: Paradigm Shift Beyond ResNets and ViTs","paperUrl":"https://arxiv.org/abs/2403.19588","bibliography":{"title":"DenseNets Reloaded: Paradigm Shift Beyond ResNets and ViTs","authors":["Donghyun Kim","Byeongho Heo","Dongyoon Han"],"url":"https://arxiv.org/abs/2403.19588","pdfUrl":"https://arxiv.org/pdf/2403.19588v2","codeUrl":"https://github.com/naver-ai/rdnet","preprint":{"id":"2403.19588","submittedOn":"2024-03-28","url":"https://arxiv.org/abs/2403.19588"},"publication":{"venue":"ECCV","year":2024,"kind":"conference","url":"https://doi.org/10.1007/978-3-031-72646-0_23"},"citation":"@misc{classiccnnsrdnet2024,\n  title = {{DenseNets Reloaded: Paradigm Shift Beyond ResNets and ViTs}},\n  author = {Donghyun Kim and Byeongho Heo and Dongyoon Han},\n  year = {2024},\n  eprint = {2403.19588},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2403.19588}\n}\n","citationPath":"/content/papers/citations/classic-cnns/rdnet.0ac4484543c0.bib"},"thumbnail":{"src":"/content/papers/assets/47b1a145d10885d762e8f5476e49d96dc1e35fdc1e3227a66162ec1bf6870710.png","width":1230,"height":615},"locale":"fr","path":"/content/papers/fr/classic-cnns/rdnet.94cf45c0b65f.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"addition-et-concaténation","text":"Addition et concaténation","depth":3},{"id":"tirer-dabord-quinze-mille-réseaux-au-hasard","text":"Tirer d'abord quinze mille réseaux au hasard","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"transformer-progressivement-densenet-201","text":"Transformer progressivement DenseNet-201","depth":3},{"id":"suivre-les-canaux","text":"Suivre les canaux","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"imagenet","text":"ImageNet","depth":3},{"id":"tâches-en-aval","text":"Tâches en aval","depth":3},{"id":"stochastic-depth-aide-aussi","text":"Stochastic depth aide aussi","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/densenet","relation":"referenced","topic":""},{"id":"classic-cnns/cspnet","relation":"referenced","topic":""},{"id":"classic-cnns/regnet","relation":"referenced","topic":""}]},{"id":"classic-cnns/densenet","category":"classic-cnns","legacyPath":"classic-cnns/1608-densenet","legacySlug":"1608-densenet","legacyPaths":[],"title":"DenseNet","subtitle":"Tout relier","author":"Z. Yuan","paperDate":"2016-08-25","publishedOn":"2024-07-02","paperTitle":"Densely Connected Convolutional Networks","paperUrl":"https://arxiv.org/abs/1608.06993","bibliography":{"title":"Densely Connected Convolutional Networks","authors":["Gao Huang","Zhuang Liu","Laurens van der Maaten","Kilian Q. Weinberger"],"url":"https://arxiv.org/abs/1608.06993","pdfUrl":"https://arxiv.org/pdf/1608.06993","codeUrl":null,"preprint":{"id":"1608.06993","submittedOn":"2016-08-25","url":"https://arxiv.org/abs/1608.06993"},"publication":{"venue":"CVPR","year":2017,"kind":"conference","url":"https://arxiv.org/abs/1608.06993"},"citation":"@misc{classiccnnsdensenet2016,\n  title = {{Densely Connected Convolutional Networks}},\n  author = {Gao Huang and Zhuang Liu and Laurens van der Maaten and Kilian Q. Weinberger},\n  year = {2016},\n  eprint = {1608.06993},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/1608.06993}\n}\n","citationPath":"/content/papers/citations/classic-cnns/densenet.6f28153b67f7.bib"},"thumbnail":{"src":"/content/papers/assets/4f073a0fd1fc5b7415ca19c48934d180f9043fddc08301819a50ceb1b0ebfc69.jpg","width":1184,"height":828},"locale":"fr","path":"/content/papers/fr/classic-cnns/densenet.85e3233664cd.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":"architecture-du-réseau","text":"Architecture du réseau","depth":3},{"id":"pooling-moyen","text":"Pooling moyen","depth":3},{"id":"taux-de-croissance","text":"Taux de croissance","depth":3},{"id":"couches-bottleneck","text":"Couches bottleneck","depth":3},{"id":"compression","text":"Compression","depth":3},{"id":"détails-de-mise-en-œuvre","text":"Détails de mise en œuvre","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"résultats-expérimentaux","text":"Résultats expérimentaux","depth":3},{"id":"modèles-compacts","text":"Modèles compacts","depth":3},{"id":"réutilisation-des-caractéristiques","text":"Réutilisation des caractéristiques","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/resnet","relation":"background","topic":"Entraîner des réseaux convolutifs plus profonds"}]},{"id":"classic-cnns/cspnet","category":"classic-cnns","legacyPath":"classic-cnns/1911-cspnet","legacySlug":"1911-cspnet","legacyPaths":[],"title":"CSPNet","subtitle":"Un module moitié-moitié-moitié","author":"Z. Yuan","paperDate":"2019-11-27","publishedOn":"2024-09-29","paperTitle":"CSPNet: A New Backbone that can Enhance Learning Capability of CNN","paperUrl":"https://arxiv.org/abs/1911.11929","bibliography":{"title":"CSPNet: A New Backbone that can Enhance Learning Capability of CNN","authors":["Chien-Yao Wang","Hong-Yuan Mark Liao","I-Hau Yeh","Yueh-Hua Wu","Ping-Yang Chen","Jun-Wei Hsieh"],"url":"https://arxiv.org/abs/1911.11929","pdfUrl":"https://arxiv.org/pdf/1911.11929","codeUrl":null,"preprint":{"id":"1911.11929","submittedOn":"2019-11-27","url":"https://arxiv.org/abs/1911.11929"},"publication":{"venue":"CVPR Workshops","year":2020,"kind":"workshop","url":"https://doi.org/10.1109/cvprw50498.2020.00203"},"citation":"@misc{classiccnnscspnet2019,\n  title = {{CSPNet: A New Backbone that can Enhance Learning Capability of CNN}},\n  author = {Chien-Yao Wang and Hong-Yuan Mark Liao and I-Hau Yeh and Yueh-Hua Wu and Ping-Yang Chen and Jun-Wei Hsieh},\n  year = {2019},\n  eprint = {1911.11929},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/1911.11929}\n}\n","citationPath":"/content/papers/citations/classic-cnns/cspnet.2914b9492a0c.bib"},"thumbnail":{"src":"/content/papers/assets/2602af8b5f92cba820e545c84abd94943cab1fe2631cf83834972b54b374ed20.jpg","width":2809,"height":1911},"locale":"fr","path":"/content/papers/fr/classic-cnns/cspnet.55709dafd5bf.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":"architecture-du-modèle","text":"Architecture du modèle","depth":3},{"id":"couche-de-transition","text":"Couche de transition","depth":3},{"id":"exact-fusion-model","text":"Exact Fusion Model","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"efficacité-de-larchitecture-csp","text":"Efficacité de l'architecture CSP","depth":3},{"id":"efficacité-de-larchitecture-efm","text":"Efficacité de l'architecture EFM","depth":3},{"id":"performances-sur-imagenet","text":"Performances sur ImageNet","depth":3},{"id":"performances-sur-ms-coco","text":"Performances sur MS COCO","depth":3},{"id":"vitesse-dinférence","text":"Vitesse d'inférence","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/inception-v1","relation":"comparison","topic":"Branches, convolutions groupées et réutilisation des caractéristiques"},{"id":"classic-cnns/resnext","relation":"comparison","topic":"Branches, convolutions groupées et réutilisation des caractéristiques"}]},{"id":"classic-cnns/regnet","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"RegNet","subtitle":"Les bonnes architectures se ressemblent-elles toutes ?","author":"Z. Yuan","paperDate":"2020-03-30","publishedOn":"2024-12-16","world":"external/regnet","paperTitle":"Designing Network Design Spaces","paperUrl":"https://arxiv.org/abs/2003.13678","bibliography":{"title":"Designing Network Design Spaces","authors":["Ilija Radosavovic","Raj Prateek Kosaraju","Ross Girshick","Kaiming He","Piotr Dollár"],"url":"https://arxiv.org/abs/2003.13678","pdfUrl":"https://arxiv.org/pdf/2003.13678v1","codeUrl":null,"preprint":{"id":"2003.13678","submittedOn":"2020-03-30","url":"https://arxiv.org/abs/2003.13678"},"publication":{"venue":"CVPR","year":2020,"kind":"conference","url":"https://openaccess.thecvf.com/content_CVPR_2020/html/Radosavovic_Designing_Network_Design_Spaces_CVPR_2020_paper.html"},"citation":"@misc{classiccnnsregnet2020,\n  title = {{Designing Network Design Spaces}},\n  author = {Ilija Radosavovic and Raj Prateek Kosaraju and Ross Girshick and Kaiming He and Piotr Dollár},\n  year = {2020},\n  eprint = {2003.13678},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2003.13678}\n}\n","citationPath":"/content/papers/citations/classic-cnns/regnet.51d4a967c43d.bib"},"thumbnail":{"src":"/content/papers/assets/477f84998189b88eda3ae1c093bfad949ef34cf53e00368019c348b971c3a63d.png","width":1013,"height":550},"locale":"fr","path":"/content/papers/fr/classic-cnns/regnet.b944af90d925.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"ce-qui-manque-à-la-conception-manuelle-et-au-nas","text":"Ce qui manque à la conception manuelle et au NAS","depth":3},{"id":"comment-comparer-deux-espaces-de-conception","text":"Comment comparer deux espaces de conception","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"point-de-départ-anynet","text":"Point de départ : AnyNet","depth":3},{"id":"resserrer-pas-à-pas","text":"Resserrer pas à pas","depth":3},{"id":"la-largeur-suit-une-droite","text":"La largeur suit une droite","depth":3},{"id":"regnet","text":"RegNet","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"là-où-les-résultats-sécartent-des-pratiques-courantes","text":"Là où les résultats s'écartent des pratiques courantes","depth":3},{"id":"face-à-resnet-et-resnext","text":"Face à ResNet et ResNeXt","depth":3},{"id":"budgets-de-calcul-mobiles","text":"Budgets de calcul mobiles","depth":3},{"id":"face-à-efficientnet","text":"Face à EfficientNet","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/nasnet","relation":"referenced","topic":""},{"id":"classic-cnns/efficientnet","relation":"referenced","topic":""}]}],"text":"Il existe deux façons de faire une connexion de raccourci. ResNet additionne entrée et sortie, $x + f(x)$ ; DenseNet les concatène, $[x, f(x)]$.\n\nEn 2016, DenseNet rejoignait ResNet avec moins de paramètres et remportait le prix du meilleur article à CVPR 2017. Pourtant, les architectures dominantes suivantes, ResNeXt, EfficientNet, ConvNeXt, puis ViT et Swin, ont presque toutes retenu l'addition. DenseNet s'est progressivement effacé des débats.\n\nCe travail de NAVER Cloud AI et NAVER AI Lab est signé Donghyun Kim, Byeongho Heo et Dongyoon Han. Pour eux, le problème vient des méthodes d'entraînement et des détails de conception vieillissants, plutôt que de la concaténation. Ils la conservent donc, rénovent tout le reste et regardent jusqu'où DenseNet peut aller.\n\n\n> [!TIP]\n> \n> Pour la conception initiale de DenseNet et CSPNet, qui en reprend certains éléments :\n> \n> - **[[16.08] DenseNet : Tout relier](/blog/papers/classic-cnns/densenet)**\n> - **[[19.11] CSPNet : Un module moitié-moitié-moitié](/blog/papers/classic-cnns/cspnet)**\n\n\n## Définir le problème\n\n### Addition et concaténation\n\nLe raccourci additif conserve une largeur fixe. Quel que soit le nombre de couches, les caractéristiques occupent toujours $d$ canaux ; chaque couche ne peut que modifier ces $d$ canaux.\n\nAvec la concaténation, chaque couche ajoute $g$ canaux, où $g$ est le taux de croissance, ou growth rate (GR). Les caractéristiques de toutes les couches précédentes restent intactes et directement accessibles aux suivantes.\n\nLes auteurs expliquent l'intérêt par le rang matriciel. Pour une sortie $f(XW)$, avec une entrée $X$ de taille $N\\times d_{in}$ et des poids $W$ de taille $d_{in}\\times d_{out}$, la non-linéarité porte généralement le rang de la sortie près de $d_{out}$. Une dimension plus grande augmente l'expressivité. La concaténation revient à écrire $W=[W_P, I]$ : les $d_{in}$ canaux d'origine sont préservés, et les $g$ canaux produits par $W_P$ s'y ajoutent, faisant croître le rang.\n\nC'est aussi le vieux défaut de DenseNet. Les canaux et la mémoire augmentent sans cesse. La version originale utilise donc un petit GR, par exemple 32, et empile beaucoup de couches. Les quatre blocs denses de DenseNet-201 en contiennent 6, 12, 48 et 32. Un réseau aussi profond et étroit est lent sur GPU.\n\nAutre argument : réduire les canaux par des couches de transition peut préserver une grande partie du rang, tant que la dimension finale reste suffisante. Des réductions fréquentes peuvent donc limiter la mémoire sans trop sacrifier l'expressivité.\n\n### Tirer d'abord quinze mille réseaux au hasard\n\nCe sont encore des hypothèses ; les auteurs commencent par les tester. Sur Tiny-ImageNet, ils génèrent plus de 15 000 réseaux, répartis entre raccourcis additifs et concaténatifs. Profondeur, largeur, activation, normalisation et taille des noyaux sont aussi aléatoires. Seuls les réseaux respectant le budget sont entraînés, ce qui rend les coûts des deux groupes comparables.\n\nCinq espaces sont utilisés : A, B et C sont trois tailles ; D ajoute l'augmentation de données à C ; E remplace ensuite l'optimiseur par AdamW :\n\n| Espace | Addition top-1 | Concaténation top-1 | Mémoire addition (GB) | Mémoire concaténation (GB) |\n| --- | ---: | ---: | ---: | ---: |\n| A (environ 2.2M paramètres) | 45.8 ± 2.0% | **47.5 ± 2.1%** | 0.65 | 0.75 |\n| B (environ 4.5M) | 50.1 ± 2.1% | **51.2 ± 2.1%** | 0.78 | 0.90 |\n| C (environ 9.5M) | 53.2 ± 2.2% | **54.3 ± 2.0%** | 1.01 | 1.24 |\n| D (C avec augmentation) | 57.4 ± 1.5% | **58.1 ± 1.4%** | 1.02 | 1.24 |\n| E (D avec AdamW) | 58.2 ± 1.5% | **58.9 ± 1.6%** | 1.02 | 1.25 |\n\n*Tableau : tableau 7 de l'article, moyenne et écart-type de tous les réseaux de chaque espace.*\n\nDans les cinq espaces, la concaténation gagne en moyenne de 0.7 à 1.7 point. Mais les écarts-types avoisinent 2 points, donc les distributions se recouvrent largement. Avec une recette d'entraînement plus forte, le gain passe aussi de 1.1 à 0.7 point. En contrepartie, la mémoire augmente de 15% à 23% : le vieux défaut persiste.\n\nCes expériences portent sur des images de 64×64 et des réseaux de moins de 10 millions de paramètres. Elles donnent une direction, qui reste à vérifier sur de grands modèles. D'où l'étape suivante sur ImageNet.\n\n\n> [!TIP]\n> \n> La comparaison de distributions de précision sur un grand nombre de réseaux aléatoires vient des auteurs de RegNet :\n> \n> - **[[20.03] RegNet : Les bonnes architectures se ressemblent-elles toutes ?](/blog/papers/classic-cnns/regnet)**\n\n\n## Résoudre le problème\n\n### Transformer progressivement DenseNet-201\n\nLa démarche ressemble à ConvNeXt : partir d'un ancien modèle, changer un élément à la fois et mesurer précision et vitesse. DenseNet-201 reçoit d'abord une recette moderne : AdamW, taux d'apprentissage cosinus, 300 epochs et diverses augmentations. Il atteint 79.7% sur ImageNet.\n\n| Étape | top-1 | Paramètres | FLOPs | Latence d'inférence (batch 1) | Latence d'entraînement | Mémoire d'entraînement |\n| --- | ---: | ---: | ---: | ---: | ---: | ---: |\n| DenseNet-201 (nouvelle recette) | 79.7% | 20.0M | 4.3G | 38.4 ms | 131 ms | 3.9 GB |\n| Plus large et moins profond | 79.5% | 21.8M | 11.1G | 8.5 ms | 85 ms | 3.2 GB |\n| Blocs modernes | 80.4% | 12.9M | 4.8G | 10.4 ms | 112 ms | 3.4 GB |\n| Expansion liée à l'entrée | 80.8% | 19.9M | 4.7G | 11.8 ms | 88 ms | 3.1 GB |\n| Davantage de transitions, GR propre à chaque étage | 82.3% | 21.2M | 5.0G | 11.0 ms | 90 ms | 3.4 GB |\n| Stem patchify | 82.4% | 21.2M | 4.9G | 11.0 ms | 88 ms | 3.2 GB |\n| Transitions redessinées | 82.6% | 22.4M | 4.9G | 13.6 ms | 97 ms | 3.1 GB |\n| Remise à l'échelle des canaux | **82.8%** | 23.9M | 5.0G | 14.0 ms | 99 ms | 3.1 GB |\n\n*Tableau : certaines colonnes du tableau 1 de l'article.*\n\nVoyons les étapes.\n\n**Élargir et réduire la profondeur.** Le GR passe de 32 à 120, et les blocs des quatre étages de $(6, 12, 48, 32)$ à $(3, 3, 12, 3)$. La précision change à peine, la latence d'entraînement baisse de 35% et la mémoire de 18%. Les FLOPs montent à 11.1G ; ce sera traité ensuite.\n\n**Adopter des blocs modernes.** Chaque bloc prend la forme de ConvNeXt : depthwise 7×7, LayerNorm, expansion puis réduction par convolutions 1×1, avec moins de normalisations et d'activations. Seule différence : la sortie a GR canaux, moins que l'entrée. Chaque bloc compresse donc les caractéristiques concaténées en GR nouveaux canaux. Gain : 0.9 point.\n\n**Lier l'expansion à l'entrée.** Le goulot du DenseNet original a une largeur de 4 fois le GR. Les auteurs passent à 4 fois les canaux d'entrée, enrichissant les caractéristiques avant la non-linéarité, puis réduisent le GR de 120 à 60 pour maîtriser le calcul. Gain de 0.4 point, et entraînement 21% plus rapide.\n\n**Multiplier les transitions.** DenseNet ne plaçait ses transitions qu'entre étages, avec sous-échantillonnage. Les auteurs ajoutent dans les étages une transition de pas 1 tous les 3 blocs, uniquement pour diviser les canaux par deux. Le calcul économisé permet d'augmenter le GR et de le différencier selon l'étage. Le gain de 1.5 point est le plus grand du processus.\n\nLes trois dernières étapes sont plus modestes. Le stem devient un patchify 4×4 de pas 4. Les transitions abandonnent le pooling moyen et sous-échantillonnent par une convolution dont le pas égale la taille du noyau. Enfin, la remise à l'échelle des canaux combine layer scale et effective SE. Chaque étape gagne 0.1 à 0.2 point.\n\n[![Figure 1 de l'article : en haut à gauche, le réseau suit Stem, Stage-1, Transition S/2, Stage-2, Transition S/2, Stage-3, Transition S/2, Stage-4, GlobalAvgPool, LayerNorm et FC. À droite, le mélangeur f contient DW Conv 7×7 (C→C), LayerNorm, Linear (C→4C), GeLU et Linear (4C→GR). En bas à gauche, Stage-N montre des blocs violets de caractéristiques qui s'épaississent par concaténation à chaque f, puis une Transition S/1 ; l'ensemble se répète L_N fois. À droite, la transition S/s combine LayerNorm et une convolution s×s de pas s qui divise les canaux par deux.](/content/papers/assets/47b1a145d10885d762e8f5476e49d96dc1e35fdc1e3227a66162ec1bf6870710.png)](/content/papers/assets/47b1a145d10885d762e8f5476e49d96dc1e35fdc1e3227a66162ec1bf6870710.png)\n\n*Figure 1 de Kim et al., extraite de la [**page 6 du PDF**](https://arxiv.org/pdf/2403.19588v2#page=6). La légende originale est omise.*\n\nVoilà RDNet. En bas, dans un étage, chaque mélangeur $f$ ajoute une tranche violette. Après trois $f$, une transition de pas 1 divise l'épaisseur par deux. Ce groupe se répète $L_N$ fois.\n\n### Suivre les canaux\n\nLe dessin rend mal les changements de largeur. timm propose RDNet et les poids préentraînés de `rdnet_tiny` à `rdnet_large`. Construisons directement RDNet-T sans télécharger de poids et affichons les canaux de chaque groupe :\n\n```python\nimport timm\nimport torch.nn as nn\n\nmodel = timm.create_model(\"rdnet_tiny\", pretrained=False)    # Architecture seule, sans télécharger les poids\nprint(\"Sortie du stem\", model.stem[0].out_channels, \"canaux\")\nfor i, group in enumerate(model.dense_stages):\n    *transition, dense = group.children()\n    if transition:                                            # Transition entre groupes : LayerNorm + convolution\n        conv = transition[1]\n        kind = \"sous-échantillonnage\" if conv.stride[0] == 2 else \"réduction des canaux seule\"\n        print(f\"  Transition ({kind}) {conv.in_channels} → {conv.out_channels}\")\n    blocks = list(dense.children())\n    c_in = blocks[0].layers.layers[0].in_channels             # Canaux d'entrée de la depthwise 7×7 du premier bloc\n    gr = blocks[0].growth_rate\n    print(f\"Groupe {i} : {len(blocks)} blocs, chacun ajoute {gr} canaux  {c_in} → {c_in + len(blocks) * gr}\")\n```\n\n```text\nSortie du stem 64 canaux\nGroupe 0 : 3 blocs, chacun ajoute 64 canaux  64 → 256\n  Transition (sous-échantillonnage) 256 → 128\nGroupe 1 : 3 blocs, chacun ajoute 104 canaux  128 → 440\n  Transition (sous-échantillonnage) 440 → 216\nGroupe 2 : 3 blocs, chacun ajoute 128 canaux  216 → 600\n  Transition (réduction des canaux seule) 600 → 296\nGroupe 3 : 3 blocs, chacun ajoute 128 canaux  296 → 680\n  Transition (réduction des canaux seule) 680 → 336\nGroupe 4 : 3 blocs, chacun ajoute 128 canaux  336 → 720\n  Transition (réduction des canaux seule) 720 → 360\nGroupe 5 : 3 blocs, chacun ajoute 128 canaux  360 → 744\n  Transition (sous-échantillonnage) 744 → 368\nGroupe 6 : 3 blocs, chacun ajoute 224 canaux  368 → 1040\n```\n\ntimm regroupe les blocs par trois. Les groupes 2 à 5 forment le troisième étage de l'article, soit 12 blocs. Les canaux croissent à la fin de chaque groupe puis sont divisés par deux à la transition : la largeur du troisième étage oscille ainsi entre 216 et 744.\n\nEt sans transitions internes au troisième étage ? Cette note en fait une estimation avec les mêmes nombres. Les deux convolutions 1×1 dominent chaque bloc : expansion à 4 fois l'entrée, puis réduction à GR. Elles coûtent environ $4c^2 + 4c\\cdot\\mathrm{GR}$ multiplications-additions par position :\n\n```python\ndef stage3(every, c=216, gr=128, blocks=12):\n    macs = 0\n    for b in range(blocks):\n        if b and b % every == 0:\n            c = int(c * 0.5 / 8) * 8                          # Transition : diviser les canaux par deux\n        macs += c * 4 * c + 4 * c * gr                        # Par position : expansion 1×1 à 4 fois, puis réduction à GR\n        c += gr                                               # Concaténer la sortie\n    return macs, c\n\nfor every, label in ((3, \"Réduction tous les 3 blocs\"), (6, \"Réduction tous les 6 blocs\"), (12, \"Aucune réduction\")):\n    macs, c = stage3(every)\n    print(f\"{label} : {c} canaux finaux, {macs / 1e6:.1f}M multiplications-additions par position pour les deux 1×1\")\n```\n\n```text\nRéduction tous les 3 blocs : 744 canaux finaux, 12.2M multiplications-additions par position pour les deux 1×1\nRéduction tous les 6 blocs : 1256 canaux finaux, 29.0M multiplications-additions par position pour les deux 1×1\nAucune réduction : 1752 canaux finaux, 55.7M multiplications-additions par position pour les deux 1×1\n```\n\nCette estimation omet la depthwise et SE, pour ne compter que la partie dominante. Sans transition, le troisième étage finit à 1752 canaux et coûte 4.6 fois plus qu'une réduction tous les 3 blocs. Le coût de l'expansion est quadratique en largeur : la concaténation fait croître linéairement les canaux, donc quadratiquement le calcul. Les réductions fréquentes permettent d'augmenter le GR.\n\nL'ablation de l'article confirme cet intervalle. À calcul comparable, réduire tous les 2 blocs donne 82.7%, tous les 3 blocs 82.8%, tous les 4 blocs 82.6% et tous les 6 blocs 82.1%.\n\n## Discussion\n\n### ImageNet\n\nComparons quelques modèles représentatifs, tous entraînés sur ImageNet-1K seul. La latence correspond à l'inférence de 128 images, et la mémoire est mesurée avec un batch de 16 :\n\n| Modèle | Paramètres | FLOPs | Latence (ms) | Mémoire (GB) | top-1 |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| Swin-T | 28M | 4.5G | 173 | 2.6 | 81.3% |\n| ConvNeXt-T | 29M | 4.5G | 150 | 2.7 | 82.1% |\n| InceptionNeXt-T | 28M | 4.2G | 132 | 3.3 | 82.3% |\n| RDNet-T | 24M | 5.0G | 175 | 4.1 | **82.8%** |\n| ConvNeXt-S | 50M | 8.7G | 266 | 4.0 | 83.1% |\n| RDNet-S | 50M | 8.7G | 289 | 5.4 | **83.7%** |\n| ConvNeXt-B | 89M | 15.4G | 417 | 5.4 | 83.8% |\n| RDNet-B | 87M | 15.4G | 472 | 6.9 | **84.4%** |\n\n*Tableau : certaines lignes du tableau 4 de l'article.*\n\nÀ chaque taille, RDNet gagne 0.6 à 0.7 point sur ConvNeXt, au prix d'une latence d'inférence accrue d'environ 10% à 20% et d'une mémoire supérieure de 30% à 50%. La concaténation préserve toutes les caractéristiques précédentes ; elle reste gourmande en mémoire.\n\nLes auteurs comparent aussi les nouveaux modèles de 2022 à 2024 : HorNet, VAN, BiFormer, NAT, SMT et MogaNet. Le constat s'inverse : à taille voisine, RDNet-T égale leur précision ou perd jusqu'à 1 point, mais sa latence batch 1 n'est que de 7.4 ms, contre 20 à 52 ms. Les auteurs écrivent eux-mêmes dans la description du tableau que leur légère perte de précision est compensée par la vitesse.\n\n### Tâches en aval\n\nL'avantage est plus net en segmentation et détection. Sur ADE20K avec UperNet, RDNet-T obtient une mIoU mono-échelle de 47.6, contre 46.0 pour ConvNeXt-T ; pour B, c'est 49.6 contre 49.1. Sur COCO avec Mask R-CNN et un calendrier 3×, RDNet-T atteint 47.5 de box AP contre 46.2 pour ConvNeXt-T, avec 5M paramètres de moins. Selon les auteurs, les caractéristiques de différentes couches conservées par concaténation aident particulièrement la prédiction dense.\n\nIls entraînent aussi CLIP avec OpenCLIP, en utilisant RDNet-B ou ConvNeXt-B comme encodeur d'images. Le top-1 en classification ImageNet zéro-shot est de 54.1% contre 51.2%.\n\n### Stochastic depth aide aussi\n\nDenseNet original n'utilisait pas stochastic depth, selon les auteurs parce que leurs modes de connexion ont déjà des ressemblances. L'essai produit pourtant un gros effet : le taux 0 donne 81.6%, le taux 0.15 donne 82.8%, soit 1.2 point de plus.\n\n\n> [!TIP]\n> \n> Pour voir comment stochastic depth met aléatoirement une couche « en congé » :\n> \n> - **[[16.03] Stochastic Depth : Cette couche a pris sa journée](/blog/papers/classic-cnns/stochastic-depth)**\n\n\n## Conclusion\n\nRetenons trois éléments :\n\n1. **La concaténation elle-même** : sur quinze mille réseaux aléatoires, elle gagne en moyenne 0.7 à 1.7 point sur l'addition, pour environ 10% à 20% de mémoire supplémentaire.\n2. **La silhouette rend DenseNet compétitif** : un réseau plus large et moins profond accélère ; les transitions plus fréquentes permettent un GR plus élevé, avec un gain de 1.5 point sur cette seule étape.\n3. **Les résultats** : à taille égale, 0.6 à 0.7 point de plus que ConvNeXt, davantage encore en segmentation et détection ; une inférence un peu plus lente et 30% à 50% de mémoire supplémentaire.\n\nL'effacement de DenseNet venait donc surtout de sa silhouette profonde et étroite et de sa vieille recette d'entraînement. La concaténation tenait la route. Ses besoins en mémoire, eux, n'ont guère diminué depuis 2016.\n","imageSizes":{"/content/papers/assets/47b1a145d10885d762e8f5476e49d96dc1e35fdc1e3227a66162ec1bf6870710.png":{"width":1230,"height":615}}}