Déploiement d'Ultralytics YOLO sur AMD Xilinx avec Vitis AI#

Les appareils AMD Xilinx équipent de nombreuses caméras industrielles, de nombreux systèmes de vision automobile, robots, drones et produits d’imagerie médicale dans le monde. Ils associent des processeurs Arm à une logique programmable et, sur les appareils les plus récents, à des AI Engines dédiés, si bien qu’une seule puce peut capturer une vidéo, la prétraiter, effectuer la détection d’objets et agir sur le résultat avec une latence d’inférence faible et prévisible.

Ce guide présente les différentes familles d'appareils AMD Xilinx, le fonctionnement de l'IA sur ces appareils, les opérateurs Ultralytics YOLO pris en charge par chaque accélérateur et le workflow de déploiement des modèles YOLO sur le matériel Zynq UltraScale+, Kria et Versal, étape par étape.

Qu'est-ce qu'AMD Xilinx ?#

Xilinx a inventé les réseaux logiques programmables (FPGA) dans les années 1980 et est devenu un fournisseur majeur de SoC adaptatifs et de FPGA. AMD a finalisé l'acquisition de Xilinx en février 2022, et les gammes de produits sont désormais commercialisées sous la marque AMD sous les noms AMD Zynq, AMD Kria, AMD Versal et AMD Vitis.

Termes et concepts clés#

Le déploiement sur AMD Xilinx utilise un vocabulaire qui lui est propre. Le tableau ci-dessous explique tous les termes employés dans ce guide.

Familles d'appareils AMD Xilinx pour l'IA en périphérie#

Les appareils AMD Xilinx destinés à l'IA en périphérie se répartissent en trois familles. Zynq et Kria utilisent la DPU dans la logique programmable, tandis que les appareils Versal AI Edge abordés ici utilisent le NPU sur leurs moteurs IA.

Zynq UltraScale+ MPSoC#

Chaque puce Zynq UltraScale+ associe une logique FPGA à un système de traitement Arm, doté de cœurs Cortex-A53 double cœur (CG) ou quadruple cœur (EG et EV) et de cœurs Cortex-R5F temps réel. Les appareils EV intègrent un codec vidéo H.264/H.265 câblé. Pour exécuter des réseaux neuronaux, les concepteurs intègrent une DPU à la logique, à côté de leurs pipelines caméra et vidéo. Sur les petits appareils, la DPU doit partager l'espace avec le reste de la conception.

Modules système Kria#

Le module Kria K26 regroupe un Zynq UltraScale+ MPSoC, de la mémoire et l'alimentation dans un module prêt pour la production. Tu n'as donc pas à concevoir toi-même le sous-système processeur, mémoire et alimentation. Le module se branche sur une carte porteuse, qu'il s'agisse d'une carte de kit de démarrage ou de ta propre conception. Il équipe le kit de démarrage Vision AI KV260 pour les caméras intelligentes et le kit de démarrage robotique KR260 pour la robotique. Comme le K26 repose sur Zynq UltraScale+, il utilise le même workflow DPU. La gamme Kria comprend également d'autres modules : vérifie donc le processeur utilisé par ton module avant de choisir un workflow.

SoC adaptatifs Versal#

Versal est la famille de SoC adaptatifs d'AMD. Les séries AI Edge et AI Core ajoutent des moteurs IA câblés aux côtés des cœurs Arm et de la logique programmable, tandis que certaines autres séries Versal ne comportent pas de moteurs IA. L'IP NPU d'AMD fonctionne conjointement sur les moteurs IA et la logique programmable, et Vitis AI cible les composants AIE-ML de la série AI Edge, tels que VE2302 et VE2802. La série Versal AI Edge (kit d'évaluation VEK280) et la série Versal AI Edge Gen 2 (kit d'évaluation VEK385) sont les cibles actuelles d'AMD pour l'IA en périphérie et le principal objectif des versions récentes de Vitis AI.

Fonctionnement de l'IA sur les appareils AMD Xilinx : DPU ou NPU#

La plupart des déploiements d'IA sur AMD Xilinx suivent le même principe. L'accélérateur exécute les couches qu'il prend en charge, le CPU Arm gère le prétraitement, le post-traitement et les couches que l'accélérateur ne peut pas exécuter, et un environnement d'exécution sur la carte coordonne les deux.

graph LR
    A[Camera / video input]:::start --> B[Arm CPU<br>Linux, preprocessing,<br>post-processing]:::proc
    B <--> C[AI accelerator<br>DPU in programmable logic<br>or NPU on AI Engines + PL]:::out
    B --> D[Application<br>alerts, control, display]:::start

    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef out fill:#9C27B0,color:#fff

AMD a commercialisé deux générations d'accélérateurs, chacune avec sa propre chaîne d'outils et son propre fichier de modèle compilé. Ce guide s'appuie sur Vitis AI 3.5 pour la DPU et Vitis AI 6.3 pour le NPU ; consulte la documentation AMD actuelle pour les versions ultérieures.

Quel flux Vitis AI me faut-il ?#

Choisis le flux en fonction du composant de ta carte :

graph TD
    A[Start: which AMD device<br>is on your board?]:::start --> B{Device family?}:::decide
    B -->|Zynq UltraScale+ MPSoC<br>or Kria K26| C[DPU flow<br>Vitis AI 3.5]:::proc
    B -->|Versal AI Edge<br>VEK280| D[NPU snapshot flow<br>Vitis AI 6.3]:::proc
    B -->|Versal AI Edge Gen 2<br>VEK385| E[NPU Quark flow<br>Vitis AI 6.3]:::proc
    C --> F[Train YOLO with Hard-Swish<br>then compile to .xmodel]:::out
    D --> G[Run your model on calibration<br>images to capture a snapshot]:::out
    E --> H[Quantize ONNX with Quark<br>then compile to .rai]:::out

    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef decide fill:#FF9800,color:#fff
    classDef out fill:#9C27B0,color:#fff

Compatibilité des modèles YOLO et opérateurs pris en charge#

Un accélérateur n’accélère que les opérateurs qu’il implémente matériellement. Lorsqu’un modèle contient un opérateur non pris en charge, le compilateur délègue généralement cette partie du réseau au CPU Arm, et chaque aller-retour entre l’accélérateur et le CPU ajoute de la latence. Certains opérateurs ne peuvent pas être partitionnés : sur la NPU Versal AI Edge Gen 2, AMD répertorie des opérateurs comme NonZero et NonMaxSuppression qui peuvent contraindre l’ensemble du modèle à s’exécuter sur le CPU. La prise en charge des opérateurs est le facteur le plus important pour les performances d’un modèle YOLO sur le matériel AMD Xilinx.

graph LR
    subgraph S1 [Stock YOLO26 on the DPU]
        A1[Conv]:::out --> A2[SiLU<br>CPU]:::error --> A3[Conv]:::out --> A4[SiLU<br>CPU]:::error --> A5[...]:::proc
    end
    subgraph S2 [Hard-Swish YOLO26 on the DPU]
        B1[Backbone<br>Conv + Hard-Swish<br>DPU]:::out --> B2[C2PSA attention<br>CPU]:::error --> B3[Neck<br>DPU]:::out --> B4[C3k2 attention<br>CPU]:::error --> B5[Detect head<br>DPU]:::out --> B6[Sigmoid and<br>post-processing<br>CPU]:::error
    end

    classDef proc fill:#2196F3,color:#fff
    classDef out fill:#9C27B0,color:#fff
    classDef error fill:#F44336,color:#fff

Le tableau indique où s’exécute chaque opérateur d’un modèle YOLO26. Un export ONNX standard de YOLO26n contient 87 activations SiLU, chacune exportée sous la forme d’un Sigmoid et d’un Mul, ainsi que 4 opérateurs MatMul et 2 opérateurs Softmax issus de ses deux blocs d’attention : le bloc C2PSA à la fin du backbone (couche 10) et le bloc C3k2 avec attention qui produit la sortie P5 (couche 22).

Sources : opérateurs pris en charge UG1414 d’AMD, prise en charge des opérateurs PyTorch et listes d’opérateurs pris en charge, partition CPU et non pris en charge pour Versal AI Edge Gen 2. La prise en charge dépend aussi de ta configuration DPU et des motifs du graphe ; vérifie donc toujours le rapport de partition du compilateur.

Rendre YOLO26 compatible avec la DPU grâce à Hard-Swish#

La DPU ne fusionne dans ses convolutions que ReLU, ReLU6, LeakyReLU, Hard-Swish et Hard-Sigmoid. Hard-Swish est une approximation de SiLU adaptée au matériel, ce qui en fait son remplacement naturel. Les fichiers YAML de modèles Ultralytics acceptent une clé activation qui modifie l’activation par défaut des blocs Conv (Guide de configuration YAML des modèles).

Copie yolo26.yaml vers yolo26-hswish.yaml, puis ajoute une ligne sous les paramètres :

# Parameters
nc: 80 # number of classes
activation: nn.Hardswish() # default Conv activation, DPU-native
end2end: True # whether to use end-to-end mode

Construis ensuite le modèle, transfère les poids YOLO26 préentraînés et affine le modèle sur ton jeu de données :

from ultralytics import YOLO

# Construire YOLO26n avec des activations Hard-Swish ; le « n » du nom indique l’échelle nano
model = YOLO("yolo26n-hswish.yaml").load("yolo26n.pt")  # transférer les poids préentraînés

# Affiner le modèle pour que le réseau s’adapte à Hard-Swish
model.train(data="coco8.yaml", epochs=100, imgsz=640)

Les activations n’ont pas de poids, donc tous les poids préentraînés sont transférés. Le graphe ONNX exporté contient alors 87 opérateurs HardSwish et aucun SiLU. Remplace coco8.yaml par ton propre jeu de données, puis compare la précision au modèle SiLU avec le mode Val avant le déploiement.

Gérer les blocs d’attention sur la DPU#

YOLO26 applique l’attention à la résolution la plus basse (une grille de 20 × 20 pour une entrée de 640) à deux endroits : le bloc C2PSA à la couche 10 et le bloc C3k2 avec attention à la couche 22. YOLO11 comporte un seul bloc C2PSA. Sur une DPU, ses opérateurs MatMul et Softmax s’exécutent sur le CPU, ce qui divise le modèle en sous-graphes alternant entre DPU et CPU. Tu as trois possibilités :

1. Accepter les blocs CPU. Le .xmodel compilé contient alors des sous-graphes CPU. Exécute-le avec le Graph Runner d’AMD, qui exécute ensemble les sous-graphes DPU et CPU lorsqu’une implémentation CPU existe pour chaque opérateur ; sinon, tu dois implémenter et enregistrer les opérateurs manquants. À 20 × 20, le calcul d’attention est léger, mais chaque transfert supplémentaire entre la DPU et le CPU ajoute de la latence ; mesure donc les performances sur ta carte.

2. Utiliser un YAML sans attention. Dans ton YAML Hard-Swish, remplace la couche C2PSA par nn.Identity pour que les indices de couche utilisés par Concat et Detect restent valides, puis désactive l’attention dans la couche 22 :

   backbone:
       # ... layers 0-9 unchanged
       - [-1, 1, nn.Identity, []] # 10 C2PSA removed; keeps later layer indices valid
   
   head:
       # ... layers 11-21 unchanged
       - [-1, 1, C3k2, [1024, True, 0.5, False]] # 22 (P5/32-large), attention disabled
       - [[16, 19, 22], 1, Detect, [nc]] # Detect(P3, P4, P5)

   Le graphe ONNX exporté ne contient alors aucun opérateur MatMul ni Softmax. Les poids d’attention ne sont plus applicables (624 des 666 poids de YOLO26n sont transférés) ; affine donc le modèle plus longtemps et compare la précision avec le mode Val.

3. Utiliser un modèle sans attention, comme YOLOv8, qu’AMD a utilisé dans ses propres exemples DPU.

Sur Versal AI Edge Gen 2, les opérateurs d’attention sont répertoriés comme pris en charge par la NPU ; ces modifications sont donc généralement inutiles. Vérifie leur emplacement dans le rapport du compilateur, car AMD précise que des opérateurs pris en charge peuvent tout de même basculer sur le CPU en raison de contraintes de configuration ou de mémoire.

Compatibilité des modèles en un coup d’œil#

Déployer YOLO26 sur du matériel AMD Xilinx dès aujourd’hui#

En attendant la disponibilité de l’export natif, le déploiement se déroule en quatre étapes :

graph LR
    A[1. Train or fine-tune<br>Ultralytics YOLO]:::start --> B{Target?}:::decide
    B -->|Versal NPU| C[2. Export to ONNX<br>model.export]:::proc
    B -->|Zynq or Kria DPU| D[2. Keep the trained<br>PyTorch checkpoint]:::proc
    C --> E[3. Quantize and compile<br>Vitis AI 6.3 Docker]:::proc
    D --> F[3. Quantize and compile<br>Vitis AI 3.5 Docker]:::proc
    E --> G[4. Run on the board<br>VART-ML or ONNX Runtime]:::out
    F --> H[4. Run on the board<br>VART]:::out
    G -.->|accuracy check| A
    H -.->|accuracy check| A

    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef decide fill:#FF9800,color:#fff
    classDef out fill:#9C27B0,color:#fff

Étape 1 : entraîner ou affiner ton modèle#

Entraîne ton modèle sur tes propres données avec le mode Train ou sur la plateforme Ultralytics. Pour les cibles DPU, pars du YAML Hard-Swish. Établis une référence avec le mode Val afin de pouvoir mesurer plus tard l’impact de la quantification sur la précision.

Étape 2 : exporter au format ONNX pour les cibles NPU#

ONNX est le format d’entrée commun aux flux NPU d’AMD. Le flux DPU quantifie directement le checkpoint PyTorch entraîné dans l’image Docker Vitis AI 3.5 ; les utilisateurs de DPU peuvent donc ignorer cette étape. Exporte avec une taille de lot fixe de 1 et un opset pris en charge par AMD ; le tutoriel YOLOv8m d’AMD pour Versal AI Edge Gen 2 utilise l’opset 17.

from ultralytics import YOLO

# Charger le modèle entraîné à l’étape 1
model = YOLO("runs/detect/train/weights/best.pt")

# Exporter au format ONNX avec une forme statique pour le compilateur AMD
model.export(format="onnx", opset=17, imgsz=640)  # crée « best.onnx » à côté de « best.pt »

Consulte l’intégration ONNX et les arguments d’export pour connaître toutes les options. Si nms n’est pas défini, exécute NMS sur le CPU après l’inférence ; pour YOLO26, nms=False sélectionne à la place la tête sans NMS. N’intègre pas NMS avec nms=True, car AMD répertorie NonMaxSuppression parmi les opérateurs susceptibles de contraindre l’ensemble du modèle à s’exécuter sur le CPU.

Étape 3 : quantifier et compiler avec Vitis AI#

Les flux de travail ci-dessous utilisent les images Docker d’AMD sur un hôte Linux x86-64. Tu n’as pas besoin de la carte pour cette étape. Choisis l’onglet correspondant à ton appareil :

Étape 4 : exécution et validation sur la carte#

Commence par préparer la carte. Elle doit exécuter une conception matérielle et une image Linux qui contiennent la configuration de l’accélérateur pour laquelle tu as compilé, ainsi que l’environnement d’exécution Vitis AI correspondant. Consulte les guides de configuration d’AMD pour les cibles DPU Zynq UltraScale+ et Kria, Versal AI Edge (VEK280) et Versal AI Edge Gen 2 (VEK385).

Copie ensuite les artefacts nécessaires à ton environnement d’exécution :

Pour les flux NPU, le graphe ONNX exporté décode déjà les boîtes et applique la fonction sigmoïde aux scores de classe ; l’hôte n’a donc qu’à interpréter la sortie :

• nms non défini : les modèles de détection produisent un tenseur (1, 4 + nc, anchors) composé de xywh boîtes et de scores par classe. Sélectionne la meilleure classe pour chaque ancre, convertis les boîtes en coordonnées de coins, applique un seuil de confiance et exécute NMS ; la fonction non_max_suppression d’Ultralytics effectue toutes ces étapes.
• nms=False (YOLO26) : le modèle produit un tenseur (1, max_det, 6) composé de [x1, y1, x2, y2, score, class] lignes, auquel il suffit d’appliquer un seuil de confiance.

Dans les deux cas, redimensionne les boîtes de l’image d’entrée avec letterboxing aux dimensions de l’image d’origine. Seuls les graphes coupés avant l’étape de décodage nécessitent le décodage des boîtes sur l’hôte. Sur le DPU, les tampons VART stockent des valeurs INT8 à virgule fixe : interroge la forme et l’échelle fix_point de chaque tenseur, quantifie les entrées et déquantifie les sorties avant d’appliquer les étapes ci-dessus. Graph Runner renvoie les sorties du graphe complet, tandis qu’un exécuteur DPU seul renvoie les sorties intermédiaires du sous-graphe DPU, dont ton code doit terminer le calcul. Les dispositions ci-dessus correspondent aux dispositions ONNX (vue CPU) : par défaut, VART-ML utilise des vues de tenseur matérielles dont la forme, le type de données et la disposition mémoire peuvent différer ; configure donc les types de tenseur d’entrée et de sortie de l’exécuteur en vues CPU ou convertis toi-même le format matériel (consulte la présentation de l’architecture VART-ML d’AMD).

Compare la précision sur l’appareil à la référence FP32 de l’étape 1 en utilisant ton propre jeu de validation et les mêmes métriques de performance, comme le mAP. Les résultats publiés par AMD pour YOLOv8m sur le VEK385 illustrent le coût en précision du déploiement INT8 :

Source : tutoriel YOLOv8m pour Versal AI Edge Gen 2 d’AMD, qui indique également un temps d’inférence moyen de 10,69 ms sur 100 exécutions VART à dp_size=1.

Applications concrètes#

Les appareils AMD Xilinx sont courants dans les cas où l’IA visuelle doit fonctionner en temps réel, avec une faible consommation et à proximité du capteur :

• Sécurité industrielle et dans la construction : détecte les personnes et les machines à proximité d’équipements lourds, et surveille les zones de travail grâce à la détection d’objets et au comptage d’objets.
• Vision automobile et hors route : exécute la perception par caméra sur des composants homologués pour l’automobile, au service des véhicules autonomes et de l’aide à la conduite.
• Caméras intelligentes et analyse vidéo : combine la capture vidéo, l’encodage et l’inférence YOLO sur une seule puce pour les systèmes de sécurité et l’analyse vidéo.
• Vision industrielle et contrôle qualité : associe l’acquisition d’images à grande vitesse basée sur FPGA à YOLO pour la segmentation d’instances ou la classification afin de détecter les défauts en ligne.
• Robotique et drones : utilise les modules Kria KR260 ou Versal pour l’estimation de pose, la détection d’objets orientés et la navigation avec une latence déterministe.

Résumé#

Les appareils AMD Xilinx exécutent les modèles YOLO avec deux générations d’accélérateurs. Le DPU des appareils Zynq UltraScale+ et Kria utilise le flux Vitis AI 3.5 figé et produit des fichiers .xmodel. Il nécessite des activations natives du DPU, comme Hard-Swish, et exécute l’attention sur le CPU. Le NPU de Versal AI Edge et Versal AI Edge Gen 2 utilise les versions actuelles de Vitis AI. Le NPU Gen 2 prend en charge SiLU et les opérateurs d’attention, et exécute l’exemple YOLOv8m d’AMD sur le VEK385 presque entièrement sur le NPU, tandis que la couverture des opérateurs sur le NPU VEK280, plus ancien, dépend de la version de Vitis AI et de la précision.

L’export natif Ultralytics pour les appareils AMD Xilinx sera bientôt disponible. D’ici là, entraîne avec Ultralytics, exporte au format ONNX pour les cibles NPU Versal ou conserve le checkpoint PyTorch pour les cibles DPU, puis compile avec Vitis AI comme décrit ci-dessus. Pour d’autres cibles de déploiement, consulte le guide des options de déploiement des modèles, les bonnes pratiques de déploiement et les intégrations d’accélérateurs comme Hailo, Rockchip RKNN et Axelera.

FAQ#