Comment LLaMA.cpp est-il possible ?

• Grâce à LLaMA.cpp, qui réécrit en pur C++ le code d’inférence de LLaMA, il peut fonctionner sur divers matériels comme le Pixel 5, le MacBook Pro M2 ou le Raspberry Pi
• Les grands modèles nécessitent généralement des GPU coûteux, alors comment cela est-il possible ?
• Les GPU sont avantageux pour le deep learning grâce à leur grande bande passante mémoire et leur puissance de calcul, mais la bande passante mémoire devient souvent le goulot d’étranglement de l’inférence
  • En effet, pour effectuer les calculs, les données doivent être transférées de la mémoire HBM (RAM) vers la mémoire on-chip
• La quantization (quantification) est importante pour l’utilisation de la RAM par les poids de LLaMA
  • Réduire la précision permet de diminuer drastiquement la quantité de mémoire nécessaire pour stocker le modèle
  • Grâce à la quantification, on réduit la mémoire nécessaire pour stocker le modèle, ce qui permet de le faire tenir dans la mémoire des GPU standard de datacenter et des GPU grand public haut de gamme
• La bande passante mémoire est le facteur limitant pour presque toutes les opérations liées à l’échantillonnage des transformers
• En réduisant les besoins mémoire avec des méthodes comme la quantification, le serving devient beaucoup plus facile
• C’est aussi une autre raison de faire de la distillation ou d’« entraîner plus longtemps des modèles plus petits »

[breezymind]

J’ai testé les embeddings en chargeant llama2 avec LlamaCpp sur une machine locale.

https://breezymind.com/llamacpp-embedding

[xguru]

Le premier commentaire sur HN est utile.

« Pour ceux que ça intéresse, quantifier un modèle a un coût.
https://oobabooga.github.io/blog/posts/perplexities/

En gros, la précision baisse légèrement, des réponses étranges peuvent apparaître, et la probabilité d’obtenir des résultats inattendus ou des hallucinations augmente. Mais plus il y a de paramètres, plus la perte de qualité diminue. Donc, quand la taille du modèle est très grande, la différence devient négligeable. Et cela ne concerne que le coût de l’inférence. L’entraînement est un tout autre sujet et demande bien plus de puissance.

Malgré cela, on voit des performances de niveau GPT3 sur un seul rack de serveurs. C’est une avancée remarquable quand on pense qu’il y a tout juste un an, ce type d’IA relevait littéralement de la magie et ne pouvait tourner que dans de grands datacenters. La bande passante et la capacité mémoire sont probablement, dans mon esprit de profane, plus faciles à augmenter que la puissance de calcul brute, donc on aura peut-être bientôt de vrais appareils “intelligents”. »

[GN⁺]

Avis Hacker News

• Un article sur le coût de la quantification des modèles, la perte de précision qu’elle entraîne et la possibilité de réponses anormales. Cependant, plus un modèle a de paramètres, moins cette perte devient importante.
• Un article soulignant les excellentes performances de GPT3, désormais exécutable sur une seule baie de serveurs, ce qui représente une nette amélioration par rapport aux IA de l’an dernier qui nécessitaient de vastes centres de données.
• Un texte qui fait remarquer que la génération de tokens est sérielle et limitée par la bande passante, alors que l’insertion du prompt ne l’est pas et peut s’exécuter avec des batchs de 512 ou plus.
• Llama.cpp dispose désormais d’une quantification à environ 4 bits qui n’affecte pas beaucoup la complexité. Q6_K a une complexité presque identique à FP16, tout en étant bien plus compact.
• La véritable magie de Llama.cpp réside dans le découpage du modèle, qui permet à de petits GPU discrets de prendre complètement en charge l’insertion du prompt ainsi qu’une partie de l’inférence du modèle. C’est quelque chose d’unique dans le domaine de l’IA générative.
• Les backends GPU (OpenCL, Metal, CUDA, bientôt ROCm et Vulkan) sont la méthode privilégiée pour exécuter Llama.cpp. Sans eux, il serait impossible de faire tourner 70B sur un desktop, ou 33B sur un laptop doté de 16 Go de RAM.
• Le projet est salué pour sa facilité d’extension avec Go, Python et d’autres runtimes. Des outils ont été créés à partir de cela pour charger et exécuter plusieurs modèles en Go, puis les exposer via une API REST.
• Exécuter l’inférence sur un CPU moderne avec AVX2 est plus lent que sur GPU, mais offre l’avantage de pouvoir disposer d’une seule longue zone RAM contiguë. En revanche, le fait de devoir quantifier en 4 bits et de ne pas avoir d’option pour exécuter l’inférence en autre chose que fp32 sur les CPU x86_64 constitue un inconvénient majeur.
• L’article mentionne une reproduction réussie d’un dataset 13B sur un seul Pi4 8gig, ainsi que d’un dataset 65B sur trois nœuds pi4, ce qui montre l’accessibilité de cette technique.
• L’article est critiqué pour son manque de rigueur dans l’usage des unités lorsqu’il évoque les chiffres de latence.
• L’article soulève la question de savoir pourquoi les fabricants de puces intègrent autant d’unités fonctionnelles dans les puces alors que la plupart des charges de travail sont limitées par la mémoire.
• L’article est salué pour son contenu original, qu’on trouve rarement ailleurs qu’en dehors de Hacker News.
• Le texte discute des limites de la génération de tokens contrainte par la mémoire dans les décodeurs Transformer, et exprime l’espoir de voir émerger à l’avenir des modèles plus adaptés au matériel.
• L’article s’interroge sur les raisons pour lesquelles le matériel spécialisé a été conçu de cette façon, compte tenu des goulots d’étranglement cruciaux liés à la bande passante mémoire, et sur la possibilité qu’un changement de paradigme logiciel puisse modifier cet équilibre.