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 Résumé Les grands modèles linguistiques (LLM) entraînés sur du code révolutionnent le processus de développement logiciel. De plus en plus, les LLM de code sont intégrés dans les environnements de développement logiciel pour améliorer la productivité des programmeurs humains, et les agents basés sur les LLM commencent à montrer des promesses pour gérer des tâches complexes de manière autonome. Pour réaliser le plein potentiel des LLM de code, un large éventail de capacités est nécessaire, notamment la génération de code, la correction de bugs, l'explication et la documentation du code, la maintenance des dépôts, et plus encore. Dans ce travail, nous introduisons la série Granite de modèles de code uniquement décodeurs pour les tâches génératives de code, entraînés avec du code écrit dans 116 langages de programmation. La famille de modèles Granite Code comprend des modèles allant de 3 à 34 milliards de paramètres, adaptés aux applications allant de tâches complexes de modernisation d'applications aux cas d'utilisation sur appareil contraints en mémoire. L'évaluation sur un ensemble complet de tâches démontre que les modèles Granite Code atteignent constamment des performances de pointe parmi les LLM de code open source disponibles. La famille de modèles Granite Code a été optimisée pour les flux de travail de développement logiciel d'entreprise et fonctionne bien sur un éventail de tâches de codage (par exemple, génération, correction et explication de code), ce qui en fait un modèle de code polyvalent « tout-en-un ». Nous publions tous nos modèles Granite Code sous licence Apache 2.0 pour un usage tant en recherche que commercial. https://github.com/ibm-granite/granite-code-models 1 Introduction Au cours des dernières décennies, le logiciel s'est tissé dans le tissu de tous les aspects de notre société. Alors que la demande de développement logiciel augmente, il est plus critique que jamais d'augmenter la productivité du développement logiciel, et les LLM offrent une voie prometteuse pour augmenter les programmeurs humains. Les cas d'utilisation d'entreprise importants pour les LLM dans la productivité du développement logiciel incluent la génération de code, l'explication de code, la correction de code, la génération de tests unitaires et de documentation, la modernisation d'applications, la détection de vulnérabilités, la traduction de code, et plus encore. Ces dernières années ont vu des progrès rapides dans la capacité des LLM à générer et manipuler du code, et une gamme de modèles aux capacités de codage impressionnantes sont disponibles aujourd'hui. Les modèles varient en taille de quelques milliards de paramètres (par exemple, Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), etc.) à des centaines de milliards : DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), et varient dans la généralité de leur utilisation prévue, certains modèles visant à couvrir une gamme d'utilisations au-delà du code, tandis que d'autres se concentrent principalement sur les tâches liées au codage (par exemple, StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), et CodeGemma (CodeGemma Team et al., 2024)). Cependant, des lacunes importantes subsistent dans le domaine actuel des LLM pour le code, en particulier dans le contexte du développement logiciel d'entreprise. Premièrement, bien que les LLM généralistes très volumineux puissent atteindre d'excellentes performances de codage, leur taille les rend coûteux à déployer. Les modèles plus petits axés sur le code ( , ; , ; , ; , ; , ) peuvent atteindre d'excellentes performances de génération de code dans un package plus petit et plus flexible, mais les performances dans les tâches de codage au-delà de la génération (par exemple, la correction et l'explication) peuvent être inférieures aux performances de génération de code. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 Dans de nombreux contextes d'entreprise, l'adoption des LLM de code peut être compliquée par des facteurs autres que les performances des modèles. Par exemple, même les modèles ouverts sont parfois entachés d'un manque de transparence concernant les sources de données et les méthodes de traitement des données qui ont été utilisées pour entraîner le modèle, ce qui peut éroder la confiance dans les modèles dans des contextes critiques et réglementés. De plus, les conditions de licence des LLM ouverts actuels peuvent grever et compliquer la capacité d'une entreprise à utiliser un modèle. Nous présentons ici les modèles Granite Code, une série de LLM de code très performants, conçus pour prendre en charge le développement logiciel d'entreprise dans un large éventail de tâches de codage. Les modèles Granite Code comportent deux variantes principales que nous publions en quatre tailles différentes (3B, 8B, 20B et 34B) : modèles de base pour les tâches liées au code ; Granite Code Base : modèles d'instruction fine-tunés à l'aide d'une combinaison de commits Git associés à des instructions humaines et de jeux de données d'instructions de code synthétiques open source. Granite Code Instruct : Les modèles de base de la série ont été entraînés à partir de zéro avec une stratégie d'entraînement en deux phases. En phase 1, notre modèle est entraîné sur 3 à 4 billions de tokens provenant de 116 langages de programmation, assurant une compréhension complète des langages de programmation et de la syntaxe. En phase 2, notre modèle est entraîné davantage sur 500 milliards de tokens avec un mélange soigneusement conçu de données de haute qualité issues des domaines du code et du langage naturel pour améliorer la capacité de raisonnement du modèle. Nous utilisons l'objectif de modélisation du langage non supervisé pour entraîner les modèles de base dans les deux phases d'entraînement. Les modèles d'instruction sont dérivés en affinant davantage les modèles de base entraînés ci-dessus sur une combinaison d'une variante filtrée de CommitPack ( , ), de jeux de données d'instructions en langage naturel (OASST ( , ), HelpSteer ( , )) et de jeux de données mathématiques open source (MathInstruct ( , ) et MetaMathQA ( , )), y compris des jeux de données de code générés synthétiquement pour améliorer les capacités d'instruction et de raisonnement. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Nous procédons à des évaluations approfondies de nos LLM de code sur un ensemble complet de benchmarks, y compris HumanEvalPack ( , ), MBPP+ ( , ; , ), RepoBench ( , ), ReCode ( , ), et plus encore. Cet ensemble de benchmarks couvre de nombreux types de tâches de codage au-delà de la simple synthèse de code en Python, par exemple, la correction de code, l'explication de code, la modification de code, la traduction de code, etc., dans la plupart des langages de programmation majeurs (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 Nos conclusions révèlent que parmi les modèles open source, les modèles Granite Code affichent globalement des performances très solides sur toutes les tailles de modèles et tous les benchmarks (surperformant souvent d'autres modèles de code open source deux fois plus grands que Granite). À titre d'illustration, la figure (en haut) montre une comparaison de Granite-8B-Code-Base avec d'autres LLM de code de base open source, y compris des LLM de base généralistes performants récents comme Mistral ( , ) et LLama-3 ( , ) sur HumanEvalPack ( , ). Bien que CodeGemma et StarCoder2 obtiennent des résultats raisonnables en génération de code, ils obtiennent des résultats significativement moins bons sur les variantes de correction et d'explication de code de HumanEvalPack. En moyenne, Granite-8B-Code-Base surperforme le modèle CodeGemma-8B le plus compétitif de près de 12 points sur HumanEvalPack (33,2 % contre 21,3 %), malgré un entraînement sur un nombre de tokens significativement inférieur (4,5 T contre 7,5 T de tokens). Outre les modèles de base, les variantes d'instructions de nos modèles Granite Code affichent également de solides performances sur HumanEvalPack, surpassant d'autres modèles d'instructions (de code) open source, démontrant les avantages pour un plus large éventail de tâches de codage avec des instructions en langage naturel (voir figure (en bas)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 De plus, le raisonnement étant essentiel pour résoudre des questions et des tâches complexes, nous testons également notre modèle Granite-8B-Code-Base sur six benchmarks mathématiques, dont MATH ( , ), GSM8K ( , ) et la résolution de problèmes avec accès à des outils informatiques, où notre modèle Granite 8B obtient de meilleures performances par rapport à la plupart des LLM de pointe de 7B ou 8B. Par exemple, Granite-8B-Code-Base surperforme Llama-3-8B-Base d'environ 12 points sur GSM8K et d'environ 6 points sur MATH (voir tableau ). Cobbe et al. 2021 Cobbe et al. 2021 15 Les principaux avantages des modèles Granite Code comprennent : : Les modèles Granite Code obtiennent des performances compétitives ou de pointe sur différents types de tâches liées au code, notamment la génération, l'explication, la correction, la modification, la traduction de code, etc., démontrant leur capacité à résoudre diverses tâches de codage ; LLM de code tout-en-un : Tous nos modèles sont entraînés sur des données autorisées collectées conformément aux principes d'éthique de l'IA d'IBM et guidés par l'équipe juridique d'entreprise d'IBM pour une utilisation professionnelle digne de confiance. Tous les modèles Granite Code sont publiés sous la licence Apache 2.0. LLM digne de confiance de qualité professionnelle 1 Nous décrivons notre pipeline complet de collecte, de filtrage et de prétraitement des données dans la section . La section décrit les détails de l'architecture du modèle, suivis des détails d'entraînement dans la section . La section fournit les détails sur le réglage fin des instructions, et la section décrit les expériences et les résultats comparant les modèles Granite Code avec d'autres LLM open source. 2 3 4 5 6 2 Collecte de données Dans cette section, nous décrivons le processus d'exploration et de filtrage (Sec. ), de déduplication (Sec. ), de filtrage HAP/PII (Sec. ) utilisés pour préparer les données de code pour l'entraînement du modèle. Nous fournissons également un aperçu des données en langage naturel de haute qualité utilisées pour améliorer la compréhension du langage et les compétences en raisonnement mathématique du modèle. 2.1 2.2 2.3 2.1 Exploration et filtrage des données Les données de code de pré-entraînement ont été extraites d'une combinaison de jeux de données publiquement disponibles tels que Github Code Clean , StarCoderdata , et de dépôts et problèmes de code publics supplémentaires de GitHub. Nous filtrons les données brutes pour conserver une liste de 116 langages de programmation parmi plus de 300 langues, comme indiqué dans l'annexe . L'attribution des données aux langages de programmation est effectuée uniquement sur la base de l'extension de fichier, similaire à StarCoder ( , ). Après le filtrage linguistique, nous appliquons quatre règles de filtrage clés pour éliminer le code de moindre qualité ( , ) : (1) supprimer les fichiers contenant moins de 25 % de caractères alphabétiques, (2) à l'exception du langage XSLT, filtrer les fichiers où la chaîne « <?xml version=” apparaît dans les 100 premiers caractères, (3) pour les fichiers HTML, ne conserver que les fichiers où le texte visible constitue au moins 20 % du code HTML et a une longueur minimale de 100 caractères, (4) pour les fichiers JSON et YAML, ne conserver que les fichiers dont le nombre de caractères est compris entre 50 et 5000 caractères. Nous filtrons également les problèmes GitHub à l'aide d'un ensemble de métriques de qualité qui incluent la suppression du texte généré automatiquement, le filtrage des problèmes non anglais, l'exclusion des commentaires des bots et l'utilisation du nombre d'utilisateurs participant à la conversation comme indicateur de qualité. Nous annotons également chaque fichier de code avec des informations de licence associées au dépôt respectif, trouvées via les API GitHub, et ne conservons que les fichiers avec des licences permissives pour l'entraînement du modèle. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Déduplication exacte et floue Nous adoptons une stratégie de déduplication agressive, incluant la déduplication exacte et floue, pour supprimer les documents ayant un contenu de code (quasi) identique de notre ensemble d'entraînement. Pour la déduplication exacte, nous calculons d'abord le hachage SHA256 sur le contenu du document et supprimons les enregistrements ayant des hachages identiques. Après la déduplication exacte, nous appliquons la déduplication floue dans le but de supprimer les fichiers de code qui peuvent avoir de légères variations et ainsi de débiaiser davantage les données. Nous appliquons une méthode en deux étapes pour cela : (1) calculer les MinHashes de tous les documents, puis utiliser le hachage localement sensible (LSH) pour regrouper les documents en fonction de leurs empreintes MinHash, (2) mesurer la similarité Jaccard entre chaque paire de documents dans le même compartiment et annoter les documents, à l'exception d'un, comme doublons en fonction d'un seuil de similarité de 0,7. Nous appliquons ce processus de quasi-déduplication à tous les langages de programmation, y compris les problèmes GitHub, pour améliorer la richesse et la diversité de l'ensemble de données d'entraînement. 2.3 Filtrage HAP, PII, logiciels malveillants Pour réduire la probabilité que les modèles génèrent un langage haineux, abusif ou profane (HAP), nous faisons des efforts diligents pour filtrer le contenu HAP de l'ensemble d'entraînement. Nous créons d'abord un dictionnaire de mots-clés HAP, puis nous annotons chaque document de code avec le nombre d'occurrences de ces mots-clés dans le contenu, y compris les commentaires. Nous filtrons les documents qui dépassent le seuil HAP, calculé sur la base d'une analyse distributionnelle ainsi que d'une inspection manuelle des fichiers de code. De plus, pour protéger la vie privée, nous suivons StarCoder ( , ) et faisons des efforts diligents pour anonymiser les informations personnelles identifiables (PII) de l'ensemble d'entraînement. Spécifiquement, nous utilisons le modèle StarPII pour détecter les adresses IP, les clés, les adresses e-mail, les noms, les noms d'utilisateur et les mots de passe trouvés dans le contenu. L'étape d'anonymisation remplace le texte PII par les tokens correspondants NAME , EMAIL , KEY , PASSWORD et modifie l'adresse IP avec une adresse IP générée synthétiquement, comme chez Li et al. (2023a). Nous scannons également nos ensembles de données à l'aide de pour identifier et supprimer les instances de logiciels malveillants dans le code source. Li et al. 2023a 4 2.4 Jeux de données en langage naturel En plus de collecter des données de code pour l'entraînement du modèle, nous avons organisé plusieurs jeux de données en langage naturel de haute qualité publiquement disponibles pour améliorer la maîtrise du modèle en compréhension du langage et en raisonnement mathématique. Les jeux de données représentatifs de cette catégorie incluent des documents web (Stackexchange, CommonCrawl), du texte web mathématique (OpenWeb-Math ; ( ), StackMathQA ; ( )), du texte académique (Arxiv, Wikipedia), et des jeux de données d'instruction tuning (FLAN ; ( ), HelpSteer ( , )). Nous ne dédupliquons pas ces jeux de données en langage naturel déjà prétraités. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Architecture du modèle Nous entraînons une série de modèles de code de différentes tailles basés sur l'architecture de décodeur transformeur ( , ). Les hyperparamètres du modèle pour ces modèles sont donnés dans le tableau . Pour toutes les architectures de modèle, nous utilisons la pré-normalisation ( , ) : normalisation appliquée à l'entrée des blocs d'attention et MLP. Vaswani et al. 2017 1 Xiong et al. 2020 : Le plus petit modèle de la famille des modèles Granite-code est entraîné avec un embedding RoPE ( , ) et une attention multi-têtes ( , ). Ce modèle utilise la fonction d'activation swish ( , ) avec GLU ( , ) pour le MLP, également communément appelé swiglu. Pour la normalisation, nous utilisons RMSNorm ( , ) car il est plus efficace en termes de calcul que LayerNorm ( , ). Le modèle 3B est entraîné avec une longueur de contexte de 2048 tokens. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : Le modèle 8B a une architecture similaire au modèle 3B, à l'exception de l'utilisation de l'attention à requêtes groupées (GQA) ( , ). L'utilisation de GQA offre un meilleur compromis entre les performances du modèle et l'efficacité de l'inférence à cette échelle. Nous entraînons le modèle 8B avec une longueur de contexte de 4096 tokens. 8B Ainslie et al. 2023 : Le modèle de code 20B est entraîné avec des embeddings de position absolus appris. Nous utilisons l'attention multi-requêtes ( , ) pendant l'entraînement pour une inférence efficace en aval. Pour le bloc MLP, nous utilisons la fonction d'activation GELU ( , ). Pour normaliser les activations, nous utilisons LayerNorm ( , ). Ce modèle est entraîné avec une longueur de contexte de 8192 tokens. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Pour entraîner le modèle 34B, nous suivons l'approche de pour la montée en profondeur du modèle 20B. Spécifiquement, nous dupliquons d'abord le modèle de code 20B avec 52 couches, puis nous supprimons les 8 dernières couches du modèle d'origine et les 8 premières couches de son duplicata pour former deux modèles. 34B Kim et al. Enfin, nous concaténons les deux modèles pour former le modèle Granite-34B-Code avec 88 couches (voir figure pour une illustration). Après la montée en profondeur, nous observons que la baisse de performance par rapport au modèle 20B est très faible, contrairement à ce qui est observé par . Cette performance est récupérée assez rapidement après la poursuite du pré-entraînement du modèle 34B mis à l'échelle. Similairement au 20B, nous utilisons un contexte de 8192 tokens pendant le pré-entraînement. 2 Kim et al. 4 Pré-entraînement Dans cette section, nous fournissons des détails sur l'entraînement en deux phases (Sec. ), les objectifs d'entraînement (Sec. ), l'optimisation (Sec. ) et l'infrastructure (Sec. ) utilisés dans le pré-entraînement des modèles. 4.1 4.2 4.3 4.4 4.1 Entraînement en deux phases Les modèles Granite Code sont entraînés sur 3,5 T à 4,5 T de tokens de données de code et de jeux de données de langage naturel liés au code. Les données sont tokenisées par encodage par paires d'octets (BPE, ( , )), en utilisant le même tokenizer que StarCoder ( , ). Suite à ( , ; , ), nous utilisons des données de haute qualité avec deux phases d'entraînement comme suit. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Pendant la phase 1, les modèles 3B et 8B sont entraînés sur 4 billions de tokens de données de code comprenant 116 langues. Le modèle de 20 milliards de paramètres est entraîné sur 3 billions de tokens de code. Le modèle 34B est entraîné sur 1,4 T de tokens après la montée en profondeur qui est effectuée sur le checkpoint de 1,6 T du modèle 20B. Phase 1 (entraînement uniquement sur le code) • : En phase 2, nous incluons des données supplémentaires de haute qualité disponibles publiquement provenant de divers domaines, y compris des documents techniques, mathématiques et web, pour améliorer davantage les performances du modèle en matière de raisonnement et de résolution de problèmes, qui sont essentiels à la génération de code. Nous entraînons tous nos modèles sur 500 milliards de tokens (80 % de code et 20 % de données linguistiques) pendant la phase 2 d'entraînement. Phase 2 (entraînement code + langage) 4.2 Objectif d'entraînement Pour l'entraînement de tous nos modèles, nous utilisons l'objectif de modélisation du langage causal et l'objectif Fill-In-the-Middle (FIM) ( , ). L'objectif FIM est de prédire les tokens insérés avec le contexte donné et le texte suivant. Nous entraînons nos modèles à travailler avec les deux modes PSM (Prefix-Suffix-Middle) et SPM (Suffix-Prefix-Middle), avec des tokens de contrôle de formatage pertinents, comme StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a La perte globale est calculée comme une combinaison pondérée des 2 objectifs : Nous avons empiriquement défini = 0,5 pendant l'entraînement et constaté que cela fonctionne bien en pratique, conduisant à des performances SOTA sur les tâches de complétion de code et d'insertion de code. Il convient de noter que l'objectif FIM est utilisé uniquement pendant le pré-entraînement, cependant nous le supprimons lors du réglage fin des instructions, c'est-à-dire que nous définissons = 1. α α 4.3 Optimisation Nous utilisons l'optimiseur AdamW ([Kingma & Ba](#_bookmark80),(#_bookmark80)) avec β1 = 0,9, β2 = 0,95 et une décroissance de poids de 0,1 pour entraîner tous nos modèles de code Granite. Pour le pré-entraînement de phase 1, le taux d'apprentissage suit un calendrier cosinus commençant à 3 10−4 qui décroît à 3 10−5 avec une étape de préchauffage linéaire initiale de 2k itérations. Pour le pré-entraînement de phase 2, nous commençons à 3 10−4 (1,5 10−4 pour les modèles 20B et 34B) et adoptons un calendrier de décroissance exponentielle pour le réduire à 10 % du taux d'apprentissage initial. Nous utilisons une taille de lot de 4M-5M tokens en fonction de la taille du modèle pendant les deux phases de pré-entraînement. Pour accélérer l'entraînement, nous utilisons FlashAttention 2 ( , ; , ), le noyau de layernorm persistant, le noyau Fused RMSNorm (selon le modèle) et le noyau Fused Adam disponibles dans . Nous utilisons un fork personnalisé de Megatron-LM de NVIDIA ( , Dao et al. 2022 Dao 2023 la bibliothèque Apex de NVIDIA Shoeybi et al.
