What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine
À travers une étude de mesure rigoureuse du placement des modèles de langage et de la vitesse de décodage sur l'Apple Neural Engine, l'auteur démontre que l'expression computationnelle et l'encodage des poids, plutôt que l'architecture du modèle seule, dictent la résidence et la performance de l'accélérateur, menant à une procédure de conception qui priorise l'efficacité de l'encodage pour obtenir des modèles ternaires nettement plus petits et plus rapides.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez un smartphone essayant de comprendre une conversation. Pour ce faire, il doit faire fonctionner un cerveau numérique massif, un modèle de langage, directement sur l'appareil. Pour que cela fonctionne de manière fluide, le téléphone doit utiliser un processeur spécial, ultra-rapide, conçu précisément pour ce genre de réflexion, plutôt que son cerveau principal à usage général. Le défi est que ce processeur spécial est exigeant ; il n'accepte de faire tourner certains types de calculs et refuse d'en exécuter d'autres, même si ceux-ci sont mathématiquement identiques. Pendant des années, les développeurs ont essayé de deviner quels calculs fonctionneraient et comment les rendre rapides, s'appuyant souvent sur des règles empiriques qui s'avéraient fausses. Ils ont supposé que si un modèle était suffisamment petit, il fonctionnerait sur le processeur rapide, ou que réduire la taille des nombres aiderait toujours. Mais personne n'avait réellement observé le processeur pour voir ce qu'il faisait vraiment, ni mesuré précisément comment la taille du modèle et la façon dont ses nombres sont stockés modifiaient sa vitesse.
Un chercheur nommé Shahir M A a décidé d'arrêter de deviner pour commencer à observer. En utilisant un ordinateur Apple doté d'une puce M1, il a construit une série d'expériences pour voir exactement ce qui se passe lorsqu'un modèle de langage tente de s'exécuter sur le processeur spécial du téléphone, connu sous le nom de Neural Engine. Il ne s'est pas contenté de regarder ce que le logiciel disait qu'il ferait ; il a mesuré l'électricité et les données réelles circulant à travers la puce pour voir ce qui se passait réellement. Il a testé des dizaines de façons différentes de construire une opération mathématique, entraîné de vrais modèles de différentes tailles, et modifié la façon dont les nombres à l'intérieur de ces modèles étaient stockés, allant de la précision standard à des formats très compressés à faible précision. Son objectif était simple : découvrir ce qui permet réellement de placer un modèle sur le processeur rapide et à quelle vitesse il peut parler une fois qu'il y est parvenu.
La première chose qu'il a découverte est que le processeur ne se soucie pas de la signification d'un calcul, mais seulement de la façon dont il est écrit. Il a découvert que si vous écrivez un type spécifique de normalisation — une étape qui aide le modèle à stabiliser ses nombres — d'une certaine manière, le processeur l'accepte immédiatement et l'exécute à pleine vitesse. Mais si vous écrivez exactement la même étape mathématique en utilisant un ensemble d'instructions légèrement plus complexes, le processeur refuse de s'en occuper et force le téléphone à utiliser son cerveau plus lent, à usage général. C'est comme si le processeur parlait un dialecte mathématique spécifique ; si vous utilisez le bon dialecte, il écoute, mais si vous utilisez un autre, même si le sens est le même, il s'en va. Cela signifie que la façon dont un développeur écrit le code est aussi importante que les mathématiques elles-mêmes.
La deuxième découverte, et peut-être la plus surprenante, est que la taille du modèle n'est pas le seul facteur déterminant pour savoir s'il peut fonctionner sur le processeur rapide. Les chercheurs ont découvert qu'un modèle d'environ vingt-six millions de paramètres, écrit en précision standard, était trop petit pour fonctionner sur le processeur spécial du tout. Il était contraint de s'exécuter sur le cerveau lent, prenant plus d'une seconde pour générer chaque mot. Cependant, lorsqu'ils ont pris ce même modèle et ont compressé les nombres à l'intérieur pour utiliser moins de bits, le processeur l'a soudainement accepté. La version compressée fonctionnait sur le processeur rapide et générait des mots en moins d'une seconde. En fait, pour les petits modèles, la compression des nombres était le seul moyen de les faire entrer sur le processeur rapide. Le processeur avait une règle cachée : il ne ferait pas tourner de petits modèles à moins qu'ils ne soient compressés. Cela a renversé l'hypothèse commune selon laquelle les modèles plus volumineux sont toujours ceux qui ont besoin du processeur rapide ; ici, les petits modèles avaient besoin de la compression pour passer la porte.
Une fois le modèle à l'intérieur du processeur rapide, la vitesse était déterminée presque entièrement par la quantité de données qui devaient être déplacées, et non par la complexité des mathématiques. Les chercheurs ont mesuré le flux de données et ont découvert que pour chaque mot généré par le modèle, celui-ci devait acheminer l'ensemble de ses poids — les nombres qui constituent sa connaissance — à travers le processeur. Cela se produisait pour chaque mot, peu importe la longueur de la conversation. En conséquence, la vitesse était directement liée au nombre de bits présents dans ces poids. Un modèle utilisant des nombres compressés à faible précision déplaçait beaucoup moins de données et était donc beaucoup plus rapide. Ils ont découvert qu'un modèle utilisant des nombres de deux bits était presque trois fois plus rapide qu'un modèle utilisant des nombres standards, simplement parce qu'il devait déplacer moins de données. Le type de mathématiques utilisé par le modèle, comme s'il se concentrait davantage sur l'attention ou sur la convolution, importait très peu pour la vitesse une fois que le modèle était déjà en cours d'exécution sur le processeur. La seule chose qui comptait était la taille des données déplacées.
Les chercheurs ont conclu que la meilleure façon de construire un modèle de langage pour un téléphone est de commencer par la compression, et non par la taille. Au lieu de construire un grand modèle pour ensuite essayer de le rétrécir, il faut d'abord choisir le format le plus compressé possible, puis consacrer le budget de mémoire disponible à l'ajout de paramètres. Ils ont découvert qu'un modèle de vingt-cinq millions de paramètres, utilisant un type spécifique de mathématiques compressées, pouvait tenir dans seulement dix mégaoctets d'espace et générer des mots en environ six dixièmes de milliseconde. C'était presque dix fois plus petit et trois fois plus rapide que les modèles standards non compressés que les développeurs utilisent habituellement au départ. L'étude a montré que le chemin vers un modèle de langage sur l'appareil qui soit rapide ne consiste pas à rendre le modèle plus grand ou plus complexe, mais à choisir la bonne façon d'écrire les mathématiques et la bonne façon de stocker les nombres. En mesurant le flux réel de données, ils ont prouvé que la clé de la vitesse n'est pas seulement d'avoir un processeur rapide, mais de savoir exactement comment le nourrir.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.