7.11. NPU

Le H7 et le RT1062 exécutent l’inférence sur un CPU Cortex-M via TFLM et CMSIS-NN. L’AE3 et le N6 ajoutent un NPU dédié sur la même puce – une chaîne de traitement de tenseurs en silicium figé qui exécute les opérateurs lourds sans occuper le CPU. Les deux NPU de la gamme OpenMV proviennent de fabricants différents et leurs chaînes d’outils diffèrent, mais la caméra les expose tous deux via la même API ml.Model. Ce qui change, c’est le fichier sur le disque et le runtime qui le parcourt.

7.11.1. AE3 – Arm Ethos-U55

L’AE3 embarque un NPU Arm Ethos-U55 sur la même puce que le cœur applicatif Cortex-M55. Vela est le compilateur hors ligne qui prépare un modèle pour lui : Vela reçoit un .tflite standard en entrée et produit un .tflite en sortie dont les sous-graphes éligibles au NPU ont été repliés dans un opérateur Ethos-U personnalisé portant les commandes en octets exécutées par le NPU. Au moment de l’inférence, TFLM parcourt le fichier normalement ; l’opérateur Ethos-U aiguille ses commandes en octets via le pilote Ethos-U, et tout opérateur que Vela n’a pas replié retombe sur CMSIS-NN sur le M55.

7.11.2. N6 – ST Neural-ART

Le N6 embarque le NPU Neural-ART de ST et exécute STAI – le runtime de ST pour celui-ci – à la place de TFLM. STEdgeAI est le compilateur hors ligne : il reçoit un modèle en entrée et produit un blob réseau relogeable agencé pour le matériel Neural-ART. STAI charge le blob depuis ROMFS et le parcourt directement sur le NPU. La couverture des opérateurs correspond à ce que STEdgeAI prend en charge pour la pièce.

7.11.3. Même script, caméra différente

Les deux NPU exposent les mêmes tenseurs d’entrée et de sortie avec les mêmes paramètres de quantification qu’un modèle exécuté sur CPU. Un script écrit pour une caméra s’exécute sur une autre en chargeant un fichier de modèle préparé pour le NPU de cette caméra. Les seuils de détection, la gestion des ROI et le câblage du post-processeur – les décisions au niveau du script – ne changent pas.