paint-brush
ChipNeMo : LLM adaptés au domaine pour la conception de puces : annexepar@textmodels

ChipNeMo : LLM adaptés au domaine pour la conception de puces : annexe

Trop long; Pour lire

Les chercheurs présentent ChipNeMo, qui utilise l'adaptation de domaine pour améliorer les LLM pour la conception de puces, permettant ainsi de réduire la taille du modèle jusqu'à 5 fois avec de meilleures performances.
featured image - ChipNeMo : LLM adaptés au domaine pour la conception de puces : annexe
Writings, Papers and Blogs on Text Models HackerNoon profile picture
0-item

Auteurs:

(1) Mingjie Liu, NVIDIA {Contribution égale} ;

(2) Teodor-Dumitru Ene, NVIDIA {Contribution égale} ;

(3) Robert Kirby, NVIDIA {Contribution égale} ;

(4) Chris Cheng, NVIDIA {Contribution égale} ;

(5) Nathaniel Pinckney, NVIDIA {Contribution égale} ;

(6) Rongjian Liang, NVIDIA {Contribution égale} ;

(7) Jonah Alben, NVIDIA ;

(8) Himyanshu Anand, NVIDIA ;

(9) Sanmitra Banerjee, NVIDIA ;

(10) Ismet Bayraktaroglu, NVIDIA ;

(11) Bonita Bhaskaran, NVIDIA ;

(12) Bryan Catanzaro, NVIDIA ;

(13) Arjun Chaudhuri, NVIDIA ;

(14) Sharon Clay, NVIDIA ;

(15) Bill Dally, NVIDIA ;

(16) Laura Dang, NVIDIA ;

(17) Parikshit Deshpande, NVIDIA ;

(18) Siddhanth Dhodhi, NVIDIA ;

(19) Sameer Halepete, NVIDIA ;

(20) Eric Hill, NVIDIA ;

(21) Jiashang Hu, NVIDIA ;

(22) Sumit Jain, NVIDIA ;

(23) Brucek Khailany, NVIDIA ;

(24) George Kokai, NVIDIA ;

(25) Kishor Kunal, NVIDIA ;

(26) Xiaowei Li, NVIDIA ;

(27) Charley Lind, NVIDIA ;

(28) Hao Liu, NVIDIA ;

(29) Stuart Oberman, NVIDIA ;

(30) Sujeet Omar, NVIDIA ;

(31) Sreedhar Pratty, NVIDIA ;

(23) Jonathan Raiman, NVIDIA ;

(33) Ambar Sarkar, NVIDIA ;

(34) Zhengjiang Shao, NVIDIA ;

(35) Hanfei Sun, NVIDIA ;

(36) Pratik P. Suthar, NVIDIA ;

(37) Varun Tej, NVIDIA ;

(38) Walker Turner, NVIDIA ;

(39) Kaizhe Xu, NVIDIA ;

(40) Haoxing Ren, NVIDIA.

Tableau des liens

ANNEXE

A. Processus de collecte de données

La collection a été implémentée avec un ensemble de scripts Shell et Python, conçus pour identifier les données de conception et la documentation pertinentes, les convertir en texte brut le cas échéant, les filtrer à l'aide de mesures de qualité de base, calculer une somme de contrôle pour une déduplication précise des fichiers et les compresser pour le stockage. Le flux de collecte n'a pas utilisé de scripts de scraping et de collecte spécifiques au LLM, car nous visions à minimiser les besoins en espace grâce à la collecte de données in situ de sources de données internes (à la fois les systèmes de fichiers en réseau et les applications Web internes). Pour la collecte basée sur le système de fichiers, les données étaient conservées en place tout en étant filtrées pour en vérifier la qualité, au lieu de stocker des ensembles supplémentaires de données brutes localement.


La collecte de données de conception et de vérification comprenait une variété de fichiers sources, notamment Verilog et VHDL (RTL et netlists), C++, Spice, Tcl, divers langages de script et des fichiers de configuration liés à la construction. Les données des services Web internes ont été collectées via des appels d'API REST et une exploration conventionnelle, le formatage HTML étant supprimé à l'aide de la bibliothèque Python open source BeautifulSoup [52] dans les deux cas afin de minimiser la suppression par inadvertance d'exemples de codage, au prix de l'introduction de davantage de chaudières. barres de navigation de plaque et autres éléments de page HTML. Notre flux de collecte de données prenait en charge les formats de documentation conventionnels, notamment .docx, .pptx et .pdf, à l'aide de bibliothèques de conversion Python et d'outils open source facilement disponibles.


Comme la plupart des données internes sont considérées comme étant de haute qualité, un filtrage minimal a été appliqué : un filtrage par nombre de lignes a été utilisé pour garantir que les fichiers extrêmement grands ou petits étaient exclus, et les fichiers ont été triés en grandes catégories (écrites manuellement ou générées par un outil).

B. Pré-entraînement adaptatif de domaine (DAPT)

Dans cette section, nous présentons des résultats détaillés sur nos modèles pré-entraînés adaptatifs de domaine. Nous détaillons également nos expériences d'ablation sur le pré-entraînement adaptatif de domaine.


Hyperparamètres DAPT : détails présentés dans le tableau VI.


TABLEAU VI : Hyperparamètres DAPT et SFT, valeurs SFT indiquées entre parenthèses (si différentes de DAPT).


Résultats de l'évaluation automatique : Nous présentons les résultats détaillés des critères d'évaluation automatique dans les tableaux VII et VIII. Par souci de simplicité, dans le reste de la section, nous présentons les résultats de référence agrégés pour les études d'ablation :


Puce : nous rapportons les résultats moyens sur les tests de conception, de script, de bogues et de circuits dans le domaine à partir du tableau III (5 plans).


• MMLU : Nous rapportons les résultats globaux sur MMLU (5-shot) [22], une référence agrégée populaire sur une grande variété de sujets.


Raisonnement : Nous rapportons des résultats moyens sur des benchmarks publics populaires sur le raisonnement de bon sens (0-shot), notamment Winogrande [53], hellaswag [54], ARC-easy [55] et RACE-High [56].


Code : Nous rapportons le taux de réussite moyen des tests de codage avec décodage gourmand, notamment HumanEval [23], VerilogEval-Machine [12] et VerilogEval-Human [12].


Augmentation du tokenizer : nous avons expérimenté DAPT en utilisant le tokenizer LLaMA2 original et le tokenizer augmenté comme décrit dans la section III-A. La figure 11 représente la perte de formation lissée pour ChipNeMo avec le tokenizer d'origine non modifié. Par rapport à la figure 2, nous observons qu'un tokeniseur augmenté présente une perte de formation plus importante lors de l'initialisation, en raison du fait que les jetons ajoutés n'ont jamais été observés lors du pré-entraînement du modèle de base. Une perte de formation similaire est obtenue pour DAPT avec 1 époque.


Le tableau IX présente les résultats agrégés des références d’évaluation automatique. Nous notons qu'une augmentation minutieuse du tokenizer et une initialisation du poids n'ont que légèrement d'impact sur les performances du modèle sur les références académiques générales. DAPT a considérablement amélioré les références de domaine avec n'importe quel tokenizer, y compris le codage Verilog (pas de différence majeure dans HumanEval). Nous concluons que l'augmentation du tokenizer présente l'avantage d'une amélioration de l'efficacité du tokenizer et de la formation sans dégradation des capacités générales du langage et du domaine du modèle.


Mélange d'ensembles de données publics : comme introduit dans la section II-A, nous avons inclus des données publiques dans DAPT, échantillonnées à partir d'ensembles de données publics couramment utilisés pour la pré-formation du modèle de base. Nous espérions principalement que le mélange de données publiques telles que Wikipédia dans DAPT pourrait aider à « corriger » les perturbations provoquées par l'augmentation du tokenizer et améliorer les capacités générales du langage naturel.


Fig. 11 : Perte d'entraînement lissée avec le tokenizer LLaMA2 original.


Fig. 12 : Perte d'entraînement lissée avec un taux d'apprentissage plus élevé. Nous incluons les courbes de perte des hyperparamètres suggérés à des fins de comparaison.


de modèles. Nous avons effectué une autre série de DAPT avec augmentation du tokenizer en utilisant uniquement les données du domaine, entraînant le même nombre d'étapes équivalant à environ 1,1 époque des données. Nous avons constaté que la combinaison de données publiques améliore légèrement les résultats. Nous présentons les résultats détaillés dans le tableau X.



La figure 12 montre la perte de formation pour ChipNeMo-7B avec des tokenizers augmentés, y compris le mix-in d'ensembles de données publics. Nous avons observé d'importants pics de perte d'entraînement lors des étapes d'entraînement initiales, la perte d'entraînement finale pour les modèles 7B étant même meilleure que celle des hyperparamètres DAPT d'origine 13B. Cependant, nous notons une dégradation substantielle dans les tests de référence en langage naturel, comme le montre le tableau XII, y compris la conception des puces dans le domaine. Les capacités de codage se sont améliorées conformément aux résultats de [32].


Nous soulignons que notre cas diffère de celui de [32]. Bien que nous effectuions également un « pré-entraînement continu » à partir de points de contrôle pré-entraînés, nous souhaitons de préférence que le modèle maintienne des degrés élevés de performance sur les capacités générales, tout en


TABLEAU VII : Résultats de l'évaluation automatique. Nous rapportons les résultats de référence académiques pour LLaMA2 en utilisant des méthodes d'évaluation exclusives. Modèles ChipNeMo entraînés avec l'augmentation du tokenizer.


TABLEAU VIII : Codage des résultats de l’évaluation. Affichage du taux de réussite avec décodage gourmand. Nous rapportons les résultats pour LLaMA2 en utilisant des méthodes d'évaluation exclusives. Modèles ChipNeMo entraînés avec l'augmentation du tokenizer.


TABLEAU IX : Résultats d'évaluation sur les modèles ChipNeMo avec différents tokenizers. Août indique un tokenizer augmenté et Ori. indiquez en utilisant le tokenizer original LLaMA2. L'utilisation d'un tokenizer augmenté sans DAPT correspond à l'initialisation du modèle comme dans la section III-A.


distiller les informations et les connaissances des ensembles de données de domaine (invisibles lors de la pré-formation du modèle) en poids du modèle. En revanche, [32] utilisent des données de code accessibles au public qui manquent principalement d'éléments de langage naturel, mettant l'accent sur leur objectif principal sur les tâches liées au codage. Nous émettons l'hypothèse qu'un taux d'apprentissage plus faible a joué un double rôle pour l'adaptation du domaine, facilitant la distillation des connaissances du domaine via DAPT tout en maintenant un équilibre qui ne s'éloigne pas trop du modèle de base, préservant ainsi les capacités générales du langage naturel tout en améliorant considérablement les performances dans -tâches de domaine


Réglage fin efficace des paramètres (PEFT) : le réglage fin efficace des paramètres gèle les poids du modèle pré-entraîné et injecte des paramètres pouvant être entraînés dans des modèles d'adaptateur plus petits pour un réglage fin efficace des tâches en aval. Nous explorons l'utilisation du PEFT dans le DAPT en utilisant l'adaptation de bas rang (LoRA) [16]. Étant donné que notre implémentation de couche de transformateur fusionne KQV en une seule projection, nous ajoutons des adaptateurs LoRA pour une seule projection de bas rang pour chaque couche d'auto-attention de manière combinée. Nous expérimentons sur les modèles LLaMA2-13B avec le tokenizer LLaMA2 d'origine, en utilisant les mêmes configurations de formation DAPT dans le tableau VI. Nous avons mené deux expériences, introduisant des paramètres supplémentaires entraînables de 26,4 millions (petits) et 211,2 millions (grands) respectivement.


La figure 13 montre les courbes de perte d'entraînement des modèles LoRA et les compare à l'entraînement complet des paramètres. Pour les deux modèles LoRA, la perte converge rapidement et cesse de diminuer au-delà d’un certain point. Le tableau XIII présente les résultats de l'évaluation des modèles LoRA. Les deux modèles LoRA sont nettement sous-performants en matière de formation complète des paramètres sur les tâches de conception de puces dans le domaine. Les modèles LoRA s'améliorent dans les tâches de conception de puces par rapport à leurs homologues non DAPT, le modèle plus grand présentant des résultats légèrement meilleurs (mais non significatifs).


TABLEAU X : Ablation sur un mélange d'ensembles de données publics avec ChipNeMo-13B. La mixité des données publiques améliore légèrement les résultats.


TABLEAU XI : Hyperparamètres de formation avec un taux d'apprentissage plus élevé. Nous adoptons un paramètre similaire à celui de [32].

C. Formation sur le modèle de récupération

La génération manuelle d'échantillons de formation demande beaucoup d'efforts, nous avons donc choisi de mettre en œuvre un processus pour les générer automatiquement. Puisque nous utilisons l'apprentissage contrastif pour affiner notre modèle, chaque échantillon nécessite un ensemble de passages positifs et de passages négatifs, en particulier des négatifs durs, pour maximiser la précision.


1) Procédure d'échantillonnage de l'ensemble de données : La figure 14 décrit les étapes suivies pour générer un échantillon :


• Étape 1 : Sélectionner aléatoirement un passage du corpus documentaire


• Étape 2 : Utiliser un modèle de langage (Vicuna) pour générer une requête valide à partir du passage.


• Étape 3 : Utiliser un modèle de récupération préexistant (transformateur de phrase) pour récupérer les N premiers passages du corpus de documents pour la requête, où chaque passage est un potentiel dur-négatif.


• Étape 4 : Il est possible que certains des passages récupérés soient en réalité positifs. Utilisez donc le même modèle de langage pour filtrer les passages positifs.


• Étape 5 : S'il n'y a pas suffisamment de passages négatifs après ce processus de filtrage, complétez avec des passages aléatoires du corpus.


TABLEAU XII : Ablation sur le taux d'apprentissage avec ChipNeMo-7B. Un taux d’apprentissage plus élevé dégrade considérablement les performances sur toutes les tâches liées à la langue mais améliore légèrement le codage.


Fig. 13 : Perte d'entraînement lissée de LoRA [16]. 13B correspond au paramètre complet DAPT.


Pour notre recherche initiale, nous avons utilisé Vicuna [4] et Sentence Transformer [33] ; cependant, ils peuvent facilement être remplacés respectivement par LLaMA2 [5] et BM25 [42] pour produire un modèle de récupération commercialement viable.


2) Comparaison de la qualité des hits : tous les hits ne sont pas créés égaux. Le passage de l'exemple Spec ci-dessous répond clairement et complètement à sa requête. Le passage de l'exemple Build contient la réponse ; cependant, plus de contexte est nécessaire pour répondre à la requête.


Exemple de spécification : le passage frappé répond clairement à la requête.



Exemple de construction : des informations supplémentaires sont requises pour répondre pleinement à la requête. Par exemple : Qu’est-ce qu’un DL ? Comment savons-nous qu'Arch-Build-Hotseat-XXX est un DL ?


TABLEAU XIII : Résultats de l'évaluation sur les modèles LoRA. La première colonne indique le nombre de paramètres pouvant être entraînés. Aucun n'indique le modèle LLaMA2-13B sans DAPT. 13B indique un entraînement complet des paramètres.


Fig. 14 : Génération d'échantillons pour la formation du modèle de récupération



D. Données d'évaluation supplémentaires


Le tableau XIV présente les données d'évaluation pour tous les modèles sur l'application chatbot d'assistant d'ingénierie.


Le tableau XV montre nos résultats d'évaluation pour tous les modèles sur la tâche de génération de script EDA.


Le tableau XVI montre nos résultats d'évaluation pour tous les modèles sur la tâche de résumé et d'analyse des bogues.


TABLEAU XIV : Évaluation humaine du chatbot de l'assistant d'ingénierie


TABLEAU XV : Évaluation de la génération de script EDA. Binaire noté pour l'évaluation automatique et 0 à 100 % pour l'évaluation humaine.


TABLEAU XVI : Résumé des bogues et évaluation de l'analyse. Échelle de Likert 1-7.

E. Exemples

1) Chatbot assistant d'ingénierie :





2) Génération de script EDA : certains noms de fonctions et commandes sont obscurcis.




3) Résumé et analyse des bogues : les noms d'utilisateur, les noms de puces et les chemins sont obscurcis.



Cet article est disponible sur arxiv sous licence CC 4.0.