[Procesamiento del lenguaje natural] [Modelo grande] BLOOM: un modelo multilingüe con 176B de parámetros y acceso abierto

BLOOM: Un modelo multilingüe de acceso abierto y parámetro 176B 《BLOOM: un modelo de lenguaje multilingüe de acceso abierto con parámetros 176B》

Dirección del artículo: https://arxiv.org/pdf/2211.05100.pdf

Blog relacionado
[Procesamiento del lenguaje natural] [Modelo grande] Análisis del código fuente de la estructura del modelo BLOOM (versión independiente)
[Procesamiento del lenguaje natural] [Modelo grande] Método de modelo grande de ajuste fino de recursos muy bajos Código de implementación LoRA y BLOOM-LORA
[Natural Procesamiento del lenguaje] [Modelo grande] Modelo grande de DeepMind Gopher
[Procesamiento del lenguaje natural] [Modelo grande] Chinchilla: un modelo de lenguaje grande con entrenamiento y utilización informática óptimos
[Procesamiento del lenguaje natural] [Modelo grande] Prueba de herramienta de razonamiento BLOOM del modelo de lenguaje grande
[Natural Procesamiento del lenguaje] [Modelo grande] GLM-130B: un modelo de lenguaje bilingüe previamente entrenado de código abierto
[Procesamiento del lenguaje natural] [Modelo grande] Introducción a la multiplicación de matrices de 8 bits para Transformers grandes
[Procesamiento del lenguaje natural] [Modelo grande] BLOOM: un parámetro 176B y puede Modelo multilingüe de acceso abierto
[Procesamiento de lenguaje natural] [Modelo grande] PaLM: Un modelo de lenguaje grande basado en Pathways
[Procesamiento de lenguaje natural] [serie chatGPT] Los modelos de lenguaje grande pueden mejorarse a sí mismos
[Procesamiento de lenguaje natural] [ChatGPT series] WebGPT: basado en preguntas y respuestas asistidas por navegador con comentarios humanos
[Procesamiento del lenguaje natural] [Serie ChatGPT] FLAN: el ajuste fino del modelo de lenguaje es un aprendizaje de tiro cero
[Procesamiento del lenguaje natural] [Serie ChatGPT] ¿De dónde viene la inteligencia de ¿De dónde viene ChatGPT?
[Procesamiento del lenguaje natural] [Serie ChatGPT] Aparición de modelos grandes

1. Introducción

Los modelos de lenguaje previamente entrenados se han convertido en la piedra angular de los procesos modernos de procesamiento del lenguaje natural porque producen mejores resultados en pequeñas cantidades de datos etiquetados. Con el desarrollo de ELMo, ULMFiT, GPT y BERT, se utiliza ampliamente el paradigma de ajuste fino de tareas posteriores utilizando modelos previamente entrenados. Posteriormente se descubrió la utilidad del modelo de lenguaje previamente entrenado para realizar tareas útiles sin ningún entrenamiento adicional. Además, la observación empírica de que el rendimiento de los modelos de lenguaje aumenta (a veces de forma predecible, a veces de forma abrupta) con modelos más grandes también conduce a una tendencia hacia tamaños de modelo cada vez mayores. Independientemente del entorno, el costo de entrenar un modelo de lenguaje grande (LLM) solo lo pueden afrontar organizaciones ricas en recursos. Además, hasta el final, la mayoría de los LLM no se hicieron públicos. En consecuencia, la mayor parte de la comunidad investigadora ha sido excluida del desarrollo de LLM. Esto tiene consecuencias concretas por no publicar públicamente: por ejemplo, la mayoría de los LLM están capacitados principalmente en textos en inglés.

Para resolver estos problemas, proponemos el modelo de lenguaje multilingüe de acceso abierto y ciencia abierta de BigScience (BLOOM). BLOOM es un modelo de lenguaje de 176 mil millones de parámetros entrenado en 46 lenguajes naturales y 13 lenguajes de programación, desarrollado y publicado por cientos de investigadores. La potencia informática utilizada para formar a BLOOM procede de las subvenciones públicas francesas GENCI e IDRIS, utilizando el superordenador Jean Zay de IDRIS. Para construir BLOOM, cada componente se diseña en detalle, incluidos los datos de capacitación, la arquitectura del modelo y los objetivos de capacitación, y las estrategias de ingeniería para el aprendizaje distribuido. También realizamos un análisis de la capacidad del modelo. Nuestro objetivo general no es sólo hacer público un modelo de lenguaje multilingüe a gran escala comparable a los sistemas desarrollados recientemente, sino también documentar el proceso de coordinación en su desarrollo.

2. FLORAR

1. Datos de entrenamiento

BLOOM está entrenado en un corpus llamado ROOTS, que es un corpus que consta de 498 conjuntos de datos de Hugging Face. Un total de 1,61 TB de texto, incluidos 46 lenguajes naturales y 13 lenguajes de programación. La Figura 3 anterior muestra una descripción general de alto nivel del conjunto de datos, mientras que la Tabla 1 anterior detalla cada idioma y su género, familia lingüística y macrorregión. Además de producir el corpus, el proceso también resultó en el desarrollo y lanzamiento de una serie de herramientas organizativas y técnicas.

1.1 Gestión de datos

Los grandes corpus de texto son creados por y sobre personas. Diferentes personas o instituciones pueden poseer "legalmente" los datos, lo que se denomina propiedad de los datos. A medida que los desarrolladores de aprendizaje automático recopilan y organizan estos datos en conjuntos de datos cada vez más grandes, es cada vez más importante tener en cuenta a las partes interesadas involucradas en el desarrollo de datos, incluidos: desarrolladores, interesados ​​y titulares de derechos.

​ BigScience tiene como objetivo resolver estos problemas combinando conocimientos multidisciplinarios como tecnología, derecho y sociología. La organización se centra en dos objetivos principales en dos escalas de tiempo diferentes: diseñar una estructura de gobernanza de datos internacional a largo plazo que priorice a los titulares de derechos de datos y proporcionar recomendaciones específicas para los datos utilizados directamente por los proyectos de BigScience. El progreso hacia el primer objetivo Jernite et al.se muestra en el trabajo, que motiva aún más la necesidad de una gobernanza de datos y describe una red de custodios de datos, titulares de derechos y otros actores. Las interacciones de estos actores están diseñadas para considerar la privacidad algorítmica y de datos, la propiedad intelectual y los derechos de los usuarios. En particular, este enfoque se basa en un acuerdo estructurado entre el proveedor de datos y el proveedor de datos que especifica el propósito de los datos.

​ Aunque fue imposible establecer una organización internacional completa en el período de tiempo relativamente corto desde el inicio del proyecto hasta la capacitación del modelo, también hemos trabajado duro para aprender lecciones de este proceso: (1) BigScience intentará obtener un uso claro de los datos de la licencia de los proveedores de datos; (2) mantener la independencia de una sola fuente y mantener la trazabilidad hasta la etapa final del preprocesamiento. (3) Adoptar un método de publicación combinado para cada fuente de datos que constituya el corpus completo, promoviendo así la reutilización y la investigación posterior. Se puede acceder y visualizar el recurso del corpus ROOTS en la organización "BigScience Data" de Hugging Face.

1.2 Fuentes de datos

Después de determinar la estrategia de gestión de datos, el siguiente paso es determinar la composición del lenguaje de formación. Esta fase está impulsada por varios objetivos, que están inherentemente en conflicto. Estos conflictos de memoria incluyen: construir un modelo de lenguaje que sea accesible para la mayor cantidad posible de personas en el mundo, al tiempo que requiere suficiente conocimiento del lenguaje para gestionar conjuntos de datos de tamaño comparable a los anteriores para mejorar la documentación estándar, y seguir el cuerpo de datos y algoritmos correctos.

• elección de idioma

  Con base en estas consideraciones, adoptamos un enfoque incremental para seleccionar los idiomas incluidos en el corpus. Comience enumerando los 8 idiomas más hablados en el mundo, promoviendo activamente esos idiomas al principio del proyecto e invitando a hablantes fluidos de ese idioma a unirse al proyecto. Luego, el swahili en la selección original se amplió a la categoría de lengua Níger-Congo, y el hindi y el urdu se ampliaron a las lenguas índicas, como sugirió la comunidad. En última instancia, proponemos que si un idioma tiene más de 3 hablantes fluidos participando, se pueda agregar a la lista de soporte.

• selección de fuente

  La mayor parte del corpus fue seleccionada por los participantes del taller y los equipos de investigación, quienes escribieron conjuntamente el "Catálogo BigScience": una lista que cubre varios lenguajes procesados ​​y no procesados. Esto toma la forma de hackatones organizados por comunidades como Machine Learning Tokyo, Masakhane y LatinX in AI. Además de estas fuentes, otros participantes del grupo de trabajo compilaron recursos específicos del idioma, como el repositorio Masader centrado en árabe. Este enfoque ascendente identificó un total de 252 fuentes, con al menos 21 fuentes por idioma. Además, para aumentar la cobertura geográfica de los recursos en español, chino, francés e inglés, los participantes identificaron URL localmente relevantes para los idiomas que se agregaron al corpus mediante pseudocrawl.

• código GitHub

  Los conjuntos de datos del lenguaje de programación en este directorio se complementan con los conjuntos de datos de GitHub en BigQuer de Google y luego se eliminan los duplicados mediante una coincidencia exacta.

• Óscar

  Para no desviarnos de la investigación estándar que utiliza páginas web como fuente de datos previa al entrenamiento y para cumplir con los requisitos de volumen de datos de los costos de cálculo del tamaño de BLOOM, utilizamos además OSCAR versión 21.09 como fuente de datos, correspondiente a la instantánea de rastreo común. en febrero de 2021, que ocupa el 38% del corpus final.

1.3 Preprocesamiento de datos

Después de identificar la fuente de datos, el procesamiento de datos implica varios pasos de gestión de datos. En la Figura 2 anterior, puede ver la vista general del proceso para construir ROOTS. Todas las herramientas desarrolladas durante este proceso están disponibles en GitHub.

• obtener datos de origen

  El primer paso implicó obtener datos de texto de fuentes de datos identificadas, lo que incluyó descargar y extraer campos de texto de conjuntos de datos de PNL en varios formatos, extraer y procesar una gran cantidad de archivos PDF de archivos, 192 sitios web de un catálogo. El texto se extrajo y preprocesó de un 456 sitios adicionales geográficamente diversos seleccionados por miembros del Grupo de Trabajo de Elementos y Datos. Esto último requirió el desarrollo de nuevas herramientas para extraer texto de HTML en archivos WARC de rastreo común. Pudimos localizar y extraer datos utilizables de todas las URL en 539 redes.

• filtro de calidad

  Después de obtener el texto, descubrimos que la mayoría de las fuentes contenían una gran cantidad de lenguaje no natural, como errores de preprocesamiento, páginas SEO o basura. Para filtrar el lenguaje no natural, definimos un conjunto de métricas de calidad, donde el texto de alta calidad se define como "escrito por humanos para humanos", sin distinguir juicios a priori sobre el contenido o la gramática. Es importante destacar que estas métricas se adaptan a las necesidades de cada fuente de dos formas principales. En primer lugar, sus parámetros, como umbrales y listas de elementos admitidos, son elegidos individualmente por hablantes fluidos de cada idioma. En segundo lugar, primero examinamos cada fuente individual para determinar qué métricas tienen más probabilidades de identificar el lenguaje no natural. Ambos procesos están respaldados por herramientas para visualizar el impacto.

• Deduplicación y privacidad

  En última instancia, utilizamos dos pasos de iteración para eliminar documentos casi duplicados y redactar información de identificación personal identificada en el corpus OSCAR. Debido a que se considera la fuente del mayor riesgo para la privacidad, esto nos motiva a utilizar la edición basada en expresiones regulares, aunque las expresiones tienen algunos problemas con falsos positivos.

1.4 Conjunto de datos solicitado

El ajuste de indicaciones de tareas múltiples (también conocido como ajuste de instrucciones) implica ajustar un modelo de lenguaje previamente entrenado en un conjunto de datos ajustado que consta de una gran cantidad de tareas diferentes a través de indicaciones de lenguaje natural. T0 demuestra la fuerte generalización de tiro cero de modelos ajustados en conjuntos de datos impulsados ​​​​mixtos y multitarea. Además, T0 supera a los modelos de lenguaje que son órdenes de magnitud mayores sin ese ajuste fino. Inspirándonos en estos resultados, exploramos el uso de conjuntos de datos de lenguaje natural existentes para realizar ajustes en múltiples tareas.

T0 está capacitado en el subconjunto Public Pool of Prompt (P3), que es una colección de indicaciones para varios conjuntos de datos de lenguaje natural aplicados de código abierto existentes. Esta colección de indicaciones se creó a través de una serie de hackathons en los que participaron colaboradores de BigScience, en los que los participantes del hackathon escribieron más de 2000 indicaciones para más de 170 conjuntos de datos. Los conjuntos de datos de P3 cubren diversas tareas de lenguaje natural, incluido el análisis de sentimientos, la respuesta a preguntas, el razonamiento en lenguaje natural y excluyen contenido dañino o lenguaje no natural. PromptSource, un conjunto de herramientas de código abierto que facilita la creación, el intercambio y el consumo de indicaciones en lenguaje natural.

Después del entrenamiento previo de BLOOM, aplicamos el mismo ajuste fino de múltiples tareas a gran escala para hacer que BLOOM se generalice a tareas multilingües de disparo cero. Al modelo resultante lo llamamos BLOOMZ. Para entrenar BLOOMZ, ampliamos P3 para incluir nuevos conjuntos de datos y nuevas tareas en idiomas distintos del inglés, como la traducción. Esto produjo xP3, una colección mejorada de 83 conjuntos de datos que cubren 46 idiomas y 16 tareas. Como se menciona en la Figura 4 anterior, xP3 refleja la distribución de idiomas de ROOTS. Las tareas en xP3 incluyen tanto multilingües como monolingües. Usamos PromptSource para recopilar estas indicaciones y agregar metadatos adicionales a las indicaciones, como la entrada y el idioma de destino. Para investigar la importancia de las indicaciones multilingües, también traducimos automáticamente las indicaciones en inglés en xP3 al idioma del conjunto de datos correspondiente para generar un conjunto llamado xP3mt.

2. Arquitectura modelo

2.1 Método de diseño

La elección del diseño arquitectónico es muy amplia y es imposible explorarla por completo. Una opción es replicar completamente la arquitectura de un modelo grande existente. Por otro lado, rara vez se ha trabajado mucho para mejorar las arquitecturas existentes, y la adopción de algunas prácticas recomendadas puede conducir a un mejor modelo. Tomamos un término medio y elegimos familias de modelos que han demostrado escalar bien y que cuentan con un soporte razonable en herramientas y bases de código disponibles públicamente. Realizamos experimentos de ablación en los componentes e hiperparámetros del modelo, buscando maximizar nuestro presupuesto computacional final.

• Diseño experimental de ablación

  El principal atractivo de los LLM es su capacidad para realizar tareas de manera "cero/pocas posibilidades": modelos suficientemente grandes pueden simplemente realizar nuevas tareas a partir de instrucciones y ejemplos en contexto, sin entrenamiento en muestras supervisadas. Dado que ajustar un modelo 100B+ es engorroso, evaluamos las decisiones arquitectónicas centrándonos en las capacidades de generalización de tiro cero y no consideramos el aprendizaje por transferencia. Específicamente, medimos el rendimiento cero de diferentes conjuntos de tareas: 29 tareas del arnés de evaluación del modelo de lenguaje EleutherAI (EAI-Eval) y 9 tareas del conjunto de validación de T0 (T0-Eval). Existe una gran superposición entre los dos: solo una tarea en T0-Eval no está en EAI-Eval, aunque todas las indicaciones de los dos son diferentes.

  Además, también se realizan experimentos de ablación utilizando modelos más pequeños. Utilice el modelo 6.7B para realizar experimentos de ablación en objetivos previamente entrenados y utilice el modelo 1.3B para realizar experimentos de ablación sobre incrustación de posiciones, funciones de activación y normalización de capas. Recientemente, Dettmers descubrió una transición de fase en un modelo mayor que 6.7B y observó la aparición de "características anómalas". Entonces, ¿es posible extrapolar el tamaño del modelo final en la escala de 1.300 millones?

• Esquema fuera de alcance

  No consideramos la combinación de expertos (MoE) debido a la falta de bases de código basadas en GPU ampliamente utilizadas y adecuadas para entrenarlo a escala. De manera similar, no consideramos modelos de espacio de estados. Cuando se diseñó BLOOM, tuvieron un desempeño deficiente en tareas de lenguaje natural. Ambos enfoques son prometedores y ahora demuestran resultados competitivos en MoE a gran escala y en escalas más pequeñas utilizando modelos de espacio de estados con H3.

2.2 Arquitectura y objetivos previos a la capacitación

Aunque la mayoría de los modelos de lenguaje modernos se basan en la arquitectura Transformer, existen diferencias significativas entre las implementaciones arquitectónicas. Obviamente, el Transformer original se basa en la arquitectura codificador-decodificador, y muchos modelos populares solo eligen métodos de solo codificador o solo decodificador. Actualmente, todos los modelos de última generación con más de 100B de parámetros son modelos únicamente con decodificador. Esto es contrario a los hallazgos de Raffel et al., donde el modelo codificador-decodificador supera significativamente al modelo solo decodificador en términos de aprendizaje por transferencia.

Antes de nuestro trabajo, la literatura carecía de una evaluación sistemática de la generalización de disparo cero para diferentes arquitecturas y objetivos previos al entrenamiento. Exploramos Wang et al.(2022a)esta cuestión en el trabajo de et al., que explora arquitecturas codificador-decodificador y solo decodificador e interacciones con modelos preentrenados de modelado de lenguaje causal, de prefijo y enmascarado. Nuestros resultados muestran que el modelo de solo decodificador causal funciona mejor después del entrenamiento previo, lo que valida la elección del LLM de última generación.

2.3 Detalles de modelado

Además de elegir la arquitectura y el objetivo de preentrenamiento, se proponen muchos cambios a la arquitectura original de Transformer. Por ejemplo, esquemas de integración de ubicaciones alternativas o funciones de activación novedosas. Realizamos una serie de experimentos para evaluar cada modificación, en Le Scao et al.el modelo de solo decodificador causal. Empleamos dos variaciones en BLOOM:

• Incrustación de posición ALiBi

  En comparación con agregar información de ubicación en la capa de incrustación, ALiBi atenúa directamente la puntuación de atención en función de la distancia entre claves y consultas. Si bien la motivación original de ALiBi fue su capacidad de extrapolar a secuencias más largas, descubrimos que también conduce a un entrenamiento más equilibrado y un mejor rendimiento posterior sobre la longitud de la secuencia original, más allá de las incrustaciones que se pueden aprender y rotar.

• Norma de capa de incrustación

  En una prueba inicial de entrenamiento de un modelo de parámetros 104B, probamos la normalización de capas inmediatamente después de la capa de incrustación, según lo recomendado por la biblioteca bitsandbytes y su capa StableEmbedding. Descubrimos que esto puede mejorar significativamente la estabilidad del entrenamiento. Aunque Le Scao et al.descubrimos en nuestro trabajo que tiene una penalización por la generalización de disparo cero, agregamos una capa de normalización de capa adicional después de la primera capa de incrustación de BLOOM para evitar la inestabilidad del entrenamiento. Tenga en cuenta que float16 se usa en el experimento 104B preliminar y bfloat16 se usa en el entrenamiento final. Porque float16 ha sido identificado como la causa de muchas inestabilidades observadas durante la formación de LLM. bfloat16 tiene el potencial de aliviar la necesidad de incorporar LayerNorm.

  La arquitectura completa de BLOOM se muestra en la Figura 5 anterior.

3. Tokenización

Las opciones de diseño para los tokenizadores a menudo se ignoran en favor de la configuración "predeterminada". Por ejemplo, tanto OPT como GPT-3 utilizan el tokenizador GPT-2, entrenado para inglés. Debido a la naturaleza diversa de los datos de entrenamiento de BLOOM, se requieren elecciones de diseño cuidadosas para garantizar que el tokenizador codifique oraciones sin pérdidas.

3.1 Verificación

Comparamos el tokenizador (Acs, 2019) utilizado en este artículo con los tokenizadores monolingües existentes como métrica para la detección de integridad. La fertilidad se define como la cantidad de subpalabras creadas por el tokenizador por palabra o por conjunto de datos, que medimos utilizando Universal Dependencies 2.9 y el subconjunto OSCAR del idioma de interés. Tener una fertilidad muy alta en un idioma en comparación con un tokenizador monolingüe puede indicar una degradación del rendimiento en varios idiomas posteriores. Nuestro objetivo es garantizar que la capacidad de fertilidad de cada idioma no sea más de 10 puntos porcentuales menor al comparar nuestro tokenizador multilingüe con su contraparte lingüística. En todos los experimentos, se utilizó la biblioteca Hugging Face Tokenizers para diseñar y entrenar tokenizadores de prueba.

3.2 datos de entrenamiento del tokenizador

Inicialmente utilizamos un subconjunto no repetitivo de ROOTS. Sin embargo, un estudio cualitativo sobre los vocabularios de los tokenizadores reveló problemas con los datos de entrenamiento. Por ejemplo, en versiones anteriores del tokenizador descubrimos que las URL completas se almacenaban como tokens, lo que se debía a que varios documentos contenían mucha duplicación. Este problema nos motiva a eliminar filas duplicadas en los datos de entrenamiento del tokenizador.

3.3 Tamaño del vocabulario

Un tamaño de vocabulario grande reduce el riesgo de segmentar excesivamente ciertas oraciones, especialmente en idiomas de bajos recursos. Realizamos experimentos de validación utilizando tamaños de vocabulario de 150k y 250k para compararlos con la literatura de modelado multilingüe existente. En comparación con el tokenizador monolingüe, finalmente determinamos que el tamaño del vocabulario sería de 250.000 tokens para lograr el objetivo de fertilidad inicial. Debido a que el tamaño del vocabulario determina el tamaño de la matriz de incrustación, el tamaño de incrustación debe ser divisible por 128 para la eficiencia de la GPU y debe ser divisible por 4 para poder utilizar el paralelismo tensorial. Terminamos usando un tamaño de vocabulario de 250680, con 200 tokens reservados para aplicaciones futuras, como el uso de tokens de marcador de posición para seleccionar información privada.

3.4 BPE a nivel de byte

El tokenizador es un tokenzier de subpalabras que se puede aprender y que se entrena utilizando el algoritmo de codificación de pares de bytes (BPE). Para no perder información durante el proceso de tokenización, el tokenizador crea fusiones a partir de bytes en lugar de caracteres como unidad más pequeña. De esta manera, la tokenización nunca podrá generar tokens desconocidos, ya que los 256 bytes pueden incluirse en el vocabulario del tokenizador. Además, BPE a nivel de bytes maximiza el intercambio de vocabulario entre idiomas.

3.5 Normalización

​ En el sentido ascendente del algoritmo BPE, para obtener el modelo más general posible, el texto no está normalizado. Agregar normalización Unicode como NFKC no reduce la fertilidad en más del 0,8% en todos los casos, pero a costa de hacer que el modelo sea menos general. Por ejemplo, dando como resultado $2^2$ y 22 están codificados de la misma manera.

3.6 Pre-tokenizador

Nuestra pretokenización tiene dos objetivos: producir la primera partición del texto y limitar la longitud máxima de las secuencias de tokens producidas por el algoritmo BPE. La escala previa a la tokenización utiliza la siguiente expresión regular: ?[^(\S|[.,!?...。，、|_])]+, que separa las palabras conservando todos los caracteres, especialmente los espacios en blanco y las secuencias de nueva línea que son cruciales para los lenguajes de programación. No utilizamos las particiones centradas en inglés que son comunes en otros tokenizadores. Tampoco usamos división de números, lo que causó problemas con el árabe y el código.

4. Ingeniería

4.1 Hardware

El modelo fue entrenado en Jean Zay, una supercomputadora financiada por el gobierno francés, propiedad de GENCI y dirigida por IDRIS, el centro informático nacional del Centro Nacional Francés de Investigación Científica (CNRS). La capacitación de BLOOM tardó 3,5 meses en completarse y consumió 1.082.990 horas de computación. El entrenamiento se realizó en 48 nodos, cada uno con 8 GPU NVIDIA A100 de 80 GB (384 GPU en total); también mantuvimos 4 nodos de repuesto debido a posibles daños en el hardware durante el entrenamiento. Los nodos están equipados con 2 CPU AMD EPYC 7543 de 32 núcleos y 512 GB de RAM, mientras que el almacenamiento es un sistema de archivos paralelo SpectrumScale (GPFS) híbrido de unidades de disco duro y all-flash.

4.2 Marco

BLOOM se entrena utilizando Megatron-DeepSpeed, un marco para entrenamiento distribuido a gran escala. Consta de dos partes: Megatron-LM proporciona implementación de Transformer, paralelismo tensorial y primitivas de carga de datos, mientras que DeepSpeed ​​​​proporciona optimizador ZeRO, canalización de modelos y componentes de entrenamiento distribuido. Este marco nos permite utilizar el paralelismo 3D para una capacitación eficiente: una fusión de tres métodos complementarios de aprendizaje profundo distribuido. Estos métodos se describen a continuación:

• Paralelismo de datos (Paralelismo de datos, DP)

  Replica varias copias del modelo, cada copia se coloca en un dispositivo diferente e ingresa fragmentos de datos. Este proceso se realiza en paralelo, con todas las copias del modelo sincronizadas al final de cada paso de entrenamiento.

• Paralelismo tensorial (TP)

  Divida capas independientes de su modelo en múltiples dispositivos. De esta manera, en lugar de colocar todo el tensor de activación o el tensor de gradiente en una sola GPU, colocamos fragmentos de este tensor en una sola GPU. Esta técnica a veces se denomina paralelismo horizontal o paralelismo intramodelo.

• Paralelismo de tuberías (PP)

  Divida las capas del modelo en varias GPU y cada GPU coloque solo una fracción de las capas del modelo. A esto también se le llama a veces paralelismo vertical.

En última instancia, Zero Redundancy Optimizer (ZeRO) ejecuta diferentes procesos que contienen solo una parte de los datos (parámetros, gradientes y estado del optimizador) y los datos necesarios para un paso de entrenamiento. Usamos ZeRO etapa 1, lo que significa que solo el estado del optimizador se fragmenta de esta manera.

La combinación de los cuatro componentes descritos anteriormente puede escalar a cientos de GPU con una utilización de GPU extremadamente alta. Pudimos alcanzar 156 TFLOP en la configuración más rápida de la GPU A100, la mitad del pico teórico de 312 TFLOP.

4.3 Formato de coma flotante

En experimentos preliminares con un modelo de parámetro 104B en GPU NVIDIA V100, observamos una inestabilidad numérica que conduce a una divergencia de entrenamiento irreversible. Nuestra hipótesis es que estas inestabilidades surgen del uso original de IEEE float16, un formato numérico de punto flotante de 16 bits con un rango dinámico muy limitado que podría provocar un desbordamiento. Finalmente obtuvimos permiso para admitir el formato bfloat16, que tiene el mismo rango dinámico que float32. Por otro lado, la precisión de bfloat16 sigue siendo mucho menor, lo que nos motiva a utilizar un entrenamiento de precisión mixto. La técnica realiza operaciones sensibles a la precisión, como la acumulación de gradiente y softmax en precisión float32, y utiliza baja precisión para las operaciones restantes, lo que permite un equilibrio entre alto rendimiento y estabilidad del entrenamiento. Finalmente, realizamos el entrenamiento final con precisión mixta bfloat16, lo que demostró resolver el problema de la inestabilidad del entrenamiento.

4.4 Fusión de núcleos CUDA

En general, las GPU no pueden realizar estos cálculos al mismo tiempo que se recuperan los datos. Además, el rendimiento computacional de las GPU modernas es mucho mayor que la velocidad de transferencia de memoria requerida para cada operación (lo que se conoce como núcleo en la programación de GPU). La fusión de kernel es un método de optimización basado en la computación GPU que realiza múltiples operaciones consecutivas en una llamada al kernel. Este método proporciona una forma de minimizar las transferencias de datos: los resultados intermedios se dejan en los registros de la GPU en lugar de copiarse en la VRAM, lo que ahorra gastos generales.

Usamos Megatron-LM para proporcionar varios núcleos CUDA fusionados personalizados. Primero, usamos un kernel optimizado para realizar LayerNorm y usamos el kernel para fusionar varias combinaciones de operaciones de escalado, enmascaramiento y softmax. Agregue un término de sesgo a las activaciones de GeLU utilizando la funcionalidad JIT de Pytorch. Como ejemplo de uso de núcleos fusionados, agregar un término de sesgo a la operación GeLU no agrega tiempo adicional porque la operación está limitada a la memoria: el cálculo adicional es insignificante en comparación con las transferencias de datos entre la VRAM de la GPU y los registros. Por lo tanto, fusionar las dos operaciones reduce sustancialmente su tiempo de ejecución.

4.5 Desafíos adicionales

Escalar a 384 GPU requirió dos modificaciones: deshabilitar los lanzamientos asincrónicos del kernel CUDA (para facilitar la depuración y evitar interbloqueos) y dividir los grupos de parámetros en subgrupos más pequeños (para evitar una asignación excesiva de memoria de la CPU).

Durante el proceso de formación, nos enfrentamos al problema de los fallos del hardware: en promedio, 1 o 2 fallos de GPU por semana. Dado que los nodos de respaldo están disponibles y se usan automáticamente, y los puntos de control se guardan cada tres horas, esto no afecta significativamente el rendimiento del entrenamiento. El error de interbloqueo de Pytorch y la falla de espacio en disco en el cargador de datos pueden causar un tiempo de inactividad de 5 a 10 horas. Dado que los problemas de ingeniería fueron relativamente escasos y el modelo se recuperó rápidamente debido a un solo pico de pérdidas, la intervención humana fue menos necesaria que proyectos similares.

5. Entrenamiento

• modelo previamente entrenado

  Entrenamos las 6 variantes de tamaño de BLOOM utilizando los hiperparámetros detallados en la Tabla 3 anterior. La arquitectura y los hiperparámetros se derivan de nuestros resultados experimentales (Le Scao et al.) y del entrenamiento previo de modelos de lenguaje grandes (Brown et al.). La profundidad y el ancho del modelo que no es 176B siguen aproximadamente la literatura anterior (Brown et al.), y la desviación de 3B y 7.1B es solo para facilitar el ajuste a nuestro entorno de entrenamiento. Debido al mayor vocabulario multilingüe, el tamaño del parámetro de incrustación de BLOOM es mayor. Durante el desarrollo del modelo de parámetros 104B, utilizamos diferentes Adam $Se\; utilizaron\; parámetros\; \beta$ , disminución de peso y recorte de gradiente para experimentar con la estabilidad objetiva, pero no resultaron útiles. Para todos los modelos, utilizamos un programa de disminución de la tasa de aprendizaje del coseno en 410 millones de tokens, que se utiliza como límite superior en la duración del entrenamiento si el cálculo lo permite, y calienta 375 millones de tokens. Usamos disminución de peso, recorte de gradiente y sin abandono. El conjunto de datos ROOTS contiene el texto de los tokens 341B. Sin embargo, según las leyes de escala revisadas publicadas durante el entrenamiento, decidimos entrenar modelos grandes con 25 mil millones de tokens adicionales en datos repetidos. Dado que los tokens de calentamiento + tokens de decadencia son mayores que el número total de tokens, la caída de la tasa de aprendizaje nunca ha llegado al final.

• Ajuste multitarea

  El modelo BLOOMZ ajustado mantiene los mismos hiperparámetros arquitectónicos que el modelo BLOOM. Los hiperparámetros ajustados se basan aproximadamente en T0 y FLAN. La tasa de aprendizaje consiste en duplicar la tasa de aprendizaje mínima del modelo previamente entrenado correspondiente y luego redondear hacia arriba. Para variantes más pequeñas, el tamaño del lote global se multiplica por 4 para aumentar el rendimiento. El modelo se ajusta en tokens 13B y el punto de control óptimo se selecciona en función de un conjunto de validación independiente. Después de ajustar los tokens 1-6B, el rendimiento tiende a ser estable.

• ajuste fino del contraste

  También utilizamos el esquema SGPT Bi-Encoder para un ajuste comparativo de los modelos BLOOM con parámetros 1.3B y 7.1B para entrenar modelos que produzcan incrustaciones de texto de alta calidad. Creamos SGPT-BLOOM-1.7B-msmarco para la recuperación de información multilingüe y SGPT-BLOOM-1.7B-nli para la similitud semántica multilingüe. Sin embargo, puntos de referencia recientes han encontrado que dichos modelos también pueden generalizarse a otras tareas de integración, como la minería de bittexto, la reorganización o la extracción de características para la clasificación posterior.

6. Publicar

​ La apertura es el núcleo del desarrollo de BLOOM y queremos asegurarnos de que sea fácil de usar para la comunidad.

6.1 Tarjeta modelo

​ Siguiendo las mejores prácticas para lanzar modelos de aprendizaje automático, los modelos BLOOM se lanzan junto con una tarjeta de modelo detallada, que describe las especificaciones técnicas, los detalles de capacitación, el uso previsto, los usos fuera de alcance y las limitaciones del modelo. Los participantes de los grupos de trabajo trabajan juntos para generar la Tarjeta Modelo final y cada tarjeta de punto de control.

6.2 Licencia

Dados los casos de uso potencialmente dañinos que podría traer BLOOM, elegí lograr un equilibrio entre el acceso de desarrollo sin restricciones y el uso responsable, incluido un código de conducta para limitar la aplicación del modelo a casos de uso potencialmente dañinos. Estos términos suelen incluirse en las "Licencias de IA Responsable (RAIL)", las licencias adoptadas por la comunidad al lanzar modelos. La diferencia significativa con la licencia RAIL adoptada por BLOOM al principio es que separa "código fuente" y "modelo". También incluye definiciones detalladas del "uso" del modelo y el "trabajo derivado" para garantizar una identificación clara de los usos posteriores mediante indicaciones, ajustes, destilación, uso de logits y distribuciones de probabilidad. La licencia contiene 13 restricciones de uso conductuales, que se determinan de acuerdo con el uso previsto y las restricciones descritas en la Tarjeta Modelo BLOOM y el Código de Ética de BigScience. La licencia proporciona el modelo de forma gratuita y los usuarios pueden utilizarlo libremente siempre que respeten los términos. El código fuente de BLOOM se ha hecho accesible bajo la licencia de código abierto Apache 2.0.

3. Evaluación

La evaluación se centra en las configuraciones de disparo cero y de pocos disparos. Nuestro objetivo es presentar una imagen precisa de BLOOM en comparación con los LLM existentes. Debido al tamaño de estos modelos, los enfoques basados ​​en indicaciones y el "aprendizaje en contexto" de pocas oportunidades son más comunes que el ajuste fino.

1. Diseño experimental

1.1 Indicaciones

Con base en una investigación reciente sobre el impacto de las indicaciones en el rendimiento del modelo de lenguaje, decidimos crear un conjunto de evaluación de modelos de lenguaje que nos permita variar los datos de las tareas subyacentes, así como también solicitar tareas "contextualizadas". Nuestro mensaje se desarrolló antes del lanzamiento de BLOOM sin ninguna mejora previa utilizando el modelo. Nuestro objetivo al diseñar el mensaje de esta manera es simular los resultados de disparo cero o de disparo único que los nuevos usuarios esperan de BLOOM.

Usamos PromptSource para generar múltiples mensajes para cada tarea. Seguimos Sanh et al.(2022)el proceso utilizado, las indicaciones se generaron mediante crowdsourcing, por lo que pudimos ver diferentes longitudes y estilos de indicaciones. Para promover la calidad y la claridad, realice varias revisiones por pares en cada mensaje.

La Tabla 5 anterior muestra algunas indicaciones finales para las tareas de WMT'14. Debido a limitaciones de recursos, también generamos indicaciones para muchas tareas no incluidas en este artículo. Todas las indicaciones para todas las tareas son de acceso público.

1.2 Infraestructura

Nuestro marco amplía el arnés de evaluación del modelo de lenguaje de EleutherAI integrando la biblioteca PromptSource. Lanzamos el Arnés de evaluación del modelo de lenguaje solicitado como una biblioteca de código abierto para que la gente la use. Usamos este marco para ejecutar experimentos y agregar resultados.

1.3 Conjunto de datos

• Super pegamento

  Utilizamos un subconjunto del conjunto de evaluación de tareas de clasificación SuperGLUE, en particular: tareas Ax-b, Ax-g, BoolQ, CB, WiC, WSC y RTE. Excluimos las tareas restantes porque requerían un orden de magnitud más de cálculo que todas las tareas que consideramos combinadas. Las tareas están en un inglés sencillo, principalmente para facilitar la comparación con trabajos anteriores. También observamos que no se informa ampliamente sobre el rendimiento al utilizar configuraciones de disparo cero y de disparo único en estas tareas. La primera excepción es T0, pero el modelo está ajustado a las instrucciones, por lo que no se puede comparar directamente con BLOOM y OPT. Para cada tarea, seleccionamos aleatoriamente 5 muestras de la fuente de mensajes y luego evaluamos todos los modelos en el conjunto de mensajes.

• Traducción automática (MT)

  Evaluamos BLOOM en tres conjuntos de datos: WMT14 $\text{eng}\leftrightarrow \text{fre}$和$\text{eng}\leftrightarrow \text{hin}$ , Flores-101 y DiaBLa. Usamos sacrebleu, una implementación BLEU, para la evaluación. Utilice la decodificación codiciosa en el proceso de generación hasta el token EOS, agregue \n###\n para 1 disparo.

• Resumen

  Evaluamos el resumen en el conjunto de datos de WikiLingua. WikiLingua es un conjunto de datos de resúmenes multilingüe que consta de artículos de WikiHow y pares de resúmenes paso a paso. Los modelos comparables en tamaño a BLOOM generalmente no informan sobre la generación de lenguaje natural condicional de una sola vez. PaLM es la primera excepción, ya que informa sobre WikiLingua; sin embargo, sólo se examina la capacidad de resumen en inglés del modelo. A modo de comparación, probamos las capacidades multilingües de BLOOM evaluando resúmenes abstractos en el idioma de origen. Nos centramos en 9 idiomas (árabe, inglés, español, francés, hindi, portugués, vietnamita y chino) que son los objetivos de BigScience.

1.4 Modelo de referencia

• mGPT: modelos estilo GPT entrenados en 60 idiomas;
• GPT-Neo, GPT-J-6B, GPT-NeoX: familia de modelos estilo GPT entrenados en Pile;
• T0: variante T5 ajustada mediante multitarea promovida en el conjunto de datos P3;
• OPT: un modelo de estilo GPT, entrenado en conjuntos de datos mixtos;
• XGLM: modelo multilingüe estilo GPT entrenado en variantes CC100;
• M2M: Modelo codificador-decodificador entrenado con funciones objetivas causales y enmascaradas en Wikipedia y mC4;
• mTk-Instruct: la variante T5 para tareas múltiples provocó un ajuste fino en el conjunto de datos Super-NaturalInstructions;
• Codex: modelo GPT ajustado con código de GitHub;
• GPT-fr: modelo de estilo GPT entrenado en texto francés;

2. Efecto disparo cero

En las tareas de generación y comprensión del lenguaje natural, encontramos que el rendimiento cero de los modelos de lenguaje previamente entrenados es casi aleatorio. La Figura 7 anterior muestra el rendimiento del disparo cero.

2.1 SúperPEGAMENTO

En SuperGLUE, aunque algunas indicaciones independientes muestran una mejora en el rendimiento de aproximadamente 10 puntos, la mejora promedio de las indicaciones individuales es casi aleatoria . Excepto el modelo T0, que presenta un fuerte efecto. Sin embargo, este modelo está ajustado en la configuración de tareas múltiples para mejorar el efecto de las indicaciones de disparo cero.

2.2 Traducción automática

En la configuración de disparo cero, los resultados de la traducción automática son muy pobres . Hay dos problemas principales con los resultados generados: (1) sobregenerados; (2) no se puede generar el lenguaje correcto.

3. Resultados de una sola vez

3.1 SúperPEGAMENTO

​ La visualización en la Figura 7 anterior también muestra el efecto de una sola vez. En comparación con el efecto de disparo cero, se reduce la variabilidad del efecto de disparo único de todas las indicaciones y modelos en SuperGLUE. En general, no hay una mejora significativa en la configuración de un solo disparo: la precisión del modelo sigue siendo casi aleatoria. Realizamos análisis adicionales sobre BLOOM en diferentes tamaños de modelos. Como punto de referencia, también medimos la precisión de un solo disparo de modelos OPT de tamaño similar. Las familias de modelos OPT y BLOOM mejoran ligeramente con la escala. BLOOM-176B supera a OPT-175B en Ax-B, CB y WiC.

3.2 Traducción automática

En la configuración de 1 disparo, utilizamos el mensaje XGLM para probar las instrucciones del idioma central en el conjunto de prueba de desarrollo Flores-101. Seleccionamos aleatoriamente muestras de un solo disparo del mismo conjunto de datos, que pueden diferir de trabajos anteriores. Separamos los diferentes resultados por pares de lenguas de altos recursos, pares de lenguas de altos y medianos recursos, pares de lenguas de bajos recursos y familias de lenguas romances. Según la proporción de idiomas en ROOTS, los idiomas se clasifican en recursos bajos, medios y altos. Para pares de idiomas de recursos altos y medios-altos, comparamos con los resultados supervisados ​​​​del modelo M2M-124 con parámetros 615M. Además, comparamos los resultados de 1 disparo de XGLM(7.5B) con los resultados de AlexaTM de 32 disparos. **Buenos resultados para traducciones de idiomas de altos recursos y de idiomas de altos recursos a idiomas de recursos medios. **Esto demuestra que BLOOM tiene buena capacidad multilingüe. En comparación con los modelos M2M supervisados, los resultados suelen ser comparables o incluso mejores en la configuración de 1 disparo y, en muchos casos, los resultados son comparables a los de AlexaTM.

**La calidad de la traducción es buena para muchos idiomas de bajos recursos, comparable o incluso mejor que los modelos M2M supervisados. **Sin embargo, el desempeño entre swahili y yoruba es bastante pobre debido a la falta de datos de entrenamiento de BLOOM.

3.3 Resumen

​ La Figura 9 arriba muestra la comparación de los resultados de un solo disparo de BLOOM y OPT-175B. Cada punto representa una puntuación previa a la indicación. La conclusión clave es que BLOOM logra un mayor rendimiento que OPT en el resumen multilingüe, y el rendimiento aumenta a medida que aumentan los parámetros del modelo. Sospechamos que esto se debe a la formación multilingüe de BLOOM.

4. Ajuste multitarea

Sobre la base de trabajos recientes sobre ajuste fino de múltiples tareas, exploramos el uso del ajuste fino multitarea multilingüe para mejorar el rendimiento de disparo cero de los modelos BLOOM. Usamos el corpus xP3 para realizar ajustes multitarea multilingüe en BLOOM. Descubrimos que la capacidad de realizar un rendimiento de disparo cero mejora significativamente. En la Figura 10 anterior, comparamos el efecto de disparo cero de los modelos BLOOM y XLGM con el ajuste fino de múltiples tareas BLOOMZ, T0 y mTk-Instruct. El rendimiento de BLOOM y XGLM se resuelve en líneas de base aleatorias. Después del ajuste multilingüe y multitarea (BLOOMZ), el efecto de disparo cero mejora significativamente. A pesar de estar ajustado en múltiples tareas, dado que T0 es un modelo monolingüe en inglés, tiene un rendimiento deficiente en conjuntos de datos multilingües. Sin embargo, Muennighoff et al.los resultados adicionales que proporcionamos muestran que el modelo ajustado en el conjunto de datos en inglés xP3 aún supera a T0 cuando se controla el tamaño y la arquitectura. Esto podría deberse al hecho de que el conjunto de datos ajustado T0 (P3) contiene una menor diversidad de conjuntos de datos e indicaciones que xP3.

5. Generación de código

El corpus ROOTS de preentrenamiento de BLOOM contiene aproximadamente el 11% del código. La Tabla 9 anterior muestra los resultados comparativos de BLOOM en HumanEval. Descubrimos que BLOOM previamente entrenado funciona tan bien como un modelo GPT de tamaño similar entrenado en Pile. Pile contiene datos en inglés y aproximadamente un 13% de código, que es similar a la fuente y proporción de datos del código en ROOTS. El modelo Codex, que se afina únicamente en el código, es mucho más potente que otros modelos. En comparación con el modelo BLOOM, el modelo BLOOMZ optimizado para múltiples tareas no mejora significativamente. Suponemos que esto se debe a que el conjunto de datos de ajuste xP3 no contiene una gran cantidad de código puro.