69 entreprises Edge AI et NPU : puces, SDK et YOLO (2026)

Il n'existe pas de marché NPU unique. Ce guide non exhaustif suit 69 entreprises et écosystèmes de plateformes : 51 fabricants de puces ou plateformes déployables, neuf fournisseurs d'IP NPU et neuf entreprises clairement indiquées comme à surveiller. Ils couvrent plusieurs catégories d'accélérateurs incompatibles et presque autant de chaînes de compilation. La plupart promettent le même parcours : exporter un modèle, le quantifier, le compiler, copier un artefact propriétaire sur une carte et appeler un runtime du fabricant. Les détails déterminent si cela prend un après-midi ou un trimestre d'ingénierie.

Ce guide recense les entreprises qui fournissent du matériel crédible pour la vision par ordinateur en 2026. Il indique les puces pertinentes, les noms des SDK et compilateurs, les artefacts de déploiement, le niveau d'accès public et les modèles réellement documentés par le fabricant. Il s'attarde aussi sur Amlogic, dont la nouvelle pile ADLA diffère sensiblement de l'ancien écosystème NPU A311D.

Périmètre de recherche : les sources ont été vérifiées le 15 août 2026. Les mentions de modèles précis proviennent de pages produit, de documentation, de model zoos, de dépôts ou de tutoriels du fabricant, sauf indication contraire. Les TOPS annoncés sont des chiffres fournis par les fabricants et ne constituent pas des résultats de benchmark comparables de manière indépendante. Il s'agit d'un guide pour les développeurs, pas d'un conseil en investissement ni d'un classement payant.

Navigation rapide : tableaux des entreprises | analyse détaillée d'Amlogic | profils des fabricants | tableau des artefacts compilés | accès et cycle de vie | feuille de route LibreYOLO

Le constat essentiel

Le matériel est fragmenté, mais le schéma de déploiement est remarquablement cohérent :

PyTorch checkpoint
    -> ONNX or TFLite interchange graph
    -> representative calibration data
    -> vendor quantizer and graph compiler
    -> chip-specific binary or model package
    -> vendor runtime on the target
    -> application preprocessing, decode, NMS and rendering

ONNX autorise explicitement les runtimes, les générateurs de code et les implémentations matérielles, mais un fichier ONNX ne constitue qu'un point de transfert. Cela ne signifie pas que chaque opérateur ONNX peut être abaissé vers chaque accélérateur. Les formes d'entrée statiques, les contraintes sur les opérateurs pris en charge, les règles de quantification et le repli côté hôte déterminent ce qui s'exécute réellement sur le NPU.

La pile logicielle fait donc partie de la puce. Un NPU rapide sur le papier, mais doté d'un compilateur verrouillé ou fragile, peut être une moins bonne cible qu'un appareil plus modeste avec une chaîne d'outils publique, un model zoo, un simulateur et un runtime stable.

Ce que signifie « pris en charge » dans ce guide

La documentation des fabricants emploie le mot support avec beaucoup de latitude. Cet article distingue quatre niveaux de preuve :

Cette distinction compte. « Importe ONNX » n'équivaut pas à « prend en charge la segmentation YOLO11 ». Un modèle peut être analysé puis basculer sur le CPU, compiler avec des valeurs de sortie incorrectes, dépasser la mémoire de l'accélérateur ou perdre en exactitude pendant la quantification.

Entreprises et plateformes NPU en un coup d'œil

Les tableaux mêlent volontairement SoC, accélérateurs discrets, capteurs intelligents et cibles GPU/FPGA proches. Ils interviennent dans le même choix de déploiement, même si les fabricants parlent de NPU, AIPU, BPU, KPU, DLA, HTP, TPU ou MLA.

SoC embarqués, capteurs intelligents et processeurs industriels

Accélérateurs edge dédiés et modules

Plateformes proches que les développeurs comparent aux NPU

Amlogic : deux générations de NPU, pas une seule

Amlogic mérite une explication plus détaillée, car les informations en ligne mélangent souvent des produits incompatibles. L'entreprise propose une ancienne voie fondée sur VeriSilicon et une nouvelle voie propriétaire ADLA. Elles n'utilisent ni le même compilateur, ni le même artefact, ni le même runtime.

La fiche technique A311D identifie le NPU INT8 original de 5-TOPS. L'ancienne page d'application Khadas VIM3 et la présentation du NPU documentent DenseNet CTC, MTCNN, RetinaFace, YOLOFace, YOLOv2, YOLOv3, YOLOv3-tiny, YOLOv4, YOLOv7-tiny et YOLOv8n ; la présentation ajoute YOLOv8n-pose et indique que FaceNet est obsolète. Ces exemples sont réels, mais prouvent le fonctionnement de l'ancien écosystème Acuity .nb, pas celui des puces ADLA actuelles. A311D n'est pas A311D2, et C305X n'est pas C305X2.

Un second piège concerne le matériel. Le guide des révisions Khadas VIM4 indique que la carte d'origine V12/A311D2 révision B ne possède pas de NPU ; le NPU annoncé à 3,2-TOPS apparaît sur les cartes V13A et ultérieures, équipées de la puce A311D2-N0D révision C. Le nom du produit ne suffit pas pour choisir un appareil de test.

La pile AMLNN et ADLA actuelle

L'AMLNN Toolkit actuel couvre la conversion, la quantification, la compilation, l'inférence et le profiling des modèles. Son guide utilisateur de mai 2026, épinglé sur une révision précise, documente les importateurs ONNX, TFLite en virgule flottante ou quantifié, TorchScript .pt et PyTorch 2 ExportedProgram/PT2. Le guide détaillé indique que les parcours TensorFlow, Paddle et Keras sont prévus, malgré la formulation plus large de la présentation du dépôt. Le compilateur produit des .adla. Le déploiement Python utilise AMLNN ou amlnn_edge_toolkit_lite ; en C/C++ natif, il faut lier libnnsdk.so via nnsdk2.h. Le développement côté hôte peut utiliser ADB avec nnserver ; le runtime cible également Android, Buildroot, Yocto et certains environnements Debian/Armbian.

Les identifiants de plateforme publiés par le toolkit comprennent actuellement :

Ce champ de cible n'est pas décoratif. Amlogic exige que .adla, nnsdk2.h, libnnsdk.so, le BSP et la génération du compilateur/runtime correspondent. Le guide de démarrage rapide épinglé requiert un pilote ADLA 2.0.2 ou plus récent, NNSDK 3.0.0 ou plus récent et NNSDK2 1.0.0 ou plus récent ; le guide de déploiement Android détaille les dépendances entre bibliothèque, en-tête, pilote et BSP. Considérez .adla comme un artefact de build lié à l'ABI, pas comme un modèle portable.

La quantification dépend elle aussi de la génération du NPU. Les cibles ADLA2 001 à 006 documentent la compilation W8A8 et W8A16. Les cibles ADLA3 007 et 008 ajoutent les combinaisons W4A8, W4A16, W8A8, W8A16 et W16A16, avec une prise en charge native INT4, FP16 et BF16 dans le guide des opérateurs. Amlogic recommande 200 à 500 échantillons de calibration représentatifs. L'option de données aléatoires sert explicitement aux tests de performance, pas à une quantification préservant l'exactitude.

Couverture des modèles documentée par Amlogic

Le model playground Amlogic épinglé constitue une preuve bien plus solide qu'une affirmation générique de prise en charge ONNX. Sa matrice publique d'exemples et de modèles cite A311D2, S905X5, A311Y3, C305X2 et A123X. Le fait que le compilateur accepte d'autres ID de cible ne prouve pas que toute cette liste de modèles y a été validée.

Le même dépôt publie les mesures suivantes d'exécution de modèles W8A8. Ce sont des mesures du réseau neuronal sur le NPU communiquées par le fabricant, et non celles d'un pipeline caméra complet.

Les réserves sont particulièrement importantes. Le guide des opérateurs Amlogic place NMS dans le logiciel pour ADLA2 comme ADLA3. Le README définit ces mesures comme des résultats d'exécution du modèle natif sur NPU, sans prétraitement ni post-traitement ; il ne précise pas si tous les transferts mémoire sont inclus. Les mesures d'exactitude YOLO utilisent des sous-ensembles COCO de 300 images et non l'ensemble complet de validation ; les mesures de classification utilisent ImageNet val1000. Les tableaux rapportent aussi une latence YOLOv8n A311Y3 différente des FPS, dans des conditions que le dépôt ne rapproche pas. Les fréquences, le mode d'alimentation, le refroidissement, l'état thermique stabilisé, les versions exactes du SDK/BSP et la durée du test ne sont pas indiqués. Utilisez ces chiffres pour comprendre une pile du fabricant, pas pour la classer face à une autre.

Pourquoi Amlogic est intéressant sur le plan stratégique

Amlogic réunit quatre propriétés inhabituelles : une large présence dans les SoC embarqués, une nouvelle pile de compilation publique, une matrice actuelle de modèles qui recoupe largement les tâches de LibreYOLO et peu d'intégrations natives dans les principales bibliothèques d'entraînement. Les dépôts actuels sont aussi récents : ils sont apparus publiquement fin 2025 et début 2026, et les manuels détaillés datent de mai à juillet 2026. Il existe donc une vraie possibilité d'être parmi les premiers, avec le risque correspondant de stabilité de l'API.

Une intégration propre devrait utiliser l'export ONNX déterministe de LibreYOLO en entrée du compilateur, exiger des images de calibration représentatives pour les builds basse précision, produire .adla avec un manifeste de métadonnées et charger le résultat via un adaptateur NNSDK2. A311D historique devrait avoir une cible .nb clairement distincte, car présenter .nb et .adla comme un seul backend entraînerait des erreurs de compatibilité silencieuses. Les dépôts Amlogic ont des licences Apache-2.0 à leur niveau principal, mais les droits de redistribution des wheels, bibliothèques partagées, nnserver et binaires AAR Android fournis doivent être confirmés directement avant que LibreYOLO les republie.

Les écosystèmes publics de déploiement les plus solides

Les entreprises suivantes offrent actuellement la combinaison la plus claire de matériel accessible, de documentation technique publique et de preuves concernant des modèles nommés. Cela ne les rend pas systématiquement plus rapides. Leurs affirmations de compatibilité sont simplement plus faciles à évaluer avant l'achat du matériel.

Hailo

Hailo est l'exemple de référence d'un écosystème dédié à l'accélération de la vision. Les modèles sont analysés et convertis en Hailo Archive, optimisés et quantifiés avec des images représentatives, puis compilés dans un fichier Hailo Executable Format (.hef). Les applications chargent ce HEF via HailoRT.

Le Hailo Model Zoo contient des recettes, des modèles pré-entraînés, des configurations de post-traitement et des mesures de performance pour la détection, la segmentation, la classification, la pose et d'autres tâches. Sa couverture YOLO comprend YOLOv3/v4/v5/v6/v7/v8/v9/v10/11/12 et YOLO26, ainsi que YOLOX, DAMO-YOLO, SSD et EfficientDet. La table de détection d'objets Hailo-8, épinglée sur une version précise, est une meilleure source de compatibilité qu'une page produit générique. L'application autonome documente aussi des pipelines YOLO déployables.

Une frontière de version est à prendre en compte. Hailo-8 et Hailo-8L utilisent l'ancienne génération Model Zoo 2.x, Dataflow Compiler 3.x et HailoRT 4.x, tandis que Hailo-10 et Hailo-15 utilisent la génération actuelle 5.x. Les recettes, le comportement des parseurs et les HEF ne sont pas interchangeables simplement parce que les appareils portent le nom Hailo.

Hailo-15 possède également une couche applicative distincte. Elle utilise Vision Processor Software Package et Hailo Media Library, et non le parcours hôte de type TAPPAS pour Hailo-8/10H. Le dépôt de référence public hailo-camera-apps a été archivé le 3 mai 2026, tandis que hailo-apps-core reste un framework applicatif public distinct. L'archivage d'un dépôt ne prouve pas la fin de vie du produit, mais les projets Hailo-15 devraient confirmer le paquet applicatif actuel dans le Developer Zone.

Le guide de déploiement Hailo de LibreYOLO s'arrête volontairement à un transfert ONNX statique, car le compilateur propriétaire ne peut pas être fourni comme dépendance Python. C'est la limite honnête entre produire un graphe adapté et prétendre avoir un HEF testé.

Rockchip

Rockchip possède l'un des plus grands écosystèmes Linux embarqués, amateur et commercial, notamment grâce aux cartes RK3588, RK3576 et RK356x. Le RKNN-Toolkit2 public convertit et quantifie les modèles sur un hôte Linux x86 ; RKNN Runtime ou Toolkit-Lite exécute ensuite le fichier .rknn obtenu sur la carte.

Le RKNN Model Zoo précise particulièrement bien les puces, familles de modèles et précisions. Sa table actuelle répertorie les parcours FP16 et INT8 pour YOLOv5/6/7/8/10/11, YOLOX, PP-YOLOE, YOLO-World et les variantes de segmentation YOLOv5/v8 ; YOLOv8 OBB et YOLOv8 pose sont répertoriés uniquement en INT8. Elle couvre également l'OCR, le visage et d'autres réseaux de segmentation.

LibreYOLO dispose déjà d'un exporteur RKNN direct et prudent. Il valide quatre variantes exactes de détection sur RK3588, peut comparer le simulateur du compilateur à ONNX Runtime et rejette les familles non validées au lieu d'assimiler une compilation réussie à des prédictions correctes. Cette revendication de prise en charge ciblée est un bon modèle pour chaque futur backend NPU.

Axelera AI

Axelera AI, souvent orthographié à tort « Accelera », développe l'AIPU Metis, vendu en produits M.2, PCIe et multipuces. Metis est la famille disponible à la commande publique ; Europa et Titania sont des produits annoncés dans le portefeuille, leur disponibilité ne doit donc pas être ramenée à un statut unique. Le SDK Voyager est public sur GitHub et gère la sélection, la compilation, la quantification, l'exécution des modèles et les pipelines applicatifs ; le support client nécessite toujours un compte.

Le Voyager Model Zoo public compte parmi les plus informatifs du marché. Il répertorie les variantes de modèle, les tailles d'entrée, la précision, l'exactitude et les performances mesurées pour YOLOv3, YOLOv5, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 n/s/m/l/x, YOLOX, YOLO-NAS, OBB, pose et segmentation, ainsi que de nombreux modèles de classification et de prédiction dense. Publier les pertes de quantification et l'exactitude à côté de la vitesse est plus utile que de publier seulement une valeur TOPS de pointe.

Le nom des artefacts a changé avec la génération de l'API. Le flux de compilation alpha Pipeline Builder produit un modèle .axm et peut empaqueter un pipeline portable en .axe. La documentation du pipeline classique décrit .axmodel avec les métadonnées et un manifeste. Une intégration doit détecter la génération Voyager installée au lieu de coder en dur une extension unique.

Qualcomm

Qualcomm offre une immense portée de déploiement, mais l'expression « NPU Qualcomm » masque plusieurs interfaces. Selon l'appareil et la catégorie de produit, les développeurs utilisent Hexagon HTP via QAIRT/QNN, l'ancien flux SNPE, les services de compilation Qualcomm AI Hub, LiteRT ou le fournisseur d'exécution QNN d'ONNX Runtime.

Le dépôt officiel Qualcomm AI Hub Models constitue une preuve solide au niveau des modèles. Il publie des paquets optimisés pour YOLOv3, YOLOv5, YOLOv6, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, la détection/segmentation/pose YOLO26, YOLOX, YOLO-World, YOLOR, RF-DETR et de nombreux modèles de classification, profondeur et pose. AI Hub propose aussi du profiling par appareil, ce qui importe, car un modèle compilé pour une génération HTP n'est pas automatiquement portable vers une autre.

Le coût principal d'intégration vient de la taille de la matrice : Android ou Linux embarqué, références QCS ou Snapdragon grand public, architecture HTP, version QNN/QAIRT et schéma de quantification ont tous leur importance. Les pages actuelles de Qualcomm se contredisent au sujet du statut Dragonwing IQ-9075 : la page produit le marque Active et son EVK peut être évalué, tandis que le Product Longevity Program marque toujours IQ-9075 Sampling et indique une longévité jusqu'en 2038. Le préfixe de commande/SKU est QCS9075 ; Qualcomm annonce des configurations de 50 et 100 TOPS INT8 denses, ainsi que la prise en charge d'Ubuntu/Yocto. Il faut confirmer le statut de production pour le SKU de commande précis. Une intégration LibreYOLO devrait enregistrer ce SKU au lieu de créer un dossier générique « Qualcomm ».

DEEPX

Les accélérateurs DX-M1/DX-M1M de DEEPX utilisent le SDK DXNN. DX-COM compile et quantifie le modèle, DX-RT l'exécute et l'artefact déployé utilise le format .dxnn. L'entreprise publie DX-AllSuite, des exemples applicatifs dans DX-APP et un vaste Model Zoo en ligne.

Le catalogue public comptait 354 entrées avec DX-COM 2.4.0 et DX-RT 3.4.0 lors de sa vérification le 15 août 2026. Sa couverture documentée comprend YOLOv3 à YOLO11 et YOLO26, YOLOX, SSD, EfficientDet, NanoDet, DAMO-YOLO, YOLO segmentation, pose et boîtes orientées. DEEPX est une cible d'intégration particulièrement plausible, car les limites entre compilateur, runtime et artefact de déploiement sont clairement définies et la couverture vision publique est large.

Les SoC industriels forment plusieurs écosystèmes

Les fabricants industriels proposent souvent des cycles de vie plus longs ainsi qu'une meilleure intégration caméra, sûreté et temps réel que les SoC des cartes de makers. Leurs piles IA peuvent être plus complexes, car un même fabricant commercialise parfois plusieurs architectures NPU sans lien entre elles.

Texas Instruments

Les processeurs Edge AI actuels de TI comprennent AM62A, AM67A, AM68A, AM69A et les appareils TDA4 associés. Le parcours logiciel combine Processor SDK Linux, le compilateur/runtime TIDL, Edge AI TIDL Tools et le Edge AI Model Zoo. TIDL peut s'intégrer à ONNX Runtime, TensorFlow Lite et à d'autres runtimes applicatifs, en déchargeant les sous-graphes pris en charge.

TI publie bien davantage qu'une simple affirmation d'import de framework : le zoo contient des modèles convertis et des métadonnées de performance pour la détection d'objets, la segmentation, la pose, la classification, la profondeur et d'autres tâches. TI précise aussi que les artefacts du model zoo sont des points de départ pour le développement, pas automatiquement des ressources prêtes pour la production. Cette réserve manque souvent dans les comparatifs de fabricants.

TI présente également le TDA54-Q1 comme étant en préversion, avec jusqu'à quatre NPU C7 et jusqu'à 400 TOPS pour cette puce ; la famille TDA5 est annoncée jusqu'à 1 200 TOPS. Ce sont les chiffres du fabricant pour une nouvelle génération, et ils ne permettent pas de transférer la validation de modèles TIDL AM6xA/TDA4 au TDA54-Q1 avant la publication d'une matrice propre à cette cible par TI.

NXP

NXP nécessite au moins quatre descriptions de backend :

Le eIQ Model Zoo contient des artefacts ou recettes pour YOLOv4-tiny, YOLOv8, NanoDet, CenterNet, FastestDet, SSD Lite, YOLACT et d'autres modèles ; son entrée YOLOv5 a été ajoutée uniquement à titre documentaire. Une entrée validée pour un backend ne prouve pas sa prise en charge par les quatre. Les conseils d'export YOLO pour les plateformes i.MX NXP de NXP illustrent ce problème de conversion propre à chaque cible. NXP indique que l'eIQ Toolkit monolithique n'a plus été mis à jour après la version 1.17 au T3 2025 ; les parcours actuels utilisent des paquets autonomes comme eIQ Neutron SDK.

NXP a finalisé l'acquisition de Kinara en octobre 2025. La fiche technique Ara240 annonce jusqu'à 40 eTOPS et indique 313 images par seconde pour YOLOv8n. NXP répertorie Ara SDK et eIQ Toolkit sur la page produit, mais cela ne prouve pas l'interchangeabilité des artefacts avec le parcours Neutron distinct de l'i.MX 95. Le module M.2 de 16 GB est actif tandis que l'option USB est en préproduction. NXP définit le « e » de eTOPS comme « equivalent », et non « effective » ; ce n'est pas la mesure TOPS INT8 denses d'un autre fabricant et il ne faut pas les comparer directement.

STMicroelectronics

Les appareils STM32N6x7, dont STM32N657 et STM32N647, intègrent un accélérateur Neural-ART de 600-GOPS dans un produit de classe MCU ; la gamme polyvalente N6x5 n'inclut pas cet accélérateur. STM32Cube AI Studio et ST Edge AI Core analysent et optimisent les modèles importés, tandis que STM32 AI Model Zoo Services fournit les parcours de déploiement, d'optimisation, de benchmark et d'exemple.

La présentation actuelle de la détection d'objets documente Tiny YOLOv2, YOLOv5u, YOLOv8, YOLO11, YOLO26 et ST-YOLOX, ainsi que des services de classification, pose et segmentation. Ce produit ne joue pas dans la même catégorie de performance qu'une carte PCIe de 200-TOPS. Son intérêt tient à la possibilité d'intégrer acquisition caméra, inférence et contrôle dans une enveloppe de puissance et de mémoire très contrainte.

Renesas

Les processeurs Renesas RZ/V intègrent des accélérateurs DRP-AI. Le logiciel a évolué de DRP-AI Translator et DRP-AI TVM vers RUHMI, fondé sur la technologie MERA d'EdgeCortix. Le dépôt RZ/V DRP-AI TVM ouvert et la liste de validation RZ/V2H citent YOLOv5, YOLOv8, YOLO11 et YOLO26 n/s/m, YOLOX, des réseaux de pose et segmentation, ainsi que des modèles de classification.

Renesas constitue une cible crédible en robotique et dans l'industrie, mais il faut consigner la carte précise, la génération DRP-AI, la version du traducteur et le post-traitement côté CPU pour assurer la reproductibilité.

Capteurs intelligents et processeurs conçus pour les caméras

Sony IMX500

Le Sony IMX500 n'est pas un processeur applicatif classique. Il combine détection d'image et traitement IA afin de réaliser l'inférence dans le capteur et de réduire la quantité de données image qui quitte la caméra. Raspberry Pi AI Camera rend cette architecture particulièrement accessible.

Le dépôt officiel des modèles Raspberry Pi IMX500 publie des paquets YOLOv8n, YOLO11n, EfficientDet Lite0, NanoDet+ et SSD MobileNetV2 FPN Lite. La documentation AI Camera explique la conversion, l'empaquetage et le post-traitement dans le capteur. L'unité de déploiement est un paquet RPK et non un fichier ONNX générique ; la mémoire du capteur et les contraintes d'opérateurs sont des limites de conception centrales. La page produit de Raspberry Pi indique que cette caméra restera en production au moins jusqu'en janvier 2028.

Ambarella

Les processeurs CVflow d'Ambarella sont bien implantés dans les caméras, les drones et la vision automobile. Les familles actuelles comprennent CV72/CV75 pour les caméras, CV5/CV52 pour les systèmes de vision plus puissants et les appareils automobiles CV3-AD. La plateforme développeur Cooper et le flux de compilation/runtime CVflow constituent la pile logicielle nommée publiquement.

Le model garden développeur public cite YOLOX, RTMDet, DeepLabV3+, TopFormer, OWL-ViT et des modèles multimodaux. Toutefois, la documentation détaillée du compilateur et les téléchargements restent destinés aux partenaires. Une intégration Ambarella devrait donc commencer par une relation avec le fabricant ou un OEM, et non par l'hypothèse qu'un paquet pip public est disponible.

Synaptics Astra

Synaptics propose trois cibles pertinentes. Les systèmes Astra SL1600/SL1680 utilisent le toolkit SyNAP, qui convertit un modèle source et une description YAML en paquet model.synap. Les appareils SL2611/13/15/17/19 plus récents utilisent la plateforme Torq, un flux fondé sur IREE/MLIR qui produit .vmfb. La série SR100 est une famille MCU distincte, bâtie autour de Cortex-M55 et Ethos-U55 avec son propre SDK. Ces artefacts et API ne sont pas interchangeables.

Le tutoriel benchmark YOLO officiel est particulièrement concret : il exporte YOLOv8 vers TFLite, effectue une calibration UINT8 asymétrique dans SyNAP, compile pour SL1680, puis lance synap_cli et l'application de détection d'objets. Il prouve YOLOv8n/v8s sur SL1680 et décrit la prise en charge de SyNAP jusqu'à YOLO11. Un guide distinct de détection d'objets SL261x exécute YOLOv8 à partir d'un .vmfb Torq. Ce sont des exemples officiels propres à leurs cibles, pas une affirmation que tous les graphes YOLO sont pris en charge sur les trois familles.

MediaTek Genio

MediaTek mérite une rubrique complète, car son IoT AI Hub actuel expose désormais la matrice matériel/logiciel, les paquets de modèles et les tableaux de benchmark qui étaient difficiles à vérifier dans les anciennes études de marché. Genio 360/360P/420/520/720 utilise NeuroPilot 8 avec MDLA 5.3 ; Genio 510/700 utilise NP6 avec MDLA 3.0 ; Genio 1200 utilise NP6 avec MDLA 2.0. MediaTek indique que les générations NeuroPilot et MDLA, les opérateurs, le compilateur et le runtime sont liés par version pendant toute la durée de vie de chaque SoC.

Le parcours d'IA analytique est centré sur TFLite :

PyTorch model
    -> NeuroPilot Converter and representative calibration
    -> quantized .tflite
    -> version-matched ncc-tflite compiler
    -> chip-generation-specific .dla
    -> Neuron Runtime on MDLA

Les produits Genio récents proposent également la délégation LiteRT en ligne et un parcours ONNX Runtime CPU/NPU sur les systèmes d'exploitation pris en charge. Ces modes d'exécution diffèrent du .dla hors ligne. Le guide d'architecture logicielle et la matrice de ressources rendent cette distinction explicite.

La table officielle des modèles analytiques publie des entrées YOLOv5s et YOLOv8s avec benchmarks et guides de conversion couvrant plusieurs générations MDLA. Elle ne distribue explicitement pas d'artefacts YOLO préconvertis en raison des restrictions AGPL-3.0. Ses mesures hors ligne Quant8 en 640 x 640 comprennent respectivement 5.35 ms et 8.04 ms sur Genio 720. La page du modèle YOLOv8s publie les tenseurs d'entrée/de sortie, les temps propres à chaque backend et des avertissements sur les opérations personnalisées MediaTek. Ce sont des benchmarks du fabricant, pas des résultats caméra de bout en bout.

L'accès constitue le facteur limitant. La documentation Yocto est publique et détaillée, mais le lot convertisseur/compilateur intégré NP8 actuel et une grande partie de la documentation Android sont indiqués comme ressources sous NDA ou réservées aux clients directs. Un compte développeur ordinaire ne donne pas le même accès qu'un compte client MediaTek Online. LibreYOLO devrait donc considérer Genio comme techniquement validé, mais dépendant d'un partenariat pour une intégration de compilation reproductible de modèles personnalisés.

Écosystèmes Edge AI centrés sur la Chine

Plusieurs des plateformes vision à bas coût les plus performantes et accessibles apparaissent peu dans les études de marché en anglais.

D-Robotics et plateformes BPU dérivées de Horizon

D-Robotics maintient l'écosystème de cartes de développement RDK autour des accélérateurs BPU utilisés dans RDK X3, X5, Ultra et les produits récents de série S100. La branche rdk_x5 actuelle du RDK Model Zoo documente YOLOv5/v5u, YOLOv8/9/10/11/12/13/26, YOLOE, YOLO-World, la détection, la segmentation, la pose, la classification, l'OCR et les parcours CLIP pour RDK X5. X3 utilise une branche distincte, tandis que le déploiement actuel de la série S se trouve dans la branche rdk_s du zoo principal ; l'ancien dépôt rdk_model_zoo_s contient des démos historiques. La liste moderne X5 ne prouve donc pas que chaque modèle a été validé sur X3, Ultra ou S100.

OpenExplorer/Algorithm Toolchain importe ONNX ou Caffe pour le PTQ et prend en charge des flux QAT orientés PyTorch. Le déploiement dépend de la plateforme : le RDK X5 actuel utilise .bin via hbm_runtime sur libdnn, tandis que le flux principal rdk_s actuel utilise .hbm via une API hbm_runtime homonyme sur libhbucp ; X3 conserve son ancienne branche et ses interfaces d'inférence. L'ancien contenu de rdk_model_zoo_s décrit également des parcours historiques .bin et .hbm : ces artefacts doivent rester associés à leur branche et chaîne d'outils correspondantes. Les opérateurs non pris en charge peuvent s'exécuter sur CPU. Les exemples publics sont utiles, mais la correspondance entre version de RDK OS, firmware de carte, chaîne d'outils et binaire de modèle fait partie du contrat de compatibilité.

AXERA

Les familles AX650/AX630/AX620 d'AXERA sont présentes dans des caméras et cartes IA compactes, notamment la gamme MaixCAM de Sipeed. Pulsar2 importe ONNX, effectue la calibration et l'analyse de précision, puis produit .axmodel ; AXEngine exécute l'artefact.

Les exemples AXERA officiels couvrent YOLOv5/6/7/8/9/10/11/13/26, YOLOX et YOLO-World ; la prise en charge des tâches et puces varie selon la plateforme. Sur les cibles prises en charge, les exemples YOLO26 actuels couvrent détection, pose, segmentation et OBB. Les exemples de conversion Pulsar2 montrent le travail réel : noms de tenseurs exacts, coupures des sorties, transformations de format, archives de calibration et paramètres du matériel cible.

SOPHGO

TPU-MLIR de SOPHGO est l'une des piles de compilation les plus intéressantes pour une intégration indépendante, car le compilateur lui-même est open source. Il importe ONNX, PyTorch, TFLite et Caffe, abaisse et quantifie les graphes, puis produit .bmodel pour les cibles BM ou .cvimodel pour le matériel CV18xx.

Le projet TPU-MLIR prend en charge les parcours FP32, BF16, FP16 et INT8 selon la cible. La collection de démos SOPHON cite YOLOv3/4/5/7/8/9/10/11/12/26, YOLOX, PP-YOLOE, YOLO-World, des variantes OBB/segmentation, SSD, CenterNet, RetinaFace, SAM/SAM2 et OCR. Comme toujours, une démo sur BM1684X ne valide pas le même artefact sur BM1688 ou CV18xx.

Huawei Ascend

La gamme d'inférence edge de Huawei comprend le silicium Ascend 310/310P/310B dans les produits Atlas 200I et 300I. CANN fournit le compilateur ATC, le runtime AscendCL et des noyaux d'opérateurs propres aux puces ; ATC convertit ONNX et d'autres représentations sources en modèle .om hors ligne.

La documentation Atlas 200I DK A2 actuelle et les exemples CANN proposent un parcours YOLOv5 .om pour Ascend 310B. Le ModelZoo Ascend plus large et plus ancien contient YOLOv2/3/4/5, YOLOX, YOLOR, SSD, RetinaNet, Mask R-CNN, pose et segmentation, mais ne doit pas être présenté comme si chaque entrée avait été validée de nouveau sur 310B. CANN, les noyaux, le firmware et le SoC doivent correspondre. Un .om pour Ascend310P n'est pas un artefact Ascend générique.

Cambricon

Les accélérateurs MLU de Cambricon utilisent Neuware et le moteur d'inférence MagicMind. Le dépôt public MagicMind Cloud est épinglé sur MagicMind 1.7 et une matrice MLU370-X4/S4 ; il apporte des preuves historiques de compatibilité et ne valide ni le SDK actuel ni MLU270. Le dépôt documente les parcours PyTorch, ONNX, Caffe et Paddle ; la prise en charge du framework TensorFlow a été supprimée en 1.7 même si des exemples TensorFlow historiques subsistent. Le portail développeur série 3 actuel de Cambricon liste des versions ultérieures du SDK global : le dépôt d'exemples publics et la pile commerciale actuelle ne doivent pas être présentés comme une seule version.

Le dépôt officiel de modèles MagicMind cloud publie une matrice MLU370-X4/S4 particulièrement directe. Il répertorie YOLOv3, Tiny-YOLOv3, YOLOv4, YOLOv5, YOLOv7, YOLOv8, PP-YOLOE, SSD, RetinaFace, RetinaNet, Mask R-CNN, DeepLab et UNet, en précisant notamment si des exemples C++ ou Python existent. Les preuves sont solides ; le principal obstacle reste l'accès au SDK et au conteneur via les canaux Cambricon.

Canaan/Kendryte

Les puces KPU actuelles K230/K230D et historiques K210/K510 de Kendryte sont importantes pour les cartes à bas coût et les caméras intelligentes. Le compilateur nncase importe ONNX ou TFLite, utilise des données de calibration pour la conversion en virgule fixe, simule le résultat sur hôte et produit .kmodel.

Le guide officiel de développement nncase K230 explique comment compiler, simuler et exécuter YOLOv5s. Le catalogue de démos IA distinct comprend des artefacts de détection, segmentation et pose YOLOv8n, tandis que le journal des modifications CanMV actuel ajoute des exemples optimisés YOLOv8/11/26 de classification, détection, segmentation, OBB et pose. Le résultat YOLOv5s de la fiche technique est le benchmark publié ; les versions du compilateur et du plug-in binaire KPU doivent correspondre au SDK de la carte.

Allwinner

Allwinner V853 associe du matériel média orienté caméra à un NPU Vivante de 1-TOPS. Le guide NPU officiel en anglais décrit l'import Acuity/Pegasus, la quantification, la vérification et le déploiement via viplite. Les pages de modèles d'Allwinner et son guide YOLOv5 citent YOLOv2/3/4/4-tiny/5/5s, RetinaNet, MobileNet, ResNet et des réseaux visage/personne.

Il s'agit d'une prise en charge réelle de la vision par ordinateur, mais qui reste liée à l'ancienne chaîne Tina Linux/Vivante et aux téléchargements du SDK soumis à un compte. La plateforme a sa place dans la cartographie du marché, avec cette limite clairement indiquée.

Plateformes coréennes, taïwanaises et chinoises moins connues

Les listes en anglais passent souvent directement de Rockchip à NVIDIA et omettent un deuxième groupe de silicium documenté et réellement disponible. Certains de ces écosystèmes présentent une matrice YOLO actuelle plus vaste que celle de jeunes entreprises occidentales plus connues.

Mobilint

Le fabricant coréen Mobilint commercialise REGULUS basse consommation et ARIES MLA100 à débit supérieur. Son SDK qb accepte des entrées PyTorch, TensorFlow, TFLite, ONNX et Keras, quantifie en INT8 et produit l'artefact compilé .mxq. La matrice vision publique cite YOLOv3/v5/v7/v8/v9/v10/11/12/26 en détection, plus des variantes YOLO de segmentation, pose et OBB. La page ARIES publie même des résultats spécifiques à YOLO11s et YOLO26m. Les preuves d'intégration sont solides, même si l'accès au SDK et au matériel reste commercial.

Sunplus

SP7350/C3V de Sunplus utilise une pile NPU dérivée de Vivante, empaquetée différemment de celle d'Allwinner ou de l'ancien Amlogic. Son parcours public combine conversion Acuity, environnement Docker NPU, runtime SNNF et sortie .nb. Le guide YOLOv8 personnalisé officiel décrit conversion et déploiement au lieu de simplement revendiquer la prise en charge d'un framework. Une IP apparentée ne rend pas .nb portable vers un autre SoC basé sur Vivante.

ESWIN Computing

La famille RISC-V d'ESWIN comprend EIC7700/EIC7700X et EIC7702/EIC7702X à deux puces ; EIC7700 équipe notamment la carte Milk-V Megrez commercialisée. ENNP réunit EsQuant, le compilateur EsAAC actuel, la génération de données de référence, la simulation et le runtime ESSDK, avec une sortie compilée .model ; d'anciens documents ENNP utilisaient le nom ennc-compile. La page EsAAC actuelle documente l'entrée ONNX ; les autres frameworks doivent donc être exportés ou convertis vers cette représentation prise en charge. La présentation ENNP et le tutoriel YOLOv3 hébergés par Milk-V établissent un parcours public de bout en bout, mais pas une vaste matrice actuelle de modèles/exactitude.

Nuvoton M55M1

Le M55M1 de Nuvoton est une conception Cortex-M55 de classe MCU avec Ethos-U55-256, et non un processeur applicatif Linux. NuEdgeWise/NuML et Arm Vela préparent les modèles TFLite Micro quantifiés. Le dépôt public NuEdgeWise cite YOLOv8-nano, YOLOX-nano, YOLO Fastest v1.1, SSD-MobileNet FPNLite et plusieurs classificateurs. Ces petits exemples de réseaux constituent des preuves crédibles pour cette catégorie de mémoire/puissance, pas pour les variantes YOLO classiques à 640 pixels.

Rebellions et FuriosaAI

La famille ATOM de Rebellions utilise le SDK RBLN et les artefacts compilés .rbln. Sa version de prise en charge officielle cite YOLOv3 tiny/full/SPP, YOLOv5 n à x, YOLOv6 n à l, des variantes YOLOv7 et YOLOv8 n à x. La matrice actuelle de prise en charge des cartes indique ATOM CA02 et ATOM+ CA12 en fin de vie, tandis que ATOM+ CA22 et ATOM-Max CA25 sont actifs. ATOM-Lite CA21 possède une page produit, mais est absent de cette matrice du SDK ; le statut de sa chaîne d'outils actuelle reste donc incertain. La documentation est publique, mais le wheel compilateur nécessite les identifiants du portail Rebellions.

FuriosaAI doit être réparti par génération. Warboy est l'ancien accélérateur de vision, avec artefacts INT8 .enf et model zoo officiel contenant SSD, YOLOv5M/L et YOLOv7-w6-pose. RNGD utilise une pile .fxb différente, principalement destinée aux charges LLM/VLM. La feuille de route actuelle de Furiosa indique que la prise en charge vision de YOLOv8m a été achevée au T4 2024, mais les pages publiques actuelles sur les modèles pris en charge et les performances sont centrées sur LLM/VLM et ne présentent pas de matrice détaillée d'exactitude/performance pour YOLOv8m. Il s'agit d'une preuve concernant une génération commercialisée, pas d'une affirmation de compatibilité avec Warboy.

Realtek, Telechips, T-Head et SigmaStar

Ces quatre plateformes existent, mais leur parcours de modèles personnalisés est plus restreint, plus ancien ou réservé :

HiSilicon smart vision n'est pas Huawei Ascend

Les SoC caméra HiSilicon Hi3516CV610/DV500, Hi3519DV500 et Hi3403V100 exposent un flux ATC vers .om via les runtimes NNN/SVP-NNN. Le model zoo HiSpark officiel cite YOLOv3/4/5/6/7/8/9/10/11, segmentation/pose YOLO11, OBB/World/segmentation YOLOv8, OCR, profondeur et TinySAM dans une matrice propre aux cibles, notamment Hi3403 et Hi3591P. Cela ne prouve pas que chaque entrée fonctionne sur tous les SoC de vision intelligente cités plus haut. Certaines entrées sont des éléments de feuille de route : il faut distinguer les exemples disponibles du support prévu. Le dépôt précise que les modèles fournis par son ModelZoo sont réservés à un usage non commercial. Le vocabulaire ATC/.om commun ne prouve pas la compatibilité d'artefact ou de runtime avec la gamme Ascend fondée sur CANN.

Entreprises émergentes et accélérateurs spécialisés

MemryX

Les modules MX3 de MemryX utilisent une architecture dataflow et peuvent associer plusieurs puces. Le Neural Compiler accepte des modèles ONNX, TensorFlow Lite, Keras et TensorFlow, puis produit un paquet DFP utilisé par le runtime de l'accélérateur. Ses API runtime prennent en charge des pipelines multi-modèles et de streaming.

La documentation et les exemples MemryX incluent le prétraitement et le post-traitement YOLO optimisés pour la détection, la segmentation et la pose. Les notes de version du SDK citent explicitement la prise en charge de YOLOv10, YOLO11 et YOLO26. La documentation publique est techniquement utile, bien qu'elle ne comporte pas de tableau unique modèles/exactitude/appareils comparable à celui d'Axelera.

Kneron

Les produits KL520/KL530/KL630/KL720/KL730 de Kneron couvrent de petits accélérateurs USB et embarqués. Kneron PLUS gère le runtime applicatif, tandis que la version actuelle 0.33.1 de Model Toolchain documente la conversion, la quantification, l'évaluation, la simulation et la compilation .nef pour ces cibles. KL830 apparaît dans certaines API runtime PLUS, mais pas dans la liste actuelle des cibles du compilateur ; sans confirmation du fabricant, il ne faut pas généraliser la compilation .nef à KL830.

L'exemple YOLO officiel montre le processus avec Tiny-YOLOv3 et d'autres ressources Kneron couvrent l'entraînement et le déploiement YOLOv5. Les preuves sont crédibles, mais la couverture est plus étroite que les vastes matrices modernes de Hailo, Axelera, Rockchip ou DEEPX.

SiMa.ai

MLSoC et la plateforme Modalix 50-TOPS en production de SiMa.ai utilisent l'environnement logiciel Palette. ModelSDK, le compilateur MLA et ModelExecutor couvrent import, quantification, compilation, profiling et exécution. Selon la charge et le produit, les outils prennent en charge des parcours INT8, INT16 et BF16.

Les notes de version de l'entreprise citent les pipelines YOLOv7, détection/pose/segmentation YOLOv8, YOLOX et segmentation YOLOX, DETR, Mask R-CNN et EfficientDet validés. Il ne faut pas masquer une limite actuelle : les notes de Palette SDK 2.1 signalent que le QAT ne fonctionne pas à cause d'une régression de quantification Python/PT2E. La solution de contournement documentée consiste à créer le ONNX annoté dans le SDK 2.0 et à le compiler avec la version 2.1. L'accès et l'achat du produit sont destinés aux entreprises.

La limite de déploiement est également documentée : le flux de compilation ModelSDK produit un .tar.gz compilé et peut générer un ELF exécutable, tandis que MPK Tool empaquette un .mpk déployable. Ces sorties sont liées à la cible MLSoC/Modalix et à la version Palette.

EdgeCortix

SAKURA-II est un accélérateur annoncé à 60-TOPS pour la vision et l'IA générative, compilé via le framework logiciel MERA. EdgeCortix fournit également la technologie MERA au nouveau flux RUHMI de Renesas.

La documentation produit SAKURA-II établit l'existence du matériel et du compilateur, et les cartes M.2/PCIe sont proposées à l'essai ou sur demande de commande. Aucune matrice YOLO publique suffisamment précise et récente n'a été trouvée. Ce manque constitue une information utile pour l'achat : demander une validation du modèle avant de s'engager sur le matériel.

BrainChip

Akida de BrainChip est un processeur neuromorphique à événements, plutôt qu'un NPU classique à tenseurs denses. Son environnement MetaTF comprend des paquets Python installables pour créer des modèles, les quantifier en basse précision, les convertir, les simuler et les exécuter sur le matériel. BrainChip commercialise désormais le coprocesseur AKD1500 disponible, au format M.2, avec l'ancien matériel AKD1000 et l'IP Akida 2.

La fiche modèle Akida 2 actuelle cite un détecteur YOLOv2 AkidaNet0.5, CenterNet, AkidaUNet et des réseaux de reconnaissance faciale. D'autres documents couvrent FOMO et les charges à événements. Akida prend en charge des poids et activations exceptionnellement peu précis, mais un déploiement réussi peut nécessiter une conversion adaptée à l'architecture, au lieu de le traiter comme une cible ONNX INT8 générique. Un résultat du model zoo AKD1000 ou Akida 2 ne doit pas être attribué à AKD1500 sans rapport explicite de mappage/compatibilité.

Blaize

Blaize commercialise des produits Pathfinder et Xplorer à base de P1600, avec Picasso SDK, NetDeploy et AI Studio comme parcours logiciel. Les pages produit ciblent clairement la vision et l'Edge AI, mais il n'existe pas de matrice publique actuelle de compatibilité par modèle.

Ce guide classe donc Blaize comme commercial et à accès restreint plutôt que de combler ce manque avec des affirmations communautaires. Il faudrait exiger un rapport de compilation et d'exactitude fourni par le fabricant pour le modèle visé.

TinyML et vision endpoint

Arm Ethos-U et Alif

Arm concède sous licence les IP NPU Ethos-U55, U65 et U85 aux fabricants de puces. Le compilateur Vela prend des graphes LiteRT/TFLite quantifiés et transforme les sous-graphes pris en charge en opérations personnalisées Ethos-U. Les opérations non prises en charge peuvent rester sur le CPU ; « l'application s'exécute » et « tout le réseau s'exécute sur le NPU » sont donc deux affirmations différentes.

Parmi les implémentations figurent Ethos-U55 dans Alif Ensemble E7, Ethos-U65 dans NXP i.MX 93 et Ethos-U85 dans des systèmes récents. Le kit E7 AI/ML AppKit d'Alif documente deux accélérateurs ML et montre le parcours TFLite vers Vela du E7 ; l'Ensemble E8 associe un Ethos-U85 à deux NPU Ethos-U55. Alif publie aussi un benchmark de détection de visages YOLO-Fastest INT8 pour sa famille, en 192 par 192 sur Cortex-M55 plus Ethos-U55, mais pas de vaste matrice moderne YOLO par cible. Ces systèmes contraints en mémoire conviennent aux petits réseaux de classification et de détection, pas à des détecteurs arbitraires de 640 pixels simplement parce qu'ils sont exprimables en TFLite.

Infineon PSOC Edge, Himax WiseEye2 et Analog Devices MAX7800x

Les familles PSOC Edge E83 et E84 d'Infineon associent Cortex-M55 à Ethos-U55 et ajoutent un bloc NNLite séparé côté basse consommation M33. Le manuel d'architecture E84 documente des poids 8 bits, des activations 8 ou 16 bits et un flux Vela où les opérateurs pris en charge deviennent un flux de commandes NPU tandis que les opérations non prises en charge restent sur CPU. Le DEEPCRAFT Model Converter accepte les parcours TFLite, Keras et PyTorch ; la documentation d'architecture cite MobileNetV1/V2 comme noyaux représentatifs, et non comme benchmarks de la cible. Le kit AI E84 comprend une caméra et utilise ModusToolbox, mais les ressources publiques ne fournissent pas encore de matrice YOLO nommée. Il s'agit d'une véritable plateforme vision programmable dont les preuves au niveau des modèles se développent, pas d'une cible de détection généraliste validée.

Le HX6538 WiseEye2 de Himax associe lui aussi Cortex-M55 et Ethos-U55 pour la vision toujours active. Ses ressources logicielles publiques sont particulièrement concrètes pour cette catégorie de puissance : les exemples officiels du Grove Vision AI Module V2 comprennent la détection d'objets YOLOv8n, la pose, la classification de genre, la détection YOLO11n, le face mesh et PeopleNet. Le parcours unifié utilise TFLite Micro et Vela, puis se replie sur CMSIS-NN et les noyaux de référence si nécessaire. Il s'agit volontairement de petits modèles et résolutions, pas d'une preuve qu'un graphe YOLO classique de taille serveur tient dans le système.

Analog Devices emprunte une autre voie avec les accélérateurs CNN MAX78000/MAX78002. L'outil public ai8x-synthesis quantifie un réseau entraîné et génère du code C, des poids et une configuration d'accélérateur propres à la cible, au lieu d'un paquet runtime ONNX portable. Les preuves du fabricant comprennent l'identification des visages, la détection QR TinierSSD dans le model zoo ADI et des classificateurs d'image. Ces appareils conviennent à la vision endpoint, mais aucune matrice YOLO moderne officielle n'a été trouvée.

GreenWaves GAP9

GAP9 associe des calculs RISC-V au moteur neuronal NE16. NNTool importe et quantifie les réseaux, tandis qu'AutoTiler et le GAP SDK génèrent le code déployable. Le menu de réseaux neuronaux GAP9 public comprend MobileNet, EfficientNet, ResNet, MobileNet SSD et des applications faciales/de reconnaissance. GreenWaves publie aussi un projet de détection de personnes YOLOX avec des résultats d'exactitude et de simulation.

Il s'agit de preuves TinyML exceptionnellement transparentes, mais le SDK complet est réservé aux clients qualifiés et les modèles sont bien plus petits que les variantes YOLO courantes en 640 par 640.

Lattice sensAI

Lattice sensAI est une alternative fondée sur FPGA à un NPU fixe. sensAI Studio et Neural Network Compiler mappent un graphe pris en charge sur une IP d'accélérateur configurable pour les appareils ECP5, iCE40 UltraPlus, CrossLink-NX, CertusPro-NX, Avant-E et Avant-X. La sortie dépend du FPGA choisi, du mode d'accélérateur, de la disposition mémoire et du bitstream, et n'est donc pas un modèle runtime portable.

Le manuel actuel de Neural Network Compiler contient une table de topologies particulièrement directe. Elle répertorie YOLOv1 pour ECP5, YOLOv5 et YOLOv8 pour les modes optimisés/avancés de CrossLink-NX et CertusPro-NX, et YOLO11 uniquement avec l'IP Advanced mode. Elle cite aussi SSD, MobileNetV2-SSD, ResNet, ENet, SqueezeDet et d'autres réseaux vision, en rendant visibles les cellules non prises en charge selon la famille de FPGA. L'Advanced CNN Accelerator cible Avant-E/Avant-X/CertusPro-NX et constitue une IP commerciale. Cette table du compilateur ne garantit pas qu'un bitstream prenne en charge simultanément toutes les topologies listées.

Microchip VectorBlox

Le VectorBlox SDK 3.1 public de Microchip prétraite et compile des réseaux TFLite INT8 entièrement quantifiés pour l'IP CoreVectorBlox configurable des FPGA PolarFire SoC. tflite_preprocess et vnnx_compile produisent les artefacts de déploiement .vnnx, .hex et .ucomp ; le dépôt comprend un simulateur et un pilote C côté cible. Les graphes TensorFlow, ONNX et OpenVINO en amont doivent toujours passer par le parcours documenté de préparation TFLite/INT8.

La matrice actuelle des tutoriels inclut YOLOv5n, détection, classification, OBB, pose et segmentation YOLOv8n, YOLOv9t, des variantes YOLO creuses/compressées, MobileNet, EfficientNet-Lite0, ResNet18, MiDaS, FFNet et QuickSRNet. Le guide du post-traitement C cite séparément YOLOv2/3/4/5 et les décodeurs de détection, pose et OBB Ultralytics. SDK 3.1 prend actuellement en charge PolarFire SoC Video Kit, et explicitement pas PolarFire Video Kit sans SoC : les anciennes démos de cartes ne doivent pas être confondues avec le contrat de cible actuel.

Le SDK est téléchargeable publiquement sous une licence propre à Microchip qui limite le logiciel et ses dérivés aux produits Microchip. Microchip propose des licences Libero Silver et CoreVectorBlox gratuites sur demande. Le déploiement reste un contrat système FPGA : configuration de l'accélérateur, bitstream, firmware, données réseau générées par le SDK et disposition mémoire doivent concorder. Une compilation VectorBlox réussie ne transforme pas le modèle en binaire copiable vers n'importe quelle conception PolarFire.

Syntiant

Le NDP200 de Syntiant cible l'inférence toujours active de vision, audio et capteurs dans une enveloppe de puissance inférieure à celle des SoC Linux classiques. La table matériel actuelle indique que le NDP200 est en production de masse et le NDP250 en échantillonnage. La fiche produit NDP200 documente la prise en charge de réseaux CNN, RNN et entièrement connectés sous 1 mW ; l'annonce NDP250 décrit plutôt la reconnaissance d'images toujours active sous 30 mW. Il ne faut pas généraliser la consommation « sous le milliwatt » aux deux puces.

Les ressources publiques ne prouvent pas de compatibilité étendue avec YOLO. Il vaut donc mieux évaluer ce produit pour de petits classificateurs et détecteurs toujours actifs, au moyen d'une étude de modèle prise en charge par le fabricant, plutôt que de supposer qu'un export ONNX générique fonctionnera.

Google Coral : deux générations sans lien direct

Les produits Edge TPU historiques utilisent Edge TPU Compiler, libedgetpu et PyCoral avec des modèles TFLite entièrement INT8. Leurs principaux dépôts Edge TPU et PyCoral sont archivés. Cela représente un véritable risque de maintenance, mais pas un avis officiel de fin de vie du matériel.

Google maintient également un projet Coral NPU open source, distinct et actif : une IP d'accélérateur RISC-V destinée à être intégrée dans des SoC basse consommation. Le projet public fournit actuellement de la RTL, de la simulation matérielle, une chaîne d'outils et des exemples ELF. Il ne s'agit pas d'un successeur Edge TPU USB/M.2 prêt à l'emploi et il ne publie pas de matrice actuelle de déploiement YOLO.

Pièges des GPU, NPU client et calcul adaptatif

NVIDIA, AMD, Intel et Apple apparaissent souvent dans les recherches sur les NPU, mais ne proposent pas une seule catégorie d'accélérateur interchangeable.

NVIDIA Jetson : Jetson Orin associe un GPU CUDA à des cœurs DLA dédiés. TensorRT peut construire un moteur sérialisé pour DLA, mais les couches non prises en charge s'exécutent sur le GPU uniquement si le repli GPU est explicitement activé. La table YOLO DeepStream actuelle couvre YOLOv4/v7/v8/v9/11, mais la plupart des entrées ciblent le GPU ; son entrée ONNX DLA explicite est YOLOv8s INT8. Les restrictions DLA de NVIDIA détaillent les limites d'opérateurs. Thor est un autre cas : le guide de migration DriveOS de NVIDIA indique que les cœurs DLA ont été retirés de Thor au profit de la flexibilité d'ordonnancement GPU. « Fonctionne sur Jetson » ne permet donc pas d'identifier l'accélérateur utilisé.

AMD Vitis AI : l'ancienne génération Kria/DPU compilait des graphes .xmodel exécutés via VART. La version actuelle Vitis AI 6.2 est GA pour deux parcours Versal AI Edge distincts : Gen1, sur VEK280/VE2802, utilise ONNX, AMD Quark et un flux de snapshots/sous-graphes lié à la cible ; Gen2, sur VEK385, possède son propre contrat de compilation et runtime. Gen1 publie des exemples YOLOv5, YOLOv7, YOLOv8 et YOLOX. Ryzen AI constitue une quatrième pile NPU client distincte. Ne réutilisez pas les artefacts ou validations entre ancien DPU, Versal Gen1, Versal Gen2 et Ryzen AI au seul motif qu'ils portent le nom Vitis ou AMD.

Intel OpenVINO : OpenVINO peut cibler CPU, GPU et NPU Core Ultra via une API unique. La documentation du plug-in NPU Intel identifie les générations NPU prises en charge, tandis que la matrice des modèles vérifiés présente des colonnes propres aux appareils. Un notebook YOLO démontre une recette applicative, pas une validation NPU, sauf mention dans la matrice. Les opérations et formes prises en charge, la précision et le pilote NPU installé déterminent encore si le graphe complet peut s'y exécuter. L'IR OpenVINO (.xml plus .bin) est une représentation source réutilisable ; le cache du modèle compilé dépend de l'appareil et du logiciel.

Apple Core ML : coremltools convertit les modèles en .mlpackage, que Xcode compile en .mlmodelc. Core ML peut répartir le travail entre CPU, GPU et Apple Neural Engine, mais masque volontairement la répartition précise. Apple est ainsi une excellente plateforme de déploiement, mais il est difficile d'affirmer que « tout le graphe YOLO s'est exécuté sur le NPU » sans preuves issues du profiling.

Les entreprises d'IP NPU derrière les fabricants de puces

Certaines entreprises ne vendent ni carte ni accélérateur conditionné. Elles concèdent des conceptions NPU sous licence aux fabricants de SoC. Elles comptent, car une même architecture sous-jacente peut apparaître sous plusieurs marques de puces, alors que le SDK final et l'artefact peuvent rester personnalisés par le titulaire de la licence.

Imagination montre pourquoi les mentions d'accès et de cycle de vie doivent accompagner les noms d'architecture. Son programme Open Access propose trois configurations Series3NX éprouvées sur silicium sans frais de licence IP initiaux, après évaluation de l'entreprise, mais avec support/maintenance payants et redevances de production. Le Neural Compute SDK fournit des outils de compilation, d'optimisation, de quantification et de runtime ; une collaboration officielle avec Baidu PaddlePaddle cite détection PP-YOLOE, classification EfficientNet et segmentation HRNet. Ces exemples ne valident pas toutes les configurations Series3NX ou Series4. De plus, les pages individuelles actuelles de produits Series4 indiquent leur indisponibilité : considérez Series4 comme historique, sauf confirmation commerciale contraire.

Cette couche explique les ressemblances apparentes entre familles. Elle ne rend pas les artefacts portables. Deux SoC intégrant des IP Vivante ou Ethos proches peuvent avoir des cartes mémoire, pilotes, versions de compilateur, ensembles d'opérateurs et runtimes différents.

Ce que vous déployez vraiment : le tableau de dépendance aux artefacts

C'est le dernier fichier de la chaîne de compilation qui met fin à la portabilité ONNX apparente. Les noms et extensions changent au fil du temps, mais la règle pratique reste la même : conservez le modèle d'origine et les données de calibration, car l'artefact natif ne peut généralement pas être déplacé vers une autre génération de NPU ni recompilé de façon fiable avec une autre version du SDK.

Ce tableau n'est pas un simple aide-mémoire des extensions. La version du compilateur, l'identifiant de cible, le pilote, le firmware et le BSP font partie de l'identité reproductible du modèle. Un futur exporteur LibreYOLO devrait les inscrire dans un manifeste lisible par machine à côté de chaque artefact.

Accès aux outils et signaux de cycle de vie

La disponibilité du matériel et l'accès au compilateur sont deux choses distinctes. Une carte peut être facile à acheter alors que son compilateur actuel nécessite un accord client ; un SDK public peut viser un silicium difficile à trouver. Les éléments ci-dessous sont des signaux concrets issus des fabricants, pas un classement universel de longévité.

Pourquoi les TOPS ne suffisent pas à choisir

Les TOPS de pointe peuvent être utiles au sein d'un même fabricant et d'une même architecture, mais les comparaisons entre fabricants sont généralement invalides à moins que les éléments suivants concordent :

• Précision numérique, INT8, INT4, FP16 ou mode mixte compris
• Convention de comptage d'une multiplication-accumulation, comme une ou deux opérations
• Calcul dense ou creux structuré
• Résolution d'entrée, taille de batch et graphe du modèle
• Exactitude après quantification
• Latence NPU uniquement ou pipeline applicatif complet
• Transferts mémoire et repli sur hôte
• État thermique et fonctionnement soutenu, et non en rafale

Un détecteur fait partie d'un pipeline : acquisition de l'image, redimensionnement/letterbox, normalisation, transfert vers l'appareil, inférence neuronale, décodage, NMS, mise à l'échelle des coordonnées et logique applicative. Les fabricants ne publient souvent que la partie centrale, l'inférence neuronale. MLPerf Inference Edge est utile car il définit des scénarios, des exigences de qualité et des règles de mesure système au lieu de comparer isolément des chiffres marketing.

Pour les déploiements YOLO, un compte rendu de benchmark crédible devrait au minimum contenir :

exact checkpoint + checksum
source and compiled model format
compiler, runtime, driver and firmware versions
target board and clock/power mode
input resolution and batch
precision and calibration dataset
accuracy before and after compilation
warmup and sample count
preprocess, inference and postprocess latency
power measurement boundary

Sans ces champs, deux chiffres FPS mesurent généralement des choses différentes.

Comment choisir un NPU pour la vision par ordinateur

Procédez dans cet ordre, plutôt que de vous fier au plus grand chiffre imprimé sur une page produit.

1. Prouvez la compatibilité du graphe. Compilez le modèle exporté exact, pas un checkpoint de zoo portant un nom similaire.
2. Mesurez l'exactitude. Validez l'artefact compilé sur le vrai dataset de la tâche après calibration et quantification.
3. Mesurez le pipeline de bout en bout. Incluez conversion d'entrée, transferts, décodage et NMS.
4. Vérifiez l'accès au logiciel. Déterminez si le compilateur est public, soumis à inscription ou disponible seulement après un accord commercial.
5. Figez la matrice des versions. Consignez le compilateur, le runtime, le pilote, le firmware et les identifiants de cible.
6. Vérifiez la réalité des systèmes d'exploitation. Android, Debian, Yocto, Buildroot, RTOS et Windows ne sont pas interchangeables.
7. Vérifiez l'approvisionnement et le cycle de vie. Une excellente puce est un mauvais choix de production si les modules, pilotes ou le support à long terme sont incertains.
8. Comparez ensuite coût, puissance et performances. Ces mesures ne deviennent pertinentes qu'une fois que le même modèle fonctionne correctement sur les deux cibles.

Premières pistes pratiques selon le cas d'usage

Ce tableau est une liste de pistes issue de la recherche, pas un classement de performance. L'achat, la disponibilité régionale et le modèle exact peuvent inverser l'ordre.

Conséquences pour LibreYOLO

Une architecture évolutive ne consiste pas à créer des dizaines d'exporteurs sans lien. Il faut un contrat d'échange strict, accompagné de petits adaptateurs de compilation et de runtime pour chaque fabricant :

LibreYOLO model
    -> deterministic static ONNX
    -> VendorCompiler.compile(model, target, calibration, precision)
    -> native artifact + manifest
    -> VendorRuntime.load() / infer()
    -> shared task-specific decode and Results objects

Chaque artefact natif devrait avoir un manifeste associé contenant :

• Fabricant, cible puce et cible carte
• Versions du compilateur, runtime, pilote et firmware
• Sommes de contrôle du checkpoint source et ONNX
• Noms d'entrée, formes, disposition, espace colorimétrique, normalisation et type de données
• Précision de quantification, échelles si disponibles et empreinte des données de calibration
• Noms et formes des tenseurs de sortie et leur signification
• Tâche de détection, noms de classes et indication si le décodage/NMS est sur la puce ou côté hôte
• Parité numérique et résultats d'exactitude de la tâche enregistrés

LibreYOLO fournit déjà un export ONNX portable, des outils de quantification, un export RKNN direct mais volontairement limité, et un parcours Hailo honnêtement fondé sur un compilateur externe. Selon les critères de ce guide, Amlogic ADLA est un excellent prochain candidat d'intégration : le toolkit est public, la couverture des modèles recoupe fortement celle de LibreYOLO et l'ancien parcours A311D peut rester distinct.

Après Amlogic, il faut établir les priorités selon le matériel des utilisateurs et la possibilité de valider l'exactitude, et pas seulement selon la disponibilité du compilateur. DEEPX, Sony IMX500, D-Robotics, AXERA, SOPHGO et Qualcomm sont des options techniquement intéressantes ; TI, NXP, ST et Renesas deviennent particulièrement utiles si des partenaires industriels peuvent fournir cartes et accès continu à la CI.

À surveiller : silicium réel sans contrat d'intégration public

Exclure complètement une entreprise peut fausser la cartographie du marché. La déclarer « prise en charge » peut être encore pire. Ces fabricants vendent, échantillonnent ou ont annoncé des puces pertinentes, mais les preuves publiques n'établissent pas encore un parcours reproductible actuel avec compilateur, artefact et modèle nommé adapté à un backend LibreYOLO.

Cette liste de surveillance repose volontairement sur les preuves. Un fabricant peut rejoindre les tableaux de déploiement en publiant une chaîne d'outils ou un parcours d'évaluation à jour, un contrat d'artefact propre à la cible et au moins un modèle nommé avec une recette de bout en bout.

Ce que cet article n'affirme volontairement pas

Cet article ne prétend pas que chaque modèle cité fonctionne à partir de n'importe quel dépôt amont. Les modèles des vendor zoos sont souvent modifiés, découpés à différents nœuds de sortie ou associés à un post-traitement personnalisé.

Il ne transforme pas non plus les affirmations suivantes en déclarations de prise en charge :

• Un compilateur importe ONNX.
• Une puce annonce un pilote Android NNAPI.
• Un distributeur affirme que la carte est « compatible YOLO ».
• Un dépôt communautaire exécute une variante d'un modèle.
• Un modèle compile sans erreur.
• Un fabricant annonce des FPS NPU uniquement sans résultat d'exactitude.

Les accélérateurs de téléphone Google Tensor et de nombreux ASIC personnalisés réservés aux OEM existent aussi, mais Google ne propose pas Tensor comme cible de compilateur générale en libre-service comparable aux plateformes ci-dessus. L'existence d'une entreprise, un schéma bloc de NPU ou l'accélération Android ne suffit pas pour inventer une affirmation d'intégration LibreYOLO.

De même, les accélérateurs cloud tels que Google TPU, AWS Inferentia/Trainium, Microsoft Maia et les cartes IA exclusivement destinées aux centres de données sont hors périmètre. Ce guide porte sur le matériel qu'un développeur de vision par ordinateur peut raisonnablement déployer à la périphérie.

La licence du modèle est un sujet distinct. La publication par un fabricant de puce d'une recette de conversion YOLO n'accorde aucun droit d'utiliser ou redistribuer les poids amont, le code d'entraînement ou un dérivé compilé. Il faut vérifier séparément la prise en charge matérielle, la licence du SDK et la licence du modèle pour le produit visé.

Méthodologie de recherche et corrections

Pour chaque entreprise, la recherche s'est appuyée sur quatre types de sources principales :

1. Une page produit ou une fiche technique actuelle identifiant le silicium.
2. La documentation du compilateur et du runtime expliquant le vrai parcours de déploiement.
3. Un model zoo, une table de compatibilité ou un tutoriel de bout en bout citant des modèles de vision.
4. Un signal de cycle de vie ou d'accès indiquant si les développeurs peuvent réellement obtenir les outils.

Les organisations GitHub officielles comptent comme sources du fabricant. La documentation d'un fabricant de cartes est signalée comme preuve au niveau de l'écosystème lorsque l'entreprise qui fabrique la puce ne publie pas les mêmes ressources. Les affirmations de performance tierces ont été exclues des tableaux comparatifs.

Le brouillon complet a ensuite été réaudité lors de passages distincts par groupes de fabricants et à travers les tableaux. Ces vérifications ont réévalué les périmètres de cible, les noms d'artefacts, la précision, les preuves concernant modèles et postprocesseurs, les différences entre annonces et produits commercialisés, les libellés de cycle de vie, les dénominateurs de benchmarks et tous les comptes d'entités. Lorsque deux pages du fabricant se contredisent, ce guide expose le conflit au lieu de choisir discrètement la valeur la plus commode.

Ce marché évolue rapidement. Si vous travaillez pour l'une de ces entreprises et qu'une puce, un SDK, une liste de modèles ou un statut d'accès est inexact, envoyez à LibreYOLO l'URL exacte de la documentation publique et sa version. Les corrections étayées par des sources primaires remplaceront ce texte ; les affirmations marketing non documentées ne le feront pas.

FAQ

Combien existe-t-il d'entreprises Edge AI avec NPU ?

Il n'existe pas de nombre universel, car les fabricants de produits, les fournisseurs de licences IP, les capteurs intelligents, les GPU et les ASIC automobiles privés se recoupent. Ce guide non exhaustif suit 69 entreprises et écosystèmes de plateformes proposant des puces Edge AI, des plateformes d'accélération, des IP NPU sous licence ou des puces pertinentes à surveiller en août 2026.

Qu'est-ce qu'un NPU ?

Une unité de traitement neuronal est un matériel spécialisé dans les opérations des réseaux de neurones, comme les convolutions et les multiplications matricielles. Les fabricants emploient notamment les termes NPU, AIPU, BPU, KPU, DLA, HTP, TPU et MLA. Leurs modèles compilés ne sont généralement pas portables d'un fabricant à l'autre.

Quelles entreprises NPU prennent officiellement en charge les modèles YOLO ?

Amlogic, Hailo, Axelera AI, Rockchip, Qualcomm, MediaTek, DEEPX, D-Robotics, AXERA, SOPHGO, Huawei, Cambricon, Sony IMX500 via le dépôt officiel AI Camera de Raspberry Pi, STMicroelectronics, Renesas, Lattice, Himax, Microchip et plusieurs autres publient des entrées de model zoo, des tutoriels ou des résultats validés par leurs équipes pour au moins une génération de YOLO. La génération, la tâche, la puce ciblée et la version du SDK restent déterminantes.

Un modèle ONNX quelconque peut-il s'exécuter sur n'importe quel NPU ?

Non. ONNX est un format d'échange, pas une garantie de compatibilité matérielle. Le compilateur NPU doit prendre en charge chaque opérateur, forme de tenseur et type de données du graphe. Les formes statiques, les découpages de graphe, les opérations personnalisées et le repli sur le CPU sont fréquents.

Quel est le meilleur NPU pour YOLO ?

Il n'existe pas de vainqueur universel. Hailo, Rockchip, Axelera AI, DEEPX et Amlogic disposent d'une couverture YOLO bien documentée, tandis que Qualcomm bénéficie d'une présence exceptionnelle dans les appareils. Choisissez selon l'exactitude après quantification, la latence de bout en bout, la puissance soutenue, le prix, la disponibilité, l'accès au SDK et la prise en charge du système d'exploitation.

Pourquoi ne peut-on pas comparer directement les valeurs TOPS des NPU ?

Les fabricants peuvent compter différemment les précisions, les opérations creuses, les multiplications-accumulations et les hypothèses d'utilisation de pointe. Les TOPS ne tiennent pas compte du trafic mémoire, des opérateurs non pris en charge, du prétraitement, du post-traitement ni de la surcharge de l'hôte. Comparez le même modèle, la même précision, la même résolution, la même exactitude et le pipeline complet.

Qu'est-ce que la calibration d'un NPU ?

La calibration fait passer des images représentatives du déploiement, généralement non annotées, dans le modèle afin que le compilateur estime les plages d'activation pour INT8 ou un autre format de faible précision. Des images aléatoires ou non représentatives peuvent produire un artefact compilé tout en dégradant l'exactitude sur la tâche.

LibreYOLO prend-il en charge les NPU edge ?

LibreYOLO exporte vers ONNX et plusieurs formats de runtime, propose un chemin direct de compilation RKNN pour certains modèles Rockchip et documente le flux de compilation Hailo externe. Tout autre artefact natif d'un fabricant exige encore son SDK et doit être présenté comme un candidat d'intégration tant qu'il n'a pas été compilé, validé et exécuté sur le matériel.