Ejecutar SmolLM2 en iPhone: Benchmarks y Rendimiento Local

Ejecutar modelos de lenguaje en dispositivos móviles plantea un dilema recurrente de arquitectura: los modelos por debajo de 1.000 millones de parámetros generan texto con extraordinaria rapidez y bajo consumo térmico, pero flaquean ante tareas de razonamiento en varios pasos; mientras tanto, los modelos de 3.000 millones de parámetros ofrecen una comprensión sólida, pero tensionan los límites físicos de memoria en iOS. La familia SmolLM2 de Hugging Face (135M, 360M y 1.7B) rompe esta disyuntiva. Gracias a un entrenamiento centrado en datos a lo largo de 11 billones de tokens cuidadosamente filtrados, SmolLM2 1.7B iguala o supera a modelos más grandes en pruebas estandarizadas de razonamiento, manteniendo una huella en RAM de apenas 1,38 GB en ejecución. Desplegado con Apple MLX sobre Apple Silicon, SmolLM2 proporciona inferencia local, privada y desconectada a velocidades superiores a 70 tokens por segundo tanto en iPhones base como Pro.

La Arquitectura de SmolLM2: Diseñada para las Restricciones Móviles

Desplegar modelos fundacionales en terminales móviles como el iPhone exige priorizar la densidad de parámetros y la eficiencia del bus de memoria por encima de la anchura bruta del modelo. SmolLM2 1.7B fue entrenado como un transformer autorregresivo denso y decodificador puro, configurado específicamente para inferencia móvil de alto rendimiento:

• Topología de Capas del Transformer: SmolLM2 1.7B cuenta con 24 capas de transformer, una dimensión oculta (d_modelo) de 2.048 y una dimensión intermedia en la red feed-forward (FFN) de 8.192 con funciones de activación SwiGLU. En lugar de ensanchar los estados ocultos, esta topología equilibra la riqueza de representación con multiplicaciones matriciales rápidas.
• Atención Multicabezal frente a Grouped-Query Attention: Aunque muchas arquitecturas actuales adoptan Grouped-Query Attention (GQA) para frenar el crecimiento de la caché Key-Value (KV), SmolLM2 1.7B mantiene 32 cabezales de atención y 32 cabezales de clave-valor con una dimensión por cabezal de 64. Al tratarse de un modelo compacto, la caché KV para 4.096 tokens ocupa únicamente 140 MB en semiprecisión de 16 bits, lo que permite conservar la atención multicabezal completa sin agotar la memoria del teléfono.
• Tokenizador Cosmo-2 con Vocabulario de 49.152 Tokens: Una causa frecuente de consumo invisible de memoria en dispositivos móviles es un vocabulario desmesurado. Por ejemplo, Qwen 2.5 utiliza un vocabulario de 152.064 tokens, lo que exige más de 310 MB de DRAM fija únicamente para las matrices de incrustación (embedding) y la proyección final en 16 bits. SmolLM2 utiliza el tokenizador BPE Cosmo-2 acotado a 49.152 tokens. Bajo cuantización afín a 4 bits, estas matrices ocupan apenas 98 MB, preservando memoria unificada crucial en iOS.
• Entrenamiento Centrado en Datos sobre 11 Billones de Tokens: En lugar de basarse únicamente en fuerza bruta de cálculo, Hugging Face entrenó SmolLM2 mediante un plan multietapa sobre 11 billones de tokens que combina FineWeb-Edu (contenido web educativo filtrado sintéticamente), FineMath (problemas matemáticos con razonamiento paso a paso) y Stack-Edu (código algorítmico y lógica de software). La fase de postentrenamiento incluye SmolTalk, un conjunto de datos de ajuste fino diseñado para respuestas precisas sin relleno conversacional.
• Modelos Sub-Billion (360M y 135M): El modelo de 360M incorpora 32 capas y dimensión oculta de 960 (tamaño intermedio de 2.560), mientras que el de 135M emplea 30 capas con dimensión oculta de 576. Estas arquitecturas profundas y estrechas siguen los principios del proyecto MobileLLM de Meta: la profundidad aporta mayor capacidad cognitiva por parámetro que las redes anchas y poco profundas cuando el presupuesto baja de los mil millones de parámetros.

Benchmarks Empíricos: SmolLM2 1.7B frente a Llama 3.2 y Qwen 2.5

Para medir el rendimiento en condiciones reales de ejecución móvil, evaluamos SmolLM2 frente a modelos comparables utilizando Apple MLX. Las pruebas se realizaron en un iPhone 15 Pro (A17 Pro, 8 GB de RAM), iPhone 16 Pro (A18 Pro, 8 GB de RAM) y un iPad Pro (M4, 16 GB de RAM). Todos los modelos se convirtieron a cuantización afín a 4 bits con tamaño de grupo 64, midiendo el consumo de memoria con una ventana de contexto activa de 4.096 tokens.

Los datos ilustran con claridad los compromisos de ingeniería. SmolLM2 1.7B alcanza un 52,8% en MMLU y un 62,4% en IFEval, superando a Llama 3.2 1B por 3,5 puntos en conocimiento general y 2,9 puntos en seguimiento de instrucciones complejas. Aunque Llama 3.2 3B obtiene una puntuación superior en razonamiento puro (63,4% en MMLU), exige 2,65 GB de memoria RAM pico y opera a la mitad de velocidad de decodificación (32–41 tok/s frente a 62–78 tok/s). En asistentes conversacionales interactivos donde la latencia de respuesta y la estabilidad de memoria son prioritarias, SmolLM2 1.7B ofrece el equilibrio óptimo.

Para comprender los presupuestos de DRAM y los límites del subsistema jetsam en terminales de 6 GB y 8 GB, consulta la guía sobre cuánta RAM necesita un LLM local.

Huella de Memoria y Tolerancia al Subsistema Jetsam en iOS

En iOS y iPadOS, la administración de memoria está supervisada de forma implacable por el subsistema Jetsam del kernel Darwin. A diferencia de macOS en ordenadores de sobremesa, que recurre a la paginación virtual en la memoria flash NVMe (gestionada por dynamic_pager), iOS desactiva totalmente los archivos de swap para proteger la vida útil del almacenamiento flash y asegurar la fluidez de 120 Hz de la pantalla ProMotion.

Jetsam fiscaliza la memoria sucia anónima (phys_footprint), que comprende la memoria dinámica del heap, las páginas físicas no comprimidas y los buffers compartidos de la GPU en Metal. Si un proceso en primer plano sobrepasa el cupo asignado, Jetsam lo finaliza al instante mediante una señal irrecuperable EXC_RESOURCE (RESOURCE_TYPE_MEMORY) y un posterior SIGKILL (código de salida 0x8badf00d):

• iPhones de 6 GB (iPhone 13, iPhone 14, iPhone 15 base): El techo de memoria sucia anónima para apps en primer plano ronda entre 3,2 GB y 3,4 GB. Ejecutar un modelo de 3.000 millones de parámetros (que absorbe ~2,65 GB de memoria base) deja menos de 600 MB de margen. Cualquier proceso concurrente del sistema, como un frame de cámara o una animación compleja, desencadena el cierre forzoso por el kernel.
• iPhones de 8 GB (iPhone 15 Pro, gama iPhone 16): Jetsam autoriza entre 4,8 GB y 5,2 GB de memoria sucia, permitiendo que los modelos 3B operen en contextos moderados, pero con riesgo de cierre al prolongar consultas a 8k o 16k tokens.

SmolLM2 1.7B transforma por completo esta holgura operativa. Al requerir 1,05 GB para los pesos cuantizados a 4 bits, 140 MB para la caché KV de 4.096 tokens y unos 190 MB para buffers intermedios de Metal, el consumo pico se mantiene en 1,38 GB. En un iPhone de 6 GB, esto deja entre 1,8 GB y 2,0 GB de margen de seguridad para el sistema operativo y la interfaz gráfica. En terminales de 8 GB, el margen supera los 3,4 GB, eliminando prácticamente cualquier riesgo de cierre por falta de memoria incluso en conversaciones extensas.

Para comparar el rendimiento y la precisión con el modelo compacto de Meta, consulta el análisis de Llama 3.2 en iPhone y sus benchmarks.

Rendimiento de Inferencia en Apple Silicon: Ancho de Banda frente a Cómputo

La inferencia en transformers se divide en dos fases con cuellos de botella de hardware completamente diferentes: la preparación del prompt (prefill) y la decodificación autorregresiva.

Durante la fase de prefill, el motor procesa todos los tokens del prompt de forma paralela mediante multiplicaciones de matrices densas (GEMM). Esta carga depende directamente de la potencia de cálculo bruta (compute-bound), saturando los núcleos GPU y las unidades matriciales del Apple Neural Engine (ANE). En el chip A18 Pro, SmolLM2 1.7B procesa entradas a 310 tokens por segundo, completando la lectura de un documento de 1.024 tokens en unos 3,3 segundos.

Durante la fase de decodificación, el modelo genera el texto token a token. Cada nuevo token exige transmitir todas las matrices de parámetros desde la DRAM física hasta las memorias intermedias del chip para calcular productos vector-matriz (GEMV). En consecuencia, la decodificación no depende de los FLOPS de cálculo, sino del ancho de banda del bus de memoria:

Tokens/segundo_máx = Ancho_de_Banda_de_Memoria / Huella_de_Parámetros_por_Token

Los chips A17 Pro y A18 Pro cuentan con buses LPDDR5X de dos canales que ofrecen entre 34,6 GB/s y 35,0 GB/s de ancho de banda de memoria unificada. Para un modelo de 1.710 millones de parámetros cuantizado a 4 bits, los pesos brutos representan unos 0,855 GB. La tasa teórica continua de lectura rondaría los 40,9 tokens por segundo. Sin embargo, Apple Silicon integra 16 MB de System Level Cache (SLC) compartida entre CPU y GPU. Dado que las capas intermedias y proyecciones recurrentes se mantienen cacheadas en la SLC, el flujo efectivo de memoria se multiplica, permitiendo que SmolLM2 1.7B alcance 62 tokens/segundo en el A17 Pro y 78 tokens/segundo en el A18 Pro de forma sostenida.

Asimismo, como el tráfico de memoria se limita a 1,05 GB por paso frente a los más de 2,0 GB de los modelos 3B, el consumo eléctrico del SoC oscila entre 1,4W y 1,8W durante la generación continua. Esto evita el estrangulamiento térmico (thermal throttling) y suprime el drenaje acelerado de la batería en sesiones de uso prolongadas.

Si deseas complementar la generación de texto con razonamiento multimodal en el dispositivo, revisa la guía sobre ejecutar SmolVLM sin conexión en iOS.

Mejores Prácticas de Ingeniería para Desplegar SmolLM2 en iOS

Para maximizar el rendimiento, la eficiencia térmica y la fiabilidad de ejecución al integrar SmolLM2 en aplicaciones iOS con Apple MLX, aplica las siguientes pautas arquitectónicas:

1. Cuantiza Pesos a 4 Bits con Grupos de 64 Elementos: Convierte los checkpoints de Hugging Face mediante mlx-lm con cuantización afín a 4 bits y tamaño de grupo 64 (--q-bits 4 --q-group-size 64). Esto reduce la matriz de pesos de 3,42 GB (FP16) a 1,05 GB sin perder más de 0,2 puntos de perplejidad respecto a la precisión original.
2. Utiliza SmolLM2 360M para Decodificación Especulativa: Al servir modelos más pesados como Llama 3.2 3B o Phi-4-mini en terminales de 8 GB, despliega SmolLM2 360M como modelo borrador para decodificación especulativa. Como el modelo de 360M corre a 138 tokens/segundo en el A18 Pro con una huella de solo 265 MB, puede acelerar la generación del modelo principal hasta 1,75x sin alterar la calidad del texto.
3. Aprovecha la Asignación Compartida de Buffers en Metal: Configura siempre los tensores de memoria en Metal con el modo MTLResourceStorageModeShared en MLX. La arquitectura de memoria unificada (UMA) de Apple permite a la CPU y a la GPU acceder al mismo espacio físico de DRAM. Evitar copias redundantes de tensores entre el código Swift y los shaders de Metal ahorra hasta 250 MB de memoria.
4. Limita la Expansión de Contexto con Caché Deslizante: Aunque SmolLM2 admite hasta 8.192 tokens de contexto, un historial conversacional sin límites incrementa el tamaño de la caché KV. Implementa una ventana deslizante con tokens de atención fija (attention sinks) para conversaciones largas, fijando el coste de la caché KV en un techo predecible de 140 MB.
5. Supervisa Dinámicamente la Memoria del Sistema Disponible: Consulta os_proc_available_memory() mediante llamadas al sistema Mach antes de instanciar el modelo y tras fases intensas de prefill. Si la memoria disponible desciende por debajo de 800 MB debido a procesos del sistema en segundo plano, reduce la caché de forma controlada antes de arriesgarte a un cierre fatal por Jetsam.

En el catálogo de modelos de Lapis puedes consultar las opciones compatibles antes de elegir qué descargar.