```html Autores: 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 Resumen Los Modelos de Lenguaje Grandes (LLM) entrenados en código están revolucionando el proceso de desarrollo de software. Cada vez más, los LLM de código se están integrando en entornos de desarrollo de software para mejorar la productividad de los programadores humanos, y los agentes basados en LLM están comenzando a mostrar promesas para manejar tareas complejas de forma autónoma. La realización del potencial completo de los LLM de código requiere una amplia gama de capacidades, que incluyen generación de código, corrección de errores, explicación y documentación de código, mantenimiento de repositorios y más. En este trabajo, presentamos la serie Granite de modelos de código de solo decodificador para tareas generativas de código, entrenados con código escrito en 116 lenguajes de programación. La familia de modelos Granite Code consta de modelos que varían en tamaño desde 3 hasta 34 mil millones de parámetros, adecuados para aplicaciones que van desde tareas complejas de modernización de aplicaciones hasta casos de uso con memoria limitada en el dispositivo. La evaluación en un conjunto completo de tareas demuestra que los modelos Granite Code alcanzan consistentemente un rendimiento de última generación entre los LLM de código de código abierto disponibles. La familia de modelos Granite Code se optimizó para los flujos de trabajo de desarrollo de software empresarial y funciona bien en una variedad de tareas de codificación (por ejemplo, generación, corrección y explicación de código), lo que la convierte en un modelo de código versátil "todo terreno". Liberamos todos nuestros modelos Granite Code bajo una licencia Apache 2.0 para uso tanto en investigación como comercial. https://github.com/ibm-granite/granite-code-models 1 Introducción En las últimas décadas, el software se ha tejido en la estructura de cada aspecto de nuestra sociedad. A medida que la demanda de desarrollo de software se dispara, es más crítico que nunca aumentar la productividad del desarrollo de software, y los LLM proporcionan un camino prometedor para aumentar a los programadores humanos. Los casos de uso empresariales prominentes para los LLM en la productividad del desarrollo de software incluyen la generación de código, la explicación de código, la corrección de código, la generación de pruebas unitarias y documentación, la modernización de aplicaciones, la detección de vulnerabilidades, la traducción de código y más. Los últimos años han visto un rápido progreso en la capacidad de los LLM para generar y manipular código, y hoy en día hay disponibles una variedad de modelos con impresionantes capacidades de codificación. Los modelos varían en tamaño desde miles de millones de parámetros de un solo dígito (por ejemplo, Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), etc.) hasta cientos de miles de millones: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), y varían en la generalidad del uso previsto, con algunos modelos que apuntan a cubrir una variedad de usos fuera del código, mientras que otros se centran principalmente en tareas relacionadas con la codificación (por ejemplo, StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), y CodeGemma (CodeGemma Team et al., 2024)). Sin embargo, persisten brechas importantes en el campo actual de los LLM para código, especialmente en el contexto del desarrollo de software empresarial. Primero, si bien los LLM generalistas muy grandes pueden lograr un excelente rendimiento de codificación, su tamaño los hace costosos de implementar. Los modelos de código más pequeños ( , ; , ; , ; , ; , ) pueden lograr un excelente rendimiento de generación de código en un paquete más pequeño y flexible, pero el rendimiento en tareas de codificación más allá de la generación (por ejemplo, corrección y explicación) puede quedarse atrás del rendimiento de generación de código. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 En muchos contextos empresariales, la adopción de LLM de código puede complicarse aún más por factores más allá del rendimiento de los modelos. Por ejemplo, incluso los modelos abiertos a veces se ven plagados por la falta de transparencia sobre las fuentes de datos y los métodos de procesamiento de datos que se utilizaron en el modelo, lo que puede erosionar la confianza en los modelos en contextos críticos y regulados. Además, los términos de licencia en los LLM abiertos actuales pueden obstaculizar y complicar la capacidad de una empresa para utilizar un modelo. Aquí, presentamos los modelos Granite Code, una serie de LLM de código altamente capaces, diseñados para admitir el desarrollo de software empresarial en una amplia gama de tareas de codificación. Los modelos Granite Code tienen dos variantes principales que lanzamos en cuatro tamaños diferentes (3B, 8B, 20B y 34B): modelos base fundamentales para tareas relacionadas con el código; Granite Code Base: modelos que siguen instrucciones, ajustados utilizando una combinación de commits de Git emparejados con instrucciones humanas y conjuntos de datos de instrucciones de código sintético de código abierto. Granite Code Instruct: Los modelos base de la serie se han entrenado desde cero con una estrategia de entrenamiento en dos fases. En la fase 1, nuestro modelo se entrena en 3 a 4 billones de tokens de código escrito en 116 lenguajes de programación, lo que garantiza una comprensión integral de los lenguajes de programación y la sintaxis. En la fase 2, nuestro modelo se entrena aún más en 500 mil millones de tokens con una mezcla cuidadosamente diseñada de datos de alta calidad de dominios de código y lenguaje natural para mejorar la capacidad de razonamiento del modelo. Utilizamos el objetivo de modelado de lenguaje no supervisado para entrenar los modelos base en ambas fases de entrenamiento. Los modelos de instrucción se derivan del ajuste fino adicional de los modelos base entrenados anteriores en una combinación de una variante filtrada de CommitPack ( , ), conjuntos de datos de seguimiento de instrucciones en lenguaje natural (OASST ( , ), HelpSteer ( , )) y conjuntos de datos matemáticos de código abierto (MathInstruct ( , ) y MetaMathQA ( , )), incluidos conjuntos de datos de código generados sintéticamente para mejorar el seguimiento de instrucciones y las capacidades de razonamiento. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Realizamos evaluaciones exhaustivas de nuestros LLM de código en un conjunto completo de puntos de referencia, que incluyen HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ), y más. Este conjunto de puntos de referencia abarca muchos tipos diferentes de tareas de codificación más allá de la simple síntesis de código en Python, por ejemplo, corrección de código, explicación de código, edición de código, traducción de código, etc., en la mayoría de los lenguajes de programación principales (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 Nuestros hallazgos revelan que entre los modelos de código abierto, los modelos Granite Code muestran en general un rendimiento muy sólido en todos los tamaños de modelos y puntos de referencia (a menudo superando a otros modelos de código de código abierto que son el doble de grandes en comparación con Granite). A modo de ilustración, la figura (arriba) muestra una comparación de Granite-8B-Code-Base con otros LLM base de código de código abierto, incluidos LLM base de propósito general de alto rendimiento recientes como Mistral ( , ) y LLama-3 ( , ) en HumanEvalPack ( , ). Si bien CodeGemma y StarCoder2 funcionan razonablemente bien en la generación de código, funcionan significativamente peor en las variantes de corrección y explicación de código de HumanEvalPack. En promedio, Granite-8B-Code-Base supera al modelo CodeGemma-8B más competitivo en casi 12 puntos en HumanEvalPack (33.2% frente a 21.3%), a pesar de haber sido entrenado con un número significativamente menor de tokens (4.5T frente a 7.5T tokens). Además de los modelos base, las variantes de instrucción ajustadas de nuestros modelos Granite Code también muestran un rendimiento sólido en HumanEvalPack, superando a otros modelos de instrucción (de código) de código abierto, lo que demuestra los beneficios para un conjunto más amplio de tareas de codificación con instrucciones en lenguaje natural (ver figura (abajo)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Además, dado que el razonamiento es fundamental para resolver preguntas y tareas complejas, también probamos nuestro modelo Granite-8B-Code-Base en seis puntos de referencia matemáticos, incluidos MATH ( , ), GSM8K ( , ) y resolución de problemas con acceso a herramientas computacionales, donde nuestro modelo Granite 8B logra un mejor rendimiento en comparación con la mayoría de los LLM de última generación de 7B u 8B. Por ejemplo, Granite-8B-Code-Base supera a Llama-3-8B-Base en aproximadamente 12 puntos en GSM8K y aproximadamente 6 puntos en MATH (ver tabla ). Cobbe et al. 2021 Cobbe et al. 2021 15 Las ventajas clave de los modelos Granite Code incluyen: : Los modelos Granite Code logran un rendimiento competitivo o de última generación en diferentes tipos de tareas relacionadas con el código, incluida la generación, explicación, corrección, edición, traducción de código, etc., lo que demuestra su capacidad para resolver diversas tareas de codificación; LLM de Código Todoterreno : Todos nuestros modelos se entrenan con datos permitidos por licencia recopilados siguiendo los principios de ética de IA de IBM y guiados por el equipo legal corporativo de IBM para un uso empresarial confiable. Todos los modelos Granite Code se publican bajo la licencia Apache 2.0. LLM Confiable de Grado Empresarial 1 Describimos nuestro pipeline completo de recopilación, filtrado y preprocesamiento de datos en la sección . La sección describe los detalles de la arquitectura del modelo, seguidos de los detalles de entrenamiento en la Sección . La sección proporciona los detalles sobre el ajuste de instrucciones, y la sección describe los experimentos y los resultados que comparan los modelos Granite Code con otros LLM de código abierto. 2 3 4 5 6 2 Recopilación de Datos En esta sección, describimos el proceso de rastreo y filtrado (Sec. ), deduplicación (Sec. ), filtrado HAP/PII (Sec. ) utilizados para preparar los datos de código para el entrenamiento del modelo. También proporcionamos una descripción general de los datos de lenguaje natural de alta calidad utilizados para mejorar la comprensión del lenguaje y las habilidades de razonamiento matemático del modelo. 2.1 2.2 2.3 2.1 Rastreo y Filtrado de Datos Los datos de código de preentrenamiento se obtuvieron de una combinación de conjuntos de datos disponibles públicamente como Github Code Clean , StarCoderdata , y repositorios de código público adicional y problemas de GitHub. Filtramos los datos brutos para retener una lista de 116 lenguajes de programación de más de 300 lenguajes, como se enumera en el Apéndice . La asignación de datos a lenguajes de programación se realiza únicamente en función de la extensión del archivo, similar a StarCoder ( , ). Después de filtrar los idiomas, aplicamos cuatro reglas de filtrado clave para eliminar código de baja calidad ( , ): (1) eliminar archivos con menos del 25% de caracteres alfabéticos, (2) excepto para el idioma XSLT, filtrar archivos donde la cadena “<?xml version=” aparece dentro de los primeros 100 caracteres, (3) para archivos HTML, solo conservar archivos donde el texto visible constituya al menos el 20% del código HTML y tenga una longitud mínima de 100 caracteres, (4) para archivos JSON y YAML, solo conservar archivos que tengan un recuento de caracteres entre 50 y 5000 caracteres. También anotamos cada archivo de código con información de licencia asociada con el repositorio respectivo, encontrada a través de las API de Github y solo conservamos archivos con licencias permisivas para el entrenamiento del modelo. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Deduplicación Exacta y Difusa Adoptamos una estrategia de deduplicación agresiva que incluye deduplicación exacta y difusa para eliminar documentos que tienen contenido de código (casi) idéntico en nuestro conjunto de entrenamiento. Para la deduplicación exacta, primero calculamos el hash SHA256 sobre el contenido del documento y eliminamos los registros que tienen hashes idénticos. Después de la deduplicación exacta, aplicamos deduplicación difusa con el objetivo de eliminar archivos de código que pueden tener ligeras variaciones y, por lo tanto, sesgar aún más los datos. Aplicamos un método de dos pasos para esto: (1) calcular MinHashes de todos los documentos y luego utilizar el Hashing Sensible a la Localidad (LSH) para agrupar documentos según sus huellas dactilares MinHash, (2) medir la similitud de Jaccard entre cada par de documentos en el mismo grupo y anotar los documentos excepto uno como duplicados según un umbral de similitud de 0.7. Aplicamos este proceso de near-deduplicación a todos los lenguajes de programación, incluidos los problemas de GitHub, para mejorar la riqueza y diversidad del conjunto de datos de entrenamiento. 2.3 Filtrado HAP, PII, Malware Para reducir la probabilidad de generar lenguaje odioso, abusivo o profano (HAP) de los modelos, hacemos esfuerzos diligentes para filtrar el contenido HAP del conjunto de entrenamiento. Primero creamos un diccionario de palabras clave HAP y luego anotamos cada documento de código con el número de ocurrencias de dichas palabras clave en el contenido, incluidos los comentarios. Filtramos los documentos que exceden el umbral HAP, calculado en base a un análisis distributivo, así como a la inspección manual de los archivos de código. Además, para proteger la privacidad, seguimos a StarCoder ( , ) y hacemos esfuerzos diligentes para redactar información de identificación personal (PII) del conjunto de entrenamiento. Específicamente, utilizamos el modelo StarPII para detectar direcciones IP, claves, direcciones de correo electrónico, nombres, nombres de usuario y contraseñas que se encuentran en el contenido. El paso de redacción de PII reemplaza el texto PII con los tokens correspondientes NOMBRE, EMAIL, CLAVE, CONTRASEÑA y cambia la dirección IP por una dirección IP generada sintéticamente, como en Li et al. (2023a). También escaneamos nuestros conjuntos de datos utilizando para identificar y eliminar instancias de malware en el código fuente. Li et al. 2023a 4 2.4 Conjuntos de Datos de Lenguaje Natural Además de recopilar datos de código para el entrenamiento del modelo, curamos varios conjuntos de datos de lenguaje natural de alta calidad disponibles públicamente para mejorar la competencia del modelo en la comprensión del lenguaje y el razonamiento matemático. Los conjuntos de datos representativos en esta categoría incluyen documentos web (Stackexchange, CommonCrawl), texto web matemático (OpenWeb-Math; ( ), StackMathQA; ( )), texto académico (Arxiv, Wikipedia), y conjuntos de datos de ajuste de instrucciones (FLAN; ( ), HelpSteer ( , )). No deduplicamos estos conjuntos de datos de lenguaje natural ya preprocesados. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Arquitectura del Modelo Entrenamos una serie de modelos de código de tamaños variables basados en la arquitectura de decodificador transformer ( , ). Los hiperparámetros del modelo para estos modelos se dan en la Tabla . Para todas las arquitecturas de modelos, utilizamos pre-normalización ( , ): normalización aplicada a la entrada de los bloques de atención y MLP. Vaswani et al. 2017 1 Xiong et al. 2020 : El modelo más pequeño de la familia de modelos Granite-code se entrena con incrustación RoPE ( , ) y Atención Multi-Cabeza ( , ). Este modelo utiliza la función de activación swish ( , ) con GLU ( , ) para el MLP, también comúnmente conocido como swiglu. Para la normalización, utilizamos RMSNorm ( , ) ya que es computacionalmente más eficiente que LayerNorm ( , ). El modelo 3B se entrena con una longitud de contexto 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 : El modelo 8B tiene una arquitectura similar al modelo 3B con la excepción de usar Atención de Consulta Agrupada (GQA) ( , ). Usar GQA ofrece una mejor compensación entre el rendimiento del modelo y la eficiencia de inferencia a esta escala. Entrenamos el modelo 8B con una longitud de contexto de 4096 tokens. 8B Ainslie et al. 2023 : El modelo de código 20B se entrena con incrustaciones de posición absolutas aprendidas. Utilizamos Atención Multi-Consulta ( , ) durante el entrenamiento para una inferencia posterior eficiente. Para el bloque MLP, utilizamos la función de activación GELU ( , ). Para normalizar las activaciones, utilizamos LayerNorm ( , ). Este modelo se entrena con una longitud de contexto de 8192 tokens. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Para entrenar el modelo 34B, seguimos el enfoque de para la escalada en profundidad del modelo 20B. Específicamente, primero duplicamos el modelo de código 20B con 52 capas y luego eliminamos las últimas 8 capas del modelo original y las primeras 8 capas de su duplicado para formar dos modelos. 34B Kim et al. Finalmente, concatenamos ambos modelos para formar el modelo Granite-34B-Code con 88 capas (ver Figura para una ilustración). Después de la escalada en profundidad, observamos que la caída en el rendimiento en comparación con el modelo 20B es muy pequeña, a diferencia de lo observado por . Este rendimiento se recupera bastante rápido después de continuar el preentrenamiento del modelo 34B escalado. Similar al 20B, usamos un contexto de 8192 tokens durante el preentrenamiento. 2 Kim et al. 4 Preentrenamiento En esta sección, proporcionamos detalles sobre el entrenamiento en dos fases (Sec. ), objetivos de entrenamiento (Sec. ), optimización (Sec. ) e infraestructura (Sec. ) utilizados en el preentrenamiento de los modelos. 4.1 4.2 4.3 4.4 4.1 Entrenamiento en Dos Fases Los modelos Granite Code se entrenan con 3.5T a 4.5T de tokens de datos de código y conjuntos de datos de lenguaje natural relacionados con el código. Los datos se tokenizan mediante codificación de pares de bytes (BPE, ( , )), utilizando el mismo tokenizador que StarCoder ( , ). Siguiendo ( , ; , ), utilizamos datos de alta calidad con dos fases de entrenamiento como sigue. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Durante la fase 1, tanto los modelos 3B como 8B se entrenan con 4 billones de tokens de datos de código que comprenden 116 idiomas. El modelo de 20 mil millones de parámetros se entrena con 3 billones de tokens de código. El modelo 34B se entrena con 1.4T tokens después de la escalada en profundidad que se realiza en el checkpoint de 1.6T del modelo 20B. Fase 1 (entrenamiento solo de código) • : En la fase 2, incluimos datos adicionales de alta calidad disponibles públicamente de varios dominios, incluidos documentos técnicos, matemáticos y web, para mejorar aún más el rendimiento del modelo en habilidades de razonamiento y resolución de problemas, que son esenciales para la generación de código. Entrenamos todos nuestros modelos con 500 mil millones de tokens (80% de código y 20% de datos de lenguaje) en la fase 2 de entrenamiento. Fase 2 (entrenamiento de código + lenguaje) 4.2 Objetivo de Entrenamiento Para el entrenamiento de todos nuestros modelos, utilizamos el objetivo de modelado de lenguaje causal y el objetivo de Relleno en el Medio (FIM) ( , ). El objetivo FIM se encarga de predecir los tokens insertados con el contexto dado y el texto subsiguiente. Entrenamos nuestros modelos para que funcionen tanto en modos PSM (Prefijo-Sufijo-Medio) como SPM (Sufijo-Prefijo-Medio), con tokens de control de formato relevantes, al igual que StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a La pérdida general se calcula como una combinación ponderada de los 2 objetivos: Establecemos empíricamente = 0.5 durante el entrenamiento y encontramos que esto funciona bien en la práctica, lo que lleva a un rendimiento SOTA en tareas de completado de código y relleno de código. Cabe señalar que el objetivo FIM solo se utiliza durante el preentrenamiento; sin embargo, lo eliminamos durante el ajuste fino de instrucciones, es decir, establecemos = 1. α α 4.3 Optimización Utilizamos el optimizador AdamW ([Kingma & Ba](#_bookmark80), [2017](#_bookmark80)) con β1 = 0.9, β2 = 0.95 y decaimiento de peso de 0.1 para entrenar todos nuestros modelos de código Granite. Para el preentrenamiento de fase 1, la tasa de aprendizaje sigue un cronograma coseno que comienza desde 3 10−4 y decae a 3 10−5 con un paso inicial de calentamiento lineal de 2k iteraciones. Para el preentrenamiento de fase 2, comenzamos desde 3 10−4 (1.5 10−4 para los modelos 20B y 34B) y adoptamos un cronograma de decaimiento exponencial para reducirlo al 10% de la tasa de aprendizaje inicial. Utilizamos un tamaño de lote de 4M-5M tokens dependiendo del tamaño del modelo durante ambas fases de preentrenamiento. Para acelerar el entrenamiento, utilizamos FlashAttention 2 ( , ; , ), el kernel persistente de layernorm, el kernel Fused RMSNorm (dependiendo del modelo) y el kernel Fused Adam disponibles en la . Utilizamos una bifurcación personalizada de Megatron-LM de NVIDIA ( , ; , ) para el entrenamiento distribuido de todos nuestros modelos. Entrenamos con una mezcla de paralelismo 3D: paralelismo de tensor, paralelismo de pipeline y paralelismo de datos. También utilizamos paralelismo de secuencia ( , ) para reducir el consumo de memoria de activación de una longitud de contexto larga durante el entrenamiento. Utilizamos el optimizador distribuido de Megatron con entrenamiento de precisión mixta ( , ) en BF16 ( , ) con all-reduce de gradientes y acumulación de gradientes en FP32 para la estabilidad del entrenamiento. Dao et al. 2022 Dao 2023 biblioteca Apex de NVIDIA Shoeybi et al. 2019 Narayanan et al. 2021 Korthikanti et al. 2023 Micikevicius et al. 2018 Kalamkar et al. 2019 4.4 Infraestructura Entrenamos los modelos Granite Code utilizando los dos clústeres de supercomputación de IBM, Vela y Blue Vela, equipados con GPUs NVIDIA A100 y H100, respectivamente. En el clúster de GPU Vela A100, cada nodo tiene 2 procesadores Intel Xeon Scalable con 8 GPUs A
