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   Résumé et introduction   Base de données   Méthodes d'adaptation de domaine ChipNemo   Candidatures LLM   Évaluations   Discussion   Travaux connexes   Conclusions   Remerciements, contributions et références   annexe  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.    détails présentés dans le tableau VI.  Hyperparamètres DAPT :    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 : Résultats de l'évaluation automatique :  •   : 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). Puce    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. • MMLU :  •   : 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]. Raisonnement  •   : 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]. Code    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. Augmentation du tokenizer :  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.    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.  Mélange d'ensembles de données publics :  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   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 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. Réglage fin efficace des paramètres (PEFT) : le  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).    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.    La figure 14 décrit les étapes suivies pour générer un échantillon : 1) Procédure d'échantillonnage de l'ensemble de données :  • É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.   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.    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. 2) Comparaison de la qualité des hits :    le passage frappé répond clairement à la requête.  Exemple de spécification :    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 ?  Exemple de construction :   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.    E. Exemples     1) Chatbot assistant d'ingénierie :    certains noms de fonctions et commandes sont obscurcis.  2) Génération de script EDA :    les noms d'utilisateur, les noms de puces et les chemins sont obscurcis.  3) Résumé et analyse des bogues :  Cet article est   sous licence CC 4.0. disponible sur arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

AI Models on HackerNoon

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Boost your HackerNoon story @ $159.99! 🚀

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

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps