```html 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 Abstract Große Sprachmodelle (LLMs), die auf Code trainiert wurden, revolutionieren den Softwareentwicklungsprozess. Immer häufiger werden Code-LLMs in Entwicklungsumgebungen integriert, um die Produktivität menschlicher Programmierer zu steigern, und LLM-basierte Agenten zeigen vielversprechende Ergebnisse bei der autonomen Bewältigung komplexer Aufgaben. Um das volle Potenzial von Code-LLMs auszuschöpfen, sind eine Vielzahl von Fähigkeiten erforderlich, darunter Code-Generierung, Fehlerbehebung, Code-Erklärung und -Dokumentation, Repository-Wartung und mehr. In dieser Arbeit stellen wir die Granite-Serie von nur-Decoder-Code-Modellen für code-generative Aufgaben vor, die mit Code in 116 Programmiersprachen trainiert wurden. Die Granite Code-Modelle-Familie besteht aus Modellen mit Größen von 3 bis 34 Milliarden Parametern, die für Anwendungen von komplexen Anwendungsmodernisierungsaufgaben bis hin zu speicherbeschränkten On-Device-Anwendungsfällen geeignet sind. Die Evaluierung auf einem umfassenden Aufgabensatz zeigt, dass Granite Code-Modelle durchweg Spitzenleistungen unter den verfügbaren Open-Source-Code-LLMs erzielen. Die Granite Code-Modell-Familie wurde für Unternehmens-Softwareentwicklungs-Workflows optimiert und erzielt gute Ergebnisse bei einer Reihe von Codierungsaufgaben (z. B. Code-Generierung, -Korrektur 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 für Forschungs- und kommerzielle Zwecke. https://github.com/ibm-granite/granite-code-models 1 Einleitung In den letzten Jahrzehnten hat sich Software in das Gewebe jedes Aspekts unserer Gesellschaft 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 Unterstützung menschlicher Programmierer. Prominente Anwendungsfälle für LLMs in der Softwareentwicklungsproduktivität umfassen Code-Generierung, Code-Erklärung, Code-Korrektur, Unit-Test- und Dokumentationserstellung, Anwendungsmodernisierung, Schwachstellenerkennung, Code-Übersetzung und mehr. In den letzten Jahren gab es rasante Fortschritte bei der Fähigkeit von LLMs, Code zu generieren und zu manipulieren, und eine Reihe von Modellen mit beeindruckenden Codierungsfähigkeiten sind heute verfügbar. Die Modelle reichen in der Größe von einstelligen Milliarden 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 des beabsichtigten Einsatzes, wobei einige Modelle darauf abzielen, eine Reihe von Anwendungen außerhalb von Code abzudecken, während andere sich hauptsächlich auf Code-bezogene Aufgaben konzentrieren (z. B. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), und CodeGemma (CodeGemma Team et al., 2024)). Es gibt jedoch weiterhin wichtige Lücken im aktuellen Feld der LLMs für Code, insbesondere im Kontext der Unternehmenssoftwareentwicklung. Erstens können sehr große, generalistische LLMs zwar eine ausgezeichnete Coding-Leistung erzielen, aber ihre Größe macht ihre Bereitstellung teuer. Kleinere Code-fokussierte Modelle ( , ; , ; , ; , ; , ) können eine exzellente Code-Generierungsleistung in einem kleineren und flexibleren Paket erzielen, aber die Leistung bei Codierungsaufgaben über die Generierung hinaus (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 mangelnder Transparenz bezüglich der Datenquellen und -verarbeitungsmethoden, die in das Modell eingeflossen sind, was das Vertrauen in Modelle in missionskritischen 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 präsentieren wir Granite Code-Modelle, eine Reihe hochleistungsfähiger Code-LLMs, die entwickelt wurden, um die Unternehmenssoftwareentwicklung bei einer Vielzahl von Codierungsaufgaben zu unterstützen. 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: Instruktionsfolgende Modelle, die mittels einer Kombination aus Git-Commits, gepaart mit menschlichen Anweisungen und Open-Source-synthetisch generierten Code-Instruktionsdatensätzen feinabgestimmt wurden. Granite Code Instruct: Die Basismodelle der Serie wurden von Grund auf mit einer zweiphasigen Trainingsstrategie trainiert. In Phase 1 wurde unser Modell auf 3 bis 4 Billionen Tokens trainiert, die aus 116 Programmiersprachen stammen, um ein umfassendes Verständnis von Programmiersprachen und Syntax zu gewährleisten. In Phase 2 wurde unser Modell auf weiteren 500 Milliarden Tokens mit einer sorgfältig gestalteten Mischung aus hochwertigen Daten aus Code- und natürlicher Sprachdomäne 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 Instruktionsmodelle werden durch weiteres Finetuning der oben trainierten Basismodelle auf einer Kombination aus einer gefilterten Variante von CommitPack ( , ), Datensätzen zur Befolgung von Anweisungen in natürlicher Sprache (OASST ( , ), HelpSteer ( , )) und Open-Source-Mathe-Datensätzen (MathInstruct ( , ) und MetaMathQA ( , )) abgeleitet, einschließlich synthetisch generierter Code-Datensätze zur Verbesserung der Instruktionsbefolgung und der Schlussfolgerungsfähigkeiten. 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 einer umfassenden Reihe von Benchmarks durch, darunter HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) und mehr. Dieser Benchmark-Satz 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 unter den Open-Source-Modellen die Granite Code-Modelle insgesamt sehr starke Leistungen über alle Modellgrößen und Benchmarks hinweg aufweisen (oft besser als andere Open-Source-Code-Modelle, die doppelt so groß sind wie Granite). Zum Beispiel zeigt Abbildung (oben) einen Vergleich von Granite-8B-Code-Base mit anderen Open-Source-Basis-Code-LLMs, einschließlich neuerer leistungsstarker allgemeiner Basis-LLMs wie Mistral ( , ) und LLama-3 ( , ) auf HumanEvalPack ( , ). Während CodeGemma und StarCoder2 bei der Code-Generierung gute Leistungen erbringen, schneiden sie bei den Code-Korrektur- und Erklärungs-Varianten von HumanEvalPack signifikant schlechter ab. Im Durchschnitt übertrifft Granite-8B-Code-Base das wettbewerbsfähigste CodeGemma-8B-Modell um fast 12 Punkte auf HumanEvalPack (33,2 % vs. 21,3 %), obwohl es auf einer signifikant geringeren Anzahl von Tokens trainiert wurde (4,5 T vs. 7,5 T Tokens). Neben Basismodellen zeigen auch die instruktionsgetunten Varianten unserer Granite Code-Modelle starke Leistungen auf HumanEvalPack und übertreffen andere Open-Source-(Code-)Instruktionsmodelle, was Vorteile für eine breitere Palette von Codierungsaufgaben mit natürlicher Sprache zeigt (siehe Abbildung (unten)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Da Schlussfolgerungen für die Lösung komplizierter Fragen und Aufgaben entscheidend sind, testen wir unser Granite-8B-Code-Base-Modell auch auf sechs mathematischen Benchmarks, darunter MATH ( , ), GSM8K ( , ) und Problem-Solving mit Zugriff auf rechnerische Werkzeuge, wo 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 auf GSM8K und ca. 6 Punkte auf MATH (siehe Tabelle ). Cobbe et al. 2021 Cobbe et al. 2021 15 Die Hauptvorteile der Granite Code-Modelle sind: : Granite Code-Modelle erzielen wettbewerbsfähige oder Spitzenleistungen bei verschiedenen Arten von Code-bezogenen Aufgaben, einschließlich Code-Generierung, -Erklärung, -Korrektur, -Bearbeitung, -Übersetzung usw., was ihre Fähigkeit beweist, verschiedene Codierungsaufgaben zu lösen; Allround-Code-LLM : Alle unsere Modelle werden auf zulässigerweise lizenzierten Daten trainiert, die gemäß den KI-Ethikprinzipien von IBM erfasst und vom IBM Corporate Legal Team für vertrauenswürdige Unternehmensnutzung geleitet werden. Alle Granite Code-Modelle werden unter der Apache 2.0-Lizenz veröffentlicht. Vertrauenswürdiges Enterprise-Grade-LLM 1 Unsere gesamte Pipeline zur Datenerfassung, -filterung und -vorverarbeitung wird in Abschnitt beschrieben. Abschnitt beschreibt die Details der Modellarchitektur, gefolgt von den Trainingsdetails in Abschnitt . Abschnitt enthält die Details zur Instruktionsabstimmung, und Abschnitt beschreibt die Experimente und Ergebnisse, die 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 Crawlings und Filterns (Abs. ), der Deduplizierung (Abs. ) und des HAP/PII-Filterns (Abs. ), die zur Vorbereitung der Code-Daten für das Modelltraining verwendet wurden. Wir geben auch einen Überblick über hochwertige Daten in natürlicher Sprache, die zur Verbesserung der Sprachverständnis- und mathematischen Schlussfolgerungsfähigkeiten des Modells verwendet werden. 2.1 2.2 2.3 2.1 Datencrawling und -filterung Die Pretraining-Code-Daten wurden aus einer Kombination von öffentlich verfügbaren Datensätzen wie Github Code Clean , StarCoderdata und zusätzlichen öffentlichen Code-Repositorys 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 Schlüssel-Filterregeln an, um qualitativ minderwertigen Code ( , ) herauszufiltern: (1) Entfernen von Dateien mit weniger als 25 % alphabetischen Zeichen, (2) Außer für die XSLT-Sprache, Entfernen von Dateien, bei denen der String „<?xml version=” innerhalb der ersten 100 Zeichen vorkommt, (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 aufweisen. 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 annotieren auch jede Code-Datei mit Lizenzinformationen, die dem jeweiligen Repository zugeordnet sind, gefunden über Github APIs, 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, einschließlich exakter und Fuzzy-Deduplizierung, um Dokumente mit (nahezu) identischem Codeinhalt in unserem Trainingsdatensatz 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 können, und dadurch die Daten weiter zu entzerren. Wir verwenden hierfür eine zweistufige Methode: (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 Dokumentenpaar 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 an, einschließlich GitHub-Issues, 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, unternehmen wir sorgfältige Anstrengungen, HAP-Inhalte aus dem Trainingsdatensatz herauszufiltern. Zuerst erstellen wir ein Wörterbuch mit HAP-Schlüsselwörtern und annotieren dann jedes Code-Dokument mit der Anzahl der Vorkommen solcher Schlüsselwörter im Inhalt, einschließlich Kommentaren. Wir filtern Dokumente heraus, die den HAP-Schwellenwert überschreiten, der auf einer Verteilungsanalyse sowie einer manuellen Inspektion von Code-Dateien basiert. Darüber hinaus unternehmen wir im Sinne des Schutzes der Privatsphäre und ähnlich wie bei StarCoder ( , ) sorgfältige Anstrengungen, persönlich identifizierbare Informationen (PII) aus dem Trainingsdatensatz zu schwärzen. 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-Schwärzungsschritt ersetzt den PII-Text durch die entsprechenden Tokens NAME , EMAIL , KEY , PASSWORD und ändert die IP-Adresse in eine synthetisch generierte IP-Adresse, wie bei Li et al. (2023a). Wir scannen unsere Datensätze auch mit , um Instanzen von Malware im Quellcode zu identifizieren und zu entfernen. Li et al. 2023a 4 2.4 Datensätze in natürlicher Sprache Zusätzlich zur Erfassung von Code-Daten für das Modelltraining kuratieren wir mehrere öffentlich verfügbare hochwertige Datensätze in natürlicher Sprache, um die Sprachkompetenz und mathematischen Schlussfolgerungsfähigkeiten des Modells zu verbessern. Repräsentative Datensätze in dieser Kategorie umfassen Web-Dokumente (Stackexchange, CommonCrawl), mathematische Web-Texte (OpenWeb-Math; ( ), StackMathQA; ( )), akademische Texte (Arxiv, Wikipedia) und Instruktions-Tuning-Datensä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 basierend auf der Transformer-Decoder-Architektur ( , ). Die Modellhyperparameter für diese Modelle sind in Tabelle aufgeführt. Für alle Modellarchitekturen verwenden wir Pre-Normalisierung ( , ): Normalisierung angewendet auf die Eingabe von Aufmerksamkeits- und MLP-Blöcken. 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 das MLP, auch bekannt als SwiGLU. Zur Normalisierung verwenden wir RMSNorm ( , ), da es recheneffizienter als LayerNorm ( , ) ist. Das 3B-Modell wird mit einer Kontextlänge von 2048 Tokens 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, dass Grouped-Query Attention (GQA) ( , ) verwendet wird. Die Verwendung von GQA bietet bei dieser Skalierung einen besseren Kompromiss zwischen Modellleistung und Inferenz-Effizienz. Wir trainieren das 8B-Modell mit einer Kontextlänge von 4096 Tokens. 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 Tokens trainiert. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Um das 34B-Modell zu trainieren, folgen wir dem Ansatz von zur Tiefen-Skalierung 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 Duplikat, um zwei Modelle zu bilden. 34B Kim et al. Schließlich konkatenieren wir beide Modelle zu dem Granite-34B-Code-Modell mit 88 Schichten (siehe Abbildung zur Illustration). Nach der Tiefen-Skalierung stellen wir fest, dass der Leistungsabfall im Vergleich zum 20B-Modell sehr gering ist, im Gegensatz zu dem, was von beobachtet wurde. Diese Leistung wird nach Fortsetzung des Pretrainings des skalierten 34B-Modells recht schnell wiederhergestellt. Ähnlich wie beim 20B-Modell verwenden wir während des Pretrainings einen Kontext von 8192 Tokens. 2 Kim et al. 4 Pretraining In diesem Abschnitt geben wir Details zu Zwei-Phasen-Training (Abs. ), Trainingszielen (Abs. ), Optimierung (Abs. ) und Infrastruktur (Abs. ) an, die beim Pretraining der Modelle verwendet wurden. 4.1 4.2 4.3 4.4 4.1 Zwei-Phasen-Training Granite Code-Modelle werden auf 3,5 T bis 4,5 T Tokens von Code-Daten und Code-bezogenen Textdaten trainiert. Die Daten werden mittels Byte Pair Encoding (BPE, ( , )) tokenisiert, wobei derselbe Tokenizer wie bei StarCoder ( , ) verwendet wird. Nach ( , ; , ) 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 Tokens von Code-Daten trainiert, die 116 Sprachen umfassen. Das 20B-Parameter-Modell wird auf 3 Billionen Tokens Code trainiert. Das 34B-Modell wird nach der Tiefen-Skalierung auf 1,4 T Tokens trainiert, die auf dem 1,6 T Checkpoint des 20B-Modells durchgeführt wird. Phase 1 (nur Code-Training) • : In Phase 2 nehmen wir zusätzliche hochwertige öffentlich verfügbare Daten aus verschiedenen Domänen auf, 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 Tokens (80 % Code und 20 % Sprachdaten) in Phase 2 des Trainings. 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 besteht darin, eingefügte Tokens 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 Formatierungs-Steuerungs-Tokens, wie bei StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a Der Gesamtverlust wird als gewichtete Kombination der beiden Ziele berechnet: Wir setzen empirisch = 0,5 während des Trainings 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 ist zu beachten, dass das FIM-Ziel nur während des Pretrainings verwendet wird, während wir es beim Instruktions-Finetuning fallen lassen, d. h. wir setzen = 1. α α 4.3 Optimierung Wir verwenden den AdamW-Optimierer ([Kingma & Ba](#_bookmark80), [2017](#_bookmark80)) mit β1 = 0,9, β2 = 0,95 und einer Gewichtungsabnahme von 0,1 für das Training aller unserer Granite Code-Modelle. Für das Pretraining in Phase 1 folgt die Lernrate einem Kosinus-Zeitplan, beginnend bei 3 10−4, der auf 3 10−5 absinkt, mit einem anfänglichen linearen Aufwärmschritt von 2k Iterationen. Für das Pretraining in Phase 2 beginnen wir bei 3 10−4 (1,5 10−4 für 20B- und 34B-Modelle) und verwenden einen exponentiellen Abklingplan, um ihn auf 10 % der anfänglichen Lernrate zu reduzieren. Wir verwenden eine Batch-Größe von 4 Mio. bis 5 Mio. Tokens, abhängig von der Modellgröße, während beider Phasen des Pretrainings. Um das Training zu beschleunigen, verwenden wir FlashAttention 2 ( , ; Dao et al. 2022
