Le succès de l'apprentissage automatique repose sur l'évolutivité

Fourni par Bras

Steve Roddy est vice-président, Machine Learning Group, chez Arm.

Le changement est constant, et l'intelligence artificielle (IA) et l'apprentissage automatique (ML) changent tout, encore une fois. Pour les développeurs qui tentent de commercialiser de nouveaux produits et services qui tirent parti de l'IA et du ML, les défis sont aggravés par le fait que le paysage technologique est encore en développement.

Contrairement au secteur embarqué traditionnel, qui présente une relation linéaire entre le besoin de plus de performances de traitement et la manière dont ces performances sont utilisées, il existe une disparité entre l'IA et le ML, et les plates-formes matérielles sur lesquelles ils s'exécuteront : le ML est en constante évolution.

Visitez le centre de contenu

• Apprentissage automatique évolutif

L'abandon de la pensée séquentielle

Le ML est susceptible d'être utilisé partout, tout comme les logiciels embarqués traditionnels sont utilisés aujourd'hui. Cependant, contrairement au code traditionnel, qui est écrit ligne par ligne selon un schéma séquentiel (même si la génération automatique est utilisée), le ML sera déployé sous forme de modèles, créés par des frameworks qui apprennent. Des modèles vont, dans un sens très réel, naître. Et comme toute forme de progéniture, vous ne pouvez jamais vraiment être sûr de ce que vous obtiendrez jusqu'à ce qu'il arrive.

Pour les développeurs, alors, la nature prévisible des logiciels embarqués va disparaître ou changer de manière significative. Des outils sont en cours de développement pour aider à prédire comment un modèle fonctionnera, ou imposeront certaines restrictions sur la façon dont le modèle est formé pour se conformer à la plate-forme, mais ceux-ci sont naissants et en aucun cas une panacée. Il est probable que l'adaptation aux contraintes du système conduira à une perte de précision. La nature du ML est qu'il fournit la précision nécessaire sur le matériel fourni. Il s'ensuit donc que si le matériel est capable de s'adapter, vous pouvez éviter de compromettre la précision.

Il n'y a pas de solution unique pour l'apprentissage automatique. Les ingénieurs doivent concevoir des systèmes qui offrent des performances évolutives et peuvent ajuster le type de ressource de traitement qu'ils fournissent en fonction de la tâche à accomplir.

La façon dont un modèle fonctionne sur une plate-forme matérielle fixe changera également. La nature prévisible des logiciels embarqués a longtemps été un pilier de la conception ; en effet, l'idée que les caractéristiques du code vont changer après son déploiement est le cauchemar des ingénieurs. Les systèmes embarqués sont développés selon des paramètres de performance, une enveloppe basée sur la puissance, le coût, la dissipation thermique, la taille, le poids et un nombre quelconque de paramètres mesurables qui peuvent être échangés les uns contre les autres pour atteindre des objectifs définis. C'est essentiellement la façon dont le développement embarqué a toujours été fait, mais ce n'est pas la façon dont il sera fait à l'avenir.

L'évolutivité est la nouvelle norme

Au lieu de cela, les ingénieurs devront concevoir des systèmes offrant des performances évolutives, capables d'ajuster dynamiquement le type de ressource de traitement qu'ils fournissent en fonction de la tâche à accomplir. C'est différent de ce avec quoi les ingénieurs embarqués peuvent être à l'aise en ce moment. Depuis quelques années, les processeurs embarqués ont la possibilité de faire varier leur fréquence de fonctionnement et leur tension d'alimentation en fonction de la charge de travail. Essentiellement, le cœur d'un processeur peut fonctionner plus lentement lorsqu'il n'est pas occupé ; la réduction de la fréquence d'horloge principale se traduit directement par moins de transistors allumés et éteints par seconde, ce qui économise de l'énergie. Lorsque le cœur a vraiment besoin d'être occupé, la fréquence d'horloge est augmentée, ce qui augmente le débit. Il existe une relation entre la tension d'alimentation et la fréquence d'horloge ; en réduisant les deux, la quantité de puissance conservée est amplifiée. Ce type de mise à l'échelle ne suffira pas à fournir la puissance et les performances nécessaires dans les appareils embarqués en cours de développement pour exécuter des modèles ML.

C'est parce que la façon dont nous mesurons les performances va changer. À l'heure actuelle, les processeurs sont généralement mesurés en termes d'opérations par seconde ; nous mesurons maintenant cela en téraops, ou en billions d'opérations par seconde (TOPS). L'utilisation de TOPS pour mesurer les performances d'un processeur exécutant des inférences n'aura pas autant de sens que lors de l'exécution de code séquentiel, car la façon dont le modèle s'exécute n'est pas directement comparable à un logiciel embarqué classique. Les processeurs ML seront mesurés sur la précision qu'ils obtiennent lorsqu'ils fournissent un nombre donné d'inférences par seconde pour une quantité de puissance donnée. Nous n'avons pas encore de métrique standard pour cela, mais nous pouvons dire que le simple fait d'augmenter la fréquence d'horloge pour atteindre l'objectif d'inférences/s n'est pas garanti et fera probablement exploser le budget de puissance, sans améliorer la précision.

Le chemin de l'inférence est jonché de variables

Pourquoi? La raison réside dans le fonctionnement des modèles ML. Avec de nombreuses couches de probabilité à traverser, il y a tout autant de variables qui peuvent changer le chemin à travers ces couches. Le monde réel aura un impact beaucoup plus important sur la façon dont les modèles ML s'exécutent, avec beaucoup plus de variabilité que le code embarqué séquentiel linéaire. Prenons l'exemple du traitement du langage naturel et de la reconnaissance vocale : la voix et la cadence du locuteur joueront toutes un rôle dans l'efficacité du modèle, mais il peut également y avoir une interaction entre ces paramètres qui se traduit par une expérience différente dans diverses conditions. Le simple fait d'augmenter la vitesse du processeur dans ce cas peut ne pas donner le résultat souhaité.

De plus, l'une des caractéristiques déterminantes du ML est sa capacité à apprendre. Même si l'apprentissage par renforcement n'est pas appliqué dans l'appareil lui-même, il est toujours possible que les données soient renvoyées à un ordinateur central où le modèle peut être modifié en fonction des résultats observés. Même sans ces commentaires, il est probable que le modèle sera amélioré au fil du temps, uniquement en raison de la façon dont le ML évolue encore. Cela conduirait à la création et au déploiement d'un nouveau modèle (à l'aide de mises à jour en direct, par exemple), qui aurait alors des exigences de traitement potentiellement entièrement différentes, fonctionnant différemment dans des conditions identiques ou similaires.

La nature changeante des modèles ML signifie que, bien que les architectures CPU actuelles puissent être et soient utilisées pour ML, les architectures actuelles ne peuvent presque certainement pas fournir le moyen le plus optimal de les exécuter. Oui, les modèles peuvent fonctionner sur des processeurs utilisant toutes les fonctionnalités ALU habituelles trouvées dans la plupart des processeurs. Ils peuvent également bénéficier d'architectures hautement parallèles qui comportent massivement plusieurs instances de ces fonctionnalités, telles que les GPU, mais il est déjà clair que les GPU ne sont pas le meilleur moyen d'exécuter des modèles ML. En fait, nous avons déjà des exemples d'unités de traitement neuronal, et l'industrie des semi-conducteurs travaille dur pour développer des architectures entièrement nouvelles pour exécuter plus efficacement des modèles ML. À un moment donné, le matériel ou le logiciel devient fixe afin de laisser l'autre avancer. La bonne façon de résoudre ce problème est de s'engager dans un cadre logiciel commun pouvant être utilisé sur des plates-formes matérielles compatibles mais évolutives, de sorte que les deux évoluent ensemble.

Architectures hétérogènes flexibles

Ce faisant, l'évolutivité nécessaire pour prendre en charge l'IA et le ML peut être étendue du cœur du réseau à la périphérie, sans verrouiller l'architecture sur une plate-forme fixe. Le projet Trillium est la plate-forme de calcul ML hétérogène d'Arm composée de cœurs et de logiciels. Arm étend le projet Trillium pour lutter contre le ML à chaque point du réseau. La plate-forme logicielle commune ici est constituée des bibliothèques logicielles de réseau neuronal d'Arm, Arm NN, qui peuvent fonctionner sur les plates-formes de processeur Arm et sont également compatibles avec les principaux cadres de réseau neuronal tiers. Le matériel comprend les processeurs GPU Arm Cortex-A et Arm Mali existants qui sont améliorés pour l'IA et le ML, ainsi que de tout nouveaux processeurs pour l'accélération du ML.

En termes d'évolutivité, ML peut fonctionner et fonctionne sur des processeurs aussi petits et limités en ressources dans la classe Cortex-M, et aussi riches en fonctionnalités que les GPU Mali. Cependant, une véritable évolutivité est nécessaire pour répondre à tous les besoins de ML du cœur à la périphérie, c'est là qu'intervient la prochaine étape de l'évolution du processeur. Les unités de traitement neuronales, ou NPU, représentent la nouvelle génération d'architecture de processeur qui prendra en charge le ML. dans plus d'applications.

Seul Arm offre ce niveau d'évolutivité dans le paysage ML. Le choix d'architectures évolutives pouvant être composées de MCU, de CPU, de GPU et de NPU aidera les plates-formes matérielles à l'épreuve du temps face aux nouvelles applications logicielles qui n'ont même pas encore été conçues.

Il existe de nombreuses inconnues, en termes de modèles ML que nous créerons à l'avenir, de la puissance de calcul dont ils auront besoin pour fournir la précision souhaitée, de la rapidité avec laquelle les informaticiens pourront améliorer les modèles afin qu'ils aient besoin de moins de puissance, tout de ces considérations ont un impact direct sur le matériel sous-jacent. La seule chose que nous savons, c'est que répondre aux attentes changeantes des utilisateurs finaux nécessite une plate-forme flexible et évolutive.

cacher