```html 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 de langage (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. La réalisation du plein potentiel des LLM de code nécessite un large éventail de capacités, 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 présentons 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 se compose de modèles de tailles allant de 3 à 34 milliards de paramètres, adaptés aux applications allant des tâches complexes de modernisation d'applications aux cas d'utilisation contraints par la mémoire sur appareil. 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 une gamme 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 autour ». Nous publions tous nos modèles Granite Code sous licence Apache 2.0 pour une utilisation tant en recherche qu'en 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 crucial 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 comprennent 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 été marquées par 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 est disponible aujourd'hui. Les modèles varient en taille, allant 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 l'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, il subsiste des lacunes importantes 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 grands, 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 allant au-delà des 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 utilisées dans 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 entraver 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'instructions affiné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étisés en 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 jetons 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 jetons avec un mélange soigneusement conçu de données de haute qualité provenant 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'instructions 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 synthétisés pour améliorer les capacités de suivi des instructions 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 menons 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 englobe 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, l'édition 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 montrent globalement de très bonnes performances sur tous les tailles de modèles et tous les benchmarks (dépassant souvent les modèles de code open source deux fois plus grands que Granite). À titre d'illustration, la figure (haut) montre une comparaison de Granite-8B-Code-Base avec d'autres LLM de base de code open source, y compris des LLM de base à usage général récents et performants comme Mistral ( , ) et LLama-3 ( , ) sur HumanEvalPack ( , ). Alors que CodeGemma et StarCoder2 donnent des résultats raisonnablement bons 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 surpasse 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 jetons significativement inférieur (4,5 T contre 7,5 T de jetons). Outre les modèles de base, les variantes d'instructions affinées de nos modèles Granite Code montrent également de bonnes performances sur HumanEvalPack, surpassant d'autres modèles d'instructions open source (de code), démontrant les avantages pour un plus large ensemble de tâches de codage avec des instructions en langage naturel (voir la figure (bas)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 De plus, comme le raisonnement est 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 surpasse 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 incluent : : Les modèles Granite Code atteignent des performances compétitives ou de pointe sur différents types de tâches liées au code, y compris la génération, l'explication, la correction, l'édition, la traduction de code, etc., démontrant leur capacité à résoudre diverses tâches de codage ; LLM de code polyvalent : 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 licence Apache 2.0. LLM de qualité professionnelle digne de confiance 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 de l'entraînement dans la section . La section fournit les détails sur l'ajustement 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 textuelles 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 pré-entraînement du code ont été extraites d'une combinaison de jeux de données disponibles publiquement tels que Github Code Clean , StarCoderdata , et des dépôts de code publics supplémentaires et des problèmes de GitHub. Nous filtrons les données brutes pour conserver une liste de 116 langages de programmation sur 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) sauf pour le 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 représente 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 engagés dans 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 comprenant à la fois la déduplication exacte et floue pour supprimer les documents ayant un contenu de code (quasi) identique dans 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 présenter de légères variations et ainsi de déséquilibrer 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 groupe et annoter les documents sauf un comme doublons sur la base 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, Malware Pour réduire la probabilité que les modèles génèrent un langage haineux, abusif ou grossier (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 nous faisons des efforts diligents pour anonymiser les informations personnelles identifiables (PII) de l'ensemble d'entraînement. Plus précisément, 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 jetons 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 analysons également nos jeux 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 textuelles de haute qualité disponibles publiquement 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 comprennent 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'ajustement d'instructions (FLAN ; ( ), HelpSteer ( , )). Nous ne dédupliquons pas ces jeux de données textuelles 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 tailles variables basés sur l'architecture décodeur transformateur ( , ). Les hyperparamètres du modèle pour ces modèles sont donnés dans le tableau . Pour toutes les architectures de modèles, nous utilisons la pré-normalisation ( , ) : normalisation appliquée à l'entrée des blocs attention et MLP. Vaswani et al. 2017 1 Xiong et al. 2020 : Le modèle le plus petit de la famille de 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 jetons. 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 à celle du 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 la performance 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 jetons. 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 en aval efficace. 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 jetons. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Pour entraîner le modèle 34B, nous suivons l'approche de pour la mise à l'échelle en profondeur du modèle 20B. Plus précisément, 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 mise à l'échelle en profondeur, nous observons que la baisse de performance par rapport au modèle 20B est très faible, contrairement à ce qu'observent . Cette performance est récupérée assez rapidement après avoir continué le pré-entraînement du modèle 34B mis à l'échelle. Similairement au 20B, nous utilisons un contexte de 8192 jetons 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 jetons de données de code et de jeux de données textuelles liés au code. Les données sont tokenisées via le codage par paires d'octets (BPE, ( , )), en utilisant le même tokenizer que StarCoder ( , ). En suivant ( , ; , ), 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 jetons de données de code comprenant 116 langues. Le modèle de 20B paramètres est entraîné sur 3 billions de jetons de code. Le modèle 34B est entraîné sur 1,4 T de jetons après la mise à l'échelle en profondeur qui est effectuée sur le point de contrôle 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 pour la génération de code. Nous entraînons tous nos modèles sur 500 milliards de jetons (80 % de code et 20 % de données textuelles) lors de l'entraînement de phase 2. 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 consiste à prédire les jetons insérés avec le contexte donné et le texte suivant. Nous entraînons nos modèles à travailler avec les modes PSM (Prefix-Suffix-Middle) et SPM (Suffix-Prefix-Middle), avec des jetons de contrôle de formatage pertinents, tout 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 réglons empiriquement = 0,5 pendant l'entraînement et constatons 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 uniquement utilisé pendant le pré-entraînement, mais nous le supprimons pendant l'ajustement des instructions, c'est-à-dire que nous définissons = 1. α α 4.3 Optimisation Nous utilisons l'optimiseur AdamW ([Kingma & Ba](#_bookmark80), [2017](#_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 partant de 3 10−4 et diminuant jusqu'à 3 10−5 avec une étape initiale de préchauffage linéaire de 2k itérations. Pour le pré-entraînement de phase 2, nous commençons à partir de 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 jetons 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 une version Dao et al. 2022 Dao 2023 la bibliothèque Apex de NVIDIA
