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

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.

DAPT-Hyperparameter: Einzelheiten sind in Tabelle VI dargestellt.

Ergebnisse der automatischen Bewertung: 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:

• Chip : Wir berichten über Durchschnittsergebnisse bei den domäneninternen Design-, Scripting-, Bugs- und Schaltkreis-Benchmarks aus Tabelle III (5-Shot).

• MMLU: Wir berichten über die Gesamtergebnisse zu MMLU (5-Schuss) [22], einem beliebten aggregierten Benchmark für eine breite Palette von Themen.

• Argumentation : 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].

• Code : Wir berichten über die durchschnittliche Bestehensquote von Coding-Benchmarks mit Greedy-Decoding, einschließlich HumanEval [23], VerilogEval-Machine [12] und VerilogEval-Human [12].

Erweiterung des Tokenizers: 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.

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.

Einbindung öffentlicher Datensätze: 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.

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 (PEFT): 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.

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.

1) Verfahren zur Datensatzstichprobenerstellung: Abbildung 14 beschreibt die Schritte zur Generierung einer Stichprobe:

• 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.

2) Vergleich der Trefferqualität: 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.

Spezifikationsbeispiel: Die Trefferpassage beantwortet die Abfrage eindeutig.

Build-Beispiel: 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?

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:

2) EDA-Skriptgenerierung: Einige Funktionsnamen und Befehle sind verschleiert.

3) Fehlerzusammenfassung und -analyse: Benutzernamen, Chipnamen und Pfade sind verschleiert.