Autoren: Mayank Mishra⋆, IBM Matt Stallone⋆, IBM Gaoyuan Zhang⋆, IBM Yikang Shen, IBM Aditya Prasad, IBM Adriana Meza Soria, IBM Michele Merler, IBM Parameswaran Selvam, IBM Saptha Surendran, IBM Shivdeep Singh, IBM Manish Sethi, IBM Xuan-Hong Dang, IBM Pengyuan Li, IBM Kun-Lung Wu, IBM Syed Zawad, IBM Andrew Coleman, IBM Matthew White, IBM Mark Lewis, IBM Raju Pavuluri, IBM Yan Koyfman, IBM Boris Lublinsky, IBM Maximilien de Bayser, IBM Ibrahim Abdelaziz, IBM Kinjal Basu, IBM Mayank Agarwal, IBM Yi Zhou, IBM Chris Johnson, IBM Aanchal Goyal, IBM Hima Patel, IBM Yousaf Shah, IBM Petros Zerfos, IBM Heiko Ludwig, IBM Asim Munawar, IBM Maxwell Crouse, IBM Pavan Kapanipathi, IBM Shweta Salaria, IBM Bob Calio, IBM Sophia Wen, IBM Seetharami Seelam, IBM Brian Belgodere, IBM Carlos Fonseca, IBM Amith Singhee, IBM Nirmit Desai, IBM David D. Cox, IBM Ruchir Puri†, IBM Rameswar Panda†, IBM Abstrakt Große Sprachmodelle (LLMs), die auf Code trainiert sind, revolutionieren den Softwareentwicklungsprozess. Zunehmend werden Code-LLMs in Softwareentwicklungsumgebungen integriert, um die Produktivität menschlicher Programmierer zu verbessern, und LLM-basierte Agenten beginnen vielversprechend für die autonome Bewältigung komplexer Aufgaben zu sein. Die volle Ausschöpfung des Potenzials von Code-LLMs erfordert eine breite Palette von Fähigkeiten, einschließlich Code-Generierung, Fehlerbehebung, Code-Erklärung und -Dokumentation, Repository-Wartung und mehr. In dieser Arbeit stellen wir die Granite-Serie von Decoder-only-Codemodellen für generative Codierungsaufgaben vor, die mit Code in 116 Programmiersprachen trainiert wurden. Die Granite Code-Modellfamilie besteht aus Modellen mit Größen zwischen 3 und 34 Milliarden Parametern, die für Anwendungen von komplexen Anwendungsmodernisierungsaufgaben bis hin zu speicherbeschränkten On-Device-Anwendungsfällen geeignet sind. Die Evaluierung anhand eines umfassenden Satzes von Aufgaben zeigt, dass die Granite Code-Modelle durchweg eine Spitzenleistung unter den verfügbaren Open-Source-Code-LLMs erzielen. Die Granite Code-Modellfamilie wurde für Unternehmens-Softwareentwicklungs-Workflows optimiert und liefert gute Ergebnisse bei einer Reihe von Codierungsaufgaben (z. B. Code-Generierung, -Behebung und -Erklärung), was sie zu einem vielseitigen „Allround“-Code-Modell macht. Wir veröffentlichen alle unsere Granite Code-Modelle unter einer Apache 2.0-Lizenz sowohl für Forschungs- als auch für kommerzielle Zwecke. https://github.com/ibm-granite/granite-code-models 1 Einleitung In den letzten Jahrzehnten hat sich Software in jedes Gewebe unseres gesellschaftlichen Lebens eingewoben. Da die Nachfrage nach Softwareentwicklung steigt, ist es wichtiger denn je, die Produktivität der Softwareentwicklung zu steigern, und LLMs bieten einen vielversprechenden Weg zur Ergänzung menschlicher Programmierer. Prominente Anwendungsfälle für LLMs in der Softwareentwicklungsproduktivität umfassen Code-Generierung, Code-Erklärung, Code-Korrektur, Generierung von Unit-Tests und Dokumentationen, Anwendungsmodernisierung, Schwachstellenerkennung, Code-Übersetzung und mehr. In den letzten Jahren gab es rasche Fortschritte bei der Fähigkeit von LLMs, Code zu generieren und zu manipulieren, und eine Reihe von Modellen mit beeindruckenden Kodierungsfähigkeiten ist heute verfügbar. Die Modelle reichen in der Größe von einstelligen Milliarden von Parametern (z. B. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024) usw.) bis zu Hunderten von Milliarden: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere) und variieren in der Allgemeinheit ihres beabsichtigten Einsatzes, wobei einige Modelle darauf abzielen, eine Reihe von Verwendungen außerhalb von Code abzudecken, während andere sich hauptsächlich auf kodierungsbezogene Aufgaben konzentrieren (z. B. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), CodeGemma (CodeGemma Team et al., 2024)). Es gibt jedoch weiterhin wichtige Lücken im aktuellen Bereich der LLMs für Code, insbesondere im Kontext der unternehmensweiten Softwareentwicklung. Erstens können sehr große, generalistische LLMs zwar eine exzellente Kodierungsleistung erzielen, ihre Größe macht jedoch ihren Einsatz teuer. Kleinere, auf Code spezialisierte Modelle ( , ; , ; , ; , ; , ) können eine exzellente Code-Generierungsleistung in einem kleineren und flexibleren Paket erzielen, aber die Leistung bei Kodierungsaufgaben, die über die Generierung hinausgehen (z. B. Fehlerbehebung und Erklärung), kann hinter der Code-Generierungsleistung zurückbleiben. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 In vielen Unternehmenskontexten kann die Akzeptanz von Code-LLMs durch Faktoren erschwert werden, die über die Leistung der Modelle hinausgehen. Beispielsweise leiden selbst offene Modelle manchmal unter einem Mangel an Transparenz über die Datenquellen und Datenverarbeitungsmethoden, die in das Modell eingeflossen sind, was das Vertrauen in Modelle in geschäftskritischen und regulierten Kontexten untergraben kann. Darüber hinaus können Lizenzbedingungen in heutigen offenen LLMs die Fähigkeit eines Unternehmens zur Nutzung eines Modells einschränken und verkomplizieren. Hier stellen wir die Granite Code-Modelle vor, eine Reihe von hochleistungsfähigen Code-LLMs, die für die Unterstützung der unternehmensweiten Softwareentwicklung bei einer Vielzahl von Codierungsaufgaben konzipiert sind. Die Granite Code-Modelle gibt es in zwei Hauptvarianten, die wir in vier verschiedenen Größen (3B, 8B, 20B und 34B) veröffentlichen: Basis-Grundlagenmodelle für Code-bezogene Aufgaben; Granite Code Base: Anweisungsfolge-Modelle, die mittels einer Kombination aus Git-Commits, menschlichen Anweisungen und offen lizenzierten synthetisch generierten Code-Anweisungsdatensätzen feinabgestimmt wurden. Granite Code Instruct: Die Basismodelle der Serie wurden von Grund auf mit einer zweiphasigen Trainingsstrategie trainiert. In Phase 1 wird unser Modell auf 3 bis 4 Billionen Token aus 116 Programmiersprachen trainiert, um ein umfassendes Verständnis von Programmiersprachen und Syntax zu gewährleisten. In Phase 2 wird unser Modell auf 500 Milliarden Token mit einer sorgfältig gestalteten Mischung aus hochwertigen Daten aus Code- und natürlichen Sprachdomänen weiter trainiert, um die Fähigkeit des Modells zur Schlussfolgerung zu verbessern. Wir verwenden das unüberwachte Sprachmodellierungsziel, um die Basismodelle in beiden Trainingsphasen zu trainieren. Die Instruct-Modelle werden durch weitere Feinabstimmung der oben trainierten Basismodelle auf einer Kombination aus einer gefilterten Variante von CommitPack ( , ), natürlichen Sprach-Anweisungsfolgungsdatensätzen (OASST ( , ), HelpSteer ( , )) und offen lizenzierten mathematischen Datensätzen (MathInstruct ( , ) und MetaMathQA ( , )), einschließlich synthetisch generierter Code-Datensätze zur Verbesserung der Anweisungsfolge- und Schlussfolgerungsfähigkeiten, abgeleitet. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Wir führen umfangreiche Evaluierungen unserer Code-LLMs auf einem umfassenden Satz von Benchmarks durch, darunter HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) und mehr. Diese Benchmark-Sammlung umfasst viele verschiedene Arten von Codierungsaufgaben über die reine Codesynthese in Python hinaus, z. B. Code-Korrektur, Code-Erklärung, Code-Bearbeitung, Code-Übersetzung usw. über die meisten wichtigen Programmiersprachen (Python, JavaScript, Java, Go, C++, Rust usw.). Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 Unsere Ergebnisse zeigen, dass die Granite Code-Modelle unter den Open-Source-Modellen insgesamt eine sehr starke Leistung über alle Modellgrößen und Benchmarks hinweg aufweisen (oftmals besser als andere Open-Source-Code-Modelle, die doppelt so groß sind wie Granite). Als Illustration zeigt Abbildung (oben) einen Vergleich von Granite-8B-Code-Base mit anderen Open-Source-Basis-Code-LLMs, einschließlich aktueller leistungsstarker Allzweck-Basis-LLMs wie Mistral ( , ) und LLama-3 ( , ) auf HumanEvalPack ( , ). Während CodeGemma und StarCoder2 bei der Code-Generierung gute Leistungen erbringen, sind sie bei den Varianten HumanEvalPack zur Code-Korrektur und -Erklärung deutlich schlechter. Im Durchschnitt übertrifft Granite-8B-Code-Base das wettbewerbsfähigste CodeGemma-8B-Modell um fast 12 Punkte auf HumanEvalPack (33,2 % gegenüber 21,3 %), obwohl es auf einer signifikant geringeren Anzahl von Token trainiert wurde (4,5 T gegenüber 7,5 T Token). Neben den Basismodellen zeigen auch die auf Anweisungen feinabgestimmten Varianten unserer Granite Code-Modelle eine starke Leistung auf HumanEvalPack und übertreffen andere Open-Source-(Code-)Anweisungsmodelle, was die Vorteile für eine breitere Palette von Codierungsaufgaben mit natürlichen Anweisungen zeigt (siehe Abbildung (unten)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Da Schlussfolgerung entscheidend für die Lösung komplizierter Fragen und Aufgaben ist, testen wir unser Granite-8B-Code-Base-Modell auch auf sechs mathematischen Benchmarks, darunter MATH ( , ), GSM8K ( , ) und Problemlösung mit Zugang zu computergestützten Werkzeugen, wobei unser Granite 8B-Modell eine bessere Leistung erzielt als die meisten State-of-the-Art 7B- oder 8B-LLMs. Zum Beispiel übertrifft Granite-8B-Code-Base Llama-3-8B-Base um ca. 12 Punkte bei GSM8K und ca. 6 Punkte bei MATH (siehe Tabelle ). Cobbe et al. 2021 Cobbe et al. 2021 15 Die Hauptvorteile der Granite Code-Modelle sind: : Granite Code-Modelle erzielen eine wettbewerbsfähige oder Spitzenleistung bei verschiedenen Arten von codebezogenen Aufgaben, einschließlich Code-Generierung, -Erklärung, -Korrektur, -Bearbeitung, -Übersetzung usw., was ihre Fähigkeit zeigt, vielfältige Codierungsaufgaben zu lösen; Allround-Code-LLM : Alle unsere Modelle werden auf zulässigen Daten trainiert, die gemäß den IBM AI Ethics-Grundsätzen erfasst und vom IBM Corporate Legal Team für eine vertrauenswürdige unternehmensweite Nutzung geleitet wurden. Alle Granite Code-Modelle werden unter der Apache 2.0-Lizenz veröffentlicht. Vertrauenswürdiges Enterprise-Grade-LLM 1 Wir beschreiben unsere gesamte Datenerfassungs-, Filter- und Vorverarbeitungspipeline in Abschnitt . Abschnitt beschreibt die Details der Modellarchitektur, gefolgt von Trainingsdetails in Abschnitt . Abschnitt enthält die Details zur Anweisungsabstimmung, und Abschnitt beschreibt die Experimente und Ergebnisse, die Granite Code-Modelle mit anderen Open-Source-LLMs vergleichen. 2 3 4 5 6 2 Datenerfassung In diesem Abschnitt beschreiben wir den Prozess des Crawlens und Filterns (Abs. ), der Deduplizierung (Abs. ), des HAP/PII-Filterns (Abs. ), der zur Vorbereitung der Codedaten für das Modelltraining verwendet wurde. Wir geben auch einen Überblick über hochwertige Daten in natürlicher Sprache, die verwendet wurden, um das Sprachverständnis und die mathematischen Schlussfolgerungsfähigkeiten des Modells zu verbessern. 2.1 2.2 2.3 2.1 Daten-Crawling und -Filterung Die Daten für das Vortraining wurden aus einer Kombination von öffentlich verfügbaren Datensätzen wie Github Code Clean , StarCoderdata und zusätzlichen öffentlichen Code-Repositories und Issues von GitHub bezogen. Wir filtern Rohdaten, um eine Liste von 116 Programmiersprachen aus über 300 Sprachen zu erhalten, wie in Anhang aufgeführt. Die Zuordnung von Daten zu Programmiersprachen erfolgt ausschließlich anhand der Dateierweiterung, ähnlich wie bei StarCoder ( , ). Nach der Sprachfilterung wenden wir vier wichtige Filterregeln an, um qualitativ minderwertigen Code zu filtern ( , ): (1) Entfernen von Dateien mit weniger als 25 % alphabetischen Zeichen, (2) Außer für die XSLT-Sprache, Filtern von Dateien, bei denen der String „<?xml version=” innerhalb der ersten 100 Zeichen erscheint, (3) Für HTML-Dateien nur Dateien behalten, bei denen der sichtbare Text mindestens 20 % des HTML-Codes ausmacht und eine Mindestlänge von 100 Zeichen hat, (4) Für JSON- und YAML-Dateien nur Dateien behalten, die eine Zeichenanzahl zwischen 50 und 5000 Zeichen haben. Wir filtern auch GitHub-Issues mit einer Reihe von Qualitätsmetriken, die das Entfernen von automatisch generiertem Text, das Filtern von nicht-englischen Issues, das Ausschließen von Kommentaren von Bots und die Verwendung der Anzahl der an der Konversation beteiligten Benutzer als Qualitätsindikator umfassen. Wir versehen jede Code-Datei auch mit Lizenzinformationen, die dem jeweiligen Repository zugeordnet sind, die über GitHub-APIs gefunden werden, und behalten nur Dateien mit permissiven Lizenzen für das Modelltraining. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Exakte und Fuzzy-Deduplizierung Wir verfolgen eine aggressive Deduplizierungsstrategie, die sowohl exakte als auch Fuzzy-Deduplizierung umfasst, um Dokumente mit (nahezu) identischem Code-Inhalt in unserem Trainingssatz zu entfernen. Für die exakte Deduplizierung berechnen wir zunächst den SHA256-Hash des Dokumenteninhalts und entfernen Datensätze mit identischen Hashes. Nach der exakten Deduplizierung wenden wir eine Fuzzy-Deduplizierung an, mit dem Ziel, Code-Dateien zu entfernen, die geringfügige Variationen aufweisen und dadurch die Daten weiter zu entzerren. Wir wenden hierfür eine zweistufige Methode an: (1) Berechnung von MinHashes aller Dokumente und anschließende Verwendung von Locally Sensitive Hashing (LSH), um Dokumente basierend auf ihren MinHash-Fingerabdrücken zu gruppieren, (2) Messung der Jaccard-Ähnlichkeit zwischen jedem Paar von Dokumenten in derselben Gruppe und Kennzeichnung von Dokumenten außer einem als Duplikate basierend auf einem Ähnlichkeitsschwellenwert von 0,7. Wir wenden diesen Near-Deduplizierungsprozess auf alle Programmiersprachen, einschließlich GitHub-Issues, an, um die Reichhaltigkeit und Vielfalt des Trainingsdatensatzes zu erhöhen. 2.3 HAP-, PII-, Malware-Filterung Um die Wahrscheinlichkeit der Generierung von hasserfüllter, missbräuchlicher oder vulgärer (HAP) Sprache aus den Modellen zu reduzieren, bemühen wir uns sorgfältig, HAP-Inhalte aus dem Trainingssatz zu filtern. Wir erstellen zunächst ein Wörterbuch mit HAP-Schlüsselwörtern und versehen dann jedes Code-Dokument mit der Anzahl des Vorkommens solcher Schlüsselwörter im Inhalt, einschließlich Kommentaren. Wir filtern Dokumente, die den HAP-Schwellenwert überschreiten, der auf einer Verteilungsanalyse sowie manueller Inspektion von Code-Dateien basiert. Darüber hinaus bemühen wir uns, um die Privatsphäre zu schützen, wie StarCoder ( , ), sorgfältig, persönlich identifizierbare Informationen (PII) aus dem Trainingssatz zu entfernen. Insbesondere nutzen wir das StarPII -Modell, um IP-Adressen, Schlüssel, E-Mail-Adressen, Namen, Benutzernamen und Passwörter im Inhalt zu erkennen. Der PII-Redaktionsschritt ersetzt den PII-Text durch die entsprechenden Token NAME , EMAIL , KEY , PASSWORD und ändert die IP-Adresse in eine synthetisch generierte IP-Adresse, wie bei Li et al. (2023a). Wir scannen auch unsere Datensätze, um Malware-Instanzen im Quellcode zu identifizieren und zu entfernen. Li et al. 2023a 4 2.4 Datensätze in natürlicher Sprache Zusätzlich zur Sammlung von Codedaten für das Modelltraining stellen wir mehrere öffentlich verfügbare hochwertige Datensätze in natürlicher Sprache zusammen, um die Sprachkompetenz und die mathematischen Schlussfolgerungsfähigkeiten des Modells zu verbessern. Repräsentative Datensätze dieser Kategorie umfassen Webdokumente (Stackexchange, CommonCrawl), mathematische Webtexte (OpenWeb-Math; ( ), StackMathQA; ( )), akademische Texte (Arxiv, Wikipedia) und Anweisungsabstimmungsdatensätze (FLAN; ( ), HelpSteer ( , )). Wir deduplizieren diese bereits vorverarbeiteten Datensätze in natürlicher Sprache nicht. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Modellarchitektur Wir trainieren eine Reihe von Code-Modellen unterschiedlicher Größe auf Basis der Transformer-Decoder-Architektur ( , ). Die Modellhyperparameter für diese Modelle sind in Tabelle angegeben. Für alle Modellarchitekturen verwenden wir Pre-Normalisierung ( , ): Normalisierung, die auf den Input von Aufmerksamkeits- und MLP-Blöcken angewendet wird. Vaswani et al. 2017 1 Xiong et al. 2020 : Das kleinste Modell der Granite-Code-Modellfamilie wird mit RoPE-Embedding ( , ) und Multi-Head Attention ( , ) trainiert. Dieses Modell verwendet die Swish-Aktivierungsfunktion ( , ) mit GLU ( , ) für die MLP, auch bekannt als SwiGLU. Zur Normalisierung verwenden wir RMSNorm ( , ), da es recheneffizienter ist als LayerNorm ( , ). Das 3B-Modell wird mit einer Kontextlänge von 2048 Token trainiert. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : Das 8B-Modell hat eine ähnliche Architektur wie das 3B-Modell, mit der Ausnahme der Verwendung von Grouped-Query Attention (GQA) ( , ). Die Verwendung von GQA bietet bei dieser Größe einen besseren Kompromiss zwischen Modellleistung und Inferenz-Effizienz. Wir trainieren das 8B-Modell mit einer Kontextlänge von 4096 Token. 8B Ainslie et al. 2023 : Das 20B-Code-Modell wird mit gelernten absoluten Positions-Embeddings trainiert. Wir verwenden Multi-Query Attention ( , ) während des Trainings für eine effiziente nachgelagerte Inferenz. Für den MLP-Block verwenden wir die GELU-Aktivierungsfunktion ( , ). Zur Normalisierung der Aktivierungen verwenden wir LayerNorm ( , ). Dieses Modell wird mit einer Kontextlänge von 8192 Token trainiert. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Zum Trainieren des 34B-Modells folgen wir dem Ansatz von zur Tiefenskallierung des 20B-Modells. Insbesondere duplizieren wir zunächst das 20B-Code-Modell mit 52 Schichten und entfernen dann die letzten 8 Schichten des Originalmodells und die ersten 8 Schichten seiner Duplikate, um zwei Modelle zu bilden. 34B Kim et al. Schließlich fügen wir beide Modelle zusammen, um das Granite-34B-Code-Modell mit 88 Schichten zu bilden (siehe Abbildung zur Veranschaulichung). Nach der Tiefenskallierung stellen wir fest, dass der Leistungsabfall im Vergleich zum 20B-Modell gering ist, im Gegensatz zu dem, was bei beobachtet wurde. Diese Leistung wird nach der Fortsetzung des Vortrainings des skalierten 34B-Modells recht schnell wiederhergestellt. Ähnlich wie bei 20B verwenden wir während des Vortrainings einen Kontext von 8192 Token. 2 Kim et al. 4 Vortraining In diesem Abschnitt geben wir Details zu den zweiphasigen Trainings (Abs. ), Trainingszielen (Abs. ), Optimierung (Abs. ) und Infrastruktur (Abs. ) an, die beim Vortraining der Modelle verwendet wurden. 4.1 4.2 4.3 4.4 4.1 Zweiphasiges Training Granite Code-Modelle werden auf 3,5 T bis 4,5 T Token von Codedaten und natürlichen Sprachdatensätzen im Zusammenhang mit Code trainiert. Daten werden mittels Byte Pair Encoding (BPE, ( , )) tokenisiert, wobei derselbe Tokenizer wie bei StarCoder ( , ) verwendet wird. Gemäß ( , ; , ) verwenden wir hochwertige Daten mit zwei Trainingsphasen wie folgt. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Während Phase 1 werden sowohl die Modelle 3B als auch 8B für 4 Billionen Token von Codedaten, die 116 Sprachen umfassen, trainiert. Das 20B-Parameter-Modell wird auf 3 Billionen Token Code trainiert. Das 34B-Modell wird nach der Tiefenskallierung, die auf dem 1,6T-Checkpoint des 20B-Modells durchgeführt wird, auf 1,4T Token trainiert. Phase 1 (nur Code-Training) • : In Phase 2 fügen wir zusätzliche hochwertige, öffentlich verfügbare Daten aus verschiedenen Domänen hinzu, darunter technische, mathematische und Web-Dokumente, um die Leistung des Modells bei Schlussfolgerungs- und Problemlösungsfähigkeiten weiter zu verbessern, die für die Code-Generierung unerlässlich sind. Wir trainieren alle unsere Modelle für 500B Token (80 % Code und 20 % Sprachdaten) im Phase-2-Training. Phase 2 (Code + Sprach-Training) 4.2 Trainingsziel Für das Training aller unserer Modelle verwenden wir das kausale Sprachmodellierungsziel und das Fill-In-the-Middle (FIM) ( , ) Ziel. Das FIM-Ziel hat die Aufgabe, eingefügte Token mit dem gegebenen Kontext und nachfolgendem Text vorherzusagen. Wir trainieren unsere Modelle, um sowohl mit PSM- (Präfix-Suffix-Mitte) als auch mit SPM- (Suffix-Präfix-Mitte) Modi zu arbeiten, mit entsprechenden Formatierungssteuertoken, wie bei StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a Der Gesamtverlust wird als gewichtete Kombination der 2 Ziele berechnet: Wir legen empirisch = 0,5 während des Trainings fest und stellen fest, dass dies in der Praxis gut funktioniert und zu SOTA-Leistungen sowohl bei Code-Vervollständigung als auch bei Code-Infilling-Aufgaben führt. Es sei darauf hingewiesen, dass das FIM-Ziel nur während des Vortrainings verwendet wird, wir es jedoch während der Anweisungs-Feinabstimmung fallen lassen, d. h. = 1 setzen. α α 4.3 Optimierung Wir verwenden den AdamW-Optimierer ([Kingma & Ba](#_bookmark80),(#_bookmark80)) mit β1 = 0,9, β2 = 0,95 und einer Gewichtsnorm von 0,1 für das Training aller unserer Granite-Code-Modelle. Für das Phase-1-Vortraining folgt die Lernrate einem Kosinus-Zeitplan, der bei 3 10−4 beginnt und auf 3 10−5 absinkt, mit einem anfänglichen linearen Aufwärmschritt von 2k Iterationen. Für das Phase-2-Vortraining beginnen wir bei 3 10−4 (1,5 10−4 für die Modelle 20B und 34B) und verwenden einen exponentiellen Abfall-Zeitplan, um ihn auf 10 % der anfänglichen Lernrate zu reduzieren. Wir verwenden eine Batch-Größe von 4M-5M Token, abhängig von der Modellgröße, während beider Phasen des Vortrainings. Um das Training zu beschleunigen, verwenden wir FlashAttention 2 ( , ; , Dao et al. 2022 Dao 202
