{"notes":[{"id":"classic-cnns/dcnv4","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DCNv4","subtitle":"Des poids sans borne","author":"Z. Yuan","paperDate":"2024-01-11","publishedOn":"2025-12-29","paperTitle":"Efficient Deformable ConvNets: Rethinking Dynamic and Sparse Operator for Vision Applications","paperUrl":"https://arxiv.org/abs/2401.06197","bibliography":{"title":"Efficient Deformable ConvNets: Rethinking Dynamic and Sparse Operator for Vision Applications","authors":["Yuwen Xiong","Zhiqi Li","Yuntao Chen","Feng Wang","Xizhou Zhu","Jiapeng Luo","Wenhai Wang","Tong Lu","Hongsheng Li","Yu Qiao","Lewei Lu","Jie Zhou","Jifeng Dai"],"url":"https://arxiv.org/abs/2401.06197","pdfUrl":"https://arxiv.org/pdf/2401.06197v1","codeUrl":"https://github.com/OpenGVLab/DCNv4","preprint":{"id":"2401.06197","submittedOn":"2024-01-11","url":"https://arxiv.org/abs/2401.06197"},"publication":{"venue":"CVPR","year":2024,"kind":"conference","url":"https://openaccess.thecvf.com/content/CVPR2024/html/Xiong_Efficient_Deformable_ConvNets_Rethinking_Dynamic_and_Sparse_Operator_for_Vision_CVPR_2024_paper.html"},"citation":"@misc{classiccnnsdcnv42024,\n  title = {{Efficient Deformable ConvNets: Rethinking Dynamic and Sparse Operator for Vision Applications}},\n  author = {Yuwen Xiong and Zhiqi Li and Yuntao Chen and Feng Wang and Xizhou Zhu and Jiapeng Luo and Wenhai Wang and Tong Lu and Hongsheng Li and Yu Qiao and Lewei Lu and Jie Zhou and Jifeng Dai},\n  year = {2024},\n  eprint = {2401.06197},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2401.06197}\n}\n","citationPath":"/content/papers/citations/classic-cnns/dcnv4.f17f87f8ee11.bib"},"thumbnail":{"src":"/content/papers/assets/fe768f9a1b9df098fd7de1ed2c34ba0713cb83936e024d45ca26e85a2b340ff1.png","width":1020,"height":522},"locale":"fr","path":"/content/papers/fr/classic-cnns/dcnv4.c237e5351849.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"seulement-9-points-et-pourtant-si-lent","text":"Seulement 9 points, et pourtant si lent","depth":3},{"id":"un-softmax-emprunté","text":"Un softmax emprunté","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"1-retirer-softmax","text":"1. Retirer softmax","depth":3},{"id":"2-réduire-les-transferts-du-gpu","text":"2. Réduire les transferts du GPU","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"lopérateur-seul","text":"L'opérateur seul","depth":3},{"id":"flashinternimage","text":"FlashInternImage","depth":3},{"id":"linsérer-dans-dautres-réseaux","text":"L'insérer dans d'autres réseaux","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":"classic-cnns/internimage","relation":"referenced","topic":""},{"id":"classic-cnns/deformable-convnets","relation":"referenced","topic":""}]},{"id":"classic-cnns/internimage","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"InternImage","subtitle":"La force brute fait des miracles ?","author":"Z. Yuan","paperDate":"2022-11-10","publishedOn":"2025-09-04","world":"external/internimage","paperTitle":"InternImage: Exploring Large-Scale Vision Foundation Models with Deformable Convolutions","paperUrl":"https://arxiv.org/abs/2211.05778","bibliography":{"title":"InternImage: Exploring Large-Scale Vision Foundation Models with Deformable Convolutions","authors":["Wenhai Wang","Jifeng Dai","Zhe Chen","Zhenhang Huang","Zhiqi Li","Xizhou Zhu","Xiaowei Hu","Tong Lu","Lewei Lu","Hongsheng Li","Xiaogang Wang","Yu Qiao"],"url":"https://arxiv.org/abs/2211.05778","pdfUrl":"https://arxiv.org/pdf/2211.05778v4","codeUrl":null,"preprint":{"id":"2211.05778","submittedOn":"2022-11-10","url":"https://arxiv.org/abs/2211.05778"},"publication":{"venue":"CVPR","year":2023,"kind":"conference","url":"https://openaccess.thecvf.com/content/CVPR2023/html/Wang_InternImage_Exploring_Large-Scale_Vision_Foundation_Models_With_Deformable_Convolutions_CVPR_2023_paper.html"},"citation":"@misc{classiccnnsinternimage2022,\n  title = {{InternImage: Exploring Large-Scale Vision Foundation Models with Deformable Convolutions}},\n  author = {Wenhai Wang and Jifeng Dai and Zhe Chen and Zhenhang Huang and Zhiqi Li and Xizhou Zhu and Xiaowei Hu and Tong Lu and Lewei Lu and Hongsheng Li and Xiaogang Wang and Yu Qiao},\n  year = {2022},\n  eprint = {2211.05778},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2211.05778}\n}\n","citationPath":"/content/papers/citations/classic-cnns/internimage.4baca0899bc9.bib"},"thumbnail":{"src":"/content/papers/assets/eb597a4ac9a7c2e5e9b05e8ff1c61a951adab71d5cc5a273796762d353a9a0e9.png","width":1012,"height":1179},"locale":"fr","path":"/content/papers/fr/classic-cnns/internimage.61b6fcef5191.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"où-la-convolution-est-en-retard","text":"Où la convolution est en retard","depth":3},{"id":"pourquoi-dcnv2-ne-convient-pas-tel-quel","text":"Pourquoi DCNv2 ne convient pas tel quel","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"les-trois-modifications-de-dcnv3","text":"Les trois modifications de DCNv3","depth":3},{"id":"empiler-en-réseau","text":"Empiler en réseau","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":"ablation-la-softmax","text":"Ablation : la softmax","depth":3},{"id":"le-prix-à-payer","text":"Le prix à payer","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/deformable-convnets","relation":"referenced","topic":""},{"id":"reparameterization/replknet","relation":"referenced","topic":""},{"id":"classic-cnns/slak","relation":"referenced","topic":""}]},{"id":"classic-cnns/deformable-convnets","category":"classic-cnns","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Deformable ConvNets","subtitle":"Un sacré jeu de jambes","author":"Z. Yuan","paperDate":"2017-03-17","publishedOn":"2024-05-01","world":"external/deformable-convnets","paperTitle":"Deformable Convolutional Networks","paperUrl":"https://arxiv.org/abs/1703.06211","bibliography":{"title":"Deformable Convolutional Networks","authors":["Jifeng Dai","Haozhi Qi","Yuwen Xiong","Yi Li","Guodong Zhang","Han Hu","Yichen Wei"],"url":"https://arxiv.org/abs/1703.06211","pdfUrl":"https://arxiv.org/pdf/1703.06211v3","codeUrl":null,"preprint":{"id":"1703.06211","submittedOn":"2017-03-17","url":"https://arxiv.org/abs/1703.06211"},"publication":{"venue":"ICCV","year":2017,"kind":"conference","url":"https://openaccess.thecvf.com/content_iccv_2017/html/Dai_Deformable_Convolutional_Networks_ICCV_2017_paper.html"},"citation":"@misc{classiccnnsdeformableconvnets2017,\n  title = {{Deformable Convolutional Networks}},\n  author = {Jifeng Dai and Haozhi Qi and Yuwen Xiong and Yi Li and Guodong Zhang and Han Hu and Yichen Wei},\n  year = {2017},\n  eprint = {1703.06211},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/1703.06211}\n}\n","citationPath":"/content/papers/citations/classic-cnns/deformable-convnets.f724f3ff1784.bib"},"thumbnail":{"src":"/content/papers/assets/942dcd98b1119ce95e8a9a24b84ed42b780d062caafa004c66f75640c4e2584a.png","width":987,"height":633},"locale":"fr","path":"/content/papers/fr/classic-cnns/deformable-convnets.20c475e9ecf6.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"une-grille-figée","text":"Une grille figée","depth":3},{"id":"faire-apprendre-la-déformation-au-réseau-une-idée-déjà-explorée","text":"Faire apprendre la déformation au réseau, une idée déjà explorée","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"les-deux-étapes-dune-convolution","text":"Les deux étapes d'une convolution","depth":3},{"id":"un-décalage-pour-chaque-point","text":"Un décalage pour chaque point","depth":3},{"id":"échantillonner-une-position-fractionnaire","text":"Échantillonner une position fractionnaire","depth":3},{"id":"doù-viennent-les-décalages","text":"D'où viennent les décalages ?","depth":3},{"id":"deux-cas-particuliers","text":"Deux cas particuliers","depth":3},{"id":"roi-pooling-déformable","text":"RoI pooling déformable","depth":3},{"id":"dans-le-réseau","text":"Dans le réseau","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"le-champ-réceptif-suit-vraiment-lobjet","text":"Le champ réceptif suit vraiment l'objet","depth":3},{"id":"combien-de-couches-remplacer","text":"Combien de couches remplacer ?","depth":3},{"id":"face-à-la-convolution-dilatée","text":"Face à la convolution dilatée","depth":3},{"id":"le-coût","text":"Le coût","depth":3},{"id":"coco","text":"COCO","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"classic-cnns/stn","relation":"referenced","topic":""},{"id":"object-detection/deformable-detr","relation":"referenced","topic":""}]}],"text":"Dans les ablations d'InternImage, remplacer softmax par sigmoid pour les poids de modulation de DCNv3 faisait tomber la précision ImageNet de 83.5% à 65.7%. Softmax semblait indispensable à DCNv3.\n\nUn peu plus d'un an après, une équipe largement identique présente DCNv4. Sa première modification consiste à retirer softmax, et la convergence devient pourtant plus rapide.\n\nLe premier auteur, Yuwen Xiong, participait déjà à la première convolution déformable en 2017 ; l'auteur correspondant, Jifeng Dai, en était le premier auteur. L'équipe réunit notamment l'Université de Toronto, le Shanghai AI Laboratory, Tsinghua, SenseTime et l'Université chinoise de Hong Kong. L'autre moitié de l'article pose une question : pourquoi une convolution déformable qui n'échantillonne que 9 points est-elle plus lente qu'une depthwise 7×7 ?\n\n\n> [!TIP]\n> \n> Pour le fonctionnement de DCNv3, d'InternImage et de la première convolution déformable :\n> \n> - **[[22.11] InternImage : La force brute fait des miracles ?](/blog/papers/classic-cnns/internimage)**\n> - **[[17.03] Deformable ConvNets : Un sacré jeu de jambes](/blog/papers/classic-cnns/deformable-convnets)**\n\n\n[![Figure 1 de l'article : (a) histogramme pour trois tailles d'entrée, 56×56×128, 28×28×256 et 14×14×512. L'axe vertical donne le temps relatif à DCNv3, fixé à 1. Chaque groupe compare FlashAttention, Window Attention, DWConv, DCNv3 et DCNv4. DCNv4 est le plus court dans les deux premiers groupes et proche de FlashAttention dans le troisième ; le premier groupe indique une accélération de 3.76 fois sur DCNv3. (b) Courbes de précision ImageNet top-1 selon les itérations, de 0 à 15K : DCNv4 mène au début, DWConv et Dense Attention sont au milieu, et DCNv3 est dernier.](/content/papers/assets/5a7b5fe22fc3c1bf41919d57fbcca8c73c4d14c00875c73ce999527f2f9ae54e.png)](/content/papers/assets/5a7b5fe22fc3c1bf41919d57fbcca8c73c4d14c00875c73ce999527f2f9ae54e.png)\n\n*Figure 1 de Xiong et al., extraite de la [**page 1 du PDF**](https://arxiv.org/pdf/2401.06197v1#page=1). La légende originale est omise.*\n\nÀ gauche, DCNv3 vaut 1 et une barre plus courte est meilleure. DCNv4 mène pour les deux premières tailles et rejoint FlashAttention à 14×14×512. À droite, une même architecture utilise différents opérateurs : DCNv4 mène dès le début de l'entraînement, tandis que DCNv3 ferme la marche.\n\n## Définir le problème\n\n### Seulement 9 points, et pourtant si lent\n\nRappelons DCNv3. À la position $p_0$, la sortie du groupe de canaux $g$ est\n\n$$\ny_g(p_0)=\\sum_{k=1}^{K} m_{gk}\\, x_g\\!\\left(p_0+p_k+\\Delta p_{gk}\\right),\n$$\n\n$K=9$ est le nombre de points de la grille 3×3, $\\Delta p_{gk}$ le décalage appris et $m_{gk}$ le poids de modulation, normalisé par softmax suivant $K$ dans DCNv3. Décalages et poids sont calculés à partir de l'entrée et varient selon la position.\n\nUn opérateur clairsemé à 9 points devrait être plus rapide qu'une depthwise 7×7 ou qu'une attention dense. En pratique, l'accès mémoire l'en empêche.\n\nLes auteurs utilisent le modèle roofline. Pour une entrée et une sortie $H\\times W\\times C$, DCNv3 demande $36HWC$ FLOPs : chacun des 9 points nécessite une interpolation bilinéaire portant sur 4 pixels. Dans le cas idéal, chaque valeur est lue une seule fois, soit environ $3.7HWC$ accès mémoire.\n\nEn calcul parallèle, de nombreux threads lisent simultanément et les succès de cache ne sont pas garantis. Au pire, chaque sortie relit 36 pixels d'interpolation et 27 décalages et poids, soit 2 décalages et 1 poids par point, puis écrit 1 résultat. Le trafic atteint $64HWC$, 17 fois l'idéal.\n\nLe rapport calcul/accès mémoire n'est que de 0.6 à 9.7. Sur le roofline, l'opérateur est limité par la bande passante ; ajouter de la puissance de calcul ne l'aide pas.\n\n### Un softmax emprunté\n\nL'autre problème est softmax, emprunté à l'attention. Mais l'attention a ses propres raisons de l'utiliser.\n\nL'attention par produit scalaire mis à l'échelle s'écrit $\\mathrm{softmax}(QK^\\top/\\sqrt{d})V$. Sans softmax, on peut d'abord calculer $K^\\top V$, une matrice $d\\times d$. Toutes les requêtes d'une fenêtre multiplient alors la même matrice, et l'attention se réduit à une projection linéaire.\n\nLa convolution et DCNv3 n'ont pas ce problème. Chaque position possède déjà sa propre fenêtre d'échantillonnage, dont les valeurs diffèrent d'une position à l'autre. Il n'y a pas de notion de « key » imposant cette normalisation.\n\nPour tester l'idée, les auteurs ajoutent au contraire softmax aux poids des convolutions depthwise 7×7 de ConvNeXt :\n\n| Modèle | Epoch 5 | Epoch 10 | Epoch 20 | Epoch 50 | Epoch 300 |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| ConvNeXt | 29.9% | 53.5% | 66.1% | 74.8% | 83.8% |\n| ConvNeXt + softmax | 8.5% | 25.3% | 51.1% | 69.1% | 81.6% |\n\n*Tableau : tableau 1 de l'article, top-1 sur ImageNet-1K.*\n\nSoftmax ralentit nettement la convergence et coûte encore 2.2 points en fin d'entraînement.\n\nIl borne chaque poids entre 0 et 1 et impose une somme de 1 : la sortie est une moyenne pondérée des valeurs échantillonnées. Elle reste entre le minimum et le maximum et ne peut pas effectuer une soustraction, pourtant à la base de filtres élémentaires comme la détection de contours. Faisons apprendre aux deux pondérations un filtre « droite moins gauche » :\n\n```python\nimport torch\n\ntorch.manual_seed(0)\nx = torch.randn(1000, 3)                     # Mille positions, avec trois points : gauche, centre, droite\ntarget = x[:, 2] - x[:, 0]                   # Filtre élémentaire de contour : droite moins gauche\n\nfor name, to_weight in [(\"Poids softmax\", lambda z: z.softmax(0)), (\"Poids sans borne\", lambda z: z)]:\n    z = torch.zeros(3, requires_grad=True)\n    opt = torch.optim.Adam([z], lr=0.1)\n    for _ in range(500):\n        loss = ((x @ to_weight(z) - target) ** 2).mean()\n        opt.zero_grad()\n        loss.backward()\n        opt.step()\n    w = to_weight(z).detach()\n    print(f\"{name} : gauche {w[0]:+.2f}  centre {w[1]:+.2f}  droite {w[2]:+.2f}  erreur {loss.item():.3f}\")\nprint(f\"Variance de la cible : {target.var():.3f}\")\n```\n\n```text\nPoids softmax : gauche +0.00  centre +0.00  droite +1.00  erreur 0.995\nPoids sans borne : gauche -1.00  centre +0.00  droite +1.00  erreur 0.000\nVariance de la cible : 2.008\n```\n\nLes poids sans borne apprennent directement $(-1, 0, 1)$. Softmax ne peut produire de poids négatif ; son meilleur choix consiste à tout placer à droite, laissant environ la moitié de l'erreur.\n\n[![Figure 2 de l'article : quatre schémas comparent l'agrégation spatiale de pixels requêtes à différentes positions d'un même canal. L'étoile marque la requête et les cases les pixels répondants ; les barres de couleur distinguent (0, 1) et (−∞, +∞). (a) Attention : fenêtre partagée/fixe, poids dynamiques et bornés. (b) DCNv3 : fenêtre propre/adaptative, poids dynamiques et bornés. (c) Convolution : fenêtre propre/fixe, poids statiques et sans borne. (d) DCNv4 : fenêtre propre/adaptative, poids dynamiques et sans borne.](/content/papers/assets/fe768f9a1b9df098fd7de1ed2c34ba0713cb83936e024d45ca26e85a2b340ff1.png)](/content/papers/assets/fe768f9a1b9df098fd7de1ed2c34ba0713cb83936e024d45ca26e85a2b340ff1.png)\n\n*Figure 2 de Xiong et al., extraite de la [**page 3 du PDF**](https://arxiv.org/pdf/2401.06197v1#page=3). La légende originale est omise.*\n\nLa figure compare les quatre opérateurs. Les poids de l'attention varient, mais sont bornés. Ceux de la convolution sont sans borne, mais fixes, comme la forme de sa fenêtre. DCNv4 vise le coin inférieur droit : une fenêtre déformable propre à chaque position et des poids dépendant de l'entrée, sans borne.\n\n## Résoudre le problème\n\n### 1. Retirer softmax\n\nLa formule reste celle de DCNv3, mais $m_{gk}$ ne passe plus par softmax. Une couche linéaire le prédit directement depuis l'entrée ; il peut prendre toute valeur réelle.\n\nCe retrait apporte un autre gain. Décalages et poids utilisaient deux couches linéaires ; on peut maintenant les réunir, en économisant un lancement de kernel et une synchronisation. Le sous-réseau des décalages est aussi simplifié : depthwise 3×3, LayerNorm, GELU puis couche linéaire deviennent une simple convolution séparable à la Xception, sans LayerNorm ni GELU intermédiaires.\n\n### 2. Réduire les transferts du GPU\n\n[![Figure 3 de l'article : répartition du travail entre threads pour DCNv3 et DCNv4. À gauche de chaque schéma se trouve un groupe de décalages et de poids dans la mémoire GPU ; à droite, un tenseur de sortie cubique H, W, C. (a) DCNv3 utilise six threads, Thread-1 à Thread-6, chacun chargé d'un canal et d'une requête mémoire. (b) DCNv4 n'utilise que trois threads, chacun chargé de deux canaux du même groupe ; les lectures sont divisées par deux, comme l'indique l'annotation en haut à droite.](/content/papers/assets/db5cc5d4b75082f8705ba96857cd9bf56bd46cfb53a7946d53500fabcace0dd5.png)](/content/papers/assets/db5cc5d4b75082f8705ba96857cd9bf56bd46cfb53a7946d53500fabcace0dd5.png)\n\n*Figure 3 de Xiong et al., extraite de la [**page 4 du PDF**](https://arxiv.org/pdf/2401.06197v1#page=4). La légende originale est omise.*\n\nL'implémentation CUDA de DCNv3 lance $H\\times W\\times C$ threads, chacun chargé d'un canal à une position. Pourtant, les $D=C/G$ canaux d'un même groupe partagent les mêmes décalages et poids à cette position. Les $D$ threads relisent donc les mêmes données et recalculent chacun les coefficients d'interpolation bilinéaire.\n\nDCNv4 confie plusieurs canaux d'un groupe au même thread. Décalages et poids ne sont lus qu'une fois, les coefficients d'interpolation ne sont calculés qu'une fois. Le dessin montre deux canaux par thread pour rester lisible ; l'implémentation en utilise 8.\n\nFait intéressant, cette seule étape ralentit le calcul. Moins de threads réduit le parallélisme, et chacun travaille 8 fois plus. Le véritable gain vient ensuite. Les canaux sont contigus en mémoire, au format channel-last : une instruction vectorielle peut lire plusieurs canaux voisins d'un coup, par exemple quatre flottants de 32 bits en une lecture de 128 bits, plutôt qu'un à un. Même principe pour l'écriture.\n\nLes auteurs mesurent séparément chaque étape. Entrée 56×56×128, batch de 64, 4 groupes de 32 canaux ; temps en millisecondes :\n\n| Implémentation | Module entier | Kernel CUDA |\n| --- | ---: | ---: |\n| DCNv3 original | 3.28 | 1.45 |\n| Module simplifié | 2.12 | 1.45 |\n| 8 canaux par thread | 2.20 | 1.53 |\n| Réutilisation des coefficients d'interpolation | 2.18 | 1.51 |\n| Lectures et écritures vectorielles | 1.28 | 0.606 |\n| Passage en demi-précision | **0.873** | **0.404** |\n\n*Tableau : tableau 10 de l'article. A100.*\n\nLa simplification touche uniquement l'extérieur du kernel, dont le temps reste identique. Les deux étapes suivantes le ralentissent légèrement ; la vectorisation réduit ensuite son temps de 60%. En demi-précision, une valeur occupe 2 octets, donc la même bande passante transporte deux fois plus de données. Selon les auteurs, DCNv3 ne profite pas de la demi-précision : seule la nouvelle implémentation en tire ce gain.\n\n## Discussion\n\n### L'opérateur seul\n\nComparons d'abord les opérateurs sur une entrée 56×56×128, en FP32 et FP16 :\n\n| Opérateur | FP32 (ms) | FP16 (ms) |\n| --- | ---: | ---: |\n| Attention globale (PyTorch) | 30.8 | 19.3 |\n| FlashAttention-2 | — | 2.46 |\n| Attention en fenêtres 7×7 | 4.05 | 1.46 |\n| DWConv 7×7 (PyTorch) | 2.02 | 1.98 |\n| DWConv 7×7 (cuDNN) | 0.981 | 0.438 |\n| DCNv3 | 1.45 | 1.52 |\n| DCNv4 | **0.606** | **0.404** |\n\n*Tableau : première colonne du tableau 2 de l'article. FlashAttention-2 n'a pas de version FP32.*\n\nDCNv4 dépasse même la depthwise 7×7 de cuDNN, avec un temps FP32 inférieur de près de 40%. La ligne DCNv3 confirme aussi le constat précédent : FP16 le ralentit légèrement.\n\n### FlashInternImage\n\nRemplacer DCNv3 par DCNv4 dans InternImage, sans rien changer d'autre, donne FlashInternImage. Le débit est mesuré séparément en FP32 et FP16 :\n\n| Modèle | top-1 | Débit (FP32 / FP16, images/s) |\n| --- | ---: | ---: |\n| ConvNeXt-T | 82.1% | 2485 / 4305 |\n| InternImage-T | 83.5% | 1409 / 1746 |\n| FlashInternImage-T | **83.6%** | 2316 / 3154 |\n| ConvNeXt-S | 83.1% | 1645 / 2538 |\n| InternImage-S | 84.2% | 1044 / 1321 |\n| FlashInternImage-S | **84.4%** | 1625 / 2396 |\n| ConvNeXt-B | 83.8% | 1241 / 1888 |\n| InternImage-B | 84.9% | 779 / 1030 |\n| FlashInternImage-B | **84.9%** | 1174 / 1816 |\n\n*Tableau : certaines lignes du tableau 4 de l'article.*\n\nFace à InternImage, T accélère de 64% à 80%, tout en gagnant un peu en précision.\n\nLa comparaison avec ConvNeXt demande plus d'attention. En FP16, FlashInternImage-T reste à un peu plus de 70% de la vitesse de ConvNeXt-T. S et B sont aussi légèrement plus lents, vers 95%. DCNv4 rapproche donc InternImage de la vitesse de ConvNeXt, avec 1.1 à 1.5 point de précision supplémentaire.\n\nLa tendance se retrouve en aval. Sur COCO avec Mask R-CNN pendant 12 epochs, FlashInternImage-T obtient 48.0 de box AP contre 47.2 pour InternImage-T, et les FPS passent de 54 / 69 à 72 / 102. Sur ADE20K avec UperNet, la mIoU mono-échelle passe de 47.9 à 49.3.\n\n### L'insérer dans d'autres réseaux\n\nLes auteurs remplacent aussi directement des composants d'autres architectures par DCNv4, sans modifier les réglages ni les hyperparamètres :\n\n- **ConvNeXt-B** : remplacer la depthwise 7×7 fait passer ImageNet de 83.8% à 84.0%, avec un débit accru de 20% en FP32 et de 33% en FP16.\n- **ViT-B** : remplacer l'attention fait passer de 81.8% à 81.9%, avec un débit supérieur de 24% et de 17% à l'original utilisant FlashAttention-2.\n- **U-Net d'un modèle de diffusion latente** : remplacer les modules d'attention et les convolutions 3×3 ordinaires abaisse le FID de 2.94 à 2.44 sur la génération conditionnée par classe d'ImageNet 256×256, et les paramètres de 860M à 566M.\n\nCes architectures étaient conçues pour leurs opérateurs respectifs. DCNv4 s'y insère avec une précision identique ou légèrement meilleure et une vitesse accrue. Pour la génération, les auteurs précisent que l'architecture et les hyperparamètres pourraient encore être mieux adaptés à DCNv4.\n\n### Le coût à payer\n\nDCNv4 reste un opérateur CUDA personnalisé. Une grande partie des issues du dépôt officiel concerne les échecs de compilation, modules introuvables, absence de prise en charge CPU et blocages d'export ONNX ou TensorRT. Le dernier push du dépôt remonte à mai 2024.\n\nDes utilisateurs rapportent aussi des résultats différents de l'article. L'un constate un [entraînement plus lent que DCNv3](https://github.com/OpenGVLab/DCNv4/issues/54) sur sa tâche de segmentation ; un autre utilise le benchmark officiel sur une 3090 et obtient [une vitesse inférieure à celle annoncée](https://github.com/OpenGVLab/DCNv4/issues/106). Plusieurs intégrations, notamment dans YOLO, signalent une [perte qui ne baisse pas](https://github.com/OpenGVLab/DCNv4/issues/80) ou des [NaN](https://github.com/OpenGVLab/DCNv4/issues/105). Sans configuration complète ni réponse officielle, leurs causes restent inconnues.\n\nL'hypothèse avancée dans cette note est que, sans la borne imposée par softmax, l'initialisation et le taux d'apprentissage peuvent nécessiter un nouveau réglage dans d'autres réseaux. Les succès de l'article concernent des architectures pensées pour la convolution déformable, comme InternImage, ou des configurations réglées par les auteurs.\n\n## Conclusion\n\nDCNv4 fait deux choses. Il retire softmax pour laisser les poids sans borne, comme dans une convolution ordinaire, ce qui accélère la convergence. Il réécrit aussi le kernel CUDA : les canaux d'un groupe partagent une lecture, et des instructions vectorielles déplacent plusieurs canaux à la fois. L'opérateur devient plus de trois fois plus rapide.\n\nPour qui utilise déjà InternImage, FlashInternImage apporte de la vitesse presque gratuitement. Dans son propre modèle, il faut penser à la demi-précision : DCNv4 est le plus rapide en FP16. Et surveiller d'un peu plus près la perte pendant les premières centaines d'itérations.\n\nLe titre promet de « repenser les opérateurs dynamiques et clairsemés ». À la fin, une grande partie du gain vient d'une question très simple : combien de fois faut-il relire en mémoire les décalages d'un même groupe de canaux ?\n","imageSizes":{"/content/papers/assets/5a7b5fe22fc3c1bf41919d57fbcca8c73c4d14c00875c73ce999527f2f9ae54e.png":{"width":1020,"height":546},"/content/papers/assets/fe768f9a1b9df098fd7de1ed2c34ba0713cb83936e024d45ca26e85a2b340ff1.png":{"width":1020,"height":522},"/content/papers/assets/db5cc5d4b75082f8705ba96857cd9bf56bd46cfb53a7946d53500fabcace0dd5.png":{"width":1020,"height":426}}}