Auteurs : 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 Grote taalmodellen (LLM's) getraind op code revolutioneren het softwareontwikkelingsproces. Steeds vaker worden code-LLM's geïntegreerd in omgevingen voor softwareontwikkeling om de productiviteit van menselijke programmeurs te verbeteren, en LLM-gebaseerde agenten beginnen veelbelovend te zijn voor het autonoom afhandelen van complexe taken. Het realiseren van het volledige potentieel van code-LLM's vereist een breed scala aan mogelijkheden, waaronder codegeneratie, het repareren van bugs, code uitleggen en documenteren, repositories onderhouden, en meer. In dit werk introduceren we de Granite-serie van decoder-only code-modellen voor code-generatietaken, getraind met code geschreven in 116 programmeertalen. De Granite Code-modellenfamilie bestaat uit modellen variërend in grootte van 3 tot 34 miljard parameters, geschikt voor toepassingen variërend van complexe taken voor het moderniseren van applicaties tot geheugenbeperkte use-cases op het apparaat. Evaluatie op een uitgebreide set taken toont aan dat Granite Code-modellen consistent state-of-the-art prestaties bereiken onder de beschikbare open-source code-LLM's. De Granite Code-modellenfamilie is geoptimaliseerd voor workflows voor softwareontwikkeling in ondernemingen en presteert goed bij een reeks codeertaken (bijv. codegeneratie, reparatie en uitleg), waardoor het een veelzijdig "all-round" code-model is. We publiceren al onze Granite Code-modellen onder een Apache 2.0-licentie voor zowel onderzoek als commercieel gebruik. https://github.com/ibm-granite/granite-code-models 1 Introductie In de afgelopen decennia is software verweven geraakt met elk aspect van onze samenleving. Nu de vraag naar softwareontwikkeling toeneemt, is het kritischer dan ooit om de productiviteit van softwareontwikkeling te verhogen, en LLM's bieden een veelbelovend pad voor het aanvullen van menselijke programmeurs. Prominente zakelijke use-cases voor LLM's in de productiviteit van softwareontwikkeling omvatten codegeneratie, code-uitleg, code-reparatie, unit test- en documentatiegeneratie, modernisering van applicaties, detectie van kwetsbaarheden, codetranslatie, en meer. De afgelopen jaren is er snelle vooruitgang geboekt in het vermogen van LLM's om code te genereren en te manipuleren, en er zijn vandaag de dag diverse modellen met indrukwekkende codeervaardigheden beschikbaar. Modellen variëren in grootte van enkele miljarden parameters (bijv. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), etc.) tot honderden miljarden: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), en verschillen in de algemeenheid van bedoeld gebruik, waarbij sommige modellen gericht zijn op een reeks toepassingen buiten code, terwijl andere primair gericht zijn op codegerelateerde taken (bijv. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), en CodeGemma (CodeGemma Team et al., 2024)). Er blijven echter belangrijke hiaten bestaan op het huidige gebied van LLM's voor code, vooral in de context van softwareontwikkeling in ondernemingen. Ten eerste, hoewel zeer grote, generalistische LLM's uitstekende codeerprestaties kunnen leveren, maakt hun grootte ze duur om te implementeren. Kleinere, op code gerichte modellen ( , ; , ; , ; , ; , ) kunnen uitstekende prestaties op het gebied van codegeneratie leveren in een kleiner en flexibeler pakket, maar prestaties in codeertaken buiten generatie (bijv. reparatie en uitleg) kunnen achterblijven bij de prestaties van codegeneratie. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 In veel zakelijke contexten kunnen de adoptie van code-LLM's verder worden gecompliceerd door factoren die verder gaan dan de prestaties van de modellen. Zo zijn zelfs open modellen soms geplaagd door een gebrek aan transparantie over de databronnen en dataprocessingmethoden die in het model zijn gebruikt, wat het vertrouwen in modellen in missiekritieke en gereguleerde contexten kan ondermijnen. Bovendien kunnen licentievoorwaarden in de huidige open LLM's de mogelijkheid van een onderneming om een model te gebruiken belemmeren en compliceren. Hier presenteren we Granite Code-modellen, een reeks zeer capabele code-LLM's, ontworpen om softwareontwikkeling in ondernemingen te ondersteunen bij een breed scala aan codeertaken. Granite Code-modellen hebben twee hoofdvarianten die we uitbrengen in vier verschillende groottes (3B, 8B, 20B en 34B): basis fundamentele modellen voor code-gerelateerde taken; Granite Code Base: instructievolgende modellen die zijn gefinetuned met een combinatie van Git commits gekoppeld aan menselijke instructies en open-source synthetisch gegenereerde code-instructiedatasets. Granite Code Instruct: De basismodellen in de serie zijn vanaf nul getraind met een tweefasige trainingsstrategie. In fase 1 wordt ons model getraind op 3 tot 4 biljoen tokens afkomstig uit 116 programmeertalen, wat zorgt voor een uitgebreid begrip van programmeertalen en syntax. In fase 2 wordt ons model verder getraind op 500 miljard tokens met een zorgvuldig ontworpen mix van hoogwaardige gegevens uit code- en natuurlijke taalgebieden om het redeneervermogen van het model te verbeteren. We gebruiken de ongesuperviseerde taalmodelleringsdoelstelling om de basismodellen in beide trainingsfasen te trainen. De instructmodellen worden afgeleid door verdere finetuning van de bovengenoemde getrainde basismodellen op een combinatie van een gefilterde variant van CommitPack ( , ), datasets voor het volgen van natuurlijke taalinstructies (OASST ( , ), HelpSteer ( , )) en open-source wiskundige datasets (MathInstruct ( , ) en MetaMathQA ( , )), inclusief synthetisch gegenereerde code-datasets ter verbetering van instructievolging en redeneervaardigheden. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 We voeren uitgebreide evaluaties uit van onze code-LLM's op een uitgebreide set benchmarks, waaronder HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ), en meer. Deze set benchmarks omvat vele verschillende soorten codeertaken, naast alleen code-synthese in Python, bijv. code-reparatie, code-uitleg, code-editing, code-vertaling, etc., in de meeste belangrijke programmeertalen (Python, JavaScript, Java, Go, C++, Rust, etc.). Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 Onze bevindingen onthullen dat onder de open-source modellen, de Granite Code-modellen over het algemeen zeer sterke prestaties laten zien over alle modelgroottes en benchmarks (vaak beter presterend dan andere open-source code-modellen die twee keer zo groot zijn vergeleken met Granite). Ter illustratie toont figuur (boven) een vergelijking van Granite-8B-Code-Base met andere open-source basis code-LLM's, waaronder recente high-performing general purpose basis LLM's zoals Mistral ( , ) en LLama-3 ( , ) op HumanEvalPack ( , ). Hoewel CodeGemma en StarCoder2 redelijk goed presteren bij het genereren van code, presteren ze significant slechter op de code-reparatie en -uitleg varianten van HumanEvalPack. Gemiddeld presteert Granite-8B-Code-Base bijna 12 punten beter dan het meest concurrerende CodeGemma-8B-model op HumanEvalPack (33,2% versus 21,3%), ondanks dat het getraind is op significant minder tokens (4,5T versus 7,5T tokens). Naast basismodellen, vertonen de instructie-getunede varianten van onze Granite Code-modellen ook sterke prestaties op HumanEvalPack, beter presterend dan andere open-source (code) instructiemodellen, wat de voordelen aantoont voor een bredere set codeertaken met natuurlijke taalinstructies (zie figuur (onder)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Bovendien, aangezien redeneren cruciaal is voor het oplossen van ingewikkelde vragen en taken, testen we ook ons Granite-8B-Code-Base model op zes wiskundige benchmarks, waaronder MATH ( , ), GSM8K ( , ) en probleemoplossing met toegang tot computationele hulpmiddelen, waarbij ons Granite 8B-model betere prestaties behaalt dan de meeste state-of-the-art 7B of 8B LLM's. Bijvoorbeeld, Granite-8B-Code-Base presteert beter dan Llama-3-8B-Base met circa 12 punten op GSM8K en circa 6 punten op MATH (zie tabel ). Cobbe et al. 2021 Cobbe et al. 2021 15 De belangrijkste voordelen van Granite Code-modellen zijn onder meer: : Granite Code-modellen bereiken competitieve of state-of-the-art prestaties op verschillende soorten code-gerelateerde taken, waaronder codegeneratie, uitleg, reparatie, editing, vertaling, enz., wat hun vermogen aantoont om diverse codeertaken op te lossen; All-rounder Code LLM : Al onze modellen zijn getraind op toegestaan gelicentieerde gegevens die zijn verzameld volgens IBM's AI Ethics principes en begeleid door IBM's Corporate Legal team voor betrouwbaar zakelijk gebruik. Alle Granite Code-modellen worden uitgebracht onder de Apache 2.0-licentie. Betrouwbaar Enterprise-Grade LLM 1 We beschrijven onze volledige pipeline voor gegevensverzameling, filtering en voorbewerking in sectie . Sectie beschrijft de details van de modelarchitectuur, gevolgd door trainingsdetails in Sectie . Sectie geeft de details over instructie-tuning, en Sectie beschrijft de experimenten en resultaten ter vergelijking van Granite Code-modellen met andere open-source LLM's. 2 3 4 5 6 2 Gegevensverzameling In deze sectie beschrijven we het proces van crawlen en filteren (Sec. ), deduplicatie (Sec. ), HAP/PII-filtering (Sec. ) dat is gebruikt om de codegegevens voor modeltraining voor te bereiden. We geven ook een overzicht van hoogwaardige natuurlijke taalgegevens die zijn gebruikt om het taalbegrip en de wiskundige redeneervaardigheden van het model te verbeteren. 2.1 2.2 2.3 2.1 Gegevens Crawlen en Filteren De pretraining code-gegevens werden verkregen uit een combinatie van publiek beschikbare datasets zoals Github Code Clean , StarCoderdata , en aanvullende publieke code-repositories en issues van GitHub. We filteren ruwe gegevens om een lijst van 116 programmeertalen te behouden uit meer dan 300 talen, zoals vermeld in Bijlage . De toewijzing van gegevens aan programmeertalen gebeurt uitsluitend op basis van bestandsextensie, vergelijkbaar met StarCoder ( , ). Na taalfiltering passen we vier belangrijke filterregels toe om code van lagere kwaliteit te verwijderen ( , ): (1) verwijder bestanden met minder dan 25% alfabetische tekens, (2) behalve voor de XSLT-taal, filter bestanden waarbij de string “<?xml version=” verschijnt binnen de eerste 100 tekens, (3) voor HTML-bestanden, behoud alleen bestanden waarbij de zichtbare tekst ten minste 20% van de HTML-code beslaat en een minimale lengte van 100 tekens heeft, (4) voor JSON- en YAML-bestanden, behoud alleen bestanden met een tekenaantal tussen 50 en 5000 tekens. We filteren ook GitHub-issues met behulp van een reeks kwaliteitsstatistieken, waaronder het verwijderen van automatisch gegenereerde tekst, het filteren van niet-Engelse issues, het uitsluiten van opmerkingen van bots, en het gebruiken van het aantal gebruikers dat deelneemt aan het gesprek als indicator van kwaliteit. We annoteren ook elk codebestand met licentie-informatie die is gekoppeld aan de respectieve repository, gevonden via GitHub API's en behouden alleen bestanden met permissieve licenties voor modeltraining. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Exacte en Fuzzy Deduplicatie We hanteren een agressieve deduplicatiestrategie, inclusief zowel exacte als fuzzy deduplicatie om documenten met (bijna) identieke code-inhoud in onze trainingsset te verwijderen. Voor exacte deduplicatie berekenen we eerst de SHA256-hash van de documentinhoud en verwijderen we records met identieke hashes. Na exacte deduplicatie passen we fuzzy deduplicatie toe met als doel codebestanden te verwijderen die lichte variaties kunnen hebben en daardoor de gegevens verder te ontbiassen. We passen hiervoor een tweestapsmethode toe: (1) bereken MinHashes van alle documenten en gebruik vervolgens Locally Sensitive Hashing (LSH) om documenten te groeperen op basis van hun MinHash-vingerafdrukken, (2) meet de Jaccard-gelijkenis tussen elk paar documenten in dezelfde bucket en annoteer documenten behalve één als duplicaten op basis van een gelijkenisdrempel van 0,7. We passen dit bijna-deduplicatieproces toe op alle programmeertalen, inclusief GitHub-issues, om de rijkdom en diversiteit van de trainingsdataset te vergroten. 2.3 HAP, PII, Malware Filtering Om de waarschijnlijkheid van het genereren van haatdragende, beledigende of profane (HAP) taal uit de modellen te verminderen, doen we er alles aan om HAP-inhoud uit de trainingsset te filteren. We maken eerst een woordenboek van HAP-zoekwoorden en annoteren vervolgens elk code-document met het aantal keren dat dergelijke zoekwoorden in de inhoud, inclusief opmerkingen, voorkomen. We filteren documenten die de HAP-drempel overschrijden, berekend op basis van een distributionele analyse en handmatige inspectie van codebestanden. Bovendien, om privacy te beschermen, volgen we StarCoder ( , ) en doen we er alles aan om Persoonlijk Identificeerbare Informatie (PII) uit de trainingsset te redigeren. Specifiek gebruiken we het StarPII -model om IP-adressen, sleutels, e-mailadressen, namen, gebruikersnamen en wachtwoorden die in de inhoud worden gevonden te detecteren. De PII-redigeringsstap vervangt de PII-tekst door de overeenkomstige tokens NAME , EMAIL , KEY , PASSWORD en verandert het IP-adres in een synthetisch gegenereerd IP-adres, zoals in Li et al. (2023a). We scannen ook onze datasets met om malware-instanties in de broncode te identificeren en te verwijderen. Li et al. 2023a 4 2.4 Natuurlijke Taal Datasets Naast het verzamelen van code-gegevens voor modeltraining, stellen we verschillende publiek beschikbare hoogwaardige natuurlijke taal-datasets samen ter verbetering van de vaardigheid van het model in taalbegrip en wiskundige redenering. Representatieve datasets onder deze categorie omvatten webdocumenten (Stackexchange, CommonCrawl), wiskundige webteksten (OpenWeb-Math; ( ), StackMathQA; ( )), academische teksten (Arxiv, Wikipedia), en instructie-tuning datasets (FLAN; ( ), HelpSteer ( , )). We dedupliceren deze reeds voorbewerkte natuurlijke taal-datasets niet. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Modelarchitectuur We trainen een reeks code-modellen van verschillende groottes op basis van de transformer-decoderarchitectuur ( , ). De modelhyperparameters voor deze modellen staan in Tabel . Voor alle modelarchitecturen gebruiken we pre-normalisatie ( , ): normalisatie toegepast op de input van aandacht- en MLP-blokken. Vaswani et al. 2017 1 Xiong et al. 2020 : Het kleinste model in de Granite-code modelfamilie is getraind met RoPE-embedding ( , ) en Multi-Head Attention ( , ). Dit model gebruikt de swish activatiefunctie ( , ) met GLU ( , ) voor de MLP, ook wel swiglu genoemd. Voor normalisatie gebruiken we RMSNorm ( , ) omdat het computationeel efficiënter is dan LayerNorm ( , ). Het 3B-model is getraind met een contextlengte van 2048 tokens. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : Het 8B-model heeft een vergelijkbare architectuur als het 3B-model, met de uitzondering van het gebruik van Grouped-Query Attention (GQA) ( , ). Het gebruik van GQA biedt een betere balans tussen modelprestaties en inferentie-efficiëntie op deze schaal. We trainen het 8B-model met een contextlengte van 4096 tokens. 8B Ainslie et al. 2023 : Het 20B code-model is getraind met geleerde absolute positie-embeddings. We gebruiken Multi-Query Attention ( , ) tijdens de training voor efficiënte downstream-inferentie. Voor het MLP-blok gebruiken we de GELU-activatiefunctie ( , ). Voor het normaliseren van de activaties gebruiken we LayerNorm ( , ). Dit model is getraind met een contextlengte van 8192 tokens. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Om het 34B-model te trainen, volgen we de aanpak van voor diepte-upscaling van het 20B-model. Specifiek dupliceren we eerst het 20B code-model met 52 lagen en verwijderen vervolgens de laatste 8 lagen uit het originele model en de eerste 8 lagen uit het duplicaat om twee modellen te vormen. 34B Kim et al. Ten slotte voegen we beide modellen samen om het Granite-34B-Code-model met 88 lagen te vormen (zie Figuur voor een illustratie). Na de diepte-upscaling observeren we dat de prestatiedaling vergeleken met het 20B-model erg klein is, in tegenstelling tot wat werd waargenomen door Dit prestatieverlies wordt vrij snel hersteld nadat we de pretraining van het opgeschaalde 34B-model voortzetten. Net als bij 20B gebruiken we een context van 8192 tokens tijdens de pretraining. 2 Kim et al. 4 Pretraining In deze sectie geven we details over de tweefasige training (Sec. ), trainingsdoelstellingen (Sec. ), optimalisatie (Sec. ) en infrastructuur (Sec. ) die zijn gebruikt bij het pretrainen van de modellen. 4.1 4.2 4.3 4.4 4.1 Tweefasige Training Granite Code-modellen zijn getraind op 3,5T tot 4,5T tokens aan codegegevens en natuurlijke taal-datasets gerelateerd aan code. Gegevens worden getokeniseerd via byte pair encoding (BPE, ( , )), waarbij dezelfde tokenizer wordt gebruikt als StarCoder ( , ). Volgens ( , ; , ) gebruiken we hoogwaardige gegevens met twee trainingsfasen als volgt. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Tijdens fase 1 worden zowel de 3B- als 8B-modellen getraind op 4 biljoen tokens aan codegegevens die 116 talen omvatten. Het 20B-parameter model is getraind op 3 biljoen tokens code. Het 34B-model is getraind op 1,4T tokens na de diepte-upscaling die is uitgevoerd op de 1,6T-checkpoint van het 20B-model. Fase 1 (alleen code training) • : In fase 2 nemen we aanvullende hoogwaardige publiek beschikbare gegevens uit verschillende domeinen op, waaronder technische, wiskundige en webdocumenten, om de prestaties van het model op het gebied van redenering en probleemoplossing te verbeteren, die essentieel zijn voor codegeneratie. We trainen al onze modellen gedurende 500 miljard tokens (80% code en 20% taalgegevens) in fase 2 training. Fase 2 (code + taal training) 4.2 Trainingsdoelstelling Voor de training van al onze modellen gebruiken we de causale taalmodelleringsdoelstelling en Fill-In-the-Middle (FIM) ( , ) doelstelling. De FIM-doelstelling is gericht op het voorspellen van ingevoegde tokens met de gegeven context en de daaropvolgende tekst. We trainen onze modellen om te werken met zowel PSM (Prefix-Suffix-Middle) als SPM (Suffix-Prefix-Middle) modi, met relevante formaatcontrole tokens, hetzelfde als StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a De totale loss wordt berekend als een gewogen combinatie van de 2 doelstellingen: We stellen empirisch = 0,5 in tijdens de training en stellen vast dat dit in de praktijk goed werkt en leidt tot SOTA-prestaties op zowel code-aanvulling als code-infilling taken. Het moet worden opgemerkt dat de FIM-doelstelling alleen wordt gebruikt tijdens pretraining, maar we laten deze vallen tijdens instructie finetuning, d.w.z. we stellen = 1 in. α α 4.3 Optimalisatie We gebruiken de AdamW-optimizer ([Kingma & Ba](#_bookmark80),(#_bookmark80)) met β1 = 0,9, β2 = 0,95 en gewichtsverval van 0,1 voor het trainen van al onze Granite code-modellen. Voor de fase-1 pretraining volgt de leersnelheid een cosinuschema beginnend vanaf 3 10−4 die afneemt tot 3 10−5 met een initiële lineaire warmup-stap van 2k iteraties. Voor de fase-2 pretraining beginnen we vanaf 3 10−4 (1,5 10−4 voor 20B- en 34B-modellen) en hanteren we een exponentieel vervalschema om deze te verlagen tot 10% van de initiële leersnelheid. We gebruiken een batchgrootte van 4M-5M
