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.
A. DAPT-Datensatz
Während des Domain-Adaptive Pre-Trainings (DAPT) stellen wir einen Datensatz aus einer Kombination von NVIDIA-proprietären Chipdesign-spezifischen Datenquellen und öffentlich verfügbaren Datensätzen zusammen.
Chipdesign-Datensätze: Unser interner Datensatz besteht aus einer Vielzahl von Textquellen, die für das Chipdesign relevant sind und Design, Verifizierung, Infrastruktur und interne Dokumentation umfassen. Tabelle I bietet eine Aufschlüsselung der nach dem Filtern gesammelten Daten und die entsprechende Anzahl von Token mithilfe des LLaMA2-Tokenizers. Wir erstellen den Datensatz, indem wir alle relevanten internen Daten sammeln, dann nach Dateityp filtern, basierend auf Dateinamenerweiterungen, und zwischen maschinengeneriertem und von Menschen geschriebenem Inhalt unterscheiden. Obwohl wir drei spezifische Anwendungsfälle ausgewertet haben, haben wir den Datensatz nicht speziell auf Quellen beschränkt, von denen wir wissen, dass sie für diese Anwendungsfälle relevant sind, da wir der Ansicht waren, dass die Einbeziehung zusätzlichen Domänenwissens die Leistung verbessern würde. Nach dem Sammeln, Bereinigen und Filtern enthält das interne Datentrainingskorpus 23,1 Milliarden Token. Weitere Einzelheiten zum Datenerfassungsprozess finden Sie in Anhang A.
Öffentliche Datensätze: Wir ergänzen die chipdesignspezifischen Daten mit einer Auswahl öffentlich verfügbarer Daten aus verschiedenen Quellen, eine gängige Praxis bei der Entwicklung grundlegender großer Sprachmodelle. Unser Ansatz bestand darin, öffentliche Trainingsdaten aus anderen Sprachmodellen wiederzuverwenden, mit der Maßgabe, dass sie öffentlich zugänglich und mit Open Source kompatibel sein müssen. Diese Datensätze weisen einen hohen Grad an Korrelation mit den in LLaMA2 [5] verwendeten Vortrainingsdaten auf, mit der Absicht, allgemeines Wissen und natürliche Sprachfähigkeiten während DAPT zu bewahren. Die von ChipNeMo verwendeten öffentlichen Datensätze können in zwei Gruppen eingeteilt werden: natürliche Sprache und Code. Für die natürliche Sprachkomponente greifen wir auf Wikipedia-Daten [17] zurück, da diese allgemein für ihre hohe Datenqualität bekannt sind. Für den Code nutzen wir GitHub-Daten [18] und konzentrieren uns auf Programmiersprachen, die auch in unserem internen Chipdesign-Datensatz vorhanden sind, wie C++, Python und Verilog. Um sicherzustellen, dass der Gesamtdatensatz repräsentativ für die Verteilungen vor dem Training ist, führen wir eine Unterabtastung durch, die dazu führt, dass ungefähr 9,2 % aller Trainingstoken aus diesen öffentlichen Datensätzen abgetastet werden, mit einer ausgewogenen Darstellung von natürlicher Sprache und Code.
Datenmischung: Ein erheblicher Anteil der von uns gesammelten Domänendaten besteht aus nicht annotiertem Code unterschiedlicher Herkunft. Um das Verständnis des Modells für domänenspezifisches Wissen zu verbessern, haben wir über einen Zeitraum von 2 bis 4 Trainingsepochen ein Downsampling der Codedaten und gleichzeitig ein Upsampling der Daten in natürlicher Sprache, insbesondere der Designdokumentation, durchgeführt. Wir haben auch die Darstellung von Daten erhöht, die wir für nachgelagerte Anwendungen als relevanter erachteten, wie z. B. von Menschen geschriebene EDA-Tool-Skripte. Darüber hinaus haben wir für eine Epoche öffentlich verfügbare Domänendaten integriert. Einzelheiten zur Token-Verteilung für das Training sind in Tabelle I aufgeführt.
B. SFT-Anweisungsdaten
Beim Supervised Fine-Tuning (SFT) verwenden wir einen allgemeinen Chat-SFT-Befehlsdatensatz, der für die kommerzielle Nutzung zugänglich ist. Der Datensatz besteht größtenteils aus öffentlich verfügbaren Befehlsdatensätzen, darunter OASST [19], FLAN [20], P3 [21] und einem kleinen Teil eines breit gefächerten proprietären Datensatzes, der verschiedene Themen wie Brainstorming, Beantwortung offener Fragen, Umschreiben, Zusammenfassung usw. umfasst. Es ist wichtig zu beachten, dass sich die SFT-Befehlsdaten, die wir hier diskutieren, auf allgemeine Aufgaben in natürlicher Sprache konzentrieren und keine Informationen oder Aufgaben enthalten, die sich auf die nachgelagerten Anwendungsfälle im Chipdesign beziehen. Insgesamt umfasst dieser Datensatz 128.000 Trainingsbeispiele.
Darüber hinaus haben wir sorgfältig einen domänenspezifischen Anweisungsdatensatz zusammengestellt, um das Modell an nachgelagerte Anwendungsfälle anzupassen. Diese Beispiele wurden von Fachexperten sorgfältig ausgearbeitet und sind als einstufige Fragen und Antworten formatiert. Tabelle II zeigt die Menge unseres domänenspezifischen Anweisungsdatensatzes. Es ist erwähnenswert, dass die Gesamtzahl der Trainingsbeispiele im domänenspezifischen Anweisungsdatensatz im Vergleich zur umfangreichen Menge an generativen Chat-Anweisungsdaten recht gering ist.
C. AutoEval
Um die Genauigkeit verschiedener Modelle schnell und quantitativ bewerten zu können, haben wir Bewertungskriterien in Form von Multiple-Choice-Fragen und -Antworten für jeden Anwendungsfall erstellt, die sich eng an etablierte Benchmarks wie MMLU [22] anlehnen. Bei der Formulierung dieser Multiple-Choice-Fragen war die Zusammenarbeit mit Fachexperten von entscheidender Bedeutung. Ziel war es sicherzustellen, dass jede Frage mindestens eine komplexe Antwortmöglichkeit enthielt, um Personen mit begrenztem Fachwissen eine Herausforderung zu bieten. Außerdem wurde sorgfältig darauf geachtet, eine unbeabsichtigte Verunreinigung der Fragen mit Daten aus unserem domänenspezifischen SFT zu verhindern. Zusätzlich zu den Benchmarks für jeden Anwendungsfall wurde ein zusätzlicher Benchmark für allgemeine Kenntnisse zum Schaltungsdesign erstellt, der sowohl analoge als auch digitale Designthemen abdeckt. Die Anzahl der Multiple-Choice-Fragen für den Bewertungsbenchmark ist in Tabelle III aufgeführt.
Wenn wir Ergebnisse der oben genannten Benchmarks berichten, verwenden wir Durchschnittsergebnisse aus fünf verschiedenen Durchläufen, um die Auswirkungen von Varianz und Rauschen im Testprozess zu mildern. Jede Iteration verwendet einen Satz von 5-Schuss-Beispielen, wobei bei jedem einzelnen Durchlauf Variationen eingeführt werden.
Zusätzlich zu diesen domänenspezifischen Evaluierungsbenchmarks beziehen wir auch allgemein verwendete, öffentlich verfügbare akademische LLM-Benchmarks ein. Darüber hinaus messen wir die Fähigkeiten des Modells zur Codegenerierung, indem wir HumanEval [23] für Python und VerilogEval [12] für Verilog evaluieren.
Dieses Dokument ist auf Arxiv unter der CC 4.0-Lizenz verfügbar .