¿Cuánta RAM Necesita un LLM Local? Guía en Apple Silicon

Ejecutar un modelo de lenguaje en local sobre hardware de consumo exige entender la memoria como un presupuesto dinámico y no como el tamaño estático de un archivo en disco. Aunque un modelo de 7.000 millones de parámetros cuantizado a 4 bits ocupa unos 4,3 GB de almacenamiento flash, ejecutarlo durante una conversación activa requiere significativamente más memoria RAM física debido al crecimiento de la caché Key-Value (KV), las activaciones temporales y la sobrecarga del sistema operativo. En dispositivos iOS, iPadOS y macOS con Apple Silicon, este cálculo determina si un asistente local funciona con alta fluidez o se cierra de forma abrupta por intervención del kernel.

La Ecuación de Memoria en Local: Pesos, Caché KV y Activaciones

Un error habitual al desplegar modelos en local consiste en asumir que la memoria disponible solo debe superar los bytes que pesa el archivo descargado. En la arquitectura transformer autorregresiva moderna, el consumo de memoria se divide en cuatro bloques independientes:

• Pesos Estáticos del Modelo ($M_{\text{pesos}}$): La huella fija de las matrices de parámetros. En cuantización afín a 4 bits, cada parámetro ocupa 0,5 bytes, más un 3% a 5% adicional por factores de escala, puntos cero y capas de normalización (RMSNorm o LayerNorm) que se mantienen en precisión de 16 bits:
  M_{\text{pesos}} \approx \frac{N \times b}{8} \times 1.05 \text{ bytes}
  Para Llama 3.2 3B ($N \approx 3.21\times 10^9$ parámetros, $b = 4$ bits), los pesos estáticos consumen aproximadamente 1,85 GB de DRAM residente.
• Caché Key-Value (KV) Dinámica ($M_{\text{KV}}$): La inferencia autorregresiva almacena las proyecciones de clave y valor de todos los tokens previos para evitar recalcular la atención de forma cuadrática $O(S^2)$ en cada nuevo paso de generación. Esta memoria crece linealmente con la longitud del contexto:
  M_{\text{KV}} = 2 \times L \times H_{\text{KV}} \times D_{\text{head}} \times S \times P_{\text{KV}} \text{ bytes}
  Donde $L$ es el número de capas, $H_{\text{KV}}$ es el recuento de cabezales de clave-valor (según Grouped-Query Attention, GQA), $D_{\text{head}}$ es la dimensión del cabezal, $S$ es la longitud de la secuencia y $P_{\text{KV}}$ es la precisión en bytes (2 bytes para FP16, 1 byte para INT8, 0,5 bytes para INT4). El factor 2 contabiliza tanto Claves como Valores.
• Activaciones de Trabajo y Espacio Temporal ($M_{\text{act}}$): Buffers intermedios necesarios durante la fase de preparación del prompt (prefill). Al procesar los tokens de entrada de forma paralela mediante multiplicaciones matriciales (GEMM), la memoria de activación escala según prefill_chunk_size \times d_{\text{model}} \times L. Para bloques estándar de 512 a 1.024 tokens, esto requiere entre 200 MB y 450 MB de DRAM temporal.
• Grafo de Ejecución y Buffers de Metal ($M_{\text{runtime}}$): En Apple MLX, los grafos de cálculo se compilan directamente en pipelines de Metal para la GPU. Aunque la arquitectura de memoria unificada (UMA) evita transferir datos por buses PCIe, los codificadores de comandos de Metal, las tablas de páginas y los pools de memoria reservan entre 180 MB y 300 MB de sobrecarga residente.

La Barrera de Jetsam en iOS: DRAM Física frente a Memoria Sucia Anónima

El modelo de memoria de iOS y iPadOS se diferencia radicalmente de macOS para escritorio. En macOS, el kernel Darwin utiliza memoria virtual con swap sobre almacenamiento flash NVMe (gestionado por dynamic_pager). Si un modelo supera la RAM física en un Mac, el sistema vuelca páginas inactivas al disco SSD; la velocidad de generación cae de 35 a 1 o 2 tokens por segundo, pero el proceso sigue en marcha.

En iOS y iPadOS, Apple desactiva por completo los archivos de paginación para proteger la durabilidad de la memoria NAND flash y asegurar la fluidez de 120 Hz de la interfaz. La asignación está controlada por el subsistema Jetsam del kernel Darwin, que vigila continuamente la memoria sucia anónima (phys_footprint obtenido mediante la llamada task_info de Mach). La memoria sucia anónima incluye memoria dinámica del heap, páginas físicas no comprimidas y buffers compartidos de la GPU con Metal que no pueden ser descartados ni leídos de nuevo desde el disco.

Si una aplicación rebasa el cupo asignado por Jetsam, el kernel emite una excepción fatal EXC_RESOURCE (RESOURCE_TYPE_MEMORY) y envía un SIGKILL (evento Jetsam 99, código de salida 0x8badf00d). Este cierre no puede ser capturado por bloques try/catch en Swift ni por excepciones de C++.

• iPhones de 6 GB (iPhone 14, iPhone 15 base): iOS reserva cerca de 2,6 GB para SpringBoard, servidores de audio, tareas de red y composición de pantalla. La memoria sucia anónima máxima permitida para una app en primer plano antes del cierre forzado oscila entre 3,2 GB y 3,4 GB. Los modelos de más de 1,5B parámetros provocan cierres frecuentes.
• iPhones de 8 GB (iPhone 15 Pro, iPhone 16, iPhone 16 Pro): Jetsam autoriza entre 4,8 GB y 5,2 GB de memoria sucia para la aplicación activa, como informa en tiempo real la función os_proc_available_memory(). Este margen permite ejecutar modelos 3B con caché KV activa en conversaciones continuadas.
• iPads y Macs de 16 GB (iPad Pro M4, MacBook Air M3/M4): Con el entitlement com.apple.developer.kernel.increased-memory-limit, una aplicación en iPadOS puede direccionar hasta 11,5 GB a 12,5 GB antes de recibir avisos de presión de memoria.

Esta restricción explica la decisión de Apple de estandarizar 8 GB de RAM en toda la gama iPhone 16: ejecutar modelos fundacionales locales de 3.000 millones de parámetros requiere un espacio continuo de 2,5 GB a 3,5 GB que un dispositivo de 6 GB no puede conceder sin expulsar procesos vitales del sistema operativo.

La velocidad de inferencia está ligada al ancho de banda del bus: la guía sobre ancho de banda en Apple Silicon para LLMs explica cómo se traduce la memoria en tokens por segundo.

Benchmarks Empíricos de Memoria en Dispositivos Apple Silicon

Para determinar las necesidades reales de hardware, evaluamos modelos fundacionales abiertos en diferentes escalas de parámetros. En cada prueba, los modelos se ejecutaron con Apple MLX bajo cuantización afín a 4 bits (tamaño de grupo 64) y una ventana de contexto fijada en 4.096 tokens.

Para reducir el consumo de DRAM en contextos largos, consulta la guía de cuantización de la caché KV en Apple Silicon.

El Peaje de Contexto en la Caché KV: Por Qué los Prompts Largos Agotan la Memoria Móvil

El fallo más común en la inferencia móvil ocurre cuando un modelo funciona bien durante pruebas con preguntas cortas, pero se cierra de golpe en conversaciones largas o al procesar documentos. Esta inestabilidad procede del crecimiento sostenido de la caché KV.

En precisión estándar de 16 bits (FP16), guardar los vectores de clave y valor en un modelo de 3.000 millones de parámetros con Grouped-Query Attention exige aproximadamente 112 KB por token. Mientras que 512 tokens consumen apenas 57 MB, ampliar la consulta a 8.192 tokens eleva la caché a 917 MB. En modelos con Multi-Head Attention clásica (MHA), donde cada cabezal de consulta tiene su propio par de claves y valores, la memoria requerida se multiplica por cuatro.

Sumado a las matrices temporales de la fase de prefill, un contexto activo de 8k tokens en Llama 3.2 3B sitúa la memoria sucia en 3,8 GB. Si una notificación push o una llamada al sistema elevan la presión de DRAM del teléfono, la app corre el riesgo de superar el límite de 4,8 GB fijado por Jetsam.

Para solucionar este cuello de botella, los motores modernos integran cuantización de la caché KV. Al comprimir los tensores de clave y valor de coma flotante de 16 bits a enteros de 4 bits (tamaño de grupo 64) en Apple MLX, el peso de la caché se reduce un 75%: pasa de 112 KB a 28 KB por token. A 8.192 tokens, la memoria baja de 917 MB a 229 MB. Esta técnica permite que un iPhone 16 Pro con 8 GB de RAM mantenga conversaciones extensas o resuma documentos largos sin aproximarse al techo de Jetsam.

Para comparar la pérdida de precisión al comprimir pesos, revisa la comparativa de cuantización a 4 y 8 bits en móvil.

Reglas de Ingeniería: Dimensionar tu LLM Local sin Cierres de Jetsam

Para asegurar una ejecución estable y mantener la máxima velocidad de generación en Apple Silicon e iOS, sigue estas prácticas de diseño de sistemas:

1. Respeta la Regla del Techo del 60% de DRAM en iOS: No configures nunca una canalización donde el consumo pico previsto (M_{\text{pesos}} + M_{\text{KV}} + M_{\text{act}}) supere el 60% de la DRAM física del dispositivo. En un iPhone de 8 GB, el límite seguro es 4,8 GB. En terminales de 6 GB, fija el umbral en 2,8 GB.
2. Aplica Cuantización Afín a 4 Bits con Grupos de 64 Elementos: Evita utilizar pesos en 16 bits sin comprimir en dispositivos móviles. La cuantización afín a 4 bits con tamaño de grupo 64 preserva la capacidad de razonamiento con una diferencia de perplejidad inferior a 0,15 puntos respecto al original, comprimiendo el peso en memoria más de un 70%.
3. Consulta Dinámicamente os_proc_available_memory() en Tiempo de Ejecución: En lugar de asumir un espacio fijo, consulta la memoria disponible al kernel Darwin antes de inicializar el modelo y durante fases de prefill extensas. Si la memoria disponible cae por debajo de 750 MB, recorta el contexto antiguo o descarta bloques de caché antes de provocar un SIGKILL.
4. Activa Cuantización de Caché KV para Contextos Superiores a 2.048 Tokens: Comprime claves y valores a 4 bits cuando el historial de diálogo o los fragmentos de documentos RAG superen los 2.000 tokens. Esta medida ahorra más de 700 MB de DRAM sin degradar la coherencia del texto.
5. Aprovecha la Memoria Unificada Compartida sin Copias en Metal: No dupliques buffers de memoria entre la lógica de la app en Swift y los shaders de Metal. Gracias a los buffers compartidos de Apple MLX (MTLResourceStorageModeShared), los tensores de parámetros son direccionables directamente por la GPU sin copias intermedias en memoria.

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