Autoren:  (1) Mingjie Liu, NVIDIA {Gleicher Beitrag};  (2) Teodor-Dumitru Ene, NVIDIA {Gleicher Beitrag};  (3) Robert Kirby, NVIDIA {Gleicher Beitrag};  (4) Chris Cheng, NVIDIA {Gleicher Beitrag};  (5) Nathaniel Pinckney, NVIDIA {Gleicher Beitrag};  (6) Rongjian Liang, NVIDIA {Gleicher Beitrag};  (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.  Linktabelle   Zusammenfassung und Einleitung   Datensatz   ChipNemo-Domänenanpassungsmethoden   LLM-Bewerbungen   Bewertungen   Diskussion   Verwandte Arbeiten   Schlussfolgerungen   Danksagungen, Beiträge und Referenzen   Anhang  ANHANG   A. Datenerfassungsprozess  Die Sammlung wurde mit einer Reihe von Shell- und Python-Skripten implementiert, die darauf ausgelegt sind, relevante Designdaten und Dokumentationen zu identifizieren, sie gegebenenfalls in Klartext umzuwandeln, sie anhand grundlegender Qualitätsmetriken zu filtern, eine Prüfsumme für eine präzise Dateideduplizierung zu berechnen und sie für die Speicherung zu komprimieren. Der Sammlungsablauf verwendete keine handelsüblichen LLM-spezifischen Scraping- und Sammlungsskripte, da wir den Platzbedarf durch die Datensammlung vor Ort aus internen Datenquellen (sowohl vernetzte Dateisysteme als auch interne Webanwendungen) minimieren wollten. Bei der dateisystembasierten Sammlung wurden die Daten an Ort und Stelle gehalten und gleichzeitig auf Qualität gefiltert, anstatt zusätzliche Sätze von Rohdaten lokal zu speichern.  Die Datensammlung für Design und Verifizierung umfasste eine Vielzahl von Quelldateien, darunter Verilog und VHDL (RTL und Netzlisten), C++, Spice, Tcl, verschiedene Skriptsprachen und buildbezogene Konfigurationsdateien. Daten von internen Webdiensten wurden sowohl über REST-API-Aufrufe als auch über konventionelles Crawling gesammelt, wobei die HTML-Formatierung in beiden Fällen mithilfe der Open-Source-Python-Bibliothek BeautifulSoup [52] entfernt wurde, um das versehentliche Entfernen von Codebeispielen zu minimieren. Dies ging mit der Einführung weiterer vorgefertigter Navigationsleisten und anderer HTML-Seitenelemente einher. Unser Datensammlungsfluss unterstützte konventionelle Dokumentationsformate, darunter .docx, .pptx und .pdf, und verwendete leicht verfügbare Python-Konvertierungsbibliotheken und Open-Source-Tools.  Da die Qualität der meisten internen Daten als hoch eingeschätzt wird, wurde nur eine minimale Filterung vorgenommen: Durch die Zeilenanzahlfilterung wurde sichergestellt, dass extrem große oder kleine Dateien ausgeschlossen wurden, und die Dateien wurden in die groben Kategorien „manuell geschrieben“ und „toolgeneriert“ sortiert.   B. Domänenadaptives Vortraining (DAPT)  In diesem Abschnitt präsentieren wir detaillierte Ergebnisse unserer domänenadaptiven vortrainierten Modelle. Wir beschreiben auch unsere Ablationsexperimente zum domänenadaptiven Vortraining.    Einzelheiten sind in Tabelle VI dargestellt.  DAPT-Hyperparameter:    Detaillierte Ergebnisse zu Benchmarks der automatischen Bewertung präsentieren wir in Tabelle VII und Tabelle VIII. Der Einfachheit halber präsentieren wir im Rest des Abschnitts zusammengefasste Benchmark-Ergebnisse für Ablationsstudien: Ergebnisse der automatischen Bewertung:  •   : Wir berichten über Durchschnittsergebnisse bei den domäneninternen Design-, Scripting-, Bugs- und Schaltkreis-Benchmarks aus Tabelle III (5-Shot). Chip    Wir berichten über die Gesamtergebnisse zu MMLU (5-Schuss) [22], einem beliebten aggregierten Benchmark für eine breite Palette von Themen. • MMLU:  •   : Wir berichten über Durchschnittsergebnisse bei gängigen öffentlichen Benchmarks zum gesunden Menschenverstand (0-shot), darunter Winogrande [53], hellaswag [54], ARC-easy [55] und RACE-High [56]. Argumentation  •   : Wir berichten über die durchschnittliche Bestehensquote von Coding-Benchmarks mit Greedy-Decoding, einschließlich HumanEval [23], VerilogEval-Machine [12] und VerilogEval-Human [12]. Code    Wir haben mit DAPT experimentiert, indem wir den ursprünglichen LLaMA2-Tokenizer und den erweiterten Tokenizer verwendet haben, wie in Abschnitt III-A beschrieben. Abbildung 11 zeigt den geglätteten Trainingsverlust für ChipNeMo mit dem ursprünglichen, unveränderten Tokenizer. Im Vergleich mit Abbildung 2 stellen wir fest, dass ein erweiterter Tokenizer bei der Initialisierung einen größeren Trainingsverlust aufweist, da hinzugefügte Token während des Vortrainings des Basismodells nie beobachtet wurden. Ein ähnlicher Trainingsverlust wird für DAPT mit 1 Epoche erreicht. Erweiterung des Tokenizers:  Tabelle IX zeigt zusammengefasste Benchmark-Ergebnisse der automatischen Auswertung. Wir stellen fest, dass eine sorgfältige Erweiterung des Tokenizers und eine Initialisierung der Gewichte die Leistung des Modells bei allgemeinen akademischen Benchmarks nur geringfügig beeinträchtigen. DAPT verbesserte die Domänen-Benchmarks mit jedem Tokenizer, einschließlich Verilog-Codierung, erheblich (kein großer Unterschied bei HumanEval). Wir kommen zu dem Schluss, dass die Erweiterung des Tokenizers den Vorteil einer verbesserten Tokenizer- und Trainingseffizienz mit sich bringt, ohne dass die allgemeinen Sprach- und Domänenfähigkeiten der Modelle beeinträchtigt werden.    Wie in Abschnitt II-A vorgestellt, haben wir öffentliche Daten in DAPT aufgenommen, die aus häufig verwendeten öffentlichen Datensätzen für das Vortraining des Basismodells entnommen wurden. Wir hofften in erster Linie, dass die Einbindung öffentlicher Daten wie Wikipedia in DAPT dazu beitragen könnte, Störungen zu „korrigieren“, die durch die Tokenizer-Erweiterung verursacht werden, und die allgemeinen Fähigkeiten in natürlicher Sprache zu verbessern.  Einbindung öffentlicher Datensätze:  von Modellen. Wir haben eine weitere DAPT-Runde mit Tokenizer-Erweiterung durchgeführt, wobei wir nur die Domänendaten verwendet haben, wobei wir für die gleiche Anzahl von Schritten trainiert haben, was ungefähr 1,1 Epochen der Daten entspricht. Wir haben festgestellt, dass die Einmischung öffentlicher Daten die Ergebnisse leicht verbessert. Detaillierte Ergebnisse präsentieren wir in Tabelle X.   Abbildung 12 zeigt den Trainingsverlust für ChipNeMo-7B mit erweiterten Tokenisierern, einschließlich des Mix-In öffentlicher Datensätze. Wir beobachteten große Spitzen im Trainingsverlust bei den ersten Trainingsschritten, wobei der endgültige Trainingsverlust für 7B-Modelle sogar besser war als die ursprünglichen DAPT-Hyperparameter von 13B. Wir stellten jedoch eine erhebliche Verschlechterung bei Benchmarks für natürliche Sprachen fest, wie in Tabelle XII gezeigt, einschließlich des domäneninternen Chipdesigns. Die Codierungsfähigkeiten verbesserten sich im Einklang mit den Ergebnissen von [32].  Wir betonen, dass sich unser Fall von dem in [32] unterscheidet. Obwohl wir auch ein „fortgesetztes Vortraining“ durchführen, das von vorab trainierten Kontrollpunkten aus initialisiert wird, möchten wir, dass das Modell vorzugsweise ein hohes Maß an Leistungsfähigkeit bei allgemeinen Fähigkeiten beibehält, während   Destillation von Informationen und Wissen aus Domänendatensätzen (die beim Vortraining des Modells nicht sichtbar sind) in Modellgewichte. Im Gegensatz dazu verwenden [32] öffentlich verfügbare Codedaten, denen überwiegend natürliche Sprachelemente fehlen, was ihren Hauptfokus auf codierungsbezogene Aufgaben betont. Wir gehen davon aus, dass eine geringere Lernrate eine doppelte Rolle bei der Domänenanpassung spielte, indem sie die Destillation von Domänenwissen durch DAPT erleichterte und gleichzeitig ein Gleichgewicht aufrechterhielt, das nicht zu weit vom Basismodell abwich, wodurch allgemeine natürliche Sprachfähigkeiten erhalten blieben und die Leistung bei domäneninternen Aufgaben deutlich verbessert wurde    Parametereffizientes Feintuning friert die vorab trainierten Modellgewichte ein und fügt trainierbare Parameter in kleinere Adaptermodelle ein, um nachgelagerte Aufgaben effizient fein abzustimmen. Wir untersuchen die Verwendung von PEFT in DAPT unter Verwendung von Low-Rank Adaptation (LoRA) [16]. Da unsere Transformer-Layer-Implementierung KQV in eine einzige Projektion verschmilzt, fügen wir LoRA-Adapter für eine einzige Low-Rank-Projektion für jede Self-Attention-Schicht in kombinierter Weise hinzu. Wir experimentieren an LLaMA2-13B-Modellen mit dem ursprünglichen LLaMA2-Tokenizer und verwenden dieselben DAPT-Trainings-Setups wie in Tabelle VI. Wir haben zwei Experimente durchgeführt und zusätzliche trainierbare Parameter von 26,4 Millionen (klein) bzw. 211,2 Millionen (groß) eingeführt. Parametereffizientes Feintuning (PEFT):  Abbildung 13 zeigt die Trainingsverlustkurven von LoRA-Modellen und vergleicht sie mit dem Vollparametertraining. Bei beiden LoRA-Modellen konvergiert der Verlust schnell und nimmt ab einem bestimmten Punkt nicht mehr ab. Tabelle XIII zeigt die Auswertungsergebnisse der LoRA-Modelle. Beide LoRA-Modelle schneiden bei Chipdesignaufgaben im eigenen Bereich deutlich schlechter ab als das Vollparametertraining. LoRA-Modelle verbessern sich bei Chipdesignaufgaben im Vergleich zu ihren nicht-DAPT-Gegenstücken, wobei das größere Modell etwas bessere (aber nicht signifikante) Ergebnisse zeigt.    C. Training des Retrievalmodells  Das manuelle Generieren von Trainingsbeispielen ist sehr aufwändig, daher haben wir uns für die Implementierung eines Prozesses zur automatischen Generierung entschieden. Da wir kontrastives Lernen zur Feinabstimmung unseres Modells verwenden, erfordert jedes Beispiel eine Reihe sowohl positiver als auch negativer Passagen, insbesondere harte Negative, um die Genauigkeit zu maximieren.    Abbildung 14 beschreibt die Schritte zur Generierung einer Stichprobe: 1) Verfahren zur Datensatzstichprobenerstellung:  • Schritt 1: Wählen Sie nach dem Zufallsprinzip eine Passage aus dem Dokumentenkorpus aus  • Schritt 2: Verwenden Sie ein Sprachmodell (Vicuna), um aus der Passage eine gültige Abfrage zu generieren  • Schritt 3: Verwenden Sie ein bereits vorhandenes Abrufmodell (Satztransformator), um die Top-N-Passagen aus dem Dokumentkorpus für die Abfrage abzurufen, wobei jede Passage ein potenzielles Hard-Negative ist  • Schritt 4: Es ist möglich, dass einige der abgerufenen Passagen tatsächlich positiv sind. Verwenden Sie daher dasselbe Sprachmodell, um die positiven Passagen herauszufiltern  • Schritt 5: Wenn nach diesem Filterprozess nicht genügend negative Passagen vorhanden sind, ergänzen Sie diese mit zufälligen Passagen aus dem Korpus   Für unsere anfängliche Forschung verwendeten wir Vicuna [4] und Sentence Transformer [33]. Diese können jedoch leicht durch LLaMA2 [5] bzw. BM25 [42] ersetzt werden, um ein kommerziell nutzbares Retrievalmodell zu erzeugen.    Nicht alle Treffer sind gleich. Die Passage im folgenden Spec-Beispiel beantwortet die Frage klar und vollständig. Die Passage im Build-Beispiel enthält die Antwort; zur Beantwortung der Frage ist jedoch mehr Kontext erforderlich. 2) Vergleich der Trefferqualität:    Die Trefferpassage beantwortet die Abfrage eindeutig.  Spezifikationsbeispiel:    Um die Abfrage vollständig zu beantworten, sind zusätzliche Informationen erforderlich. Zum Beispiel: Was ist ein DL? Woher wissen wir, dass Arch-Build-Hotseat-XXX ein DL ist?  Build-Beispiel:   D. Zusätzliche Auswertungsdaten  Tabelle XIV zeigt die Bewertungsdaten für alle Modelle der Chatbot-Anwendung „Engineering Assistant“.  Tabelle XV zeigt unsere Auswertungsergebnisse für alle Modelle bei der Aufgabe der EDA-Skriptgenerierung.  Tabelle XVI zeigt unsere Auswertungsergebnisse für alle Modelle bei der Aufgabe der Fehlerzusammenfassung und -analyse.    E. Beispiele     1) Technischer Assistent-Chatbot:    Einige Funktionsnamen und Befehle sind verschleiert.  2) EDA-Skriptgenerierung:    Benutzernamen, Chipnamen und Pfade sind verschleiert.  3) Fehlerzusammenfassung und -analyse:  Dieses Dokument ist   . auf Arxiv unter der CC 4.0-Lizenz verfügbar

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

AI Models on HackerNoon

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Boost your HackerNoon story @ $159.99! 🚀

ChipNeMo: Domänenangepasste LLMs für Chipdesign: Anhang

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

Genuine Content Creation in the Age of AI: Why Startups Need Quality Content

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

Genuine Content Creation in the Age of AI: Why Startups Need Quality Content

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps