Vue d'ensemble de l'IA¶

Vue d'ensemble¶

Cette page explique comment déployer une fonction d'IA embarquée sur SF32 : choisir un composant, préparer le modèle pour son chemin d'exécution, dimensionner la mémoire et planifier les inférences dans le budget énergétique du produit. Elle suppose acquises les notions matérielles présentées dans Accélérateur IA. Pour connaître d'abord le rôle et les limites de l'accélérateur, consultez cet article.

Le SDK expose les opérations accélérées via le HAL NNACC (accélérateur de réseaux neuronaux), avec des exemples distincts pour le HAL et le pilote RT-Thread. Ces exemples valident une opération individuelle de convolution depthwise, pas le déploiement complet d'un modèle entraîné. Utilisez-les pour établir une base de référence fonctionnelle au niveau d'un opérateur ; choisissez et vérifiez séparément l'environnement d'exécution, les outils de conversion et la correspondance des couches.

Les détails d'implémentation cités ci-dessous sont propres au SDK v2.5.1. Ni ces détails ni la disponibilité de NNACC au niveau de la famille ne garantissent la prise en charge d'une référence précise, d'un environnement d'exécution ou d'un convertisseur de modèles complets, la compatibilité des opérateurs, un repli CPU automatique ou une entrée caméra. Vérifiez ces points avec la révision et la configuration exactes du SDK, la révision de la puce, l'environnement choisi et la carte.

Utilisez cette page lorsque vous êtes responsable des choix produit et du déploiement d'une fonctionnalité IA : ce que l'appareil doit décider localement, combien de mémoire et d'énergie il peut consommer, et comment la fonctionnalité doit se comporter face à des données de capteurs réelles. Elle complète l'article sur l'accélérateur, qui décrit la frontière matérielle.

Définir ce que le produit doit décider localement¶

Partez de la décision produit, pas du modèle :

• Que doit classifier ou détecter l'appareil par lui-même, sans aller-retour vers un téléphone ou le cloud ?
• Quels capteurs alimentent cette décision : mouvement, audio, signaux biométriques, caméra ou une combinaison ?
• À quelle fréquence l'appareil doit-il prendre cette décision, et quel délai de réponse doit-il respecter ?
• Que se passe-t-il si le modèle embarqué se trompe — un faux positif ou un faux négatif est-il plus coûteux ?
• Le modèle devra-t-il un jour être mis à jour sur le terrain, et comment ?

Ces réponses déterminent tous les choix suivants : la taille du modèle, le budget mémoire, le composant à sélectionner et la durée pendant laquelle le système peut rester en veille entre deux inférences.

Choisir le bon composant SF32¶

Tous les composants SF32 ne ciblent pas les charges de travail IA de la même manière :

Ce tableau constitue un point de départ, pas une garantie que le modèle tiendra en mémoire ou s'exécutera efficacement. Vérifiez la mémoire, les interfaces de capteurs, l'instance d'accélérateur et le support SDK de la référence retenue pour la charge complète. Le guide NNACC du SDK v2.5.1 indique un accélérateur HCPU pour chacune des familles SF32LB55x et SF32LB56x, et un dans chacun des sous-systèmes HCPU et LCPU de SF32LB58x. Il ne confirme pas la disponibilité de NNACC sur SF32LB52x ou SF32LB57x ; cette absence d'information ne prouve pas l'absence de l'accélérateur. Ces nombres ne démontrent ni la compatibilité d'un modèle ni son efficacité énergétique. Voir Positionnement par famille de composants pour le contexte de sélection.

Le flux de développement du modèle¶

Sur le plan pratique, l'intégration d'un modèle sur du matériel SF32 suit la même structure quel que soit le cas d'usage spécifique :

1. Entraîner ou sélectionner un modèle sur un poste de travail, avec des données représentatives de ce que le capteur verra réellement sur le terrain — les données de laboratoire, souvent très propres, diffèrent sensiblement des signaux bruités rencontrés en conditions réelles.
2. Le réduire pour les contraintes embarquées — via le choix de l'architecture, l'élagage (pruning), ou la quantification — avant de se préoccuper de la conversion spécifique à l'accélérateur.
3. Exporter le modèle et associer ses opérations à l'environnement d'inférence choisi ainsi qu'aux opérateurs, dispositions et formats numériques effectivement pris en charge par le SDK cible. Le HAL NNACC ne fournit pas à lui seul un convertisseur de modèles complets ni un moteur d'exécution de graphes.
4. Valider numériquement après conversion et quantification ; ne supposez pas que la précision obtenue sur un poste de travail se maintient sans changement.
5. Intégrer le prétraitement, l'inférence et le post-traitement dans le firmware — le modèle n'est qu'un appel de fonction au sein d'un pipeline plus vaste.
6. Profiler la latence, la mémoire, la consommation et la précision sur du matériel réel, pas seulement en simulation.
7. Tester sous une charge combinée réaliste — Bluetooth, écran et capteurs actifs en même temps que l'inférence, pas isolément.

Une erreur fréquente d'intégration consiste à optimiser le modèle sans mesurer le prétraitement, la mise en tampon et le post-traitement. Ces étapes peuvent coûter autant que l'inférence accélérée ; mesurez donc le chemin complet.

Définir la spécification d'exécution¶

Avant de convertir un modèle, consignez précisément les exigences d'exécution auxquelles le firmware doit répondre :

Les responsables du machine learning et du firmware doivent examiner ces exigences ensemble. Si la forme des tenseurs, le format ou l'ensemble d'opérateurs du modèle change sans mise à jour du firmware, le problème peut se manifester par une précision dégradée ou une latence instable, plutôt que par une erreur de compilation explicite.

Revue des opérateurs et des replis (fallback)¶

Avant de sélectionner un modèle, vérifiez chaque opérateur, ses paramètres et son chemin réel d'exécution. Une implémentation CPU ou un repli automatique doit être explicitement fourni par l'environnement choisi ; une opération non prise en charge peut aussi empêcher le déploiement. Même un petit modèle peut être lent si des couches fréquentes s'exécutent sur le CPU ou imposent des conversions répétées de disposition.

Le critère de réussite n'est pas « le modèle s'exécute ». Le critère de réussite est « le pipeline complet atteint les objectifs de précision, de latence, de mémoire et d'énergie avec la même distribution de données que celle que le produit rencontre sur le terrain ».

Quantification et dimensionnement mémoire¶

Les modèles compacts et quantifiés sont courants pour l'IA sur microcontrôleur, souvent avec des entiers sur 8 bits plutôt que des nombres à virgule flottante. Choisissez le format numérique pris en charge par le chemin réel d'exécution. Avant de fixer l'architecture, dimensionnez la mémoire pour tous les éléments suivants, pas seulement les poids :

La quantification peut réduire les coûts mémoire et de calcul, mais revérifiez la précision après conversion avec des données de capteurs représentatives. Le guide du SDK v2.5.1 documente l'accélération de arm_convolve_1x1_HWC_q7_fast_nonsquare, arm_convolve_HWC_q7_basic_nonsquare et arm_depthwise_separable_conv_HWC_q7_nonsquare. La configuration du HAL utilise des tampons sur 8 bits et des décalages pour le biais et la sortie. Cela ne prouve pas que les points zéro et les échelles par canal de tout modèle int8 moderne sont directement compatibles. Vérifiez l'équivalence numérique ainsi que la solution prévue pour chaque couche non prise en charge : implémentation CPU, conversion ou refus de déploiement.

Placement des tampons et hiérarchie mémoire¶

La bande passante mémoire peut limiter les performances de l'IA même si la capacité de calcul est disponible. Sur les composants SF32 avec SRAM, Flash, PSRAM et caches d'instructions/données STAR-MC1, vérifiez l'accessibilité de la mémoire et le coût du placement des tampons :

• Placez les tenseurs et tampons intermédiaires souvent utilisés dans une mémoire accessible au CPU et à l'instance d'accélérateur choisie, avec l'alignement et la disposition requis.
• Placez les poids volumineux ou les ressources rarement utilisées en mémoire externe seulement si le chemin d'exécution le permet. Toute copie vers une mémoire accessible à l'accélérateur doit être incluse dans les budgets mémoire, latence et énergie.
• Pendant un transfert, le tampon partagé doit être utilisé exclusivement par le CPU ou par l'accélérateur/DMA. Avant l'accès matériel, préparez toute la plage alignée sur les lignes de cache : nettoyez les lignes de cache contenant les données d'entrée écrites par le CPU et traitez les lignes modifiées de la zone de sortie selon les règles du SDK pour les écritures de périphérique. Attendez la fin de l'opération avant d'invalider la sortie et de rendre le tampon au CPU. Ne modifiez ni le tampon ni d'autres données partageant ses lignes de cache tant que le matériel l'utilise.

L'implémentation du HAL v2.5.1 vérifie que les tampons ne franchissent pas les limites des fenêtres d'adresses de 1 MiB (1 048 576 octets) et impose que l'entrée et le biais soient dans la même fenêtre. Vérifiez les adresses réellement allouées, pas seulement la mémoire libre totale. Le démarrage bloquant attend la fin par scrutation ; le mode avec interruptions exige un traitement correct de l'IRQ et une notification de fin. Vérifiez les valeurs de retour et prévoyez une récupération après erreur ainsi que des attentes bornées côté application, sans supposer que le moteur du modèle possède un délai d'expiration.

Voir STAR-MC1 pour les considérations de cache et de système mémoire dans ce type de profil d'accès mixte.

Feuille de calcul du budget mémoire¶

Avant l'intégration au firmware, établissez un tableau de dimensionnement mémoire à partir des valeurs de pire cas, et non d'estimations moyennes :

Laissez de la marge pour la pile, le tas, les objets RTOS, la journalisation et l'OTA. Un modèle qui ne tient que lorsque tous les autres sous-systèmes sont désactivés n'est pas un modèle prêt pour la production.

Construire le pipeline complet¶

L'accélérateur est une étape du pipeline allant du capteur à la décision. Trois chemins d'entrée courants sont décrits ci-dessous.

Audio et voix¶

La détection de mots-clés, les déclencheurs de type mot de réveil et la classification d'événements audio nécessitent la capture microphone, le découpage en trames et l'extraction de caractéristiques avant le début de l'inférence. La vue d'ensemble de l'audio décrit la capture et la mise en tampon de ce flux. L'accélérateur n'est utile que si l'audio qui l'alimente est capturé et mis en tampon efficacement dès le départ.

Mouvement et fusion de capteurs¶

La reconnaissance de gestes, la classification d'activité et l'analyse biométrique utilisent généralement les données d'accéléromètres, de gyroscopes ou d'autres capteurs. Mesurez séparément le fonctionnement des capteurs, la capture, le prétraitement et l'inférence avant de déterminer ce qui consomme le plus d'énergie. Le regroupement et la capture par interruptions peuvent réduire les réveils si la latence et la détection de tous les signaux nécessaires le permettent ; leur effet ne dépasse pas systématiquement le coût du modèle. Consultez la vue d'ensemble de la conception basse consommation pour des conseils d'ordonnancement.

Caméra et entrée image¶

Une entrée caméra peut entraîner des coûts importants de capture, de mise en tampon, de bande passante et d'inférence. La charge réelle dépend de la résolution, de la cadence, du fonctionnement du capteur et de l'architecture du modèle. Si la précision le permet, réduisez l'image ou traitez une région d'intérêt. Choisissez un modèle adapté aux contraintes embarquées plutôt que de supposer qu'un modèle de vision pour ordinateur se déploie sans modification.

Ordonnancement de l'inférence en fonction de l'énergie¶

Choisissez l'ordonnancement pour détecter les signaux requis dans le délai de réponse prévu. L'inférence périodique est valable si le produit exige des décisions régulières ; conditionner l'exécution à des événements n'est utile que si aucun signal nécessaire n'est manqué.

• Lorsque cela convient, déclenchez l'inférence sur de nouvelles données pertinentes, par exemple un seuil de capteur ou une trame audio complète. Conservez le traitement périodique s'il est nécessaire et vérifiez les faux négatifs et le pire délai de réponse après modification du déclencheur.
• Regroupez les échantillons lorsque les exigences de latence le permettent, plutôt que d'exécuter de nombreuses petites inférences.
• Lorsque le composant et le SDK le prennent en charge, déplacez la détection permanente légère vers le processeur basse consommation plutôt que de réveiller le CPU applicatif principal pour chaque échantillon.
• Mesurez l'énergie par inférence en intégrant la puissance d'alimentation mesurée (tension d'alimentation × courant) sur un intervalle clairement défini. Incluez la capture, le pré/post-traitement et les transitions réveil/veille dans le budget de la fonction. Une exécution plus rapide peut réduire l'énergie en activité ou permettre un retour plus tôt en veille, mais le gain dépend du courant, du trafic mémoire et du reste du système.

Les conseils sur la consommation à l'échelle du système figurent dans la vue d'ensemble de la conception basse consommation. Consultez-la en complément pour toute fonctionnalité IA qui doit fonctionner en continu ou presque.

Arbitrage entre précision, latence et consommation¶

Ces points décrivent des contraintes de conception courantes, pas des relations fixes. Mesurez la précision réelle du modèle et l'énergie du pipeline complet pour effectuer ces arbitrages :

Avant tout réglage, déterminez quel compromis le produit doit privilégier. Un détecteur de gestes peut souvent accepter un léger délai supplémentaire pour préserver l'autonomie ; un déclencheur vocal tolère généralement peu de retard, mais doit aussi éviter les réveils intempestifs qui gaspillent de l'énergie.

Mise à jour du modèle et validation sur le terrain¶

Si la fonctionnalité IA est susceptible de s'améliorer après le lancement, concevez le support de mise à jour du modèle dès le début :

• Versionnez le modèle séparément du firmware lorsque c'est possible, et consignez dans le paquet le format et les exigences d'entrée attendus.
• Vérifiez l'authenticité, l'intégrité et la compatibilité du paquet avec l'environnement d'exécution et les entrées avant activation. L'activation doit résister à une interruption de mise à jour et permettre un retour à une version validée si les contrôles de démarrage échouent.
• Stockez la calibration, les seuils et les constantes de post-traitement avec la version du modèle qui les requiert.
• Journalisez suffisamment de statistiques de terrain pour diagnostiquer une dérive sans stocker inutilement des données brutes de capteurs privées.
• Relancez les tests de consommation et de coexistence après chaque mise à jour du modèle ; une amélioration de la précision du modèle peut rester une régression produit si elle réveille le système plus souvent.

Déboguer la performance et la précision de l'IA¶

Erreurs courantes¶

• Choisir une architecture de modèle avant de vérifier quels opérateurs l'environnement d'exécution cible accélère réellement.
• Porter un modèle à l'échelle d'un poste de travail au lieu de concevoir dès le départ pour les contraintes embarquées.
• Ignorer le coût mémoire des activations intermédiaires et ne budgétiser que les poids du modèle.
• Exécuter l'inférence sans vérifier que sa fréquence et son déclencheur respectent les signaux à détecter et le délai de réponse requis.
• Valider la précision uniquement sur des données de laboratoire propres, jamais sur du bruit réaliste de terrain/capteur.
• Tester la fonctionnalité IA isolément et ne découvrir les problèmes de coexistence qu'après l'intégration complète du produit.
• Optimiser la latence du modèle en ignorant les étapes de pré- et post-traitement qui l'entourent.

Liste de contrôle de mise en service¶

• Définir la décision locale que le produit doit prendre et le compromis acceptable latence/précision/consommation.
• Sélectionner le composant SF32 en fonction de la taille du modèle et des besoins mémoire, pas seulement de l'objectif de coût.
• Construire et valider le pipeline complet (capture -> prétraitement -> inférence -> post-traitement) d'abord avec un modèle de test minimal, puis avec le modèle de production.
• Convertir et quantifier le modèle réel, puis valider la précision par rapport à des données de capteurs réalistes.
• Budgétiser la mémoire pour les poids, les tenseurs d'entrée/sortie et les activations intermédiaires ensemble.
• Valider la gestion de la cohérence de cache pour tout tampon partagé entre le CPU et l'accélérateur.
• Valider l'ordonnancement périodique ou événementiel par rapport aux signaux à détecter, à la latence maximale et au budget énergétique mesuré.
• Profiler l'énergie par inférence sous charge système combinée (Bluetooth, écran, capteurs actifs).
• Revalider la précision et la consommation après tout changement de quantification, de modèle, ou d'ordonnancement.

Points clés à retenir¶

• Partez de la décision produit et des données de capteurs, pas de l'architecture du modèle — le modèle n'est qu'une étape dans un pipeline plus vaste.
• Utilisez le positionnement des familles pour présélectionner, puis vérifiez la référence, le SDK, l'association des opérateurs, l'allocation mémoire et la charge simultanée.
• Budgétisez la mémoire pour l'ensemble du pipeline (poids, tenseurs, activations, tampons de pré/post-traitement), pas seulement la taille du fichier modèle.
• Choisissez une inférence périodique ou événementielle qui détecte tous les signaux requis et mesurez l'énergie de la fonction complète, sans assimiler la vitesse du modèle à un résultat de consommation.
• Testez la précision sur des données de terrain réalistes et testez la fonctionnalité complète sous charge système combinée, pas isolément.

Dernière mise à jour: 2026-10-12