Cela fait 8 ans que les puces d’intelligence artificielle des téléphones gaspillent toujours leur potentiel

Cela fait un peu plus de huit ans que nous avons commencé à parler des unités de traitement neuronal (NPU) à l’intérieur de nos smartphones et des premières perspectives de l’IA intégrée aux appareils. Gros points si l’on se souvient que le processeur Kirin 970 du HUAWEI Mate 10 était le premier, même si des idées similaires circulaient auparavant, notamment dans le domaine de l’imagerie.

Bien sûr, beaucoup de choses ont changé au cours des huit dernières années : Apple a finalement adopté l’IA, bien qu’avec des résultats mitigés, et Google s’est évidemment fortement appuyé sur son processeur Tensor pour tout, de l’imagerie à la traduction linguistique sur l’appareil. Demandez à n’importe laquelle des grandes entreprises technologiques, d’Arm et Qualcomm à Apple et Samsung, et elles vous diront toutes que l’IA est l’avenir du matériel et des logiciels des smartphones.

Et pourtant, le paysage de l’IA mobile semble encore assez confiné ; nous sommes limités à un nombre restreint mais croissant de fonctionnalités d’IA sur appareil, organisées principalement par Google, avec très peu de paysage de développeurs créatifs, et les NPU sont en partie à blâmer – non pas parce qu’ils sont inefficaces, mais parce qu’ils n’ont jamais été exposés comme une véritable plate-forme. Ce qui soulève la question suivante : à quoi sert exactement ce silicium présent dans nos téléphones ?

Avant de pouvoir déterminer de manière décisive si les téléphones ont réellement « besoin » d’un NPU, nous devrions probablement nous familiariser avec ce qu’il fait réellement.

Tout comme le processeur général de votre téléphone pour exécuter des applications, le GPU pour le rendu des jeux ou son FAI dédié au traitement des données d’image et vidéo, un NPU est un processeur spécialement conçu pour exécuter des charges de travail d’IA aussi rapidement et efficacement que possible. Assez simple.

Plus précisément, une NPU est conçue pour gérer des tailles de données plus petites (telles que de minuscules modèles 4 bits et même 2 bits), des modèles de mémoire spécifiques et des opérations mathématiques hautement parallèles, telles que la multiplication-addition fusionnée et la multiplication-accumulation fusionnée.

Maintenant, comme je l’ai dit en 2017, vous n’avez pas strictement besoin d’un NPU pour exécuter des charges de travail d’apprentissage automatique ; de nombreux algorithmes plus petits peuvent fonctionner même sur un processeur modeste, tandis que les centres de données alimentant divers grands modèles de langage fonctionnent sur un matériel plus proche d’une carte graphique NVIDIA que du NPU de votre téléphone.

Cependant, un NPU dédié peut vous aider à exécuter des modèles que votre CPU ou GPU ne peut pas gérer à un rythme rapide, et il peut souvent effectuer des tâches plus efficacement. Ce que cette approche hétérogène de l’informatique peut coûter en termes de complexité et de surface de silicium, elle peut lui rapporter de la puissance et des performances, évidemment essentielles pour les smartphones. Personne ne veut que les outils d’IA de son téléphone consomment sa batterie.

Si vous avez suivi la crise actuelle des prix de la RAM, vous saurez que les centres de données d’IA et la demande d’accélérateurs d’IA et de GPU puissants, en particulier ceux de NVIDIA, sont à l’origine des pénuries.

Ce qui rend l’architecture CUDA de NVIDIA si efficace pour les charges de travail d’IA (ainsi que pour les graphiques), c’est qu’elle est massivement parallélisée, avec des cœurs tenseurs qui gèrent des opérations de multiplication-accumulation (MMA) hautement fusionnées sur une large gamme de formats de matrices et de données, y compris les minuscules profondeurs de bits utilisées pour les modèles quantifiés modernes.

Alors que les GPU mobiles modernes, comme la gamme Mali d’Arm et Adreno de Qualcomm, peuvent prendre en charge des types de données 16 bits et de plus en plus 8 bits avec des mathématiques hautement parallèles, ils n’exécutent pas de très petits modèles fortement quantifiés – tels que INT4 ou inférieur – avec la même efficacité. De même, bien qu’ils prennent en charge ces formats sur papier et offrent un parallélisme substantiel, ils ne sont pas optimisés pour l’IA en tant que charge de travail principale.

Contrairement aux puissantes puces graphiques de bureau, les architectures GPU mobiles sont conçues avant tout pour l’efficacité énergétique, en utilisant des concepts tels que des pipelines de rendu basés sur des tuiles et des unités d’exécution découpées qui ne sont pas entièrement propices aux charges de travail soutenues et gourmandes en calcul. Les GPU mobiles peuvent certainement effectuer des calculs d’IA et sont assez efficaces dans certaines situations, mais pour les opérations hautement spécialisées, il existe souvent des options plus économes en énergie.

Le développement de logiciels constitue l’autre moitié tout aussi importante de l’équation. Le CUDA de NVIDIA expose les attributs architecturaux clés aux développeurs, permettant des optimisations approfondies au niveau du noyau lors de l’exécution de charges de travail d’IA. Les plates-formes mobiles ne disposent pas d’un accès de bas niveau comparable pour les développeurs et les fabricants d’appareils, mais s’appuient plutôt sur des abstractions de niveau supérieur et souvent spécifiques au fournisseur, telles que le SDK de traitement neuronal de Qualcomm ou la bibliothèque de calcul d’Arm.

Cela met en évidence un problème important pour l’environnement de développement de l’IA mobile. Alors que le développement des ordinateurs de bureau s’est principalement basé sur CUDA (bien que le ROCm d’AMD gagne du terrain), les smartphones utilisent diverses architectures NPU. Il existe le Tensor propriétaire de Google, Snapdragon Hexagon, le Neural Engine d’Apple, et bien plus encore, chacun avec ses propres capacités et plates-formes de développement.

Les chipsets pour smartphones dotés de capacités NPU (qui sont essentiellement toutes) sont conçus pour résoudre un problème : prendre en charge des valeurs de données plus petites, des mathématiques complexes et des modèles de mémoire complexes de manière efficace sans avoir à réorganiser les architectures GPU. Cependant, les NPU discrètes introduisent de nouveaux défis, notamment en matière de développement par des tiers.

Bien que des API et des SDK soient disponibles pour les puces Apple, Snapdragon et MediaTek, les développeurs devaient traditionnellement créer et optimiser leurs applications séparément pour chaque plate-forme. Même Google ne fournit pas encore un accès simple et général aux développeurs pour sa vitrine d’IA Pixels : le SDK Tensor ML reste en accès expérimental, sans aucune garantie de publication générale. Les développeurs peuvent expérimenter des fonctionnalités Gemini Nano de niveau supérieur via le kit ML de Google, mais cela reste bien loin d’un véritable accès de bas niveau au matériel sous-jacent.

Pire encore, Samsung a complètement retiré la prise en charge de son SDK Neural et le NNAPI Android, plus universel de Google, est depuis obsolète. Le résultat est un labyrinthe de spécifications et d’API abandonnées qui rendent extrêmement difficile le développement efficace d’une IA mobile tierce. Les optimisations spécifiques aux fournisseurs n’ont jamais pu être mises à l’échelle, nous laissant coincés avec des modèles compacts basés sur le cloud et en interne, contrôlés par quelques fournisseurs majeurs, tels que Google.

Heureusement, Google a introduit LiteRT en 2024 – repositionnant efficacement TensorFlow Lite – en tant que moteur d’exécution unique sur l’appareil prenant en charge le CPU, le GPU et les NPU des fournisseurs (actuellement Qualcomm et MediaTek). Il a été spécialement conçu pour maximiser l’accélération matérielle au moment de l’exécution, laissant le logiciel choisir la méthode la plus appropriée, corrigeant ainsi le plus gros défaut de NNAPI. Alors que NNAPI était destiné à éliminer le matériel spécifique au fournisseur, il a finalement standardisé l’interface plutôt que le comportement, laissant les performances et la fiabilité aux pilotes du fournisseur – une lacune que LiteRT tente de combler en s’appropriant le moteur d’exécution lui-même.

Il est intéressant de noter que LiteRT est conçu pour exécuter l’inférence entièrement sur l’appareil sur Android, iOS, les systèmes embarqués et même les environnements de bureau, signalant l’ambition de Google d’en faire un environnement d’exécution véritablement multiplateforme pour les modèles compacts. Néanmoins, contrairement aux frameworks d’IA de bureau ou aux pipelines de diffusion qui exposent des dizaines de paramètres de réglage d’exécution, un modèle TensorFlow Lite représente un modèle entièrement spécifié, avec des contraintes de précision, de quantification et d’exécution décidées à l’avance afin qu’il puisse s’exécuter de manière prévisible sur du matériel mobile contraint.

Bien que faire abstraction du problème fournisseur-NPU soit un avantage majeur de LiteRT, il vaut toujours la peine de se demander si les NPU resteront aussi centrales qu’elles l’étaient autrefois à la lumière d’autres développements modernes.

Par exemple, la nouvelle extension externe SME2 d’Arm pour sa dernière série de processeurs C1 offre une accélération de l’IA côté processeur jusqu’à 4x pour certaines charges de travail, avec une large prise en charge du framework et aucun besoin de SDK dédiés. Il est également possible que les architectures GPU mobiles évoluent pour mieux prendre en charge les charges de travail avancées d’apprentissage automatique, réduisant éventuellement le besoin de NPU dédiés. Samsung explorerait spécifiquement sa propre architecture GPU pour mieux exploiter l’IA sur l’appareil, qui pourrait faire ses débuts dès la série Galaxy S28. De même, la série E d’Immagination est spécialement conçue pour l’accélération de l’IA, avec pour la première fois la prise en charge de FP8 et INT8. Peut-être que Pixel adoptera éventuellement cette puce.

LiteRT complète ces avancées, permettant aux développeurs de moins se soucier de l’évolution exacte du marché du matériel. L’avancée de la prise en charge d’instructions complexes sur les processeurs peut en faire des outils de plus en plus efficaces pour exécuter des charges de travail d’apprentissage automatique plutôt qu’une solution de secours. Pendant ce temps, les GPU dotés d’un support de quantification supérieur pourraient éventuellement devenir les accélérateurs par défaut au lieu des NPU, et LiteRT peut gérer la transition. Cela rend LiteRT plus proche de l’équivalent mobile de CUDA qui nous manquait – non pas parce qu’il expose le matériel, mais parce qu’il l’abstrait finalement correctement.

Il est peu probable que les NPU mobiles dédiés disparaissent de sitôt, mais l’approche centrée sur les NPU et verrouillée par le fournisseur qui a défini la première vague d’IA sur appareil n’est clairement pas la fin du jeu. Pour la plupart des applications tierces, les processeurs et les GPU continueront d’assumer une grande partie de la charge de travail pratique, en particulier à mesure qu’ils bénéficieront d’une prise en charge plus efficace des opérations modernes d’apprentissage automatique. Ce qui compte plus que n’importe quel bloc de silicium, c’est la couche logicielle qui décide comment – ​​et si – ce matériel est utilisé.

Si LiteRT réussit, les NPU deviennent des accélérateurs plutôt que des gardiens, et l’IA mobile sur appareil devient enfin quelque chose que les développeurs peuvent cibler sans parier sur la feuille de route d’un fournisseur de puces spécifique. Dans cet esprit, il reste probablement encore du chemin à parcourir avant que l’IA sur appareil ne dispose d’un écosystème dynamique de fonctionnalités tierces, mais nous nous rapprochons enfin un peu plus.