{"notes":[{"id":"classic-cnns/slak","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"SLaK","subtitle":"Le noyau Pro Max","author":"Z. Yuan","paperDate":"2022-07-07","publishedOn":"2025-03-09","world":"external/slak","paperTitle":"More ConvNets in the 2020s: Scaling up Kernels Beyond 51x51 using Sparsity","paperUrl":"https://arxiv.org/abs/2207.03620","bibliography":{"title":"More ConvNets in the 2020s: Scaling up Kernels Beyond 51x51 using Sparsity","authors":["Shiwei Liu","Tianlong Chen","Xiaohan Chen","Xuxi Chen","Qiao Xiao","Boqian Wu","Tommi Kärkkäinen","Mykola Pechenizkiy","Decebal Mocanu","Zhangyang Wang"],"url":"https://arxiv.org/abs/2207.03620","pdfUrl":"https://arxiv.org/pdf/2207.03620v3","codeUrl":null,"preprint":{"id":"2207.03620","submittedOn":"2022-07-07","url":"https://arxiv.org/abs/2207.03620"},"publication":{"venue":"ICLR","year":2023,"kind":"conference","url":"https://iclr.cc/virtual/2023/poster/11529"},"citation":"@misc{classiccnnsslak2022,\n  title = {{More ConvNets in the 2020s: Scaling up Kernels Beyond 51x51 using Sparsity}},\n  author = {Shiwei Liu and Tianlong Chen and Xiaohan Chen and Xuxi Chen and Qiao Xiao and Boqian Wu and Tommi Kärkkäinen and Mykola Pechenizkiy and Decebal Mocanu and Zhangyang Wang},\n  year = {2022},\n  eprint = {2207.03620},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2207.03620}\n}\n","citationPath":"/content/papers/citations/classic-cnns/slak.e167e693df01.bib"},"thumbnail":{"src":"/content/papers/assets/b5b8ba279efe42831c7ec4e60395d0559da26774c8519a438783f49f4b814a85.png","width":1640,"height":660},"locale":"fr","path":"/content/papers/fr/classic-cnns/slak.a981a598f00d.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"au-delà-de-31","text":"Au-delà de 31","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"première-étape-couper-en-deux-bandes","text":"Première étape : couper en deux bandes","depth":3},{"id":"deuxième-étape-un-peu-plus-creux-un-peu-plus-large","text":"Deuxième étape : un peu plus creux, un peu plus large","depth":3},{"id":"à-quoi-ressemble-slak","text":"À quoi ressemble SLaK","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":"en-conditions-réelles","text":"En conditions réelles","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/convnext","relation":"referenced","topic":""},{"id":"reparameterization/replknet","relation":"referenced","topic":""},{"id":"classic-cnns/resnext","relation":"referenced","topic":""}]},{"id":"classic-cnns/convnext","category":"classic-cnns","legacyPath":"classic-cnns/2201-convnext","legacySlug":"2201-convnext","legacyPaths":[],"title":"ConvNeXt","subtitle":"Redonner sa grandeur à la convolution","author":"Z. Yuan","paperDate":"2022-01-10","publishedOn":"2024-06-30","paperTitle":"A ConvNet for the 2020s","paperUrl":"https://arxiv.org/abs/2201.03545","bibliography":{"title":"A ConvNet for the 2020s","authors":["Zhuang Liu","Hanzi Mao","Chao-Yuan Wu","Christoph Feichtenhofer","Trevor Darrell","Saining Xie"],"url":"https://arxiv.org/abs/2201.03545","pdfUrl":"https://arxiv.org/pdf/2201.03545","codeUrl":"https://github.com/facebookresearch/ConvNeXt","preprint":{"id":"2201.03545","submittedOn":"2022-01-10","url":"https://arxiv.org/abs/2201.03545"},"publication":{"venue":"CVPR","year":2022,"kind":"conference","url":"https://arxiv.org/abs/2201.03545"},"citation":"@misc{classiccnnsconvnext2022,\n  title = {{A ConvNet for the 2020s}},\n  author = {Zhuang Liu and Hanzi Mao and Chao-Yuan Wu and Christoph Feichtenhofer and Trevor Darrell and Saining Xie},\n  year = {2022},\n  eprint = {2201.03545},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2201.03545}\n}\n","citationPath":"/content/papers/citations/classic-cnns/convnext.801b4060b807.bib"},"thumbnail":{"src":"/content/papers/assets/37882616c5c72df33699003256d14bf7c58c8ea5d1e9e4fb5b1c33268c9a6923.jpg","width":1224,"height":432},"locale":"fr","path":"/content/papers/fr/classic-cnns/convnext.9500f216d84f.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":"repenser-larchitecture-du-réseau","text":"Repenser l'architecture du réseau","depth":3},{"id":"introduire-des-méthodes-dentraînement-modernes","text":"Introduire des méthodes d'entraînement modernes","depth":3},{"id":"conception-générale","text":"Conception générale","depth":3},{"id":"à-la-manière-de-resnext","text":"À la manière de ResNeXt","depth":3},{"id":"goulot-inversé","text":"Goulot inversé","depth":3},{"id":"convolutions-à-grand-noyau","text":"Convolutions à grand noyau","depth":3},{"id":"conception-détaillée","text":"Conception détaillée","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"configurations-des-modèles","text":"Configurations des modèles","depth":3},{"id":"résultats-sur-imagenet","text":"Résultats sur ImageNet","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"vision-transformers/convmixer","relation":"comparison","topic":"Mélanger les patches par convolution"},{"id":"vision-transformers/caformer","relation":"comparison","topic":"Mélanger les patches par convolution"},{"id":"reparameterization/replknet","relation":"comparison","topic":"Grands noyaux et architectures convolutives simplifiées"}]},{"id":"reparameterization/replknet","category":"reparameterization","legacyPath":"reparameterization/2203-replknet","legacySlug":"2203-replknet","legacyPaths":[],"title":"RepLKNet","subtitle":"Des noyaux de convolution géants","author":"Z. Yuan","paperDate":"2022-03-13","publishedOn":"2024-07-21","paperTitle":"Scaling Up Your Kernels to 31x31: Revisiting Large Kernel Design in CNNs","paperUrl":"https://arxiv.org/abs/2203.06717","bibliography":{"title":"Scaling Up Your Kernels to 31x31: Revisiting Large Kernel Design in CNNs","authors":["Xiaohan Ding","Xiangyu Zhang","Yizhuang Zhou","Jungong Han","Guiguang Ding","Jian Sun"],"url":"https://arxiv.org/abs/2203.06717","pdfUrl":"https://arxiv.org/pdf/2203.06717","codeUrl":null,"preprint":{"id":"2203.06717","submittedOn":"2022-03-13","url":"https://arxiv.org/abs/2203.06717"},"publication":{"venue":"CVPR","year":2022,"kind":"conference","url":"https://arxiv.org/abs/2203.06717"},"citation":"@misc{reparameterizationreplknet2022,\n  title = {{Scaling Up Your Kernels to 31x31: Revisiting Large Kernel Design in CNNs}},\n  author = {Xiaohan Ding and Xiangyu Zhang and Yizhuang Zhou and Jungong Han and Guiguang Ding and Jian Sun},\n  year = {2022},\n  eprint = {2203.06717},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2203.06717}\n}\n","citationPath":"/content/papers/citations/reparameterization/replknet.c7cc2407aa19.bib"},"thumbnail":{"src":"/content/papers/assets/b85fa678b6e815b9d112b67d68443295a98c80478664ec8053c2e832d89574ca.jpg","width":1140,"height":972},"locale":"fr","path":"/content/papers/fr/reparameterization/replknet.d98b90ec0670.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"mode-demploi-des-convolutions-à-grand-noyau","text":"Mode d'emploi des convolutions à grand noyau","depth":2},{"id":"les-grands-noyaux-en-convolution-en-profondeur-restent-efficaces","text":"Les grands noyaux en convolution en profondeur restent efficaces","depth":3},{"id":"les-grands-noyaux-dépendent-fortement-des-connexions-résiduelles","text":"Les grands noyaux dépendent fortement des connexions résiduelles","depth":3},{"id":"les-grands-noyaux-ont-besoin-de-reparamétrisation","text":"Les grands noyaux ont besoin de reparamétrisation","depth":3},{"id":"les-grands-noyaux-améliorent-nettement-les-tâches-en-aval","text":"Les grands noyaux améliorent nettement les tâches en aval","depth":3},{"id":"les-grands-noyaux-restent-utiles-sur-de-petites-cartes-de-caractéristiques","text":"Les grands noyaux restent utiles sur de petites cartes de caractéristiques","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"architecture-du-réseau","text":"Architecture du réseau","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"évaluation-des-grands-noyaux","text":"Évaluation des grands noyaux","depth":3},{"id":"performances-sur-imagenet","text":"Performances sur ImageNet","depth":3},{"id":"un-cnn-à-grands-noyaux-a-un-erf-plus-vaste-quun-réseau-profond-à-petits-noyaux","text":"Un CNN à grands noyaux a un ERF plus vaste qu'un réseau profond à petits noyaux","depth":3},{"id":"biais-de-forme","text":"Biais de forme","depth":3},{"id":"limites","text":"Limites","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/convnext","relation":"comparison","topic":"Grands noyaux et architectures convolutives simplifiées"}]},{"id":"classic-cnns/resnext","category":"classic-cnns","legacyPath":"classic-cnns/1611-resnext","legacySlug":"1611-resnext","legacyPaths":[],"title":"ResNeXt","subtitle":"Explorer une autre dimension","author":"Z. Yuan","paperDate":"2016-11-16","publishedOn":"2024-07-12","paperTitle":"Aggregated Residual Transformations for Deep Neural Networks","paperUrl":"https://arxiv.org/abs/1611.05431","bibliography":{"title":"Aggregated Residual Transformations for Deep Neural Networks","authors":["Saining Xie","Ross Girshick","Piotr Dollár","Zhuowen Tu","Kaiming He"],"url":"https://arxiv.org/abs/1611.05431","pdfUrl":"https://arxiv.org/pdf/1611.05431","codeUrl":"https://github.com/facebookresearch/ResNeXt","preprint":{"id":"1611.05431","submittedOn":"2016-11-16","url":"https://arxiv.org/abs/1611.05431"},"publication":{"venue":"CVPR","year":2017,"kind":"conference","url":"https://arxiv.org/abs/1611.05431"},"citation":"@misc{classiccnnsresnext2016,\n  title = {{Aggregated Residual Transformations for Deep Neural Networks}},\n  author = {Saining Xie and Ross Girshick and Piotr Dollár and Zhuowen Tu and Kaiming He},\n  year = {2016},\n  eprint = {1611.05431},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/1611.05431}\n}\n","citationPath":"/content/papers/citations/classic-cnns/resnext.4945bb6b3dae.bib"},"thumbnail":{"src":"/content/papers/assets/268f5b641a1a85d929d88f2aa0d636902dd9d101824284c32266668493563672.jpg","width":1224,"height":576},"locale":"fr","path":"/content/papers/fr/classic-cnns/resnext.6042c10b09b4.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"généralisation-aux-tâches-suivantes","text":"Généralisation aux tâches suivantes","depth":3},{"id":"peu-commode-pour-concevoir-des-modèles","text":"Peu commode pour concevoir des modèles","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"architecture-du-réseau","text":"Architecture du réseau","depth":3},{"id":"configuration-du-modèle","text":"Configuration du modèle","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"entraînement-sur-imagenet-1k","text":"Entraînement sur ImageNet-1K","depth":3},{"id":"accroître-la-complexité-du-modèle","text":"Accroître la complexité du modèle","depth":3},{"id":"résultats-des-modèles-sur-imagenet-1k","text":"Résultats des modèles sur ImageNet-1K","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/cspnet","relation":"comparison","topic":"Branches, convolutions groupées et réutilisation des caractéristiques"}]}],"text":"Au premier semestre 2022, les réseaux convolutifs signent coup sur coup deux retours en force. ConvNeXt modifie ResNet pas à pas en suivant la conception de Swin Transformer, et fait passer le noyau de convolution de 3×3 à 7×7 ; deux mois plus tard, RepLKNet ose davantage, passe directement à 31×31 et s'appuie sur de petits noyaux reparamétrisés pour faciliter l'entraînement.\n\n\n> [!TIP]\n> \n> Ces deux travaux ont chacun leur note, que vous pouvez lire d'abord :\n> \n> - **[[22.01] ConvNeXt : Redonner sa grandeur à la convolution](/blog/papers/classic-cnns/convnext)**\n> - **[[22.03] RepLKNet : Des noyaux de convolution géants](/blog/papers/reparameterization/replknet)**\n\n\nRepLKNet s'arrête à 31×31. Cet article veut savoir si le noyau peut encore grandir, et si la précision continue de monter à 51×51 ou 61×61. Les auteurs viennent de l'UT Austin, de l'université de technologie d'Eindhoven et d'autres établissements. Decebal Mocanu et le premier auteur, Shiwei Liu, travaillent depuis longtemps sur l'entraînement à parcimonie dynamique ; plusieurs des méthodes de parcimonie citées dans l'article sont leurs propres travaux antérieurs, et c'est encore par la parcimonie qu'ils abordent le problème cette fois.\n\n## Définir le problème\n\n### Au-delà de 31\n\nLes auteurs commencent par agrandir les noyaux de ConvNeXt-T selon deux méthodes existantes, en n'entraînant chaque configuration que 120 époques, juste pour voir la tendance :\n\n| Plus grand noyau | Agrandissement direct | Méthode de RepLKNet |\n| --- | ---: | ---: |\n| 7×7 (ConvNeXt d'origine) | 81,0 % | — |\n| 31×31 | 80,5 % | **81,5 %** |\n| 51×51 | 80,4 % | 81,3 % |\n| 61×61 | 80,3 % | 81,3 % |\n\n*Tableau : extrait de la Table 1 de l'article ; précision top-1 de ConvNeXt-T sur ImageNet-1K. La taille des noyaux diminue d'un étage à l'autre ; la ligne 51, par exemple, correspond à [51, 49, 47, 13].*\n\nDans la colonne de l'agrandissement direct, plus le noyau est grand, plus le résultat se dégrade. La méthode de RepLKNet redresse la situation à 31×31, avec 0,5 point de pourcentage de plus que l'original, mais ne progresse plus au-delà. De plus, la version 51×51 demande 9,3 GFLOPs, deux fois plus que le ConvNeXt-T d'origine, et la version 61×61 monte même à 11,5 GFLOPs.\n\nL'explication des auteurs tient à la localité. Le stem de ConvNeXt est une convolution 4×4 de pas 4 ; une entrée de 224×224 n'en sort qu'en 56×56, et sur une telle carte de caractéristiques, un noyau de 51×51 revient presque à une convolution globale. Côté ViT, l'expérience est comparable, l'attention à fenêtres locales de Swin et consorts faisant généralement mieux que l'attention globale de ViT. Un noyau assez grand pour couvrir toute l'image perd ce biais inductif qui consiste à ne regarder que le voisinage.\n\nIl y a donc deux choses à régler. D'abord, le noyau doit être très grand tout en restant local ; ensuite, le calcul et le nombre de paramètres croissent avec le carré du côté du noyau, et ce coût doit baisser.\n\n## Résoudre le problème\n\nLa recette des auteurs se fait en deux étapes.\n\n### Première étape : couper en deux bandes\n\nOn remplace un noyau M×M par deux convolutions en bande parallèles, l'une M×N, l'autre N×M, avec N = 5. Le côté long regarde loin, le côté court préserve le détail local. Le petit noyau 5×5 placé en parallèle par RepLKNet est conservé, et les trois branches passent chacune par une BatchNorm avant d'être additionnées. Les auteurs insistent sur ce point ; une BatchNorm sur chaque branche avant l'addition est une étape essentielle.\n\n[![Schéma en trois colonnes comparant trois façons d'utiliser de grands noyaux. À gauche, le noyau carré 7×7 de ConvNeXt, avec 49 poids par canal. Au centre, le grand carré 51×51 de RepLKNet, flanqué à droite d'un petit carré 5×5, soit 2 626 poids au total. À droite, SLaK, avec côte à côte une bande verticale 51×5, une bande horizontale 5×51 et un petit carré 5×5, soit 535 poids au total ; des cases claires parsèment les trois blocs pour représenter les poids mis à 0, et une mention en dessous indique 40 % de parcimonie et une largeur multipliée par 1,3](/content/papers/assets/b5b8ba279efe42831c7ec4e60395d0559da26774c8519a438783f49f4b814a85.png)](/content/papers/assets/b5b8ba279efe42831c7ec4e60395d0559da26774c8519a438783f49f4b814a85.png)\n\n*Figure : réalisée pour cette note. Nombre de poids à apprendre par canal pour chacune des trois approches ; l'article original est sous licence CC BY-NC-SA 4.0, et sa figure n'est pas reproduite ici.*\n\nCombien cette découpe fait-elle économiser ? Comptons directement. Il s'agit ici de convolutions depthwise, où chaque canal a son propre noyau :\n\n```python\n# convolution depthwise, un noyau par canal : nombre de poids à apprendre pour chaque canal\nfor M in (7, 31, 51, 61):\n    dense = M * M                              # un noyau carré M×M\n    rep = M * M + 5 * 5                        # RepLKNet : M×M plus un 5×5 en parallèle\n    slak = M * 5 + 5 * M + 5 * 5               # SLaK : M×5 et 5×M, plus un 5×5\n    print(f\"M={M:>2} : carré {dense:>5}, RepLKNet {rep:>5}, en bandes {slak:>4} ({slak / dense:.0%} du carré)\")\n```\n\n```\nM= 7 : carré    49, RepLKNet    74, en bandes   95 (194% du carré)\nM=31 : carré   961, RepLKNet   986, en bandes  335 (35% du carré)\nM=51 : carré  2601, RepLKNet  2626, en bandes  535 (21% du carré)\nM=61 : carré  3721, RepLKNet  3746, en bandes  635 (17% du carré)\n```\n\nPour un petit noyau, la découpe coûte même plus cher ; un 7×7 découpé coûte près de deux fois l'original. À 51×51, il n'en reste qu'environ un cinquième. Le coût du carré croît comme M², celui des bandes seulement comme M ; plus le noyau est grand, plus l'écart se creuse.\n\nUne fois le noyau découpé en croix, une couche de convolution ne voit qu'une croix, avec les quatre coins vides. Mais le réseau compte de nombreuses couches, et leur empilement comble ces vides. Essayons avec une petite croix 9×3 :\n\n```python\nimport torch\nimport torch.nn.functional as F\n\nM, N = 9, 3                                    # démonstration avec un petit 9×3, plus facile à afficher\nk = torch.zeros(M, M)\nc, h = M // 2, N // 2\nk[:, c - h:c + h + 1] = 1                      # bande verticale M×N\nk[c - h:c + h + 1, :] = 1                      # bande horizontale N×M\n\nprint(\"Positions vues par une couche de convolution en bandes (cases sur 9×9) :\", int(k.sum().item()))\nfor row in k.int().tolist():\n    print(\"\".join(\"■\" if v else \"·\" for v in row))\n\ntwo = F.conv2d(k[None, None], k[None, None], padding=M - 1)[0, 0] > 0   # champ couvert après deux couches empilées\ncenter = two[c:c + M, c:c + M]                                          # retour au bloc 9×9 d'origine\nprint(f\"Après deux couches, {int(center.sum().item())} cases visibles dans le 9×9 d'origine ; le champ s'étend à {two.shape[0]}×{two.shape[1]}\")\n```\n\n```\nPositions vues par une couche de convolution en bandes (cases sur 9×9) : 45\n···■■■···\n···■■■···\n···■■■···\n■■■■■■■■■\n■■■■■■■■■\n■■■■■■■■■\n···■■■···\n···■■■···\n···■■■···\nAprès deux couches, 81 cases visibles dans le 9×9 d'origine ; le champ s'étend à 17×17\n```\n\nUne seule couche ne voit que 45 des 81 cases ; avec deux couches, tout est couvert.\n\nAprès la découpe, toujours avec ConvNeXt-T entraîné 120 époques, les plus grands noyaux de 7, 31, 51 et 61 donnent 81,0 %, 81,3 %, 81,5 % et 81,4 %, et les FLOPs ne passent que de 4,5 G à 5,6 G. Pour la première fois, 51×51 fait mieux que 31×31, et ses 5,4 GFLOPs coûtent plus de 40 % de moins que les 9,3 G de la méthode de RepLKNet.\n\n### Deuxième étape : un peu plus creux, un peu plus large\n\nResNeXt a proposé de « multiplier les groupes pour élargir le réseau », et ConvNeXt a poussé l'idée à l'extrême avec des convolutions depthwise et des canaux plus larges. Cet article reprend la même formule en version creuse, que les auteurs écrivent « use sparse groups, expand more width ».\n\n\n> [!TIP]\n> \n> Pour la convolution groupée de ResNeXt, vous pouvez lire cette note :\n> \n> - **[[16.11] ResNeXt : Explorer une autre dimension](/blog/papers/classic-cnns/resnext)**\n\n\nConcrètement, 40 % des poids de la convolution valent 0. Le taux de parcimonie de chaque couche est emprunté à SNIP. Sur l'ensemble du réseau, on retient les poids les plus importants selon $|g \\cdot w|$, c'est-à-dire la valeur absolue du gradient multiplié par le poids, on regarde quelle proportion chaque couche en conserve, et c'est ce taux qu'on lui applique ; quant aux positions mises à 0 dans chaque couche, elles sont d'abord tirées au hasard. L'entraînement utilise la parcimonie dynamique. À intervalles réguliers, on élague les poids de plus faible valeur, puis on fait repousser autant de poids à des positions aléatoires. Le nombre total de poids non nuls ne change pas, mais leurs positions ne cessent de s'ajuster.\n\nLe calcul économisé sert ensuite à multiplier par 1,3 le nombre de canaux de chaque étage :\n\n| Plus grand noyau | En bandes | + 40 % de parcimonie | + largeur ×1,3 |\n| --- | ---: | ---: | ---: |\n| 7×7 | 81,0 % (4,5 G) | 80,0 % (2,6 G) | 81,1 % (4,5 G) |\n| 31×31 | 81,3 % (5,0 G) | 80,4 % (2,9 G) | 81,5 % (4,8 G) |\n| 51×51 | **81,5 %** (5,4 G) | **80,5 %** (3,1 G) | **81,6 %** (5,0 G) |\n| 61×61 | 81,4 % (5,6 G) | 80,4 % (3,2 G) | 81,5 % (5,2 G) |\n\n*Tableau : extrait de la Table 2 de l'article ; précision top-1 de ConvNeXt-T entraîné 120 époques, FLOPs entre parenthèses.*\n\nLa parcimonie fait perdre environ 1 point de pourcentage, et environ 2 G de FLOPs ; une fois la largeur augmentée, la précision remonte au plus haut. Les 81,5 % de la ligne 61×61, comparés aux 81,3 % de la méthode de RepLKNet à 61×61, demandent 55 % de FLOPs en moins.\n\nRegardez la ligne 7×7. Appliquée à un petit noyau, la recette complète fait passer de 81,0 % à 81,1 %, presque rien. Autrement dit, la précision vient du grand noyau ; la découpe en bandes et la parcimonie servent seulement à rendre ce grand noyau entraînable et abordable en calcul.\n\nLe titre promet d'aller au-delà de 51×51, et 61×61 a bien été essayé, mais il ne fait mieux que 51×51 dans aucune colonne ; le SLaK final reste donc à 51.\n\n### À quoi ressemble SLaK\n\nSLaK reprend directement le squelette de ConvNeXt. Le stem est une convolution 4×4 de pas 4 ; les quatre étages comptent [3, 3, 9, 3] blocs pour SLaK-T, et [3, 3, 27, 3] pour SLaK-S et SLaK-B. Les noyaux des quatre étages sont dans l'ordre [51, 49, 47, 13], chacun découpé en M×5 et 5×M, plus un 5×5. Tout le réseau est creux à 40 % et sa largeur multipliée par 1,3 ; les modèles de toutes tailles partagent ces mêmes réglages, et les auteurs n'ont pas ajusté d'hyperparamètres propres à chacun.\n\n## Discussion\n\n### ImageNet\n\nAvec l'entraînement complet de 300 époques, face aux autres modèles :\n\n| Modèle | Paramètres | FLOPs | Top-1 |\n| --- | ---: | ---: | ---: |\n| Swin-T | 28 M | 4,5 G | 81,3 % |\n| ConvNeXt-T | 29 M | 4,5 G | 82,1 % |\n| **SLaK-T** | 30 M (50 M) | 5,0 G (8,7 G) | **82,5 %** |\n| ConvNeXt-S | 50 M | 8,7 G | 83,1 % |\n| **SLaK-S** | 55 M (91 M) | 9,8 G (16,7 G) | **83,8 %** |\n| RepLKNet-31B | 79 M | 15,3 G | 83,5 % |\n| ConvNeXt-B | 89 M | 15,4 G | 83,8 % |\n| **SLaK-B** | 95 M (158 M) | 17,1 G (28,5 G) | **84,0 %** |\n\n*Tableau : extrait de la Table 3 de l'article ; entrée 224×224. Entre parenthèses, les paramètres et FLOPs sans accélération de la parcimonie, en bleu dans l'article original.*\n\nÀ chaque taille, SLaK dépasse ConvNeXt, de 0,2 à 0,7 point de pourcentage. Avec une entrée 384×384, SLaK-B atteint 85,5 % contre 85,1 % pour ConvNeXt-B, un écart deux fois plus grand qu'à 224. Selon les auteurs, plus la résolution est élevée, plus le grand noyau a de quoi s'exprimer.\n\nLes chiffres entre parenthèses méritent toutefois un second regard. Sans accélération de la parcimonie, SLaK-T compte 50 M de paramètres et 8,7 GFLOPs, exactement la taille de ConvNeXt-S, qui atteint 83,1 %, plus que SLaK-T. Les 91 M et 16,7 G de SLaK-S sont eux aussi proches de ConvNeXt-B, et les deux sont à 83,8 %. Si l'on compare au coût sans accélération, l'avantage de SLaK disparaît.\n\n### Tâches en aval\n\nC'est en aval que les grands noyaux brillent vraiment. Les trois tâches sont comparées à la taille T :\n\n| Tâche | ConvNeXt-T (7×7) | ConvNeXt-T (31×31, méthode de RepLKNet) | SLaK-T (51×51) |\n| --- | ---: | ---: | ---: |\n| Segmentation sémantique ADE20K, mIoU | 44,6 | 45,0 | **46,2** |\n| Détection PASCAL VOC 2007, mAP | 80,6 | 81,3 | **82,7** |\n| Détection COCO, AP<sup>box</sup> | 47,3 | 47,8 | **48,4** |\n\n*Tableau : établi d'après les Tables 4, 5 et 6 de l'article. UperNet pour ADE20K, Faster R-CNN pour VOC, Cascade Mask R-CNN pour COCO ; backbones préentraînés 120 époques, affinage de 12 époques sur COCO.*\n\nPlus le noyau est grand, meilleurs sont les résultats sur les trois tâches. Sur ADE20K, SLaK-T devance ConvNeXt-T de 1,6, un écart bien plus grand que sur ImageNet, et dépasse même les 45,9 de ConvNeXt-S. RepLKNet avait observé le même phénomène ; des modèles aux scores de classification proches peuvent beaucoup différer sur des tâches en aval qui demandent de voir large.\n\nAvec l'entraînement complet, sur ADE20K, les tailles T, S et B passent respectivement de 46,0, 48,7 et 49,1 à 47,6, 49,4 et 50,2 ; sur COCO, avec 36 époques d'affinage, l'AP<sup>box</sup> passe de 50,4 à 51,3.\n\nLes auteurs ont aussi mesuré le champ réceptif effectif. Ils prennent 50 images de l'ensemble de validation, les agrandissent en 1024×1024, et calculent la contribution de chaque pixel d'entrée à la sortie du point central de la dernière couche. Chez ConvNeXt, les pixels à forte contribution se concentrent au centre ; la version 31×31 les disperse davantage, sans couvrir toute l'image ; SLaK les disperse le plus, avec des points à forte contribution jusque très loin du centre.\n\n### En conditions réelles\n\nLes FLOPs sont des valeurs théoriques ; dans l'annexe H, les auteurs ajoutent des mesures réelles sur A100. En FP32, sans aucune accélération de la parcimonie, ConvNeXt-T traite 1 779 images par seconde, Swin-T 1 305 et SLaK-T 709. Le débit de SLaK-T n'atteint que 40 % de celui de ConvNeXt-T ; les auteurs jugent cet écart acceptable, compte tenu d'un réseau 1,3 fois plus large et de noyaux plus de 7 fois plus grands.\n\nEn décomposant ensuite la recette étape par étape, ils mesurent le débit de ConvNeXt-B avec des noyaux [51, 49, 47, 13] :\n\n| Méthode | Images par seconde |\n| --- | ---: |\n| Noyaux carrés 51×51 directement | 96 |\n| Découpe en bandes | 283 |\n| + 40 % de parcimonie | 282 |\n| + largeur ×1,3 | 198 |\n\n*Tableau : extrait de la Table 12 de l'article ; A100, FP32, sans accélération de la parcimonie.*\n\nLa découpe en bandes accélère vraiment, près de 3 fois. L'étape de parcimonie passe de 283 à 282, sans le moindre gain, car la parcimonie est implémentée par un masque binaire et le GPU multiplie quand même tous ces zéros. L'élargissement, lui, a un coût bien réel, avec un débit en baisse de 30 %.\n\nLes auteurs le reconnaissent franchement dans la section sur les limites ; les FLOPs d'inférence de l'article sont des valeurs théoriques, qui ne se concrétiseront que lorsque le matériel prendra en charge la parcimonie non structurée. Autrement dit, les FLOPs imprimés en noir dans le tableau principal de l'article sont écrits pour les GPU de demain.\n\n## Conclusion\n\nDécouper un grand carré en deux bandes est l'astuce la plus utile de cet article. La localité est préservée, le coût ne croît que linéairement avec le côté, 51×51 bat enfin 31×31, et les tâches en aval progressent encore davantage. En plus, la découpe en bandes ne dépend pas du matériel, et vous pouvez l'essayer tout de suite dans votre propre réseau.\n\nPour la moitié creuse, c'est dommage. Sur un GPU ordinaire, les 40 % de zéros doivent quand même être multipliés, alors que l'élargissement de 1,3 fois a un coût bien réel, et le débit de SLaK-T n'atteint que 40 % de celui de ConvNeXt-T.\n\nBref, de ce modèle Pro Max, ramenez déjà chez vous la moitié en bandes ; pour la moitié creuse, on en reparlera le jour où les GPU la prendront en charge.\n","imageSizes":{"/content/papers/assets/b5b8ba279efe42831c7ec4e60395d0559da26774c8519a438783f49f4b814a85.png":{"width":1640,"height":660}}}