[Traducción] Estudio integral sobre los modelos de lenguaje pequeños (SLM)

Estudio integral sobre los modelos de lenguaje pequeños (SLM) (Small Language Models: Survey, Measurements, and Insights)

Introducción al artículo

Los avances recientes en los modelos de lenguaje se dividen en dos tendencias. La primera corresponde a los modelos de lenguaje grandes (LLM, Large Language Model), que operan en centros de datos a gran escala usando millones de GPU. Estos modelos se encargan de tareas lingüísticas avanzadas y buscan resolver problemas complejos, como los científicos, mediante inteligencia artificial. Sin embargo, estos LLM requieren altos costos y enormes recursos de cómputo, por lo que resulta poco realista desplegarlos en dispositivos personales.

En cambio, los modelos de lenguaje pequeños (SLM, Small Language Model) están diseñados para desplegarse en dispositivos con recursos limitados, como smartphones, tablets y wearables. El objetivo de los modelos de lenguaje pequeños es hacer que la IA sea fácilmente accesible para cualquiera al ofrecer una inteligencia artificial práctica y rentable. Este artículo es el primer estudio integral sobre los SLM y analiza los modelos de lenguaje pequeños publicados en los últimos años desde la perspectiva de la innovación técnica, el rendimiento y el costo de ejecución en dispositivos.

Arquitectura, datasets y entrenamiento de los modelos de lenguaje pequeños (SLM)

Descripción general de los modelos de lenguaje pequeños (SLM, Small Language Model)

Los SLM son más pequeños que los modelos de lenguaje con una gran cantidad de parámetros, pero han demostrado rendimiento en diversas tareas como razonamiento de sentido común, resolución de problemas matemáticos y aprendizaje en contexto. Esto muestra el potencial de una inteligencia artificial que puede ejecutarse directamente en el dispositivo.

En este estudio se revisaron los SLM, cuyo número ha crecido rápidamente desde finales de 2023, y se seleccionaron 59 modelos según los siguientes criterios para examinar su rendimiento y costo, entre otros aspectos:

• El tamaño de los modelos SLM se definió como modelos entre 100M y 5B, y solo se consideraron modelos con pesos abiertos que pudieran evaluarse.

• Para priorizar un buen rendimiento y el despliegue real, solo se consideraron modelos con arquitectura Transformer solo decodificador. Es decir, no se incluyeron modelos con arquitecturas como RWKV y Mamba.

• Como este estudio se centra en el conocimiento base obtenido durante el preentrenamiento, solo se consideraron modelos base (Base Model), excluyendo los modelos que solo ofrecen versiones ajustadas mediante instrucciones (Instruct Fine-tuned), como Microsoft Phi y StabilityAI StableLM.

• Además, también se excluyeron los modelos derivados obtenidos mediante fine-tuning de modelos preentrenados.

La lista de modelos seleccionados con base en estos criterios es la siguiente:

Arquitectura del modelo SLM (Model Architecture)

La arquitectura de los modelos SLM se basa en Transformer y presenta diversas variantes. El núcleo de la arquitectura Transformer está en la atención multi-cabeza (Multi-Head Attention, MHA) y la red neuronal feed-forward (Feed-Forward Neural Network, FFN). La MHA permite enfocarse en distintas partes de los datos de entrada, mejorando la eficiencia del procesamiento en paralelo. En los modelos recientes se han probado diversas variantes en el mecanismo de atención, la FFN y las funciones de activación, como las siguientes:

1. Mecanismos de atención (Attention Mechanisms):

   • Atención multi-cabeza (Multi-Head Attention, MHA): mecanismo central de Transformer que presta atención simultáneamente a varias partes de los datos de entrada.
   • Atención de consulta grupal (Group-Query Attention, GQA): método que agrupa varios valores de consulta para reducir la complejidad computacional de la atención.
   • Atención de consulta múltiple (Multi-Query Attention, MQA): método que reduce la complejidad computacional al permitir distintas proyecciones de claves y valores para cada consulta.

2. Red neuronal feed-forward (Feed-Forward Network, FFN):

   • FFN estándar (Standard FFN): estructura de red simple compuesta por dos capas.
   • FFN con compuerta (Gated FFN): estructura que mejora el rendimiento al incluir una capa de compuerta adicional.

3. Relación de expansión dimensional de la red feed-forward (The intermediate ratio of the FFN): es un valor que expresa como proporción el tamaño de la capa oculta (hidden layer) respecto al tamaño de la dimensión de entrada, y suele representar la relación de expansión dimensional. Cuanto mayor es esta relación, más patrones complejos puede aprender la FFN, pero también aumenta el costo computacional. En la FFN estándar normalmente es alrededor de 4, mientras que en la FFN con compuerta suele estar entre 2 y 8.

4. Funciones de activación (Activation Functions): en los SLM se usan principalmente ReLU (unidad lineal rectificada, Rectified Linear Unit), GELU (unidad lineal de error gaussiano, Gaussian Error Linear Uni), $GELU_{tanh}$ y SiLU (unidad lineal sigmoide, Sigmoid Linear Unit). En 2022 predominó ReLU; en 2023, GELU y sus variantes; y en 2024, SiLU se ha convertido en la función de activación más utilizada.

5. Normalización por capa (Layer Normalization): para la normalización por capa se utilizan LayerNorm y RMSNorm. RMSNorm se usa cada vez más, lo que contribuye a mejorar la estabilidad del entrenamiento del modelo.

6. Tamaño del vocabulario (Vocabulary Size): el tamaño del vocabulario se refiere a la cantidad de tokens únicos que el SLM puede reconocer. Se confirmó que los SLM recientes tienen principalmente vocabularios de más de 50 mil palabras y que un mayor tamaño de vocabulario mejora el rendimiento.

Si resumimos cómo cambia con el tiempo la distribución de estas 6 variantes en los 59 modelos seleccionados anteriormente, obtenemos lo siguiente:

Al revisar estas arquitecturas de modelo, fue posible observar las innovaciones en arquitectura de modelos (Model Architecture Innovations):

1. Compartición de parámetros (Parameter Sharing)

   • La compartición de parámetros es una técnica usada en los modelos de lenguaje grandes (LLM) para reutilizar el mismo conjunto de pesos en varias capas o componentes de la red. Este enfoque puede reducir significativamente la cantidad de parámetros del modelo, lo que permite un entrenamiento y una inferencia más eficientes sin sacrificar rendimiento.
   • Compartición Embedding-lm_head (Embedding-lm_head sharing): compartir los pesos del embedding con la capa final lm_head es la técnica de compartición de pesos más común. Se trata de la compartición de la capa de embeddings de palabras y no tiene ninguna relación con RoPE (Rotary Position Encoding). Modelos como Gemma y Qwen utilizaron esta técnica de compartición.
   • Compartición de Attention/FFN por capa (Layer-wise Attention/FFN sharing): este método reutiliza el mismo conjunto de pesos en múltiples capas del modelo. Es común verlo en SLM/LLM donde todas las capas Transformer comparten los mismos parámetros. Por ejemplo, MobiLLaMA comparte los pesos de la FFN en todos los bloques Transformer, y MobileLLM comparte los pesos de Attention y FFN entre dos bloques Transformer adyacentes.

2. Escalado de parámetros por capa (Layer-wise Parameter Scaling)

   • Esta técnica fue propuesta y utilizada en OpenELM. Los SLM convencionales usan la misma configuración para cada capa Transformer del modelo, por lo que los parámetros se asignan de forma uniforme entre capas. A diferencia de esos modelos, cada capa Transformer de OpenELM tiene una configuración distinta (por ejemplo, número de cabezas y dimensión de la FFN), lo que permite usar una cantidad diferente de parámetros en cada capa del modelo. Gracias a esto, OpenELM puede aprovechar mejor el presupuesto de parámetros disponible (available parameter budget) para lograr una mayor precisión.

3. Compensación de no linealidad (Nonlinearity Compensation)

   • PanGu-$\pi$ analiza los modelos de lenguaje más recientes con el objetivo de resolver el problema de colapso de características (feature collapse problem). El problema de colapso de características ocurre en el aprendizaje de representaciones de alta dimensión, como en los LLM, y se refiere al fenómeno en el que el modelo aprende características iguales o muy similares para entradas diversas. Para resolver este problema, PanGu-$\pi$ compensa la no linealidad de funciones de activación como GELU o ReLU, y escala la magnitud de los valores de salida de la capa para mantener constante la amplitud de variación de la salida.

Hallazgos clave: hay dos observaciones principales sobre la arquitectura de los SLM:

1. A agosto de 2024, la arquitectura típica de los SLM adopta GQA (Group-Query Attention), FFN con compuerta (Gated FFN) usando la función de activación SiLU, una razón de expansión del FFN de entre 2 y 8 (Intermediate Ratio of FFN), RMSNorm y un tamaño de vocabulario (Vocabulary Size) superior a 50 mil. Sin embargo, estas configuraciones se han establecido principalmente de forma empírica y no han sido validadas de manera rigurosa ni pública.
2. La innovación en la arquitectura Transformer dentro de los SLM es limitada. No se ha observado evidencia sólida de que otras técnicas, aparte del método de compartir Embedding-lm_head, sean superiores a la arquitectura Transformer convencional (Vanilla Transformer). Además, estas técnicas tampoco han sido adoptadas ni investigadas de forma generalizada por múltiples grupos de investigación o empresas, por lo que será necesario validarlas en el futuro.

Conjunto de datos de entrenamiento (Training Dataset)

El rendimiento de los SLM depende en gran medida del conjunto de datos usado para su entrenamiento. En este estudio se revisaron 12 conjuntos de datos públicos utilizados por modelos SLM:

Nombre	Número de tokens	Dominio principal	Descripción y uso
The Pile	825B	ciencia, artículos académicos, texto web, documentos legales	Es un conjunto de datos que combina varios datasets pequeños e incluye texto de múltiples dominios, por lo que se utiliza para mejorar la capacidad general de comprensión del modelo.
FineWeb-Edu	1.3T/5.4T	texto educativo, libros de texto, materiales didácticos	Es un gran conjunto de datos compuesto por texto educativo filtrado de FineWeb, usado para mejorar el rendimiento del modelo en tareas relacionadas con aprendizaje y dominios educativos.
StarCoder	35B	código en Python	Es un conjunto de datos que contiene código escrito en el lenguaje de programación Python y se utiliza para entrenar modelos en tareas de generación de código y programación.
Cosmopedia	25B	texto sintético, materiales educativos	Es un conjunto de datos compuesto por texto sintético que incluye libros de texto, publicaciones de blog, historias y artículos de WikiHow, lo que ayuda al modelo a aprender diversos estilos de escritura y contextos.
RefinedWeb	5T	documentos web, artículos de noticias, blogs, documentación técnica	Es un conjunto de datos de alta calidad obtenido de CommonCrawl mediante un filtrado estricto de datos web, y se utiliza para aprender conocimiento amplio de distintos dominios en tareas de procesamiento de lenguaje natural.
RedPajama	1.2T	datos web, noticias, redes sociales	Incluye un enorme volumen de datos textuales extraídos de snapshots de CommonCrawl, y se usa para entrenar modelos basados en texto web.
Dolma	-	texto en inglés sin duplicados	Es un corpus en inglés depurado con eliminación de duplicados mediante el algoritmo MinHash, y se utiliza para optimizar el rendimiento del modelo a partir de datos refinados sin texto repetido.
WuDaoCorpora	4T	texto en chino	Es un gran corpus basado en datos en chino, que incluye 3T tokens de datos de entrenamiento y 1.08T caracteres chinos, y se utiliza para entrenar modelos de lenguaje en chino.
RoBERTa CCNewsV2	-	artículos de noticias	Es una versión actualizada del conjunto de datos de noticias de CommonCrawl, usada en tareas de procesamiento de lenguaje natural basadas en datos de noticias recientes.
PushShift Reddit	-	datos de redes sociales (publicaciones de Reddit)	Son datos recolectados desde una plataforma que recopila, analiza y almacena datos de Reddit, y se usan para entrenar modelos de lenguaje conversacional e interacción en redes sociales.
DCLM-baseline	1.35T	texto web	Es un corpus estandarizado extraído de Common Crawl, usado como conjunto de datos para modelos de lenguaje preentrenados y adecuado para diversas tareas de evaluación.
CulturaX	6.3T	texto multilingüe	Es un enorme conjunto de datos de texto multilingüe compuesto por 167 idiomas, utilizado como material textual a gran escala para entrenar modelos multilingües.

Si observamos la tendencia en el uso de datasets de preentrenamiento por parte de los SLM analizados entre 2022 y 2024, se obtiene lo siguiente:

En 2022 y 2023, el dataset de preentrenamiento más utilizado fue The Pile, pero recientemente se han propuesto más datasets, lo que ha ampliado las opciones disponibles. En 2024, el dataset The Pile ya no se está usando para el preentrenamiento de SLM, mientras que datasets como RefinedWeb y RedPajama se están volviendo cada vez más comunes. Esto muestra que están avanzando activamente los esfuerzos de investigación e ingeniería para construir datasets de preentrenamiento de mejor calidad.

A continuación, se analizó el rendimiento de los SLM según el dataset de preentrenamiento utilizado. Los SLM lanzados en los últimos tres años se clasificaron en cuatro grupos según el tamaño de sus parámetros (<1B / 1B-1.4B / 1.5-2B / 2.5B-3B), y luego se ordenaron dentro de cada grupo según la exactitud promedio (promedio de exactitud en dos tipos: razonamiento/comprensión de sentido común y resolución de problemas), como se muestra a continuación:

A partir de estos resultados, se puede ver que dos datasets recientes, DCLM(DataComp-LM) y FineWeb-Edu, muestran un rendimiento superior frente a otros datasets. Una característica común de estos dos datasets es que adoptan filtrado de datos basado en modelos.

Además, aunque la capacidad de programación no es la tarea principal de los SLM desplegados en dispositivos, con frecuencia se incluyen datos de código en datasets de preentrenamiento como StarCoder. Esto podría deberse a la creencia general de que los datos de código pueden ayudar a mejorar la capacidad de razonamiento del modelo.

Después, se examinaron la cantidad de tokens usados en el preentrenamiento y el tamaño del modelo, así como la cantidad de tokens usados en el preentrenamiento y la exactitud promedio.

Primero, según la ley de Chinchilla (Chinchilla Law), que estudia la relación entre el tamaño del modelo y la cantidad de datos usada para entrenarlo (número de tokens), la proporción óptima entre el tamaño de los parámetros del modelo y la cantidad de tokens de entrenamiento debería ser de aproximadamente 20. Por ejemplo, en el caso de un modelo de 1B, se requeriría un dataset de entrenamiento de alrededor de 20B tokens.

Como resultado de un análisis estadístico del tamaño y la cantidad de tokens de entrenamiento de los SLM lanzados entre 2022 y 2024 (figura inferior izquierda, (a)), en general, cuanto más grande es el modelo, mayor es la cantidad de tokens usada en el entrenamiento, y los modelos más recientes tienden a usar más tokens de entrenamiento. Un punto notable es que, independientemente del tamaño del modelo, los SLM se entrenan con una cantidad de tokens muy superior a la propuesta por la ley de Chinchilla (por lo general, 1.5T o más).

Al analizar la cantidad de tokens usados por los SLM en el preentrenamiento y la exactitud promedio (figura inferior derecha, (b)), se observa que, en general, estos dos indicadores tienen una correlación positiva, especialmente cuando la cantidad de tokens de entrenamiento es inferior a 700B. Sin embargo, cuando los tokens de entrenamiento superan 1T, la correlación se vuelve más débil porque la calidad de los datos de entrenamiento pasa a ser más importante que la cantidad de tokens.

Ideas clave: en los datasets de entrenamiento de los SLM hay 2 observaciones principales:

• La calidad de los datos de entrenamiento es crucial para el rendimiento de los SLM y ha ido recibiendo cada vez más atención en la investigación reciente sobre SLM. En general, el impacto de la calidad de los datos en los SLM suele ser mayor que el de la cantidad de datos y la arquitectura del modelo. Una tendencia notable en la investigación sobre datasets es el uso de filtrado basado en modelos, con FineWeb-Edu (1.3T/5.4T) y DCLM-baseline (4T) como ejemplos principales. Los SLM entrenados con estos dos datasets mostraron un rendimiento competitivo frente a los SLM entrenados con datasets privados.
• Recientemente, los SLM se entrenan con grandes volúmenes de tokens de entrenamiento (por lo general, 1.5T o más) sin importar el tamaño del modelo. En algunos casos también se usa una menor cantidad de datos. (Ej.: Qwen2-0.5B usó 12T tokens, pero Qwen2-1.5B solo usó 7T tokens). Esto significa que han sido entrenados de forma considerablemente "excesiva" (over-training) en comparación con la ley de Chinchilla, y ese sobreentrenamiento se utiliza para desplegar SLM más potentes (powerful SLM) invirtiendo más tiempo de entrenamiento.

Algoritmos de entrenamiento (Training Algorithm)

Existen varios algoritmos para entrenar SLM. Entre los principales están Maximal Update Parameterization (μP), destilación de conocimiento (Knowledge Distillation) y la estrategia de preentrenamiento en dos etapas (Two Stage Pre-training).

1. Maximal Update Parameterization (μP): garantiza un entrenamiento estable independientemente del ancho de las capas del modelo mediante el control de la inicialización del modelo (initialization), la tasa de aprendizaje por capa (layer-wise learning rate), la magnitud de activación (activation magnitude), entre otros factores. Este método no solo mejora la estabilidad del entrenamiento, sino que también mejora la transferibilidad (transferability) de los hiperparámetros de entrenamiento desde modelos pequeños hacia modelos grandes, permitiendo usar la misma tasa de aprendizaje (learning rate), entre otros. Cerebras-GPT entrena sus modelos con esta técnica.

2. Destilación de conocimiento (Knowledge Distillation): es un concepto ampliamente utilizado en los modelos de lenguaje grandes (LLM), que consiste en extraer conocimiento valioso de un modelo maestro grande y complejo para entrenar un modelo estudiante más pequeño y eficiente. Estas técnicas de destilación de conocimiento (KD) funcionan minimizando la diferencia entre las salidas de ambos modelos, de modo que el modelo estudiante aprenda de manera aproximada el comportamiento y las predicciones del modelo maestro. LaMini-GPT y Gemma-2 utilizaron esta técnica.

3. Preentrenamiento en dos etapas (Two Stage Pre-training): como su nombre lo indica, es una estrategia de entrenamiento en la que el modelo pasa por dos etapas distintas. Primero, en la fase de preentrenamiento (Pretraining Phase), se entrena con grandes volúmenes de datos de baja calidad. Este proceso requiere más recursos de cómputo. Después, en la fase de refinamiento (Annealing Phase), se mezclan datos SFT (Supervised Fine-Tuning) de alta calidad y orientados a tareas específicas con los datos de preentrenamiento. MiniCPM utiliza esta técnica.

Capacidades de los SLM (Capabilities)

Datasets y métricas de evaluación de los SLM (Evaluation Datasets and Metrics)

Este estudio organizó 12 datasets para evaluar el rendimiento de los SLM en 3 categorías: razonamiento de sentido común (Commonsense Reasoning), resolución de problemas (Problem-Solving) y matemáticas (Mathematics):

Nombre	Tipo	Descripción y uso
HellaSwag	Razonamiento de sentido común	Prueba la comprensión narrativa y evalúa posibles completaciones de oraciones.
TruthfulQA	Razonamiento de sentido común	Es un dataset que evalúa si el modelo evita proporcionar información falsa.
Winogrande	Razonamiento de sentido común	Es un dataset que evalúa la capacidad de razonamiento de sentido común mediante la resolución de ambigüedad pronominal.
CommonsenseQA	Razonamiento de sentido común	Presenta problemas de razonamiento de sentido común en formato de opción múltiple que requieren conocimiento cotidiano.
PIQA	Razonamiento de sentido común	Es un dataset que evalúa razonamiento físico de sentido común e interacción entre objetos.
OpenBookQA	Razonamiento de sentido común	Incluye problemas científicos abiertos que deben resolverse combinando conocimiento científico y sentido común.
BoolQ	Razonamiento de sentido común	Evalúa la capacidad de razonamiento de sentido común y factual mediante preguntas de sí/no.
ARC Easy	Resolución de problemas	Es un dataset que incluye problemas científicos sencillos para probar conocimiento general y razonamiento.
ARC Challenge	Resolución de problemas	Presenta preguntas complejas de exámenes de ciencias que requieren integración de conocimiento.
MMLU	Resolución de problemas	Es un dataset que evalúa la capacidad de resolución de problemas en diversas disciplinas académicas.
GSM8K	Razonamiento matemático	Es un dataset que evalúa habilidades de razonamiento matemático de nivel primaria.
Minerva Math	Razonamiento matemático	Evalúa capacidades avanzadas de razonamiento matemático en diversos temas.

Durante la evaluación, la métrica principal utilizada es la exactitud (Accuracy), calculada como la proporción de predicciones correctas respecto al número total de ejemplos del dataset de evaluación. En las tareas de razonamiento de sentido común, resolución de problemas y matemáticas, se evalúa si se eligió la respuesta correcta o qué tan precisa fue la solución proporcionada.

Rendimiento general de los SLM (Overall Capabilities)

Se realizaron experimentos con SLM seleccionados en tres tareas —razonamiento de sentido común, resolución de problemas y matemáticas—, y el progreso se analizó como se muestra en la figura de abajo. En general, se observó una mejora significativa del rendimiento; en concreto, hubo mejoras de 10.4%, 13.5% y 13.5% en cada tarea, respectivamente. En comparación, el modelo de lenguaje grande de código abierto LLaMA solo registró una mejora promedio de 7.5% durante el mismo período:

En particular, la familia Phi de Microsoft, entrenada con datasets privados, mostró un rendimiento superior al de todos los demás modelos al alcanzar un nivel comparable al de LLaMA 3.1 reciente de 7B (67.6% en razonamiento de sentido común y 72.4% en resolución de problemas). Aunque todavía existe cierta diferencia en matemáticas, la brecha entre SLM y LLM se está reduciendo rápidamente en el razonamiento general. Aunque existen excepciones como Qwen2, en general se observa una tendencia a que el rendimiento mejore conforme aumenta el tamaño del modelo.

Aunque algunos SLM pioneros se entrenan con datasets privados, la brecha entre modelos de código abierto y modelos privados en tareas de razonamiento de sentido común se está reduciendo gradualmente. Por ejemplo, SmolLM y DCLM-1B muestran un rendimiento sobresaliente en razonamiento de sentido común gracias a datasets de alta calidad como DCLM y FineWeb-Edu (con 64.2% y 63.8%, respectivamente). Sin embargo, en tareas que requieren razonamiento complejo o lógica, especialmente en matemáticas, sigue existiendo una brecha considerable debido a la falta de datasets de alta calidad.

Hallazgos clave: hay 4 observaciones principales sobre el desarrollo de los SLM:

• De 2022 a 2024, los SLM lograron mejoras significativas de rendimiento en diversas tareas de lenguaje. En general, muestran avances considerables y superan las mejoras de LLaMA-7B (versiones 1/2/3/3.1). Estos resultados hacen pensar que podrán resolver diversas tareas específicas downstream en dispositivos on-device.
• La familia de modelos Phi muestra de forma consistente un rendimiento de vanguardia (state-of-the-art) en la mayoría de las tareas. Phi-3-mini alcanzó, hasta septiembre de 2024, una precisión comparable a la de Llama-3.1-8B. Se estima que este rendimiento se debe a la cuidadosa ingeniería de datos de Microsoft, aunque también podría atribuirse al ajuste por instrucciones (instructive tuning) sobre datasets específicos y a un posible sobreajuste (potential overfitting).
• En general, cuanto mayor es el tamaño del modelo, mejor es el rendimiento, aunque existen casos excepcionales como Qwen2-1.5B. Estas excepciones muestran que modelos más pequeños pueden destacar en tareas específicas.
• En el razonamiento de sentido común, el rendimiento de los SLM entrenados con datasets de código abierto está cerrando la brecha con los SLM privados. Sin embargo, en tareas que requieren razonamiento o lógica compleja todavía existe una diferencia considerable, por lo que se necesitan datasets enfocados en razonamiento matemático.

Capacidades de aprendizaje en contexto (In-Context Learning Capabilities)

El aprendizaje en contexto (In-Context Learning, ICL) es una capacidad importante de los SLM: la habilidad de realizar nuevas tareas a partir del contexto de entrada proporcionado. Se realizaron experimentos sobre las capacidades de ICL usando distintos modelos y variantes de 2B de cada modelo en 8 tareas, incluidas inferencia de sentido común y resolución de problemas. En general, los SLM pudieron obtener ventajas considerables en todas las tareas. Sin embargo, en datasets simples como HellaSwag y PIQA, de forma excepcional mostraron un rendimiento similar sin importar la cantidad de ejemplos de ICL (ICL shots). Fuera de eso, en promedio, el aprendizaje en contexto con 5 ejemplos (5-shot) mejora el rendimiento zero-shot en 2.1% en todas las tareas.

En particular, el modelo Gemma2 mostró la mayor mejora, con un aumento de precisión de 4.8%. Como excepción, el modelo LaMini presentó una caída de rendimiento de más de 2%. A partir de esto, se planteó la hipótesis de que LaMini está sobreajustado (overfitting) a su dataset de entrenamiento, por lo que ejemplos adicionales podrían introducir ruido.

En general, se pudo confirmar que, a medida que aumenta el tamaño de los SLM, también mejora su desempeño en aprendizaje en contexto (ICL capability).

Hallazgos clave: hay 2 observaciones principales sobre las capacidades de aprendizaje en contexto de los SLM:

• En general, la mayoría de los SLM incluyen cierto nivel de capacidad de aprendizaje en contexto. Sin embargo, esta capacidad varía según el tipo de tarea: la mayoría de los SLM mejoran mucho en la tarea Arc Challenge, pero la mejora es mínima en casos como HellaSwag o PIQA.
• Cuanto mayor es el tamaño del modelo SLM, más fuerte tiende a ser su capacidad de aprendizaje en contexto en comparación con modelos más pequeños. Algunos SLM de menor escala, como LaMini, incluso muestran una caída de rendimiento al usar aprendizaje en contexto.

Costo de ejecución (Runtime Cost) de los SLM

El costo de ejecución (Runtime Cost) de los SLM incluye la latencia y el uso de memoria (memory footprint) al ejecutar el modelo en un dispositivo real. Este estudio evalúa el rendimiento en tiempo de ejecución de los SLM y analiza los resultados experimentales en distintos tipos de hardware. También explica cómo la arquitectura del modelo y la cuantización (quantization) afectan el rendimiento, y a partir de ello aborda cómo pueden optimizarse los SLM en entornos en tiempo real.

Para medir el costo de ejecución, se usaron los siguientes dos tipos de dispositivos edge. Uno es Jetson Orin, utilizado principalmente en dispositivos edge como drones o robots pequeños; el otro es un smartphone, de uso cotidiano entre las personas. En concreto, fueron los siguientes:

Nombre del dispositivo	Tipo de hardware	Especificaciones
Jetson Orin NX 16GB	GPU	1024-core NVIDIA Ampere architecture GPU with 32 tensor cores, 16G DRAM
MEIZU 18Pro	CPU	Snapdragon 888, 8G RAM

Además, como el método para medir el número oficial de parámetros varía entre modelos, los autores usaron los valores de parámetros obtenidos de llama.cpp. Las mediciones se dividieron entre la etapa de prefill y la etapa de decode durante la inferencia, y salvo que se indique lo contrario, la longitud del prompt se fijó en 50 y la longitud de generación de tokens también en 50. Asimismo, para evitar la degradación de rendimiento por calor (thermal throttling), las pruebas se realizaron con intervalos de 10 segundos, y para medir modelos más grandes se aplicó cuantización de 4 bits (4-bit quantization).

• Medición de latencia: según el tamaño del modelo, se mide el tiempo de generación del primer token (prefill) y el tiempo de generación de cada token posterior (decode).
• Medición de uso de memoria: se mide el uso de la caché KV y de los búferes de memoria para analizar cuánta memoria ocupa el modelo.

Resumen del costo de ejecución (Overview)

A continuación se presenta un resumen de la latencia de inferencia (Inference Latency) y el uso de memoria (Memory Footprint) de los SLM tratados en este estudio:

• Inference Latency (latencia de inferencia): la latencia de inferencia de los SLM se divide en tres rangos según el tamaño del modelo: 0.1-1B, 1-2B y 2-3B. Dentro de cada rango, los modelos muestran latencias similares. En concreto, la arquitectura del modelo también influye de manera considerable en la latencia. Por ejemplo, Qwen2-0.5B muestra un tiempo para el primer token 1.46 veces mayor que otros modelos del mismo tamaño, mientras que Qwen1.5-0.5B, por el contrario, muestra un rendimiento similar al de OpenELM-1.1B, que es un modelo más grande.

  • Etapa de prefill: es la etapa en la que se procesa el prompt de entrada y se genera la caché KV; varios tokens se procesan en paralelo.
  • Etapa de decode: es la etapa en la que se predice el siguiente token con base en cada token generado, y requiere más recursos de memoria.

• Memory Footprint (uso de memoria): el uso de memoria de los SLM varía según el tamaño del modelo y la longitud de contexto (context length). En particular, modelos como Bloom-560M y Gemma-2B usan más memoria porque tienen un vocabulario muy grande (256,000 tokens). En cambio, la serie OpenELM ahorra uso de memoria al reducir el tamaño de la caché KV mediante GQA (Group-Query Attention).

> #### Hallazgos clave: hay 3 observaciones principales sobre el costo de ejecución de los SLM:
> - Además del tamaño del modelo, la arquitectura del modelo también afecta la latencia. Por ejemplo, Qwen1.5-0.5B tiene 25.4% más parámetros que Qwen2-0.5B, pero se ejecuta 31.9% más rápido en Jetson Orin. Esto significa que, al desarrollar SLM, deben adaptarse al hardware donde se desplegarán.
> - El impacto de la arquitectura del modelo en la velocidad de inferencia es mayor en la etapa de prefill que en la etapa de decode. Esto se debe a que la densidad de cómputo en la etapa de prefill es más alta, mientras que la etapa de decoding depende principalmente de la memoria (memory-bound). Las diferencias en la arquitectura del modelo pueden influir más fácilmente en escenarios limitados por cómputo (compute-bound). Por ejemplo, los modelos más anchos y menos profundos tienen mayor paralelismo computacional.
> - El uso de memoria en ejecución generalmente tiene una correlación lineal con el tamaño del modelo. Sin embargo, algunos modelos con un tamaño de vocabulario mayor consumen más memoria que otros modelos de tamaño similar. Por ejemplo, la familia Bloom tiene un tamaño de vocabulario de 250,880, entre 5 y 8 veces mayor que el de la mayoría de los modelos.

Impacto de la cuantización y el hardware (Impact of Quantization and Hardware)

Primero, se midió la latencia del modelo Phi-1.5 antes de la cuantización (FP16) y con cinco métodos de cuantización (Q8_0, Q6_K, Q5_K, Q4_K_M, Q3_K) para analizar cómo la cuantización (Quantization) afecta el costo de ejecución de los SLM:

En dispositivos móviles, el soporte para operaciones int8 puede ser limitado, pero aun así se puede reducir eficazmente la sobrecarga de acceso a memoria. Esto se debe a que la menor precisión comprime los datos y, como resultado, mejora el uso de la caché. Cada método cuantiza a n bits; Qn_K y Qn_K_M usan el método k-quant para cuantizar a n bits modelos con una cantidad intermedia de parámetros, mientras que Qn_0 se refiere a cuantización simétrica.

Efecto de la cuantización en la etapa de Prefill: cuando la longitud del prompt es corta, la cuantización reduce la latencia al menos en 25%. Sin embargo, a medida que aumenta la longitud del prompt, este efecto disminuye, y cuando la longitud del prompt se acerca a 50, los métodos Q6_K y Q3_K muestran una latencia similar o incluso mayor que la del modelo FP16 sin cuantizar. Los métodos Q8_0, Q4_K_M y Q5_K ofrecen mejoras de rendimiento estables, y en particular Q4_K_M muestra el mejor desempeño, logrando en promedio una reducción de latencia de 50%.

Efecto de la cuantización en la etapa de Decode: se observan mejoras de rendimiento más consistentes, con reducciones de latencia de hasta 75% y un mínimo de 17%. Además, al igual que en la etapa de Prefill, el método Q4_K_M es el más efectivo, mientras que Q6_K es el menos eficiente.

> #### Hallazgos clave: hay 2 observaciones principales sobre cómo la cuantización de los SLM afecta el costo de ejecución:
> - Los beneficios de la cuantización son mayores en la etapa de decode que en la de prefill. En dispositivos móviles, la cuantización reduce principalmente la sobrecarga de acceso a memoria. Como la etapa de decode está más afectada por el ancho de banda de memoria, puede beneficiarse más de la cuantización que la etapa de prefill, que está más influida por el cómputo.
> - Mientras más regular sea la precisión de cuantización (Quantization Precision), mejor será el rendimiento. La cuantización de 3 bits ofrece una mayor tasa de compresión que la de 4 bits, pero la cuantización de 4 bits brinda mejor rendimiento tanto en la etapa de prefill como en la de decode. El menor rendimiento de la cuantización de 3 bits se debe a la falta de soporte de optimización de hardware por su ancho de bits irregular (irregular bit-width), así como a la sobrecarga adicional causada por la alineación y el padding de datos (data alignment & padding). Por eso, aunque tiene una menor tasa de compresión, la cuantización de 4 bits es más eficiente; del mismo modo, las cuantizaciones de 5 y 6 bits, aunque comprimen más, muestran latencias de inferencia similares o incluso mayores que la cuantización de 8 bits.

A continuación, se probó el modelo Bloom-1B1 en Jetson Orin NX 16GB (usando GPU) y Meizu 18 Pro (usando CPU) para medir cómo el hardware (Hardware) afecta el costo de ejecución de los SLM:

Etapa de Prefill: cuando la longitud del prompt es corta, Jetson Orin muestra un rendimiento entre 10 y 20 veces más rápido que Meizu 18 Pro. Además, a medida que la longitud del prompt aumenta, la ventaja de rendimiento de Jetson se vuelve más clara. A medida que el prompt se alarga, el tiempo para generar el primer token aumenta linealmente en ambos dispositivos, pero Jetson mantiene un rendimiento estable incluso con prompts más largos.

Etapa de Decode: a medida que aumenta el número de tokens generados, la latencia por token de Meizu 18 Pro se incrementa bruscamente. En particular, la latencia sube con fuerza entre el primer y el décimo token, y después se estabiliza. Este aumento abrupto en la latencia de Meizu 18 Pro se debe al incremento de temperatura, ya que DVFS (Dynamic Voltage and Frequency Scaling) o el thermal throttling ajustan el consumo de energía y la frecuencia, reduciendo la eficiencia computacional. En cambio, Jetson presenta poca variación en la latencia hasta que se generan 30 tokens gracias a un sistema de enfriamiento más eficiente, y solo después se observa un aumento de la latencia.

> #### Hallazgos clave: hay 2 observaciones principales sobre cómo el hardware afecta el costo de ejecución de los SLM:
> - Mientras que la etapa de decode genera cada token de manera secuencial, la etapa de prefill puede procesar en paralelo los tokens dentro del prompt, por lo que muestra un rendimiento mucho más rápido en GPU.
> - En tareas de inferencia largas, Jetson muestra mejor estabilidad de rendimiento que un smartphone. Esto se debe a que Jetson, gracias a una estructura de hardware relativamente simple, disipa mejor el calor (heat dissipation).

Desglose de latencia y memoria (Latency and Memory Breakdown)

Al desglosar más detalladamente la latencia, se analizó qué proporción del tiempo total de latencia corresponde a cada capa (layer) y operación (operation) en los modelos Qwen1.5-0.5B y Qwen2-0.5B:

Los modelos Qwen1.5-0.5B y Qwen2-0.5B tienen tamaños similares, pero muestran diferencias en la latencia (latency), y mediante un análisis detallado de la latencia de cada modelo se midió la distribución del tiempo correspondiente a cada capa (Embedding, Attention, FFN, LM_Head).

Etapa de Prefill: en el modelo Qwen1.5, la capa de attention ocupa una proporción mayor que la capa FFN. Esto se debe a que el aumento en el tamaño de la caché KV requiere más cómputo en la capa de attention. En cambio, en el modelo Qwen2, la capa FFN ocupa una proporción mayor que la capa de attention. Esto ocurre porque el modelo Qwen2 tiene una capa FFN más ancha.

Etapa de Decode: en el modelo Qwen1.5, la proporción de operaciones de attention aumenta aún más. Esto se debe a que los tokens generados interactúan con los tokens generados previamente, lo que requiere más cómputo, y esta tendencia se vuelve todavía más marcada a medida que crece el tamaño de la caché KV. En el modelo Qwen2, la capa FFN sigue ocupando la mayor parte del tiempo, ya que el mayor ancho de cómputo de la FFN hace que tome más tiempo.

Al analizar los operadores (operator), en ambos modelos la operación de multiplicación matriz-vector (matrix-vector multiplication, mul_mat_vec_q) representa más del 80% del tiempo total de operación. En particular, en el modelo Qwen2-0.5B, como la capa FFN es más ancha, la operación mul_mat_vec_q ocupa una proporción aún mayor.

Además, al analizar el uso de memoria (Memory), se observa lo siguiente:

Los resultados del análisis destacan que no solo el tamaño del modelo, sino también el tamaño del vocabulario (vocabulary size), tiene un gran impacto en el uso de memoria. Cuanto mayor sea el tamaño del vocabulario que usa el modelo, mayor será el búfer de cómputo (Compute Buffer) utilizado en la capa de salida. Por ejemplo, el modelo Bloom-560M tiene un tamaño de vocabulario de 250,880, lo que hace que su búfer de cómputo alcance los 492 MB; esto implica un uso de memoria 3.5 veces mayor que el de OpenELM-1.1B, cuyo vocabulario es de 32,000.

Además, los modelos que usan GQA (Group-Query Attention) tienen un KV Cache más pequeño que los que usan MHA (Multi-Head Attention). Por ejemplo, el tamaño del KV cache del modelo OpenELM-3B es de 164 MB, aproximadamente 3.9 veces menor que el del modelo StableLM-zephyr-3B.

A medida que aumenta la longitud de contexto (context length), el búfer de cómputo (Compute Buffer) y el KV Cache se convierten en los principales factores que determinan el uso de memoria del modelo. En la serie de modelos Qwen2, cuando la longitud de contexto alcanza 131,072, el Compute Buffer y el KV Cache representan entre el 83% y el 87% del uso total de memoria. En cambio, en el caso de Qwen1.5, con una longitud máxima de contexto de 32,768, estos dos elementos representan entre el 85% y el 90% de la memoria total.

Este análisis permite entender con claridad el efecto del tamaño del vocabulario (Vocabulary Size) y de la longitud de contexto (Context Length) sobre el uso de memoria de los SLM: cuanto mayor sea el vocabulario y más largo sea el contexto, más abruptamente aumenta el consumo de memoria.

Conclusión y futuras líneas de investigación

Hasta aquí se ha realizado un estudio integral y una medición del rendimiento de modelos de lenguaje pequeños (SLM) con tamaños de 100M a 5B, además de evaluar su desempeño y sus costos de ejecución. A partir de ello, se busca analizar los logros actuales y las limitaciones de los SLM, y plantear diversos temas que requieren investigación futura:

• Diseño y optimización conjunta de la arquitectura de SLM y los procesadores del dispositivo (Co-design and co-optimizations of SLM architecture and device processors.): El rendimiento de un SLM puede variar significativamente según la configuración de su arquitectura, incluso dentro de un mismo tamaño de modelo. Por ejemplo, la relación profundidad-ancho del transformer, el tipo de attention y la función de activación tienen un impacto muy grande en la velocidad de ejecución. En particular, es importante encontrar formas de cuantizar SLM para que puedan ejecutarse eficientemente en procesadores optimizados para operaciones enteras, como las NPU (Neural Processing Unit). Para lograr los mejores trade-offs entre precisión y velocidad, es indispensable diseñar y optimizar arquitecturas adaptadas a hardware específico, y una posible línea es encontrar arquitecturas optimizadas para velocidad antes del preentrenamiento.

• Construcción de datasets sintéticos de alta calidad (Constructing high-quality synthetic dataset): Los datasets de preentrenamiento publicados recientemente, como DCLM y FineWeb-Edu, han mejorado notablemente el rendimiento de los SLM. La innovación central de estos datasets consiste en usar modelos preentrenados para filtrar datos de alta calidad dentro de corpus a gran escala. La investigación sobre datos sintéticos todavía está en una etapa temprana y tiene mucho potencial. Es urgente establecer procesos estandarizados para gestionar datos sintéticos, incluyendo deduplicación, filtrado, mezcla y evaluación.

• Extensión de la ley de Chinchilla considerando el entorno de despliegue (A deployment-aware Chinchilla law for model scaling): Según la ley de Chinchilla, para optimizar el rendimiento del modelo se necesita un equilibrio entre el tamaño del modelo y el tamaño de los datos de entrenamiento (número de tokens), aproximadamente de 1:20. Sin embargo, como los SLM deben ajustarse a la memoria y capacidad de cómputo limitadas del dispositivo, tienden a usar cantidades mucho mayores de datos de entrenamiento. Este enfoque es efectivo hasta cierto punto, pero como no es posible escalar indefinidamente la cantidad de datos de entrenamiento, encontrar el método óptimo para escalar los datos sigue siendo un problema abierto. Además, no solo deben considerarse el volumen de datos y los costos de entrenamiento e inferencia, sino también el ciclo de vida del SLM y sus beneficios económicos; la aplicación de sparsity, como en MoE (Mixture-of-Experts), hace este problema aún más complejo.

• Aprendizaje continuo on-device para personalización (Continual on-device learning for personalization): Una vez que un SLM se despliega en un dispositivo, puede aprovechar los datos locales (On-Device Data) para ofrecer mejor rendimiento o personalización sin preocuparse por la filtración de datos. Un primer enfoque consiste en usar técnicas RAG (Retrieval-Augmented Generation) para inyectar datos personales en el prompt. Este método aumenta el tiempo de generación de embeddings de texto y de procesamiento del prompt, y además requiere conservar durante largo tiempo en el dispositivo los datos para la personalización. Un segundo enfoque consiste en hacer fine-tuning del SLM, incorporando el conocimiento necesario para la personalización en los pesos del modelo y eliminando los datos después del ajuste fino. Sin embargo, el fine-tuning on-device puede generar problemas serios de recursos debido al alto consumo de memoria y energía. También podría investigarse la aplicación de zeroth-order optimization para evitar almacenar activaciones en memoria y aprovechar aceleradores de hardware durante la etapa de inferencia.

• Colaboración entre SLM y LLM en dispositivo y nube (Device-cloud SLM-LLM collaboration): Aunque las capacidades de los SLM están avanzando rápidamente, todavía existe una brecha frente a los modelos de lenguaje grandes (LLM) que se ejecutan en la nube. Para abordar esto, la colaboración entre el dispositivo y la nube será un tema de investigación importante. Intuitivamente, los SLM pueden encargarse en el dispositivo de tareas que se resuelven fácilmente, mientras que el LLM en la nube puede actuar como filtro para las tareas complejas. Sin embargo, se necesita un módulo de toma de decisiones que distinga qué tareas puede manejar el SLM y cuáles no, y se requiere más investigación para encontrar una forma adecuada de colaboración entre dispositivo y nube.

• Problemas de equidad en la evaluación del rendimiento de los SLM (Benchmarking SLMs fairly): Los SLM tienen problemas de sobreajuste, especialmente en benchmarks ampliamente usados como GSM8k. Además, muchos SLM se entrenan con datasets no públicos, lo que dificulta comparar su rendimiento de manera justa. Como los SLM se ejecutan principalmente on-device, realizan tareas distintas a las de un entorno cloud. Los SLM desplegados en smartphones tienden a manejar tareas sensibles a los datos del usuario, y esas tareas especializadas (ad-hoc task) no suelen estar incluidas en los benchmarks existentes, por lo que podrían quedar fuera de criterios de evaluación importantes.

• SLM con sparsity (Sparse SLMs): Actualmente casi no hay investigación sobre la aplicación de sparsity en SLM. Esto se debe a que, en comparación con los LLM, se espera que los SLM tengan niveles de sparsity relativamente bajos, por lo que los beneficios en velocidad o ahorro de memoria podrían ser limitados. Además, las arquitecturas basadas en sparsity, como MoE (Mixture-of-Experts), pueden reducir el uso de memoria pero aumentar la complejidad computacional, por lo que podrían no ser adecuadas para dispositivos con restricciones de memoria. Es posible escalar aún más los SLM usando almacenamiento externo del smartphone (por ejemplo, memoria flash) para guardar pesos fijos (Cold Weights) y cargarlos cuando sea necesario, pero este tipo de método requiere más investigación sobre problemas como la latencia de I/O y el mantenimiento de compatibilidad con aceleradores de hardware heterogéneos.

Artículo de investigación integral sobre modelos de lenguaje pequeños: Small Language Models: Survey, Measurements, and Insights

https://arxiv.org/abs/2409.15790

Página principal del proyecto

https://ubiquitouslearning.github.io/TinyLLMLeaderBoard/#/slm

Repositorio de GitHub

https://github.com/UbiquitousLearning/SLM_Survey

---

Este artículo se basa en un texto resumido con un modelo GPT, por lo que puede haber partes organizadas de forma distinta al contenido o la intención del texto original. Si el tema te interesa, ¡te recomendamos consultar también la fuente original! Si al leer encuentras algo extraño o incorrecto, te agradeceríamos que nos lo hicieras saber en los comentarios. 🤗

⚠️Publicidad⚠️: ¿Te resultó útil este artículo recopilado por 🔥la comunidad de usuarios de PyTorch en Corea🇰🇷? Si te registras como miembro, te enviaremos por correo electrónico💌 los artículos principales. (Por defecto es Weekly, pero también puedes cambiarlo a Daily.)