La technologie de compression innove encore en donnant la possibilité aux grands modèles de s'intégrer dans les téléphones portables

Source de l'image : générée par Unbounded AI

Les grands modèles de langage (LLM), en particulier les modèles génératifs de transformateurs pré-entraînés (GPT), ont montré d'excellentes performances sur de nombreuses tâches linguistiques complexes. Cette avancée a conduit à la volonté d’exécuter ces LLM de manière native sur les appareils mobiles afin de protéger la confidentialité des utilisateurs. Cependant, même les petits LLM sont trop volumineux pour être exécutés sur ces appareils.

Par exemple, le petit LLaMA a des paramètres 7B et sa version FP16 mesure 14 Go, alors que les appareils mobiles ne disposent que de 18 Go de DRAM. Par conséquent, la compression du LLM via l’optimisation du temps de formation (telle que la sparsification, la quantification ou le regroupement de poids) est une étape clé pour le déploiement du LLM sur l’appareil. Cependant, l’optimisation du temps de formation du LLM est très coûteuse en raison de la taille du modèle et de la surcharge des ressources de calcul. DKM, l'un des algorithmes SOTA pour le regroupement de poids, nécessite un temps de formation excessif pour le regroupement de poids variables en raison de la nécessité d'analyser l'interaction entre tous les poids et toutes les options de regroupement possibles.

Par conséquent, de nombreuses techniques de compression LLM existantes, telles que GTPQ et AWQ, reposent sur l'optimisation post-formation. Dans cet article, les chercheurs proposent des techniques d'optimisation de la mémoire pour réaliser un clustering pondéré en fonction du temps de formation et son application dans DKM, également connu sous le nom d'eDKM.

Les techniques utilisées dans cet article incluent l'orchestration de tenseurs multi-appareils, l'unicité et le partitionnement de matrice de poids. En utilisant eDKM pour affiner le modèle LLaMA 7B et le compresser à 3 bits par facteur de poids, les chercheurs ont obtenu une réduction d'environ 130 fois de l'empreinte mémoire de la pile de décodeur, ce qui est meilleur que la technologie de compression 3 bits existante.

Améliorer l'efficacité de la mémoire de DKM

Comme le montre la figure 1, l'élagage, la quantification et la normalisation sont toutes des techniques d'optimisation du poids populaires. Ces méthodes optimisent le poids d'origine W et obtiennent le poids

, pour optimiser la latence, la précision ou la taille du modèle d'inférence. Parmi ces technologies, les chercheurs de cet article se concentrent principalement sur le clustering pondéré, notamment l’algorithme de clustering pondéré DKM.

Le regroupement de poids est une discrétisation de poids non linéaire dans laquelle la matrice de poids est compressée en une table de recherche et une liste d'index de faible précision de la table de recherche qui peuvent être traités par des accélérateurs d'inférence modernes. DKM effectue un regroupement de poids différentiable en analysant l'interaction entre les poids (notés W) et les points centraux (notés C), et fait un compromis entre le taux de compression et la précision.

Par conséquent, l’utilisation de DKM pour la compression LLM produit des résultats de haute qualité. Cependant, la carte d'attention générée pendant le processus de calcul DKM est volumineuse et la complexité de la mémoire de la passe avant/arrière est O (|W||C|) (c'est-à-dire la matrice de la figure 1), ce qui est particulièrement difficile pour LLM. compression. . Par exemple, un modèle LLaMA 7B qui calcule uniquement les cartes d'attention pour le clustering de poids sur 4 bits nécessite au moins 224 Go de mémoire.

*Figure 1 : Aperçu du système d'optimisation du poids. Dans DKM, le système crée en interne une carte d'attention qui peut être regroupée par poids différenciables. *

Par conséquent, les chercheurs doivent utiliser la mémoire du processeur pour gérer des besoins de mémoire aussi importants, c'est-à-dire stocker d'abord les informations dans la mémoire du processeur, puis les recopier sur le GPU si nécessaire. Cependant, cela générera beaucoup de trafic entre le GPU et le CPU (ralentissant ainsi l’entraînement) et nécessitera une énorme capacité de mémoire CPU. Cela signifie qu'il est essentiel de réduire le nombre de transactions entre le CPU et le GPU et de minimiser le trafic par transaction. Afin de résoudre ces problèmes, les chercheurs ont introduit deux nouvelles technologies d'optimisation de la mémoire dans PyTorch.

  • Orchestration des tenseurs sur plusieurs appareils : suivez les tenseurs copiés sur tous les appareils pour éviter les copies redondantes, réduisant ainsi l'utilisation de la mémoire et accélérant la formation.
  • Unicité du poids et traitement de partitionnement : profitez du fait que le poids 16 bits n'a que 216 valeurs uniques pour réduire la représentation de la carte d'attention (illustré dans la figure 1) et la diviser davantage en plusieurs modèles d'apprentissage.

Orchestration tensorielle multi-appareils

PyTorch utilise un magasin de données pour représenter les tenseurs, qui est lié à la disposition réelle des données et aux métadonnées, qui sont utilisées pour enregistrer la forme, le type, etc. du tenseur. Cette architecture tensorielle permet à PyTorch de réutiliser autant que possible le stockage de données et de réduire efficacement l'utilisation de la mémoire. Cependant, lorsqu'un tenseur est déplacé vers un autre appareil (par exemple du GPU au CPU), le stockage de données ne peut pas être réutilisé et un nouveau tenseur doit être créé.

Le tableau 1 illustre l'utilisation de la mémoire des tenseurs lors du déplacement entre des appareils PyTorch. Le tenseur x0 alloué à la ligne 0 consomme 4 Mo sur le GPU. Lorsque sa vue change à la ligne 1, aucune mémoire GPU supplémentaire n'est requise puisque le magasin de données sous-jacent peut être réutilisé (c'est-à-dire que x0 et x1 sont en réalité identiques). Cependant, lorsque x0 et x1 sont déplacés vers le CPU comme dans les lignes 2 et 3, bien que y0 et y1 puissent partager le même stockage de données sur le CPU, la consommation de mémoire du CPU devient 8 Mo, ce qui entraîne une redondance de la mémoire du CPU et augmente le GPU. trafic vers le CPU.

*Tableau 1 : Le réglage fin du LLM peut nécessiter l'utilisation de la mémoire du processeur pour décharger l'empreinte mémoire du GPU. Le manque de gestion des tenseurs entre appareils peut conduire à des copies redondantes entre appareils (en particulier lorsque le graphe de calcul est complexe), ce qui est particulièrement préjudiciable à l'optimisation du temps de formation LLM. Par exemple, bien que x0 et x1 soient le même tenseur avec des vues différentes, les tenseurs résultants y0 et y1 ne partagent pas le stockage de données lorsqu'ils sont copiés sur le CPU, alors que sur le GPU, x0 et x1 le font. *

Pour remédier à cette inefficacité, les chercheurs ont placé une couche d'orchestration dans la figure 2(b), où le noir représente le stockage réel des données et les métadonnées, et le gris représente uniquement les métadonnées. La figure 2 (a) montre l'exemple du tableau 1, où x1 partage la disposition des données avec x0, mais y0 et y1 ont un stockage de données en double sur le processeur. Comme le montre la figure 2 (b), en insérant une couche d'orchestration, les chercheurs évitent cette redondance et réduisent le trafic GPU vers CPU. Les chercheurs ont utilisé le save-tensor-hook de PyTorch pour implémenter un tel schéma d'échange, vérifiant si le même magasin de données a été copié.

Cependant, utiliser un tel schéma pour vérifier si le même tenseur existe sur le périphérique cible coûte cher. Dans l'exemple de la figure 2(b), le chercheur n'a pas copié x1 sur le CPU, mais a simplement renvoyé une référence à y0 et l'opération de visualisation entre x1 et y0.

*Figure 2 : Lorsque l'orchestration tensorielle multi-appareils est appliquée à la situation du tableau 1, la duplication côté processeur peut être évitée, économisant ainsi de la mémoire et du trafic. *

La navigation dans le graphique de calcul ajoute des cycles de calcul supplémentaires, et la sauvegarde de copies inutiles peut compenser cette surcharge. Les chercheurs ont découvert qu’une recherche en 4 sauts était suffisante pour détecter tous les cas éligibles dans le graphique informatique de la mise en œuvre originale du DKM.

Unicité du poids et partitionnement

Dans la plupart des formations LLM, les pondérations utilisent généralement un stockage sur 16 bits (comme BF16 ou FP16), ce qui signifie que bien qu'il existe des milliards de paramètres dans LLM, il n'y a que 216 coefficients uniques en raison de la largeur des bits. Cela offre la possibilité de compresser considérablement la carte d’attention entre les poids et les points centraux, comme le montre la figure 3.

Figure 3 : Unicité du poids et partitionnement

Résultats expérimentaux

Précision LLM

Cet article compare eDKM à d'autres schémas de compression basés sur la quantification, notamment : RTN, SmoothQuant, GPTQ, AWQ et LLM-QAT. Pour eDKM, les chercheurs ont également effectué une compression 8 bits sur la couche d’intégration. Finalement, les conclusions suivantes ont été tirées :

  • eDKM permet au modèle LLaMA 7B compressé 3 bits de surpasser tous les autres schémas de compression 3 bits.
  • eDKM a la meilleure précision sur le benchmark ARC-e dans les configurations 3 bits et 4 bits.
  • Les performances d'eDKM sont très compétitives sur les benchmarks PIQA et MMLU utilisant un modèle de compression 4 bits.

Expérience d'ablation

Dans des expériences d'ablation, les chercheurs ont mesuré le compromis entre l'empreinte mémoire et la vitesse avant-arrière de la compression 3 bits en utilisant comme exemple une couche d'attention dans la pile de décodeur LLaMA 7B. L'orchestration tenseur multi-appareils à elle seule réduit l'empreinte mémoire de 2,9 fois avec très peu de temps d'exécution, tandis que les modules de partitionnement et d'unicité économisent respectivement 23,5 fois et 16,4 fois. Lorsque toutes les technologies sont combinées, l’eDKM permet de réaliser des économies d’environ 130 fois. Bien que ces étapes nécessitent une surcharge de calcul et de communication supplémentaire, la surcharge d'exécution est négligeable car le trafic entre le GPU et le CPU est considérablement réduit.

Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
  • Récompense
  • Commentaire
  • Partager
Commentaire
0/400
Aucun commentaire
  • Épingler
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)