MobileLLM: optimización de modelos de lenguaje con menos de mil millones de parámetros para casos de uso en el dispositivo

 (github.com/facebookresearch)
3 puntos por GN⁺ 2024-07-11 | 1 comentarios | Compartir por WhatsApp
  • El repositorio de MobileLLM proporciona el código de entrenamiento del paper de ICML 2024 “MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases” y aborda diseños para mejorar la calidad de modelos de lenguaje con menos de mil millones de parámetros
  • El diseño del modelo integra SwiGLU, una estructura profunda y delgada, embeddings compartidos y grouped-query attention para construir MobileLLM
  • MobileLLM-125M/350M logró una mejora de precisión de 2.7%/4.3%, respectivamente, frente a los modelos SoTA existentes de 125M/350M en tareas de razonamiento de sentido común zero-shot, y la versión actualizada también muestra resultados SoTA en 600M/1B/1.5B
  • El código de entrenamiento requiere Python 3.9 y PyTorch 2.0 o superior; pretrain.sh inicia con torchrun en un nodo 1x8 GPU, y si se aumenta el número de nodos o el batch size, la tasa de aprendizaje debe incrementarse linealmente
  • Con base en 1T tokens, el costo de entrenamiento en 32 GPU NVIDIA A100 80G es de aproximadamente 3 días para 125M, 6 días para 350M, 8 días para 600M, 12 días para 1B y 18 días para 1.5B

Objetivo de MobileLLM y alcance de la publicación

  • MobileLLM es un repositorio que contiene código de entrenamiento para optimizar modelos de lenguaje con menos de mil millones de parámetros para casos de uso en el dispositivo
  • El paper base es MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases, publicado en ICML 2024
  • El objetivo central es considerar de forma integral varios elementos de diseño para crear LLM de alta calidad incluso con menos de mil millones de parámetros

Elementos de diseño del modelo

  • MobileLLM integra los siguientes elementos de diseño
    • Función de activación SwiGLU
    • Arquitectura profunda y delgada

    • Embeddings compartidos

      • grouped-query attention
      • En la versión actualizada se plantea que esta filosofía de diseño también se extiende a modelos más grandes, mostrando resultados SoTA en MobileLLM-600M/1B/1.5B

Publicación y noticias de modelos posteriores

  • El 30 de octubre de 2024, los modelos MobileLLM se publicaron en HuggingFace
  • En septiembre de 2025 se publicó el trabajo posterior MobileLLM-R1
    • Con alrededor de 2T tokens de preentrenamiento y menos de 5T tokens en total, iguala o supera los resultados de Qwen3-0.6B entrenado con 36T tokens en MATH, GSM8K, MMLU y LiveCodeBench
    • Se publicaron el código, los modelos, los datos y la receta de entrenamiento
    • Se ofrece una colección en HuggingFace
  • En noviembre de 2025 se publicó MobileLLM-R1.5
    • MobileLLM-R1.5-950M supera a DeepSeek-R1-Distill-Qwen-1.5B en todos los benchmarks de matemáticas y programación evaluados
    • Tiene menos parámetros: 0.95B frente a 1.5B
  • En enero de 2026, MobileLLM-R1 fue aceptado en ICLR 2026

Ejecución y configuración de entrenamiento

  • Los requisitos son Python 3.9, PyTorch 2.0 o superior y pip install -r requirement.txt
  • El preprocesamiento de datos consiste en dividir datasets tokenizados o tokenizar datasets propios y luego distribuirlos según el número total de nodos de entrenamiento
    • Cada nodo está compuesto por 1x8 GPU
    • La estructura de datos coloca archivos xxx.jsonl bajo basepath/1, basepath/2, ..., basepath/#nodes
    • Cada línea de jsonl es un par clave-valor de datos tokenizados con la forma {"token_ids": [1,2,3,4,...]}
    • El código de entrenamiento es compatible con el método de preprocesamiento de datos de LLM360/amber-data-prep
  • pretrain.sh es un script que inicia el entrenamiento con torchrun en una configuración de nodo 1x8
    • Puede adaptarse a configuraciones multinodo como Slurm o TorchX modificando --nnodes y otros ajustes
    • La tasa de aprendizaje del script está basada en 1x8 nodos y batch size 32
    • Si se incrementa el número de nodos o el batch size, la tasa de aprendizaje debe aumentarse linealmente
  • El procedimiento de ejecución consiste en indicar los datos preprocesados en --train_data_local_path dentro de pretrain.sh, establecer --input_model_filename en ./configs/{model_size}/ y luego ejecutar bash pretrain.sh
  • La evaluación de Wiki se ejecuta descargando el modelo, actualizando la ruta del checkpoint en eval.sh y luego corriendo bash eval.sh

Costo de entrenamiento

  • Al entrenar MobileLLM con 1T tokens, el tiempo requerido usando 32 GPU NVIDIA A100 80G es el siguiente
    • 125M: aproximadamente 3 días
    • 350M: aproximadamente 6 días
    • 600M: aproximadamente 8 días
    • 1B: aproximadamente 12 días
    • 1.5B: aproximadamente 18 días

Resultados de razonamiento de sentido común zero-shot

  • MobileLLM-125M registra 46.3 en el promedio de arc_easy, arc_challenge, boolq, piqa, siqa, hellaswag, obqa y winogrande
    • OPT-125M obtiene 42.6, GPT-neo-125M 42.9 y Pythia-160M 42.5
    • MobileLLM-LS-125M obtiene un promedio de 47.0
  • MobileLLM-350M registra un promedio de 51.3
    • OPT-350M obtiene 43.9 y Pythia-410M 46.6
    • MobileLLM-LS-350M obtiene un promedio de 52.1
  • MobileLLM-600M registra un promedio de 54.3
    • Qwen1.5-500M obtiene 48.8, BLOOM-560M 44.2 y MobiLlama-800M 50.7
  • MobileLLM-1B registra un promedio de 57.3
    • Pythia-1B obtiene 48.7, MobiLlama-1B 55.2, Falcon-1B 56.3, BLOOM-1.1B 46.9 y TinyLlama-1.1B 54.2
  • MobileLLM-1.5B registra un promedio de 59.4
    • GPT-neo-1.3B obtiene 50.6, OPT-1.3B 52.3, BLOOM-1.7B 49.6 y Qwen1.5-1.8B 56.5
    • GPT-neo-2.7B obtiene 52.8, OPT-2.7B 55.1, Pythia-2.8B 55.8 y BLOOM-3B 52.3

Proyectos relacionados y licencia

  • El código se basa en parte en el repositorio HuggingFace Transformers, que usa la Apache License
  • Se presentan los siguientes proyectos relacionados
    • SpinQuant: LLM Quantization with Learned Rotations, ICLR 2025 — Paper, Code
    • LLM-QAT: Data-Free Quantization Aware Training for Large Language Models — Paper, Code
  • Como siguiente paso se presentan MobileLLM-R1 y los modelos MobileLLM-R1.5
  • MobileLLM actualmente usa la licencia FAIR NC

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-11
Opiniones de Hacker News

  • Los modelos pequeños mejoraron un poco, pero todavía parecen insuficientes para usarlos con los mismos fines que los modelos en línea. Aun así, el avance gradual en sí está bien.
    El modelo de 1.500 millones de parámetros parece un salto bastante grande y también supera por un amplio margen a modelos más grandes. No sé por qué no lo hicieron más grande. Un modelo más eficiente que quepa en hardware del nivel de una Raspberry Pi podría cambiar las reglas del juego. Si no recuerdo mal, TinyLlama 7B apenas alcanza a ejecutarse.

    • Los modelos de lenguaje más pequeños también podrían ser útiles como parte de sistemas de reconocimiento de voz. En situaciones ambiguas o con ruido, un modelo de lenguaje puede ayudar a acotar qué palabra se dijo.
    • Imaginen que un modelo así se integre en la app de Instagram y se use para segmentación publicitaria con cómputo en el dispositivo del usuario. Entonces Facebook podría ver muchos más datos con menor costo y mucho menor riesgo de demandas.
      Para este uso, no es justo comparar un modelo pequeño con un modelo en la nube. Incluso una pequeña mejora en la precisión del modelo pequeño tiene sentido y puede traducirse directamente en ingresos.
    • No estoy seguro de que la Raspberry Pi sea el objetivo adecuado para la siguiente etapa de LLM locales, y también vale la pena considerar la distribución web mediante motores como WebLLM: https://github.com/mlc-ai/web-llm
      Aunque un modelo 7B “corra bien” en una Raspberry Pi, personalmente me parece un poco grande para descargarlo y ejecutarlo desde una interfaz basada en la web. En cambio, un buen modelo de 125M puede correr en una página web, y el tiempo de descarga al navegador local y el costo de ancho de banda no son excesivos.
    • Llama-3-8b corre bien en Raspberry Pi.

  • ¿Tiene que estar necesariamente solo en dispositivos móviles? Aunque es un uso de nicho, si no consume demasiados recursos, podría servir para hacer más interesantes los diálogos de NPC en juegos.
    Mejor aún sería poder ajustarlo de algún modo para que la conversación influya en el comportamiento o las acciones del NPC.

    • ¿Ese diálogo sería realmente interesante? Se podría aumentar la cantidad de diálogo, pero me pregunto si habría una base que resulte interesante para el jugador. Por ejemplo, los habitantes de un pueblo podrían hablar del paisaje local o de sus relaciones con otros NPC, pero las cosas que describen quizá no existan realmente dentro del juego. Personalmente, me parecería raro que los NPC empezaran a inventar cosas que no existen.
      Puedo imaginar entrenar un LLM con datos del juego para que los NPC describan el mundo real del juego. Pero no sé qué escala haría falta para que eso sea más barato que simplemente hacer que una persona escriba los diálogos. Tal vez a escala de Ubisoft sea posible. Por lo que sé, Ubisoft también ha estado investigando escritura con IA, pero principalmente para usos muy repetitivos y prácticamente cercanos al ruido, como gritos durante el combate.
    • Sería interesante que los NPC tuvieran más historia de fondo y comportamientos más complejos. Eso sí, como cualquier cosa podría influir en su comportamiento, las pruebas serían casi imposibles.

  • ¿Qué apps hay ahora para ejecutar modelos así en iPhone? La única que conozco es MLC, pero ahí solo hay 3 modelos antiguos.

  • Me pregunto hasta dónde se puede llevar el enfoque de hacerlos más profundos y más delgados. En algún momento, cuando toda la FFN entre en la caché L2, creo que habrá un tramo en el que el rendimiento mejore bastante.

    • Otro estudio de Meta FAIR sugiere que, para aumentar el rendimiento manteniendo la precisión, más bien habría que podar capas profundas: https://arxiv.org/html/2403.17887v1
      Entonces debería haber un punto límite en redes pequeñas donde este enfoque funciona. Si no, los resultados se contradicen. O quizá signifique que estos nuevos modelos se pueden mejorar mucho más.
    • Me recuerda a los resultados del artículo de Google sobre EfficientT5: https://arxiv.org/abs/2109.10686. Ahí lo llaman “DeepNarrow”.

  • No sé si se me está escapando algo, pero ¿algo como la destilación de conocimiento no ayudaría aquí?

    • El artículo dice que lo intentaron: https://arxiv.org/abs/2402.14905
      Enlace profundo al HTML de la sección correspondiente: https://ar5iv.labs.arxiv.org/html/2402.14905#S3.SS5
      “Hasta ahora entrenamos modelos pequeños desde cero usando el siguiente token como etiqueta dura. También exploramos la destilación de conocimiento (KD)... Lamentablemente, la KD aumenta el tiempo de entrenamiento (2,6~3,2 veces más lento) y mostró una precisión similar o menor que el entrenamiento basado en etiquetas (ver el apéndice para más detalles)”.

  • Ahora mismo realmente necesito reconocimiento de voz tipo wake-word en el dispositivo. ¿Cuál es el modelo con menor WER que pueda ejecutarse en una Raspberry Pi 4B? Estoy mirando openWakeWord para un sistema de inventario DIY.

  • Parece que, en los modelos pequeños, la mayor reducción de tamaño viene de compartir embeddings/atar pesos entre la cabeza lineal y los embeddings de tokens. Me pregunto si hay investigación en curso para reducir aún más desde ahí

    • Si con eso quieren decir que el LM-head es simplemente la matriz de embeddings invertida, eso ya se hacía en GPT-2.
      Lamentablemente, lo único que encontré al respecto es que los modelos grandes se benefician de tener una capa separada. Pero lo vi en algún lugar de Discord, así que no tengo un paper para leer; por intuición personal, creo que también debería funcionar en modelos grandes. Al fin y al cabo, GPT-3 fue una ampliación de GPT-2.
      En mis experimentos personales, el modelo aprendía mejor cuando se le daba una tarea más difícil. Los pesos atados podrían ser una de esas cosas, la predicción de múltiples tokens también, y bitnet también puede verse así. Lo mismo ocurre con el dropout

  • ¿Y si en el escritorio no fuera IA generativa, sino simplemente IA de escritorio? Me gustaría que organizara todos mis archivos, correos y notas, y que me permitiera buscar información en mis datos

  • Suena bien. ¿Esto también se puede usar para entrenar un modelo para Windows PC? No tengo mucha RAM

    • El entrenamiento de modelos no depende del sistema operativo. La RAM depende del tamaño, y con algo de este tipo debería ser mucho más fácil hacer fine-tuning con menos RAM de GPU.
      Aun así, es muy probable que el objetivo final sea descargar modelos así, o pagar el costo de hacerles fine-tuning y luego usarlos mediante chips neuronales optimizados.
      Ahora parece más una cuestión de cuándo ocurrirá. La certificación más reciente de Windows ya exige algún tipo de chip neuronal, y mi Google Pixel 8 Pro también puede alojar modelos pequeños. El Pixel no es un teléfono barato, pero un coprocesador será mucho más barato que una GPU grande

  • Es interesante, pero aparte de un mejor autocompletado, me pregunto para qué serviría

    • Creo que podría hacerse fine-tuning para tareas de dominio estrecho, como tiny-agent https://bair.berkeley.edu/blog/2024/05/29/tiny-agent/
      Me gusta el enfoque que parece estar tomando Apple: que las tareas cotidianas las maneje un modelo pequeño ajustado, y que lo que no pueda resolver con confianza se derive a un modelo grande fuera del dispositivo. Creo que se podría crear un conjunto de entrenamiento con ejemplos en los que deba dar una respuesta de baja confianza, agregar una salida que equivalga básicamente a “pedir ayuda” y entrenarlo para elegir esa opción. Con modelos pequeños, también se podrían ejecutar varios en paralelo y hacer que otro modelo enrute la solicitud al experto adecuado
    • Cosas como leer correos, responder correos, agendar citas y usar API de servicios.
      Básicamente, cualquier tarea que requiera acción y no conocimiento. Si digo “avísale a mi esposa que voy tarde”, que se encargue hablando con algún servicio mediante esa forma mágica configurada.
      Siri maneja bastante bien la automatización del hogar incluso sin internet, pero el antiguo Asistente de Google y Alexa no lo hacían en absoluto, y creo que nunca pudieron hacerlo offline. Esto permite un asistente que funcione bien con un enfoque local primero
    • Un agente local como Siri podría encargarse de tareas simples y enrutar solicitudes más complejas
    • Se puede hacer fine-tuning para tareas relacionadas con el dispositivo. En otras palabras, prácticamente todas las funciones de las aplicaciones o servicios del dispositivo podrían estar disponibles también para un modelo pequeño.
      Podría transmitir la solicitud del usuario en lenguaje natural a la aplicación correspondiente y coordinar aplicaciones entre sí. Las solicitudes que excedan las capacidades del dispositivo podrían enviarse a un modelo en la nube. Es potente porque puede cambiar la forma en que interactuamos con el dispositivo
    • Probé Google AI en mi teléfono y, con el navegador abierto, le pedí que leyera la página; respondió que no podía acceder a internet.
      El asistente de IA que quiero debería 1) entender inglés y mi idioma nativo, 2) saber que se está ejecutando en Android o KDE/Linux y entender comandos como “abre la sección de aplicaciones en la configuración de Android”, “lee la página abierta en el navegador” o “lee el texto del popup que está abierto ahora”, además de integrarse con el sistema operativo mediante API públicas. Las grandes empresas de IA podrían competir vendiendo mejores asistentes, especialmente para usuarios multilingües.
      3) El modelo debería ser pequeño y no necesita saber cosas como geografía, historia o bandas musicales. Basta con que tenga la opción de derivar a un motor de búsqueda o a un LLM online las tareas sobre las que el usuario pregunte