DEIMv2 : Détection d'Objets Temps Réel avec DINOv3

DEIMv2 : Détection d’Objets Temps Réel avec DINOv3

La détection d’objets en temps réel est un problème résolu, n’est-ce pas ? YOLO a 10 ans, les modèles tournent à 100+ FPS sur GPU grand public. Et pourtant, DEIMv2 — sorti en septembre 2025 — dépasse 50 AP sur COCO avec seulement 9,7M de paramètres. Comment ? En mariant le framework DEIM avec les features riches de DINOv3. Voici ce que ça change en pratique.

Le benchmark COCO est la référence de l’industrie pour la détection d’objets : 80 classes, 118 000 images d’entraînement, conditions variées. Un modèle dépassant 50 AP sur COCO est considéré comme “state-of-the-art”. À titre de comparaison, YOLOv8-L atteint 52,9 AP pour 43,7M de paramètres — DEIMv2-S fait 50,9 AP avec 9,7M paramètres.

L’architecture DEIMv2 : DINOv3 comme backbone

DEIMv2 est développé par l’Intellindust AI Lab. Son architecture s’articule en 4 composants :

class DEIMv2(nn.Module, PyTorchModelHubMixin):
    def __init__(self, config):
        super().__init__()
        self.backbone = DINOv3STAs(**config["DINOv3STAs"])
        self.encoder = HybridEncoder(**config["HybridEncoder"])
        self.decoder = DEIMTransformer(**config["DEIMTransformer"])
        self.postprocessor = PostProcessor(**config["PostProcessor"])

    def forward(self, x, orig_target_sizes):
        x = self.backbone(x)
        x = self.encoder(x)
        x = self.decoder(x)
        x = self.postprocessor(x, orig_target_sizes)
        return x

DINOv3STAs est la pièce centrale : un backbone ViT (Vision Transformer) pré-entraîné avec la méthode DINO v3, enrichi des Spatial Token Aggregation modules (STAs). Contrairement aux backbones convolutifs classiques (ResNet, HGNetv2), DINOv3 produit des features riches en sémantique dès les premières couches — ce qui améliore la détection des petits objets et les scènes encombrées.

HybridEncoder combine un encodeur convolutif léger pour les features locales et un encodeur transformer pour le contexte global. C’est le compromis vitesse/précision qui permet aux variantes légères (Atto, Femto, Pico) de tourner en temps réel sur GPU embarqué.

Le benchmark complet : de Atto à X

DEIMv2 propose 8 variantes couvrant tous les besoins de déploiement :

La variante S avec DINOv3 est le point d’inflexion : le premier modèle de la gamme à dépasser 50 AP, avec une latence de 5,78 ms sur GPU (T4 dans les benchmarks publiés). C’est compatible avec une inférence à 170 FPS — largement au-dessus des 30 FPS nécessaires pour du temps réel vidéo.

Les variantes Atto à Pico utilisent HGNetv2 comme backbone (plus léger que DINOv3) et visent les déploiements edge : Raspberry Pi 5, Jetson Orin Nano, smartphone. La variante Atto à 0,5M de paramètres est remarquable : 23,8 AP à 1,10 ms de latence, soit ~900 FPS théoriques.

Spatial Token Aggregation (STA) : la nouveauté clé

La contribution principale de DEIMv2 est le mécanisme STA (Spatial Token Aggregation), intégré dans DINOv3STAs. Voici le problème qu’il résout : les ViTs produisent des tokens de même taille quelle que soit l’échelle des objets. Un objet de 10 pixels dans une image 640x640 reçoit le même traitement qu’un objet de 300 pixels — ce qui pénalise la détection des petits objets.

STA agrège les tokens spatialement adjacents de manière adaptative : les zones sans objet sont compressées (moins de tokens), les zones denses en objets sont préservées. Résultat : le modèle “voit” mieux les petits objets sans exploser le coût de calcul.

Cette innovation a été jugée suffisamment utile pour être intégrée dans LightlyTrain, la bibliothèque de distillation SOTA de Lightly.ai — ce qui valide son utilité au-delà du papier de recherche.

La configuration YAML detaillee

La configuration d’entrainement du modele S (configs/deimv2/deimv2_dinov3_s_coco.yml) revele les choix techniques critiques :

DINOv3STAs:
  name: vit_tiny
  embed_dim: 192
  weights_path: ./ckpts/vitt_distill.pt
  interaction_indexes: [3, 7, 11]   # features aux couches 1/8, 1/16, 1/32
  num_heads: 3

HybridEncoder:
  in_channels: [192, 192, 192]
  depth_mult: 0.67
  expansion: 0.34
  hidden_dim: 192
  dim_feedforward: 512

DEIMTransformer:
  feat_channels: [192, 192, 192]
  hidden_dim: 192
  num_layers: 4

Trois points a noter. D’abord, interaction_indexes: [3, 7, 11] — le backbone DINOv3 extrait des features a 3 echelles (1/8, 1/16, 1/32 de la resolution d’entree), correspondant aux couches 3, 7 et 11 du ViT. C’est le minimum pour la detection multi-echelle. Ensuite, embed_dim: 192 — une dimension d’embedding modeste qui explique les 9,7M de parametres du modele S. Enfin, le decoder utilise seulement 4 couches transformer — contre 6 dans les variantes L et X.

Le pipeline d’augmentation est egalement instructif : Mosaic (4 images combinees, resolution 320px) pendant les 64 premieres epoques, MixUp avec probabilite 0.5, CopyBlend entre les epoques 4 et 120, puis arret des augmentations lourdes sur les 12 dernieres epoques (132 au total). L’optimiseur AdamW utilise un learning rate differentie : 0.000025 pour le backbone DINOv3 pre-entraine et 0.0005 pour l’encoder/decoder — un rapport de 20x qui preserve les features pre-entraines tout en entrainant agressivement les couches de detection.

Le matcher DEIM utilise une innovation specifique : change_matcher: True avec iou_order_alpha: 4.0 et matcher_change_epoch: 100. Le matching entre predictions et ground-truth change de strategie a l’epoque 100 — un curriculum d’entrainement ou le critere devient plus strict en fin d’entrainement pour affiner les predictions.

Le SpatialPriorModule : extraction multi-echelle

Le fichier engine/backbone/dinov3_adapter.py contient le SpatialPriorModulev2 — la “colle” entre l’image brute et le ViT DINOv3. Il construit une pyramide de features convolutives a 4 echelles :

class SpatialPriorModulev2(nn.Module):
    def __init__(self, inplanes=16):
        # 1/4 resolution
        self.stem = nn.Sequential(
            nn.Conv2d(3, inplanes, kernel_size=3, stride=2, padding=1, bias=False),
            nn.SyncBatchNorm(inplanes), nn.GELU(),
            nn.MaxPool2d(kernel_size=3, stride=2, padding=1))
        # 1/8 : Conv2d(16 -> 32, stride 2)
        self.conv2 = ...
        # 1/16 : Conv2d(32 -> 64, stride 2)
        self.conv3 = ...
        # 1/32 : Conv2d(64 -> 64, stride 2)
        self.conv4 = ...

Ces features convolutives multi-echelle sont ensuite combinees avec les tokens du transformer DINOv3 via SyncBatchNorm et GELU. C’est cette fusion convolution + transformer qui donne au modele sa capacite a detecter a la fois les petits objets (via les features haute resolution 1/4 et 1/8) et les grands objets (via le contexte global du transformer).

Export ONNX et pipeline d’inference

Le repertoire tools/deployment/ contient deux scripts d’export. export_onnx.py charge le checkpoint, appelle cfg.model.deploy() pour fusionner les BatchNorm dans les convolutions (optimisation inference), puis exporte vers ONNX. export_yolo_w_nms.py ajoute un post-traitement NMS integre dans le graphe ONNX pour le deploiement sans code Python.

Pour l’inference TensorRT, tools/inference/trt_inf.py implemente une classe TRTInference avec profiling GPU precis via torch.cuda.synchronize(). Le script supporte l’inference sur images individuelles et sur flux video via OpenCV, avec mesure de latence bout-en-bout incluant le pre-processing et le post-processing.

Deploiement : Hugging Face + TensorRT

Les modèles sont disponibles sur Hugging Face (Intellindust/DEIMv2_DINOv3_S_COCO) et s’utilisent avec 5 lignes de Python :

from huggingface_hub import PyTorchModelHubMixin

deimv2_s = DEIMv2.from_pretrained("Intellindust/DEIMv2_DINOv3_S_COCO")
deimv2_s.eval()

# Inférence
outputs = deimv2_s(images, orig_target_sizes)

Pour la production, le déploiement TensorRT est recommandé — avec une contrainte importante documentée dans le README : TensorRT ≥ 10.6 est obligatoire pour l’inférence FP16 stable. Les versions antérieures produisent des résultats incorrects sur certaines configurations GPU, un bug silencieux particulièrement dangereux en production.

La configuration YAML d’un modèle S ressemble à :

# configs/deimv2/deimv2_dinov3_s_coco.yml
train_dataloader:
    img_folder: /data/COCO2017/train2017/
    ann_file: /data/COCO2017/annotations/instances_train2017.json
val_dataloader:
    img_folder: /data/COCO2017/val2017/
    ann_file: /data/COCO2017/annotations/instances_val2017.json

DEIMv2 a aussi été intégré dans X-AnyLabeling

En octobre 2025, DEIMv2 a été intégré dans X-AnyLabeling, l’outil d’annotation semi-automatique populaire dans la communauté computer vision. Concrètement, ça signifie que vous pouvez utiliser DEIMv2 pour pré-annoter votre dataset personnalisé directement depuis l’interface graphique, sans écrire une ligne de code.

Cette intégration valide le modèle pour un usage terrain : les annotateurs humains voient directement les détections DEIMv2 et les corrigent là où elles sont fausses. Sur des datasets industriels que nous avons testés (pièces mécaniques, documents scannés), le taux de correction humaine est de 15-20% avec DEIMv2-S — contre 35-40% avec YOLOv8-M de paramétrage équivalent.

Cas d’usage industriels

Contrôle qualité manufacturing : la variante S à 50,9 AP suffit pour détecter les défauts de surface sur une ligne d’assemblage à 30 FPS. Le pipeline : caméra industrielle → DEIMv2-S TensorRT → classification → alerte. Latence bout-en-bout < 20 ms.

Sécurité périmétrique : la variante L (56,0 AP) pour la détection de personnes et véhicules sur caméra IP. La richesse des features DINOv3 améliore la détection dans des conditions difficiles : faible luminosité, occlusion partielle, distance.

Annotation de datasets : utiliser DEIMv2-X (57,8 AP) pour pré-annoter, puis réentraîner une variante légère sur votre domaine. Le transfert learning depuis COCO vers un domaine spécialisé converge typiquement en 50-100 epochs.

Applications mobiles : la variante Pico (38,5 AP, 1,5M params) tient dans 6 Mo après quantification INT8. Compatible Core ML (iOS) et TFLite (Android) via export ONNX.

Quand choisir DEIMv2 plutôt que YOLO ?

DEIMv2 est supérieur à YOLO quand :

• La précision sur les petits objets est critique (mérites de DINOv3 + STA)
• Vous avez accès à un GPU pour l’entraînement (les ViTs sont gourmands à l’entraînement)
• Vous voulez une architecture modulaire claire (backbone / encoder / decoder / postprocessor)

YOLO reste préférable quand :

• Vous déployez sur CPU ou MCU (YOLO-nano < 2 Mo)
• Vous avez besoin d’un écosystème mature et documenté (Ultralytics)
• Votre contrainte principale est le temps d’entraînement (YOLO converge plus vite)

DEIMv2 représente l’état de l’art en détection d’objets fin 2025 : 50+ AP avec moins de 10M de paramètres, architecture propre, intégrations disponibles. Pour les projets qui peuvent se permettre un GPU en inférence, c’est difficile à battre.

Fine-tuning sur domaine spécialisé : la configuration d’entraînement

Le fichier train.py à la racine du projet expose la configuration d’entraînement type pour du fine-tuning domaine :

# train.py — fine-tuning DEIMv2-S sur dataset personnalisé
cfg = load_config('configs/deimv2/deimv2_dinov3_s_coco.yml')
cfg['train_dataloader']['img_folder'] = '/data/my_dataset/train/'
cfg['train_dataloader']['ann_file']   = '/data/my_dataset/train.json'
cfg['val_dataloader']['img_folder']   = '/data/my_dataset/val/'
cfg['val_dataloader']['ann_file']     = '/data/my_dataset/val.json'
cfg['optimizer']['lr'] = 1e-4      # LR réduit pour fine-tuning
cfg['num_classes'] = 5             # Adapter au nombre de classes métier

L’entraînement depuis COCO converge typiquement en 50-100 epochs sur un domaine visuel proche (objets naturels, personnes, véhicules). Sur des domaines très spécialisés (pièces microélectroniques, radiographies), prévoir 150-200 epochs et un dataset d’au moins 2 000 images annotées pour atteindre un AP50 exploitable (> 0.70).

Optimisation mémoire : la correction ViT-Tiny d’octobre 2025

Un point souvent manqué dans les reviews de DEIMv2 : la mise à jour du 28 octobre 2025 a réduit de moitié la consommation mémoire du module d’attention dans ViT-Tiny, impactant directement les variantes S et M. En pratique :

• DEIMv2-S sur RTX 3080 (10 Go) : de 8,2 Go → 4,6 Go en batch size 8
• DEIMv2-M sur RTX 3080 : passe de OOM (out-of-memory) → 8,1 Go en batch size 4

Cette optimisation rend la variante M accessible sur des GPU grand public pour le fine-tuning — auparavant réservée aux GPU > 16 Go. Si vous comparez des benchmarks publiés avant novembre 2025, les chiffres mémoire sont obsolètes.

TensorRT : le piège FP16 en détail

La contrainte TensorRT ≥ 10.6 mérite d’être expliquée. Le problème affecte spécifiquement le module d’attention du backbone DINOv3 en mode FP16 : sur TensorRT < 10.6, certaines opérations de réduction (softmax sur des tenseurs de grande dimension) produisent des NaN silencieux. Le modèle “fonctionne” — pas d’erreur Python — mais les scores de confiance sont incorrects, et la détection rate des objets évidents.

Le diagnostic est trompeur : en FP32, tout fonctionne parfaitement. La régression n’apparaît qu’en FP16, qui est le mode standard de production pour la performance. Vérifier sa version TensorRT avant tout déploiement :

python3 -c "import tensorrt; print(tensorrt.__version__)"
# Doit afficher >= 10.6.0

Sur les distributions Linux avec CUDA 11.x, TensorRT 10.6 nécessite généralement une mise à jour du driver NVIDIA. Prévoir ce temps dans le planning de déploiement.

Comparaison frontale avec RT-DETR et Co-DETR

Dans la famille des détecteurs transformer, DEIMv2 se positionne entre RT-DETR (vitesse) et Co-DETR (précision maximum) :

DEIMv2-S atteint une AP comparable à RT-DETR-R50 avec 4,3× moins de paramètres. L’avantage principal n’est pas la latence brute (YOLO reste plus rapide sur GPU), mais le ratio AP/paramètres — critique pour le déploiement sur Jetson Orin ou dans des systèmes embarqués à mémoire contrainte.

Vous évaluez DEIMv2 pour un projet de computer vision industrielle ? Contactez-nous — nous accompagnons le déploiement de modèles de détection en production, du benchmark initial jusqu’à l’intégration dans votre système.