{"notes":[{"id":"classic-cnns/wbmm","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"WBMM","subtitle":"Plus la fenêtre grandit, plus ça accélère","author":"Z. Yuan","paperDate":"2026-07-02","publishedOn":"2026-10-09","paperTitle":"WBMM: Windowed Batch Matrix Multiplication for Efficient Large Receptive Field Convolution","paperUrl":"https://arxiv.org/abs/2607.02097","bibliography":{"title":"WBMM: Windowed Batch Matrix Multiplication for Efficient Large Receptive Field Convolution","authors":["Wan Song","Wei Zhou","Rui Wang","Jun Yu","Toru Kurihara","Jiajia Xu","Shu Zhan"],"url":"https://arxiv.org/abs/2607.02097","pdfUrl":"https://arxiv.org/pdf/2607.02097v2","codeUrl":"https://github.com/wansong-s/WBMM","preprint":{"id":"2607.02097","submittedOn":"2026-07-02","url":"https://arxiv.org/abs/2607.02097"},"publication":{"venue":"ICML","year":2026,"kind":"conference","url":"https://proceedings.mlr.press/v306/song26ae.html"},"citation":"@misc{classiccnnswbmm2026,\n  title = {{WBMM: Windowed Batch Matrix Multiplication for Efficient Large Receptive Field Convolution}},\n  author = {Wan Song and Wei Zhou and Rui Wang and Jun Yu and Toru Kurihara and Jiajia Xu and Shu Zhan},\n  year = {2026},\n  eprint = {2607.02097},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2607.02097}\n}\n","citationPath":"/content/papers/citations/classic-cnns/wbmm.5eb4a1ff4a34.bib"},"thumbnail":{"src":"/content/papers/assets/5c20ec217f297d24ad8ce71ca79936d0599f7b460167e3bb89f52515ff1347ee.png","width":1017,"height":360},"locale":"fr","path":"/content/papers/fr/classic-cnns/wbmm.61d2c6e948a7.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"la-convolution-attend-les-données","text":"La convolution attend les données","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"écrire-la-convolution-comme-un-produit-matriciel","text":"Écrire la convolution comme un produit matriciel","depth":3},{"id":"plus-la-fenêtre-grandit-plus-ça-accélère","text":"Plus la fenêtre grandit, plus ça accélère","depth":3},{"id":"faire-communiquer-les-fenêtres","text":"Faire communiquer les fenêtres","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"imagenet","text":"ImageNet","depth":3},{"id":"détection-et-segmentation","text":"Détection et segmentation","depth":3},{"id":"autres-matériels","text":"Autres matériels","depth":3},{"id":"limites","text":"Limites","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"reparameterization/replknet","relation":"referenced","topic":""},{"id":"classic-cnns/slak","relation":"referenced","topic":""},{"id":"reparameterization/unireplknet","relation":"referenced","topic":""}]},{"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/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":"reparameterization/unireplknet","category":"reparameterization","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"UniRepLKNet","subtitle":"Les grands noyaux franchissent les frontières","author":"Z. Yuan","paperDate":"2023-11-27","publishedOn":"2025-12-14","world":"external/unireplknet","paperTitle":"UniRepLKNet: A Universal Perception Large-Kernel ConvNet for Audio, Video, Point Cloud, Time-Series and Image Recognition","paperUrl":"https://arxiv.org/abs/2311.15599","bibliography":{"title":"UniRepLKNet: A Universal Perception Large-Kernel ConvNet for Audio, Video, Point Cloud, Time-Series and Image Recognition","authors":["Xiaohan Ding","Yiyuan Zhang","Yixiao Ge","Sijie Zhao","Lin Song","Xiangyu Yue","Ying Shan"],"url":"https://arxiv.org/abs/2311.15599","pdfUrl":"https://arxiv.org/pdf/2311.15599v2","codeUrl":"https://github.com/AILab-CVC/UniRepLKNet","preprint":{"id":"2311.15599","submittedOn":"2023-11-27","url":"https://arxiv.org/abs/2311.15599"},"publication":{"venue":"CVPR","year":2024,"kind":"conference","url":"https://openaccess.thecvf.com/content/CVPR2024/html/Ding_UniRepLKNet_A_Universal_Perception_Large-Kernel_ConvNet_for_Audio_Video_Point_CVPR_2024_paper.html"},"citation":"@misc{reparameterizationunireplknet2023,\n  title = {{UniRepLKNet: A Universal Perception Large-Kernel ConvNet for Audio, Video, Point Cloud, Time-Series and Image Recognition}},\n  author = {Xiaohan Ding and Yiyuan Zhang and Yixiao Ge and Sijie Zhao and Lin Song and Xiangyu Yue and Ying Shan},\n  year = {2023},\n  eprint = {2311.15599},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2311.15599}\n}\n","citationPath":"/content/papers/citations/reparameterization/unireplknet.df5ca5b9a0be.bib"},"thumbnail":{"src":"/content/papers/assets/8dc0f2f7d7d64f92bea8485e2e00428225297bb13404dee50fe50f28385d34c8.png","width":1680,"height":384},"locale":"fr","path":"/content/papers/fr/reparameterization/unireplknet.0b9751d6b826.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"une-couche-33-remplit-trois-fonctions","text":"Une couche 3×3 remplit trois fonctions","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"architecture-de-référence","text":"Architecture de référence","depth":3},{"id":"principe-1--approfondir-avec-des-structures-peu-coûteuses","text":"Principe 1 : approfondir avec des structures peu coûteuses","depth":3},{"id":"principe-2--reparamétrer-avec-de-petites-convolutions-dilatées","text":"Principe 2 : reparamétrer avec de petites convolutions dilatées","depth":3},{"id":"principe-3--choisir-la-taille-du-noyau-selon-la-tâche-en-aval","text":"Principe 3 : choisir la taille du noyau selon la tâche en aval","depth":3},{"id":"principe-4--approfondir-avec-de-petits-noyaux","text":"Principe 4 : approfondir avec de petits noyaux","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"image","text":"Image","depth":3},{"id":"autres-modalités","text":"Autres modalités","depth":3},{"id":"le-coût-à-payer","text":"Le coût à payer","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"reparameterization/replknet","relation":"referenced","topic":""},{"id":"classic-cnns/slak","relation":"referenced","topic":""},{"id":"lightweight/senet","relation":"referenced","topic":""}]}],"text":"Les noyaux convolutifs ne cessent de grandir : 7×7 pour ConvNeXt, 31×31 pour RepLKNet, 51×51 pour SLaK, avant le retour à 13×13 d'UniRepLKNet. La précision progresse, mais le problème de vitesse demeure.\n\nLa convolution depthwise demande peu de FLOPs, mais ralentit fortement avec la taille du noyau. Les auteurs mesurent une chute de débit de 71% à 78% en passant de 5×5 à 13×13, puis de 92% à 94% à 27×27. Le constat reste voisin quels que soient le batch et la taille des caractéristiques.\n\nRepLKNet et UniRepLKNet ont écrit un opérateur CUDA spécifique, appelé ici LKA, Large Kernel Acceleration. Il aide sur les petites cartes de caractéristiques, mais ralentit les grandes. À 224×224 avec un batch de 128, LKA 7×7 est 80% plus lent que le 5×5 sans accélération, et le 13×13 est 89% plus lent. Or détection, segmentation et super-résolution utilisent justement de grandes cartes.\n\nDes chercheurs de l'Université de technologie de Hefei, de Lingyang Industrial Internet et de l'Université de technologie de Kochi au Japon prennent une autre voie : remplacer le calcul convolutif par des multiplications matricielles, plutôt que d'optimiser ses lectures.\n\n\n> [!TIP]\n> \n> Quelques étapes de la recherche sur les grands noyaux :\n> \n> - **[[22.03] RepLKNet : Des noyaux de convolution géants](/blog/papers/reparameterization/replknet)**\n> - **[[22.07] SLaK : Le noyau Pro Max](/blog/papers/classic-cnns/slak)**\n> - **[[23.11] UniRepLKNet : Les grands noyaux franchissent les frontières](/blog/papers/reparameterization/unireplknet)**\n\n\n## Définir le problème\n\n### La convolution attend les données\n\n[![Figure 2 de l'article, quatre panneaux. (a) Une sortie rouge y de depthwise 5×5 collecte 25 valeurs sur 5 lignes discontinues, reliées par des traits rouges. (b) WBMM découpe une carte 8×8 en quatre fenêtres colorées 4×4, W0 à W3, chacune lisant 16 valeurs d'un bloc contigu. (c) Accès mémoire depthwise : cinq segments rouges sur les lignes 1 à 5, fetch #1 à #5 ; cinq lectures séparées, pas égal à la largeur, plusieurs lignes de cache, O(1) opération par octet, limité par la mémoire. (d) Accès WBMM : quatre valeurs de chaque ligne, encadrées en bleu, sont réordonnées par window_partition et reshape en 16 cases contiguës ; un seul fetch #1, adresses continues, fenêtre tenant dans le cache L1, O(w²) opérations par octet, limité par le calcul.](/content/papers/assets/a830da4662436ed9b9ed1985cd4a866d805da44ae503db57f3af5ed78d1f3f63.png)](/content/papers/assets/a830da4662436ed9b9ed1985cd4a866d805da44ae503db57f3af5ed78d1f3f63.png)\n\n*Figure 2 de Song et al., extraite de la [**page 2 du PDF**](https://arxiv.org/pdf/2607.02097v2#page=2). La légende originale est omise.*\n\nLe problème vient des accès mémoire. Une carte de caractéristiques est stockée ligne après ligne. Pour chaque sortie depthwise, il faut récupérer $k$ valeurs dans chacune des $k$ lignes voisines. Les $k$ valeurs d'une ligne sont adjacentes, mais passer à la suivante impose un saut égal à la largeur de la carte.\n\nPlus le noyau grandit, plus il faut parcourir de lignes et plus le cache déborde. Chaque valeur lue ne sert qu'à une multiplication-addition. Le GPU attend les données au lieu d'utiliser sa puissance.\n\n## Résoudre le problème\n\n### Écrire la convolution comme un produit matriciel\n\n[![Figure 1 de l'article : à gauche (a), la depthwise collecte les 7² = 49 voisins d'une case rouge (i, j) dans une zone orange 7×7 de X, puis applique le noyau W 7×7 pour produire y[i, j]. À droite (b), WBMM découpe X en quatre fenêtres colorées 7×7. Une table de positions relatives R de taille C × (2·7 − 1)² = C × 169 est indexée pour former M de taille C × 49 × 49. Les fenêtres d'entrée multiplient M par Batched MatMul, flèche verte, et produisent Y découpé dans les mêmes fenêtres.](/content/papers/assets/5c20ec217f297d24ad8ce71ca79936d0599f7b460167e3bb89f52515ff1347ee.png)](/content/papers/assets/5c20ec217f297d24ad8ce71ca79936d0599f7b460167e3bb89f52515ff1347ee.png)\n\n*Figure 1 de Song et al., extraite de la [**page 1 du PDF**](https://arxiv.org/pdf/2607.02097v2#page=1). La légende originale est omise.*\n\nWBMM, Windowed Batch Matrix Multiplication, comporte trois étapes :\n\n1. **Découper les fenêtres** : la carte est divisée en fenêtres $w\\times w$ sans recouvrement, par exemple 7×7. Chaque fenêtre est aplatie en 49 valeurs contiguës en mémoire.\n2. **Construire les poids par indexation** : chaque canal possède une table de positions relatives $R$ de taille $(2w-1)^2$, donc 13×13 = 169 paramètres pour une fenêtre 7×7. Le poids entre les positions $i$ et $j$ dépend uniquement de leur déplacement relatif. Les valeurs indexées forment une matrice $M$ de 49×49.\n3. **Multiplier par batch** : toutes les fenêtres d'un canal partagent $M$. En plaçant les canaux dans la dimension batch, un seul `bmm` calcule toutes les fenêtres.\n\nDes poids dépendant uniquement de la position relative, c'est précisément la définition de la convolution. Le théorème 3.2 montre qu'une depthwise sur une carte bornée s'écrit exactement comme un produit matriciel à poids relatifs. Appliqué par fenêtre, WBMM équivaut à une depthwise 13×13 dont les valeurs hors fenêtre sont nulles. Comparons les deux calculs :\n\n```python\nimport torch\nimport torch.nn.functional as F\n\ntorch.manual_seed(0)\nC, H, W, w = 4, 14, 14, 7                       # 4 canaux, carte 14×14, fenêtres 7×7\nd = w * w                                        # 49 positions par fenêtre\nR = torch.randn(C, (2 * w - 1) ** 2)             # Table relative : 13×13 = 169 paramètres par canal\n\n# Index relatif : entrée de la table entre la position i et la position j\npos = torch.stack(torch.meshgrid(torch.arange(w), torch.arange(w), indexing=\"ij\")).flatten(1)  # 2 × 49\nrel = pos[:, None, :] - pos[:, :, None] + (w - 1)                                                # 2 × 49 × 49\nindex = rel[0] * (2 * w - 1) + rel[1]\n\nM = R[:, index]                                  # C × 49 × 49 : matrice de poids obtenue par indexation\n\n# Fenêtres sans recouvrement, sous forme (C, nombre de fenêtres, 49)\nx = torch.randn(1, C, H, W)\nnh, nw = H // w, W // w\nwindows = x.view(C, nh, w, nw, w).permute(0, 1, 3, 2, 4).reshape(C, nh * nw, d)\ny = torch.bmm(windows, M.transpose(1, 2))         # Un produit matriciel par canal traite toutes les fenêtres\ny = y.view(C, nh, nw, w, w).permute(0, 1, 3, 2, 4).reshape(1, C, H, W)\n\n# Référence : depthwise 13×13, fenêtre par fenêtre, avec des zéros à l'extérieur\nkernel = R.view(C, 1, 2 * w - 1, 2 * w - 1)\nref = torch.zeros_like(x)\nfor i in range(nh):\n    for j in range(nw):\n        patch = x[..., i * w:(i + 1) * w, j * w:(j + 1) * w]\n        ref[..., i * w:(i + 1) * w, j * w:(j + 1) * w] = F.conv2d(patch, kernel, padding=w - 1, groups=C)\n\nprint(\"Matrice de poids :\", tuple(M.shape), \", construite par indexation de\", R.shape[1], \"paramètres\")\nprint(\"Écart maximal avec la depthwise 13×13 dans chaque fenêtre :\", f\"{(y - ref).abs().max():.1e}\")\n```\n\n```text\nMatrice de poids : (4, 49, 49) , construite par indexation de 169 paramètres\nÉcart maximal avec la depthwise 13×13 dans chaque fenêtre : 2.9e-06\n```\n\nLes résultats coïncident, à l'erreur flottante près. Ce qui change se passe en mémoire : la convolution collecte des voisins épars un à un ; WBMM lit une fenêtre contiguë et la confie au produit matriciel, spécialité du GPU.\n\n### Plus la fenêtre grandit, plus ça accélère\n\nD'où une propriété contre-intuitive. Une depthwise ralentit quand son noyau grandit ; WBMM accélère quand sa fenêtre grandit.\n\nUne fenêtre $w\\times w$ lit $w^2$ valeurs et effectue $w^4$ multiplications-additions : chaque valeur lue permet donc $w^2$ opérations. Une grande fenêtre augmente le rapport calcul/lecture et occupe mieux le GPU. La matrice $M$ a certes $w^4$ éléments, mais toutes les fenêtres du batch la partagent, amortissant sa lecture.\n\nAvec 14×14, chaque sortie demande 196 multiplications-additions, près de 8 fois une depthwise 5×5, et couvre une étendue 7.8 fois plus grande. Le test d'opérateurs utilise un A800 en FP32 et 256 canaux. La fenêtre WBMM 14×14 est comparée à la depthwise standard 5×5 :\n\n| Batch | Carte 14×14 | 28×28 | 56×56 | 112×112 | 224×224 |\n| ---: | ---: | ---: | ---: | ---: | ---: |\n| 4 | 0.45× | 0.37× | 1.41× | 1.64× | 2.02× |\n| 16 | 0.62× | 1.56× | 1.80× | 2.00× | 2.07× |\n| 64 | 1.86× | 1.85× | 2.01× | 2.01× | 2.03× |\n| 128 | 3.17× | 2.00× | 2.06× | 1.97× | 2.01× |\n| 256 | 3.72× | 2.02× | 2.02× | 1.95× | — |\n\n*Tableau : tableau 1 de l'article, facteur de vitesse de WBMM par rapport à la depthwise 5×5.*\n\nAvec des cartes et des batchs assez grands, WBMM est environ deux fois plus rapide. Quand les deux sont petits, il ralentit : seulement 0.37 fois la vitesse de référence pour un batch de 4 et une carte 28×28.\n\nC'est très différent de l'attention en fenêtres. Dans Swin, chaque fenêtre de chaque exemple calcule sa matrice dépendant de l'entrée, puis softmax. $M$ ne dépend pas de l'entrée : tout le batch le partage, et l'inférence peut même le précalculer et le stocker.\n\n### Faire communiquer les fenêtres\n\nSans recouvrement, l'information reste dans sa fenêtre. Les auteurs intercalent des depthwise 3×3 ordinaires entre les blocs WBMM pour échanger entre fenêtres voisines.\n\nPour les tâches multi-échelles comme la segmentation, ils proposent aussi un reparamétrage hiérarchique des fenêtres. À l'entraînement, une grande fenêtre 14×14 et quatre petites 7×7 possèdent chacune leurs tables relatives. Avant l'inférence, les matrices des petites fenêtres sont ajoutées aux blocs diagonaux de la grande, sans coût supplémentaire à l'exécution. C'est le même principe qu'UniRepLKNet fusionnant petits et grands noyaux.\n\nLe modèle part d'UniRepLKNet, remplace les grands noyaux par WBMM et ajuste la répartition des blocs WBMM et 3×3 dans chaque étage.\n\n## Discussion\n\n### ImageNet\n\n| Modèle | Temps d'entraînement par epoch | Mémoire d'entraînement | top-1 |\n| --- | ---: | ---: | ---: |\n| WBMM-T | **6:18** | **15.0 GB** | 83.2% |\n| UniRepLKNet-T (avec LKA) | 9:03 | 16.6 GB | 83.2% |\n| UniRepLKNet-T (sans LKA) | 11:03 | 16.6 GB | 83.2% |\n| WBMM-S | **8:35** | **20.4 GB** | 83.9% |\n| UniRepLKNet-S (avec LKA) | 12:10 | 22.3 GB | 83.9% |\n\n*Tableau : certaines lignes du tableau 5 de l'article. 8 A800.*\n\nLa précision est identique, avec un entraînement plus de 1.4 fois plus rapide ; sans LKA, l'écart grandit. Sur les quatre tailles, l'accélération va de 1.31 à 1.88 fois, les chiffres repris dans le résumé.\n\nMais cette table compare UniRepLKNet entier, avec ses multiples branches de petites convolutions dilatées à l'entraînement. L'annexe fournit une comparaison plus équitable : tout reste identique, sauf l'opérateur spatial.\n\n| Opérateur spatial | Temps par epoch | top-1 | ADE20K mIoU | Inférence (images/s) |\n| --- | ---: | ---: | ---: | ---: |\n| WBMM (fenêtres 7×7) | **6:20** | 83.0% | 48.3 | **1833** |\n| WBMM (14×14 hiérarchique) | 6:31 | 83.2% | **48.8** | 1842 |\n| Depthwise 13×13 + LKA | 6:43 | 83.1% | 48.3 | 1662 |\n| Depthwise 13×13 (sans LKA) | 9:11 | 83.1% | 48.3 | 1305 |\n| Depthwise 13×13 + reparamétrage + LKA | 10:21 | 83.2% | 48.7 | 1662 |\n| SLaK original | 22:03 | 83.3% | 47.4 | 549 |\n| Attention en fenêtres 7×7 | 8:38 | 83.3% | 48.1 | 1245 |\n\n*Tableau : certaines lignes du tableau 8 de l'article, même architecture et taille Tiny pour tous.*\n\nFace à une simple depthwise 13×13 avec LKA, WBMM n'accélère l'entraînement que de 6%, et l'inférence de 10%. Le facteur 1.4 précédent vient surtout du retrait du reparamétrage multibranche d'UniRepLKNet, de 10:21 à 6:20. C'est face à la depthwise sans LKA que WBMM dépasse un facteur 1.4.\n\nSa valeur principale est d'égaler ou de dépasser LKA sans écrire d'opérateur CUDA spécifique.\n\n### Détection et segmentation\n\n| Méthode | ADE20K mIoU (mono-échelle) | COCO box AP | COCO mask AP |\n| --- | ---: | ---: | ---: |\n| UniRepLKNet-T | 48.6 | 51.8 | 44.9 |\n| WBMM-T (7×7) | 48.3 | 51.6 | 44.8 |\n| WBMM-T (hiérarchique) | **48.8** | **51.9** | **45.1** |\n\n*Tableau : tableaux 6 et 7 de l'article. UperNet sur ADE20K, Cascade Mask R-CNN sur COCO.*\n\nLes fenêtres 7×7 seules perdent de 0.1 à 0.3 face à UniRepLKNet. Le reparamétrage hiérarchique apporte ensuite une avance de 0.1 à 0.2, avec 3M à 4M paramètres de plus. Les performances en détection et segmentation sont donc voisines ; WBMM gagne sur la vitesse.\n\n### Autres matériels\n\nLes auteurs mesurent aussi d'autres appareils. Sur A800, WBMM est de 1.01 à 1.28 fois plus rapide qu'UniRepLKNet avec LKA. Sur CPU Intel i7-13700K, sans LKA disponible, BLAS lui donne une accélération de 1.03 à 1.48 fois. Sur Jetson Orin Nano, le GPU en FP16 gagne de 1.19 à 3.12 fois et le CPU en INT8 de 1.33 à 2.44 fois. Le produit matriciel est optimisé sur chaque matériel, un avantage particulièrement utile en périphérie.\n\n### Limites\n\nL'annexe en précise plusieurs. La matrice $M$ croît comme la quatrième puissance du côté de la fenêtre. Pour 14×14 et 256 canaux, une couche occupe environ 37.5 MB ; au-delà de 28×28, elle ne tient plus. La taille doit être choisie selon la tâche : sur ADE20K, des fenêtres 14×14 seules font moins bien que des 7×7 seules. Enfin, les poids indépendants de l'entrée peuvent limiter les tâches qui demandent une adaptation au contenu.\n\n## Conclusion\n\nDans chaque fenêtre, WBMM effectue la même depthwise 13×13. Il change l'organisation des données en mémoire et l'opérateur de calcul. Le produit matriciel par batch remplace l'attente des données par du calcul, et agrandir la fenêtre peut alors accélérer l'exécution.\n\nIl faut distinguer les références des tableaux. Le facteur 1.31 à 1.88 du résumé compare le modèle complet à UniRepLKNet. En ne changeant que l'opérateur, le gain d'entraînement sur une depthwise avec LKA est de 6%. L'économie principale est celle de l'opérateur CUDA spécialisé.\n\nSi un modèle à grands noyaux bute sur la vitesse à haute résolution, cette piste mérite un essai. Le `bmm` de PyTorch suffit : la première moitié de la démonstration contient toute la logique centrale, sans même compiler d'extension CUDA.\n","imageSizes":{"/content/papers/assets/a830da4662436ed9b9ed1985cd4a866d805da44ae503db57f3af5ed78d1f3f63.png":{"width":1032,"height":864},"/content/papers/assets/5c20ec217f297d24ad8ce71ca79936d0599f7b460167e3bb89f52515ff1347ee.png":{"width":1017,"height":360}}}