```html Författare: 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 Stora språkmodeller (LLM) tränade på kod revolutionerar programutvecklingsprocessen. I allt högre grad integreras kod-LLM i utvecklingsmiljöer för att förbättra produktiviteten hos mänskliga programmerare, och LLM-baserade agenter börjar visa lovande resultat för att hantera komplexa uppgifter autonomt. För att förverkliga den fulla potentialen hos kod-LLM krävs ett brett spektrum av förmågor, inklusive kodgenerering, felsökning, förklaring och dokumentation av kod, underhåll av kodförråd och mycket mer. I detta arbete introducerar vi Granite-serien av decoder-only kodmodeller för kodgenereringsuppgifter, tränade med kod skriven på 116 programmeringsspråk. Granite Code-modellfamiljen består av modeller som varierar i storlek från 3 till 34 miljarder parametrar, lämpliga för applikationer som sträcker sig från komplexa moderniseringsuppgifter för applikationer till användningsfall med begränsat minne på enheten. Utvärdering på en omfattande uppsättning uppgifter visar att Granite Code-modellerna konsekvent når toppmodern prestanda bland tillgängliga open source-kod-LLM. Granite Code-modellfamiljen optimerades för programutvecklingsflöden i företag och presterar bra över ett spektrum av kodningsuppgifter (t.ex. kodgenerering, felsökning och förklaring), vilket gör den till en mångsidig "allround"-kodmodell. Vi släpper alla våra Granite Code-modeller under en Apache 2.0-licens för både forsknings- och kommersiellt bruk. https://github.com/ibm-granite/granite-code-models 1 Introduktion Under de senaste decennierna har programvara vävts in i alla aspekter av vårt samhälle. I takt med att efterfrågan på programvaruutveckling skjuter i höjden är det viktigare än någonsin att öka produktiviteten inom programvaruutveckling, och LLM erbjuder en lovande väg för att förstärka mänskliga programmerare. Framstående användningsfall för LLM inom programvaruutveckling inkluderar kodgenerering, kodförklaring, kodkorrigering, generering av enhetstester och dokumentation, modernisering av applikationer, sårbarhetsdetektering, kodöversättning och mer. Under de senaste åren har det skett snabba framsteg i LLM:s förmåga att generera och manipulera kod, och en rad modeller med imponerande kodningsförmågor finns tillgängliga idag. Modellerna varierar i storlek från enstaka miljarder parametrar (t.ex. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), etc.) till hundratals miljarder: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), och skiljer sig i den generella avsedda användningen, där vissa modeller syftar till att täcka en rad användningsområden utanför kod, medan andra främst fokuserar på kodrelaterade uppgifter (t.ex. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), och CodeGemma (CodeGemma Team et al., 2024)). Det finns dock viktiga luckor inom det nuvarande fältet av LLM för kod, särskilt i samband med programvaruutveckling för företag. För det första, även om mycket stora, generalistiska LLM kan uppnå utmärkt kodningsprestanda, gör deras storlek dem dyra att driftsätta. Mindre kodfokuserade modeller ( , ; , ; , ; , ; , ) kan uppnå utmärkt kodgenereringsprestanda i ett mindre och mer flexibelt paket, men prestandan i kodningsuppgifter utöver generering (t.ex. felsökning och förklaring) kan släpa efter kodgenereringsprestandan. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 I många företagskontexter kan adoptionen av kod-LLM kompliceras ytterligare av faktorer utöver modellernas prestanda. Till exempel, även öppna modeller plågas ibland av bristande transparens om datakällor och databehandlingsmetoder som användes i modellen, vilket kan urholka förtroendet för modeller i kritiska och reglerade sammanhang. Dessutom kan licensvillkor i dagens öppna LLM belasta och komplicera ett företags förmåga att använda en modell. Här presenterar vi Granite Code-modeller, en serie högt kapabla kod-LLM, utformade för att stödja programvaruutveckling för företag över ett brett spektrum av kodningsuppgifter. Granite Code-modeller har två huvudvarianter som vi släpper i fyra olika storlekar (3B, 8B, 20B och 34B): grundläggande fundamentmodeller för kodrelaterade uppgifter; Granite Code Base: instruktionsföljande modeller som finjusterats med en kombination av Git-commits parat med mänskliga instruktioner och open source syntetiskt genererade kodinstruktionsdataset. Granite Code Instruct: Basmodellerna i serien har tränats från grunden med en tvåfasig träningsstrategi. I fas 1 tränas vår modell på 3 till 4 biljoner tokens från 116 programmeringsspråk, vilket säkerställer en omfattande förståelse av programmeringsspråk och syntax. I fas 2 tränas vår modell ytterligare på 500 miljarder tokens med en noggrant utformad blandning av högkvalitativ data från kod- och naturliga språkdomäner för att förbättra modellens förmåga att resonera. Vi använder den oövervakade språkmodelleringsmålet för att träna basmodellerna i båda faserna av träningen. Instruktionsmodellerna härleds genom ytterligare finjustering av de ovan tränade basmodellerna på en kombination av en filtrerad variant av CommitPack ( , ), dataset för instruktionsföljning på naturligt språk (OASST ( , ), HelpSteer ( , )) och open source matematiska dataset (MathInstruct ( , ) och MetaMathQA ( , )), inklusive syntetiskt genererade koddataset för att förbättra instruktionsföljning och resonemangsförmåga. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Vi genomför omfattande utvärderingar av våra kod-LLM på en omfattande uppsättning riktmärken, inklusive HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ), och mer. Denna uppsättning riktmärken omfattar många olika typer av kodningsuppgifter utöver bara kodsyntes i Python, t.ex. kodkorrigering, kodförklaring, kodredigering, kodöversättning, etc., över de flesta stora programmeringsspråk (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 Våra fynd avslöjar att bland open source-modeller, visar Granite Code-modellerna överlag mycket stark prestanda över alla modellstorlekar och riktmärken (ofta överträffar andra open source-kodmodeller som är dubbelt så stora jämfört med Granite). Som illustration visar figur (överst) en jämförelse av Granite-8B-Code-Base med andra open source-baserade kod-LLM, inklusive nyligen högpresterande allmänna bas-LLM som Mistral ( , ) och LLama-3 ( , ) på HumanEvalPack ( , ). Medan CodeGemma och StarCoder2 presterar rimligt bra på kodgenerering, presterar de betydligt sämre på kodkorrigering och förklaringsvarianterna av HumanEvalPack. I genomsnitt överträffar Granite-8B-Code-Base den mest konkurrenskraftiga CodeGemma-8B-modellen med nästan 12 poäng på HumanEvalPack (33,2% vs 21,3%), trots att den tränats på ett betydligt mindre antal tokens (4,5T vs 7,5T tokens). Förutom basmodeller visar även de instruktionsjusterade varianterna av våra Granite Code-modeller stark prestanda på HumanEvalPack och överträffar andra open source (kod) instruktionsmodeller, vilket visar fördelarna för en bredare uppsättning kodningsuppgifter med instruktioner på naturligt språk (se figur (nederst)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Dessutom, eftersom resonemang är kritiskt för att lösa komplicerade frågor och uppgifter, testar vi också vår Granite-8B-Code-Base-modell på sex matematiska riktmärken, inklusive MATH ( , ), GSM8K ( , ) och problemlösning med tillgång till beräkningsverktyg, där vår Granite 8B-modell uppnår bättre prestanda jämfört med de flesta state-of-the-art 7B eller 8B LLM. Till exempel överträffar Granite-8B-Code-Base Llama-3-8B-Base med ∼12 poäng på GSM8K och ∼6 poäng på MATH (se tabell ). Cobbe et al. 2021 Cobbe et al. 2021 15 De viktigaste fördelarna med Granite Code-modeller inkluderar: : Granite Code-modeller uppnår konkurrenskraftig eller state-of-the-art prestanda på olika typer av kodrelaterade uppgifter, inklusive kodgenerering, förklaring, korrigering, redigering, översättning, etc., vilket visar deras förmåga att lösa varierande kodningsuppgifter; Allround kod-LLM : Alla våra modeller tränas på licensmässigt tillåtna data som samlats in enligt IBM:s AI Ethics-principer och vägleds av IBM:s Corporate Legal-team för pålitlig företagsanvändning. Alla Granite Code-modeller släpps under Apache 2.0-licensen. Pålitlig LLM av företagsstandard 1 Vi beskriver hela vår pipeline för datainsamling, filtrering och förbehandling i avsnitt . Avsnitt beskriver detaljerna kring modellarkitekturen, följt av träningsdetaljer i Avsnitt . Avsnitt ger detaljer om instruktionsjustering, och Avsnitt beskriver experimenten och resultaten som jämför Granite Code-modeller med andra open source-LLM. 2 3 4 5 6 2 Datainsamling I detta avsnitt beskriver vi processen för att krypa och filtrera (avsnitt ), deduplicering (avsnitt ), HAP/PII-filtrering (avsnitt ) som används för att förbereda koddata för modellträning. Vi ger också en översikt över högkvalitativa naturliga språkdata som används för att förbättra modellens språkförståelse och matematiska resonemangsförmåga. 2.1 2.2 2.3 2.1 Datakrypning och filtrering Förträningskoddata hämtades från en kombination av publikt tillgängliga dataset som Github Code Clean , StarCoderdata , och ytterligare publika kodförråd och problem från GitHub. Vi filtrerar rådata för att behålla en lista över 116 programmeringsspråk av över 300 språk, som anges i Appendix . Tilldelningen av data till programmeringsspråk utförs enbart baserat på filändelse, liknande StarCoder ( , ). Efter språkfiltrering tillämpar vi fyra nyckelfiltreringsregler för att filtrera bort kod av lägre kvalitet ( , ): (1) ta bort filer med färre än 25% alfabetiska tecken, (2) förutom språket XSLT, filtrera bort filer där strängen "<?xml version=” förekommer inom de första 100 tecknen, (3) för HTML-filer, behåll endast filer där den synliga texten utgör minst 20% av HTML-koden och har en minimilängd på 100 tecken, (4) för JSON- och YAML-filer, behåll endast filer som har ett teckenantal mellan 50 och 5000 tecken. Vi filtrerar också GitHub-problem med en uppsättning kvalitetsmått som inkluderar borttagning av autogenererad text, filtrering av problem som inte är på engelska, exkludering av kommentarer från botar och användning av antalet användare som engagerar sig i konversationen som en indikator på kvalitet. Vi annoterar också varje kodfil med licensinformation associerad med respektive kodförråd, hittad via Github API:er, och behåller endast filer med tillåtande licenser för modellträning. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Exakt och suddig deduplicering Vi antar en aggressiv dedupliceringsstrategi som inkluderar både exakt och suddig deduplicering för att ta bort dokument med (nära) identiskt kodinnehåll i vårt träningsset. För exakt deduplicering beräknar vi först SHA256-hash på dokumentinnehållet och tar bort poster med identiska hashvärden. Efter exakt deduplicering tillämpar vi suddig deduplicering med målet att ta bort kodfiler som kan ha små variationer och därmed ytterligare av-biaisera data. Vi tillämpar en tvåstegsmetod för detta: (1) beräkna MinHashes för alla dokument och sedan använda Locally Sensitive Hashing (LSH) för att gruppera dokument baserat på deras MinHash-fingeravtryck, (2) mäta Jaccard-likhet mellan varje par av dokument i samma hink och annotera dokument utom ett som duplicerade baserat på en likhetströskel på 0,7. Vi tillämpar denna nästan-dedupliceringsprocess på alla programmeringsspråk inklusive GitHub-problem för att förbättra rikheten och mångfalden i träningsdatasetet. 2.3 HAP, PII, skadlig kod-filtrering För att minska sannolikheten för att generera hatiskt, kränkande eller profant (HAP) språk från modellerna, anstränger vi oss noggrant för att filtrera bort HAP-innehåll från träningssetet. Vi skapar först en ordbok med HAP-nyckelord och annoterar sedan varje kod dokument med antalet förekomster av sådana nyckelord i innehållet inklusive kommentarer. Vi filtrerar bort dokument som överskrider HAP-tröskeln, beräknad baserat på en distributionsanalys samt manuell inspektion av kodfiler. Dessutom, för att skydda integriteten, följer vi StarCoder ( , ) och anstränger oss noggrant för att redigera personligt identifierbar information (PII) från träningssetet. Specifikt använder vi StarPII -modellen för att upptäcka IP-adresser, nycklar, e-postadresser, namn, användarnamn och lösenord som finns i innehållet. PII-redigeringssteget ersätter PII-texten med motsvarande tokens NAME , EMAIL , KEY , PASSWORD och ändrar IP-adressen till en syntetiskt genererad IP-adress, som i Li et al. (2023a). Vi skannar också våra dataset med för att identifiera och ta bort instanser av skadlig kod i källkoden. Li et al. 2023a 4 2.4 Dataset med naturligt språk Utöver att samla in koddata för modellträning, samlar vi in flera publikt tillgängliga högkvalitativa dataset med naturligt språk för att förbättra modellens färdigheter i språkförståelse och matematiskt resonemang. Representativa dataset under denna kategori inkluderar webbdokument (Stackexchange, CommonCrawl), matematiska webbtexter (OpenWeb-Math; ( ), StackMathQA; ( )), akademiska texter (Arxiv, Wikipedia), och dataset för instruktionsjustering (FLAN; ( ), HelpSteer ( , )). Vi deduplicerar inte dessa redan förbearbetade dataset med naturligt språk. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Modellarkitektur Vi tränar en serie kodmodeller av varierande storlek baserat på transformer-decoderarkitekturen ( , ). Modellparametrarna för dessa modeller ges i Tabell . För alla modellarkitekturer använder vi pre-normalisering ( , ): normalisering applicerad på input till uppmärksamhets- och MLP-block. Vaswani et al. 2017 1 Xiong et al. 2020 : Den minsta modellen i Granite-code-modellfamiljen tränas med RoPE-inbäddning ( , ) och Multi-Head Attention ( , ). Denna modell använder swish-aktiveringsfunktionen ( , ) med GLU ( , ) för MLP, även allmänt kallad swiglu. För normalisering använder vi RMSNorm ( , ) eftersom den är beräkningsmässigt mer effektiv än LayerNorm ( , ). 3B-modellen tränas med en kontextlängd på 2048 tokens. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : 8B-modellen har en liknande arkitektur som 3B-modellen med undantag för användningen av Grouped-Query Attention (GQA) ( , ). Att använda GQA ger en bättre avvägning mellan modellprestanda och inferens effektivitet i denna skala. Vi tränar 8B-modellen med en kontextlängd på 4096 tokens. 8B Ainslie et al. 2023 : 20B-kodmodellen tränas med inlärda absoluta positionsinbäddningar. Vi använder Multi-Query Attention ( , ) under träning för effektiv nedströmsinferens. För MLP-blocket använder vi GELU-aktiveringsfunktionen ( , ). För att normalisera aktiveringarna använder vi LayerNorm ( , ). Denna modell tränas med en kontextlängd på 8192 tokens. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : För att träna 34B-modellen följer vi metoden av för djupuppskalning av 20B-modellen. Specifikt duplicerar vi först 20B-kodmodellen med 52 lager och tar sedan bort de sista 8 lagren från den ursprungliga modellen och de första 8 lagren från dess dubblett för att bilda två modeller. 34B Kim et al. Slutligen konkatenerar vi båda modellerna för att bilda Granite-34B-Code-modellen med 88 lager (se Figur för en illustration). Efter djupuppskalningen observerar vi att prestandafallet jämfört med 20B-modellen är mycket litet, till skillnad från vad som observerats av . Denna prestanda återställs ganska snabbt efter att vi fortsätter med förträning av den uppskalade 34B-modellen. Liksom med 20B använder vi en kontext på 8192 tokens under förträning. 2 Kim et al. 4 Förträning I detta avsnitt ger vi detaljer om tvåfasig träning (avsnitt ), träningsmål (avsnitt ), optimering (avsnitt ) och infrastruktur (avsnitt ) som används vid förträning av modellerna. 4.1 4.2 4.3 4.4 4.1 Tvåfasig träning Granite Code-modeller tränas på 3,5T till 4,5T tokens av koddata och naturliga språkdata relaterade till kod. Data tokeniseras via byte pair encoding (BPE, ( , )), med samma tokenizer som StarCoder ( , ). Följande ( , ; , ), använder vi högkvalitativ data med två faser av träning enligt följande. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Under fas 1 tränas både 3B och 8B-modeller för 4 biljoner tokens av koddata bestående av 116 språk. 20B-parametrarmodellen tränas på 3 biljoner tokens kod. 34B-modellen tränas på 1,4T tokens efter djupuppskalningen som görs på 1,6T-kontrollpunkten av 20B-modellen. Fas 1 (endast kodträning) • : I fas 2 inkluderar vi ytterligare högkvalitativ publikt tillgänglig data från olika domäner, inklusive tekniska, matematiska och webbdokument, för att ytterligare förbättra modellens prestanda i resonemang och problemlösningsförmåga, vilka är väsentliga för kodgenerering. Vi tränar alla våra modeller för 500B tokens (80% kod och 20% språkdata) i fas 2-träning. Fas 2 (kod + språkträning) 4.2 Träningsmål För träning av alla våra modeller använder vi målet för kausal språkmodellering och Fill-In-the-Middle (FIM) ( , ). FIM-målet har till uppgift att förutsäga insatta tokens med givet sammanhang och efterföljande text. Vi tränar våra modeller att arbeta med både PSM (Prefix-Suffix-Middle) och SPM (Suffix-Prefix-Middle) lägen, med relevanta formateringskontrolltokens, samma som StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a Den övergripande förlusten beräknas som en viktad kombination av de 2 målen: Vi sätter empiriskt = 0,5 under träning och finner att detta fungerar bra i praktiken och leder till SOTA-prestanda på både kodkomplettering och kodinfillningsuppgifter. Det bör noteras att FIM-målet endast används under förträning, men vi släpper det under instruktionsfinjustering, dvs. vi sätter = 1. α α 4.3 Optimering Vi använder AdamW-optimeraren ([Kingma & Ba](#_bookmark80), [2017](#_bookmark80)) med β1 = 0,9, β2 = 0,95 och viktnedbrytning på 0,1 för att träna alla våra Granite-kodmodeller. För fas-1 förträning följer inlärningshastigheten en cosinusplan som börjar från 3 10−4 och avtar till 3 10−5 med ett initialt linjärt uppvärmningssteg på 2k iterationer. För fas-2 förträning börjar vi från
