Qu’est-ce que l'Inference at the Edge et quand en avez-vous besoin ?
Vous avez peut-être entendu les expressions “AI at the Edge”, “Edge ML” ou “Inference at the edge”. Ces termes font référence à des modèles de machine learning exécutant des tâches d'inférence à proximité du point de collecte de données de production, généralement en temps réel. L'inférence est exécutée sur des edge devices (par exemple, microcomputers, accélérateurs, mobiles, IoT). Un exemple typique est celui des voitures autonomes. Ils collectent des informations sur la zone environnante grâce à plusieurs capteurs et les traitent en temps réel dans le hardware local. Le temps réel fait référence au délai de prédiction maximum que nous pouvons nous permettre et va de quelques millisecondes à quelques secondes selon l'application.
L'inférence at the Edge offre de nombreux avantages et constitue parfois le seul moyen viable de concevoir votre système de vision par ordinateur. En bref, l'inférence at the Edge propose :
- Capacités d'inférence à distance (les données de production sont sur le terrain, loin d'un serveur),
- Prédictions en temps réel,
- Indépendance de la connexion réseau,
- Réduction du stockage des données (vous ne conservez que les prédictions et supprimez les données de production),
- Sécurité des données, car le besoin de transférer des données (sensibles) via un réseau est limité.
Cependant, il est soumis à de nombreuses contraintes telles que la puissance de traitement limitée du matériel, les limitations de mémoire, la durée de vie limitée de la batterie à moins d'être connectée à une prise d'alimentation, des coûts éventuellement plus élevés et une phase de déploiement de modèle légèrement plus complexe. Par conséquent, vous devez décider soigneusement si l’inférence "at the edge" est nécessaire pour votre projet. En bref, si aucun des points ci-dessus n'est une exigence stricte, vous pouvez probablement vous en sortir en transférant les données collectées vers un serveur cloud pour inférence et inversement si nécessaire.
Si vous avez décidé que l'inférence "at the edge" est la meilleure conception pour votre application, vous devrez respecter les contraintes de traitement. Lorsque vous exécutez l’inférence sur du matériel local à faible consommation, vous n’avez pas le luxe de traiter les données avec de très grands modèles de deep learning, car la latence peut dépasser les contraintes de temps réel. Heureusement, il existe des techniques d'optimisation permettant de réduire la taille d'un réseau et son délai d'inférence.
Techniques d'optimisation de la vitesse et de la mémoire
Les appareils Edge ont souvent une mémoire ou une puissance de calcul limitée. Vous pouvez appliquer diverses optimisations à vos modèles pour les exécuter dans le cadre de ces contraintes. L'optimisation du modèle est particulièrement utile pour :
- Réduire la latence d’inférence pour les appareils cloud et Edge,
- Déployer des modèles sur des appareils périphériques avec des restrictions de traitement, de mémoire et/ou de consommation d'énergie,
- Activer l'exécution sur du matériel restreint ou optimisé pour les fixed-point operations (nombres entiers),
- Optimiser des modèles pour les accélérateurs hardware spéciaux,
- Réduire les coûts de stockage des modèles et les charges utiles de mise à jour des modèles (pour les mises à jour "over-the-air").
Nous passerons en revue certaines des techniques les plus cruciales d’optimisation de la taille et de la vitesse.
1. Choisissez le meilleur modèle pour l'application
L’étape suivante n’est pas une technique d’optimisation, mais c’est l’étape la plus pertinente pour commencer. Avant d'entraîner votre modèle, tenez compte de la précision et de la vitesse d'inférence que vous devez atteindre. Vous devez faire un compromis entre la complexité et la taille du modèle. Les modèles plus petits sont souvent suffisants pour la plupart des tâches, nécessitent moins d’espace disque et de mémoire et sont beaucoup plus rapides et économes en énergie. Les graphiques ci-dessous aident à mieux comprendre ce compromis. En regardant le graphique précision/latence, vous devez décider si un Mobilenet v2 a suffisamment de précision pour vos besoins ou si vous devez passer à un modèle plus complexe comme le NASNet mobile ou Inception v3 (quantifié). Quoi qu’il en soit, Inception v4 n’est probablement pas une option pour l’inférence en temps réel.
2. Quantification des poids après l'entraînement (weight quantization)
La quantification est la technique consistant à contraindre un grand ensemble de valeurs (continues) à un plus petit ensemble de valeurs (discrètes). Dans les réseaux de neurones, la quantification post-entraînement est une technique qui réduit le nombre de bits nécessaires pour représenter les poids, les biais et les fonctions d'activation d'un réseau [1]. La quantification post-entraînement implique de prendre un modèle entraîné, de quantifier ses poids, puis éventuellement de réoptimiser le modèle.
Le processus standard consiste à représenter les paramètres d'un réseau sous forme de valeurs à virgule flottante de 32 bits, ce qui permet une précision numérique élevée et, en fin de compte, une exactitude pour le réseau neuronal. En convertissant les représentations à virgule flottante 32 bits en types numériques de précision réduite, nous pouvons effectivement réduire la taille d'un paramètre de 2x à 4x, selon le type de quantification. Cela se traduirait par un modèle avec une taille initiale de 128 Mo réduite à environ 64 Mo voire 32 Mo !
Les techniques de quantification les plus courantes convertissent le type numérique en nombres à virgule flottante de 16 bits (half-quantization) ou en nombres entiers de 8 bits (full-quantization). La quantification en entiers 8 bits a deux options, “Full Integer Quantization”, et “Dynamic Range Quantization”. Le premier quantifiera les poids, les biais, les activations, les entrées et les sorties (à partir d’un ensemble de données représentatif), tandis que le second quantifiera uniquement les poids. En fonction de votre matériel, certaines techniques fonctionnent mieux que d'autres, mais nous y reviendrons en détail dans la section suivante.
Cependant, en informatique, un lancement gratuit existe rarement. En réduisant la précision numérique, vous pouvez dégrader la précision globale de votre modèle. En fonction de la gravité de la quantification, nous percevons généralement une baisse de précision d'environ 0 à 2 %. Cependant, pour une baisse de précision de 2 %, nous pouvons réaliser jusqu'à 84 % d'économie d'énergie [2] et une accélération de 3 fois ou plus. Dans la plupart des cas, la dégradation de la précision est inférieure à 1 %, tandis que dans de rares cas, nous pouvons même constater une légère augmentation de la précision, généralement un modèle surajusté et complexe régularisé suite à la quantification.
3. Le Pruning de modèles
Le pruning, ou élagage en français, supprime les paramètres redondants ou les neurones entiers qui ne contribuent pas de manière significative à la précision des résultats. Cette condition peut survenir lorsque les coefficients de pondération sont nuls, proches de zéro ou répliqués. En conséquence, vous pouvez réduire la complexité des calculs tout en maintenant l’augmentation de la vitesse d’inférence et la précision à des niveaux stables. Les réseaux élagués peuvent également être re-entraînés par la suite, offrant la possibilité d'échapper aux précédents minima locaux et d'améliorer encore la précision [3].
4. Le regroupement des poids (weight clustering)
Le clustering, ou partage de poids, réduit le nombre de valeurs de poids uniques dans un modèle, ce qui entraîne des avantages pour le déploiement. Il regroupe d'abord les poids de chaque couche en N clusters, partage ensuite la valeur du centroïde du cluster pour tous les poids appartenant à ce cluster. Vous pouvez regrouper les couches de manière sélective. Plus le nombre de clusters est petit, plus le niveau de compression est élevé, et vice versa.
Dans le tableau 1, nous voyons qu'une compression de près de 3,5x peut être obtenue avec une perte de précision minimale de 1,6 % lors du regroupement de toutes les couches convolutives avec 32 clusters. Une compression 2x peut être obtenue en regroupant seulement 3 couches de conversion avec une réduction de précision inférieure à 0,3 %.
Outils Open Source pour l'optimisation des inférences
Nous avons discuté des techniques, nous allons donc maintenant discuter des outils qui les appliquent. Dans le tableau 2, vous pouvez voir une liste complète mais non exhaustive d'outils open source pour l'optimisation de l'inférence de réseau neuronal.
Parmi eux, TensorFlow Lite est probablement le plus complet et le plus flexible. Il propose de nombreuses techniques de quantification différentes, le pruning, le regroupement de poids et une fonctionnalité expérimentale pour le "Quantization Aware Training". Il prend en charge un large éventail de matériels lors de l'inférence et est facile à utiliser. Cependant, il ne prend par défaut en charge que les modèles TensorFlow. Mais vous pouvez optimiser les modèles écrits dans d'autres frameworks en tirant parti d'un format de réseau neuronal global appelé ONNX.
Un autre SDK important, lié aux GPU NVidia, est la bibliothèque TensorRT. Il s'agit d'une bibliothèque créée par NVidia spécifiquement pour leur matériel. Le SDK propose des optimisations spécifiques au système qui aboutissent à une inférence de très hautes performances. De plus, il prend en charge les modèles TensorFlow et PyTorch. Si l'objectif est une latence très faible et un débit élevé, TensorRT est l'outil optimal avec lequel travailler. Cependant, il est limité au matériel NVidia et il peut être un peu frustrant de travailler avec celui-ci sur leurs appareils embarqués (jetson series).
Comment trouver la bonne technique d'optimisation pour votre matériel
Maintenant que nous avons expliqué les techniques et outils d'optimisation clés, nous allons entrer dans les détails de la sélection de l'optimisation la plus adaptée à votre matériel. Parfois, les choix sont limités en raison de l’architecture matérielle, mais parfois vous pouvez choisir.
Déploiement sur des CPU basse consommation: Il peut s'agir du CPU d'un micro-ordinateur (par exemple Raspberry Pi), du CPU d'un téléphone mobile ou même du CPU d'un ordinateur portable commercial. La quantification Float-16 bits est possible, mais dans ce scénario, vous devriez préférer la quantification à int-8 bits. Les raisons sont :
- Les CPUs sont très rapides lorsqu'ils travaillent avec des entiers
- Par défaut, un modèle quantifié float16 "déquantisera" ("dequantize") les valeurs des poids en float32 lorsqu'il sera exécuté sur le processeur. [4].
Avec TF-Lite, vous pouvez opter pour une plage dynamique ou une quantification entière complète. Vous pouvez réduire efficacement la taille d’un modèle par 4 et obtenir une accélération de 2 à 3 fois, généralement avec une faible perte de précision. Mais assurez-vous de vérifier que la précision du modèle optimisé se situe toujours dans la plage souhaitée.
Déploiement sur un GPU Android : Pour les GPU Android, TF-Lite prend en charge les mêmes techniques de quantification que celles répertoriées ci-dessus. Nous vous suggérons de suivre les mêmes directives.
Déploiement sur du hardware integer-only : De nombreux microcontrôleurs et TPU Edge ne prennent en charge que les opérations sur les nombres entiers. Si votre matériel appartient à cette catégorie, votre seule option est d'utiliser la Full Integer Quantization. L'accélération sera énorme, en particulier pour les TPU, mais assurez-vous d'évaluer le modèle quantifié pour vérifier que la précision se situe toujours dans la plage souhaitée.
Déploiement sur les GPU NVidia : Cette catégorie comprend les GPU informatiques commerciaux haut de gamme et les GPU intégrés comme la série NVidia Jetson. Dans ce scénario, vous avez la possibilité de travailler avec Tensor RT. TensorRT gérera les détails d'optimisation et pourra vous aider à atteindre des FPS en temps réel (20 à 60 ips).
L'architecture d'un GPU est optimisée pour les opérations avec des nombres à virgule flottante. La quantification jusqu'à des nombres à virgule flottante de 16 bits est généralement un excellent point de départ. Si la réduction de taille par 2 n'est toujours pas suffisante pour atteindre la vitesse d'inférence optimale, un pruning conservateur ou un regroupement de poids peut également être appliqué. TF-Lite ne prend en charge que la quantification à 16 bits flottants pour ces GPU. Cependant, TensorRT fournit également une quantification complète sur 8 bits.
Est-il possible d'utiliser des modèles optimisés dans le cloud pour atteindre le temps réel ?
Déploiement sur le cloud : Lors du déploiement de votre solution sur le cloud, vous avez accès à du hardware puissant, ce qui vous permet d'opter pour un modèle plus gros et plus complexe pour commencer. Toutefois, il peut s'avérer nécessaire de réduire le délai entre l'entrée et la prédiction, afin d'obtenir un temps réel.
Dans ce cas, votre plus grand ennemi est la vitesse et la bande passante du réseau. Étant donné que vous devez transférer des données dans les deux sens, une grande partie du retard global est due aux coûts de transfert de données. Si votre délai de transfert de données dépasse les contraintes de temps réel de l’application, vous ne devriez pas vous soucier d’optimiser la vitesse d’inférence en premier lieu. Optez plutôt pour un device Edge.
En revanche, si les délais de transfert de données ne constituent pas un goulot d'étranglement, nous vous conseillons d'optimiser votre modèle pour la vitesse d'inférence. En supposant que l'inférence soit exécutée sur un GPU haut de gamme, une compression légère en flottants 16 bits, un weight clustering de couches cachées spécifiques ou une combinaison quelconque devrait vous fournir une accélération suffisante pour répondre à contraintes de temps réel sans sacrifier trop de précision.
