« LLM in a Flash » : rendre possible une inférence LLM efficace avec une mémoire limitée

Collection de lectures d'articles sur le NLP

• Cette collection de lectures consacrée au traitement automatique du langage naturel (NLP) se compose de 22 éléments.
• Cette collection a été récemment mise à jour et est utile pour comprendre les dernières tendances de la recherche dans le domaine du NLP.
• Le NLP est une technologie qui permet aux ordinateurs de comprendre et de traiter le langage humain, avec de nombreuses applications comme la traduction automatique, l'analyse de sentiments et les systèmes de questions-réponses.

L'avis de GN⁺

• Cette collection constitue une ressource très utile pour les chercheurs et développeurs intéressés par le NLP, car elle offre une vue d'ensemble des recherches les plus récentes dans ce domaine.
• Le NLP est un domaine qui évolue particulièrement vite parmi les technologies d'IA, et cette collection permet de découvrir les dernières tendances ainsi que des idées innovantes.
• Les technologies de traitement automatique du langage sont profondément intégrées à notre vie quotidienne, et cette collection permet d'entrevoir leur direction d'évolution ainsi que leurs possibilités futures.

[GN⁺]

Avis sur Hacker News

• Il m’a fallu du temps pour comprendre cet article, car il s’appuie sur les techniques du papier « Deja Vu » et traite de méthodes complexes exploitant la sparsité :

  • Le papier « Deja Vu » observe que les modèles à faible sparsité des poids présentent une forte « sparsité contextuelle ». Autrement dit, les multiplications de matrices produisent, selon l’entrée, des vecteurs contenant beaucoup de zéros à des positions différentes.
  • Le papier souligne qu’il est possible d’exploiter cette sparsité pour éviter de charger certaines lignes de la matrice.
  • Mais pour obtenir un bon gain de performances, il faut pouvoir prédire à l’avance quelles lignes seront ignorées. Cela est possible avec une matrice de faible dimension.
  • L’article d’Apple suggère que cette découverte améliore non seulement les performances de chargement depuis la RAM, mais permet aussi le chargement depuis la mémoire flash sans sacrifier la bande passante :
    • Il faut noter que les matrices d’attention sont légères, et que l’important est de charger de manière sparse le réseau feedforward (FFN).
    • Le papier indique qu’en prédisant la sortie des couches ReLU, on peut obtenir une sparsité bien meilleure qu’en prédisant l’entrée du FFN. Autrement dit, « si l’on peut prédire qu’après le matmul, ce slot de vecteur aura une valeur négative avant ReLU, alors on peut ne pas charger cette colonne de matrice et produire 0 ».
    • Le papier suggère qu’il n’est pas nécessaire de charger la plupart des lignes du FFN, et qu’on peut maintenir pour chaque FFN un cache des lignes récemment utilisées, mis à jour depuis la mémoire flash selon les besoins.
  • Le papier parle aussi du chargement par chunks et de la corrélation entre couches de projection, mais l’intuition principale se trouve dans les points ci-dessus.

• J’espérais trouver dans la conclusion du papier une section expliquant comment cette fonctionnalité serait exposée à l’utilisateur, mais cette discussion est peut-être hors du périmètre.

  • Je me demande si ce type de fonctionnalité sera proposé à l’utilisateur via des appels d’API et des réglages de CoreML, par exemple avec un flag use_flash, ou s’il s’agira d’une optimisation runtime transparente. J’aimerais savoir s’il existe de bonnes conférences ou présentations où Apple parle de la feuille de route de développement de CoreML, Metal, etc.

• Je me demande quelle part du modèle peut ne pas être chargée avant qu’on commence à voir une vraie différence de performances.

  • Par exemple, si l’on veut conserver 90 % des performances de la RAM, est-ce qu’on peut se contenter de la moitié de la mémoire, ou faut-il plutôt 90 % ou 95 % ?
  • Je me demande à quelle vitesse les performances chutent par rapport au maximum lorsqu’on réduit la RAM. Le graphique compare l’algorithme de base lorsqu’on utilise moins de RAM, mais cela répond à une autre question (même si c’est une bonne question !).
  • S’il est possible d’obtenir de bonnes performances sans charger l’intégralité d’un modèle de 8 Go dans la mémoire d’un téléphone, ce serait clairement très utile.

• Il est intéressant de noter que les appareils Apple ont très peu de RAM par rapport aux appareils équivalents de la concurrence.

  • Cela s’explique aussi par le fait que les équipes logicielles d’Apple utilisent des langages plus efficaces comme Objective-C, et parce que les applications iOS ne ciblent pas une grande variété de résolutions d’écran, ce qui évite plus souvent de charger des textures haute résolution avant de les redimensionner.
  • De plus, même en achetant de la RAM à l’échelle d’Apple, son prix ne baisse pas énormément ; augmenter la RAM affecte donc davantage la marge que l’ajout d’autres fonctionnalités.
  • Mais tout cela devient un problème quand on utilise des grands modèles de langage (LLM), car ils consomment intrinsèquement beaucoup de RAM. Et toute technique d’économie mémoire peut aussi être utilisée par un concurrent disposant de plus de RAM pour déployer un modèle plus grand et meilleur.

• Ma compréhension du sujet est limitée, mais je me demande si cette technique permettrait d’exécuter un LLM en mode hors ligne sur un téléphone mobile.

  • Si oui, cela pourrait ouvrir la voie à de nombreuses applications intéressantes, comme la modération de contenu assistée par IA sans envoyer de données sensibles vers l’extérieur.

• J’apprécie que les articles récents parlent de « LLM » plutôt que d’« IA ».

  • Cela permet de montrer qu’il s’agit d’une technologie précise, et non de simple battage marketing.

• Je suis un peu surpris que ce papier ne mentionne pas FlashAttention.

  • Comme les deux travaux exploitent la mémoire flash, il semble qu’il aurait au moins fallu le mentionner.

• Apple a racheté une entreprise iranienne ?

• Par exemple, le modèle OPT 6.7B présenterait 97 % de sparsité dans les couches FFN.

  • Je me demande si quelqu’un sait exactement ce que signifie cette métrique ici. Est-ce que cela veut dire que la couche contient 97 % de valeurs nulles, ou bien qu’on peut la compresser à 3 % de sa taille ?

• J’espère que cette technique sera intégrée à llama.cpp et candle.

  • Ces avancées sont vraiment impressionnantes, et j’espère qu’elles finiront par être appliquées à ces bibliothèques aussi.