Cuantización 4-Bit vs 8-Bit en LLM para móvil

En la inferencia local de modelos de lenguaje (LLM) en iOS, la compresión de precisión no es un simple ahorro de almacenamiento; representa la frontera física entre una aplicación fluida y el cierre inmediato del proceso por el kernel. Aunque la cuantización de 8 bits se consideró durante años el estándar para preservar la fidelidad numérica en GPUs de escritorio, los chips Apple Silicon de consumo operan bajo memoria unificada y estrictos límites de memoria del sistema operativo. Analizar los compromisos entre 4 bits y 8 bits revela por qué 4 bits constituye el régimen óptimo en iPhone, duplicando la velocidad de generación y garantizando la estabilidad frente a los límites de memoria de iOS.

La mecánica de la cuantización post-entrenamiento: INT8 frente a INT4

La cuantización post-entrenamiento (PTQ) transforma los pesos continuos en coma flotante de 16 bits (FP16 o BF16) en representaciones enteras de menor ancho de bits. Matemáticamente, la cuantización lineal afín mapea los pesos w en intervalos discretos mediante un factor de escala s y un punto cero z:

q = clamp(round(w / s) + z, q_min, q_max)

Durante la inferencia, la descuantización reconstruye la aproximación en coma flotante mediante w_aprox = s × (q - z). La diferencia estructural entre 8 bits (INT8) y 4 bits (INT4) radica en la densidad de representación:

• Cuantización en 8 bits (INT8): Dispone de 256 intervalos discretos (de -128 a 127). El ruido de cuantización es prácticamente imperceptible. Las activaciones atípicas (outliers)—valores extremos que surgen en proyecciones de atención y capas MLP—se absorben de forma natural sin recortar la distribución de pesos circundantes.
• Cuantización en 4 bits (INT4): Ofrece únicamente 16 intervalos discretos (de -8 a 7, o de 0 a 15). Un enfoque ingenuo por tensor o por canal destruye la precisión del modelo: un único valor extremo expande el factor de escala s, haciendo que la inmensa mayoría de los pesos normales colapsen en el mismo valor cuantizado.

Para solucionar esta degradación, Apple MLX y los motores modernos de inferencia aplican cuantización afín por grupos. En lugar de calcular una escala única para una matriz entera, los pesos se dividen en bloques independientes de 32, 64 o 128 elementos. Cada grupo almacena su propio factor de escala y sesgo. Con un tamaño de grupo de 64, los metadatos apenas añaden ~0.25 bits por parámetro, aislando los valores atípicos y reteniendo más del 98.5% de la fidelidad numérica original.

El modelo Roofline: Por qué 4 bits duplica la velocidad de generación

Existe una concepción errónea frecuente en el aprendizaje automático para móviles: asumir que reducir la precisión acelera la inferencia porque ahorra ciclos aritméticos de cálculo. En realidad, la generación autorregresiva de tokens monousuario (batch size = 1) está limitada de forma estricta por el ancho de banda de memoria, tal como describe el modelo analítico Roofline:

Tokens/segundo = (Ancho de banda en GB/s / Tamaño de los pesos en GB) × Factor de eficiencia

Dado que la predicción del token N+1 depende del token N, el procesador no puede evaluar tokens futuros en paralelo. Para cada token emitido, el conjunto completo de parámetros de todas las capas del transformer debe transferirse desde la memoria DRAM física a la memoria SRAM y los registros de la GPU.

Analicemos un modelo de 3.2B parámetros (como Llama 3.2 3B) ejecutado en un iPhone 16 Pro con chip Apple A18 Pro, que ofrece 68 GB/s de ancho de banda con una eficiencia sostenida de Metal de ~75%:

• En cuantización de 8 bits: Los pesos del modelo ocupan 3.21 GB en DRAM. Cada token exige transferir 3.21 GB a través del bus. A 68 GB/s y 75% de eficiencia, el rendimiento teórico es (68 / 3.21) × 0.75 ≈ 15.9 tok/s. En ejecución real con MLX y Metal, se registran 15.4 tok/s.
• En cuantización de 4 bits (grupos de 64): Los pesos ocupan 1.82 GB (incluyendo escalas y sesgos). La transferencia por el bus se reduce un 43.3%. El rendimiento teórico aumenta a (68 / 1.82) × 0.75 ≈ 28.0 tok/s. En ejecución real con MLX y Metal, alcanza 27.6 tok/s.

¿Qué ocurre con el coste de descuantización? Las GPUs de Apple Silicon cuentan con una enorme densidad de cálculo vectorial SIMD. La descompresión de dos valores de 4 bits empaquetados en un byte a registros de 16 bits se realiza directamente en los registros del threadgroup mientras el controlador de memoria precarga las siguientes líneas de caché desde la DRAM LPDDR5X. Al estar los núcleos de cálculo a la espera de datos de memoria, la descompresión no añade latencia. Pasar a 4 bits duplica la velocidad casi linealmente.

La guía de ancho de banda de Apple Silicon para LLMs amplía la relación entre tamaño de los pesos y velocidad.

La frontera de memoria: El subsistema Jetsam de iOS y la caché KV

Mientras que el ancho de banda determina la velocidad de generación, la gestión de memoria del sistema operativo impone la estabilidad. A diferencia de macOS, que gestiona la presión de memoria mediante RAM comprimida y swap en disco NVMe, iOS desactiva el archivo de intercambio en disco para aplicaciones de terceros con el fin de proteger la memoria flash y asegurar la fluidez de la interfaz.

El kernel de iOS vigila el consumo a través del subsistema jetsam. En un iPhone de 8 GB (iPhone 15 Pro, iPhone 16 o iPhone 16 Pro), el límite de memoria asignable a una aplicación en primer plano se sitúa entre 4.5 GB y 4.8 GB. Superar esta frontera provoca un cierre forzado inmediato e irrecuperable por señal SIGKILL (EXC_RESOURCE / MEMORY).

En una aplicación de chat real en local, la memoria residente total se compone de cuatro niveles:

1. Pesos base del modelo: Memoria estática de parámetros almacenada permanentemente en RAM.
2. Caché Key-Value (KV): Memoria dinámica que se incrementa de manera lineal con la extensión de la conversación: 2 × capas × cabezales × dim_cabezal × tokens × bytes.
3. Picos de activación en prefill: Tensores de multiplicación matricial asignados momentáneamente durante la lectura inicial del prompt.
4. Entorno de la aplicación y estado de Metal: Búferes de pantalla, interfaz gráfica, tokenizador y pipelines de Metal (~250–350 MB).

Esta estructura revela el riesgo crítico de los modelos en 8 bits en móvil. Un modelo de 3B en 8 bits requiere 3.21 GB de RAM fija. Cuando un usuario introduce un prompt de 800 tokens y la conversación progresa a 2.048 tokens, la caché KV en FP16 suma ~260 MB y el pico de prefill añade otros ~450 MB. La memoria dirty alcanza 3.92 GB. Si el contexto supera los 4.096 tokens (~520 MB de caché) o el usuario procesa una imagen, el consumo sobrepasa los 4.6 GB. Jetsam cierra la app de forma fulminante.

En cambio, con cuantización de 4 bits, el mismo modelo de 3B ocupa solo 1.82 GB de memoria base. Incluso con 8.192 tokens de contexto (~1.05 GB de caché) y picos de prefill, el consumo total no supera los 3.3 GB, garantizando más de 1.2 GB de margen de seguridad bajo el umbral de jetsam.

La precisión de los pesos no determina la de la caché. Consulta el análisis de cuantización de la caché KV para valorar ambos costes.

Comparativa técnica: 4 bits frente a 8 bits en arquitecturas móviles

La siguiente tabla desglosa métricas reales y verificadas en modelos de lenguaje pequeños, comparando huella de memoria, velocidad de generación, perplejidad en Wikitext-2 y margen de seguridad en iOS:

Perplejidad y calidad de razonamiento: El balance empírico

El reparo histórico hacia la precisión de 4 bits se ha basado en el aumento de la perplejidad. No obstante, las leyes de escala empíricas documentadas por Dettmers y Zettlemoyer (2023) demostraron que, a medida que aumenta el volumen de parámetros, la precisión de 4 bits se consolida como la frontera óptima de Pareto entre bits de memoria consumidos y precisión en tareas.

En un modelo de 3B parámetros, pasar de 8 bits a 4 bits por grupos de 64 incrementa la perplejidad en Wikitext-2 de 6.87 a 7.02 (un incremento leve de +0.15). En benchmarks estandarizados de razonamiento, la diferencia práctica es prácticamente nula:

• MMLU (Conocimiento general en 5-shot): Pasa de 63.4% (INT8) a 62.1% (INT4)—una variación de solo 1.3 puntos porcentuales.
• GSM8K (Razonamiento matemático en 8-shot): Pasa de 44.8% (INT8) a 43.5% (INT4)—una variación del 1.3%.
• HumanEval (Generación de código en 0-shot): Pasa de 31.1% (INT8) a 30.5% (INT4)—una variación de solo 0.6%.

Este análisis empírico lleva a una conclusión arquitectónica contundente: destinar el presupuesto de memoria a una arquitectura de mayor tamaño en 4 bits supera drásticamente la opción de ejecutar un modelo menor en 8 bits.

Un modelo de 1.7B en 8 bits consume unos 1.85 GB de RAM y obtiene un 49.8% en MMLU. Un modelo de 3.2B en 4 bits ocupa prácticamente el mismo espacio (1.82 GB) y alcanza un 62.1% en MMLU—un salto cognitivo de 12.3 puntos. En entornos móviles con límites estrictos de RAM, 4 bits entrega sustancialmente más inteligencia por megabyte.

Mejores prácticas para desplegar modelos locales en iOS

Para maximizar velocidad, estabilidad de contexto y precisión al desplegar modelos locales en Apple Silicon, sigue estos criterios de ingeniería:

1. Estandariza en 4 bits con tamaño de grupo 64 para modelos sub-7B: El grupo de 64 ofrece el equilibrio óptimo entre mitigar el ruido de cuantización y no inflar la sobrecarga de metadatos. Evita cuantizaciones globales por canal sin agrupación en modelos menores de 7B.
2. Conserva al menos 2.5 GB de margen libre en terminales de 8 GB: Nunca permitas que los pesos base del modelo superen 2.2 GB en un iPhone. Reservar 2.5 GB garantiza estabilidad para la caché KV, asignaciones intermedias de prefill y consumo del sistema.
3. Cuantiza la caché Key-Value en contextos extensos: Si las conversaciones superan 4.096 tokens, comprime la caché KV a enteros de 8 bits o 4 bits. En Apple MLX, esta técnica reduce la memoria de atención entre un 50% y un 75% sin pérdida apreciable de contexto.
4. Descarta los 8 bits en modelos de más de 2B de parámetros en iOS: Aunque los 8 bits ofrecen tranquilidad teórica sobre precisión, en iOS suponen un riesgo severo de cierre en 3B y fallo inmediato en 7B. Reserva los 8 bits exclusivamente para modelos ligeros de utilidad de menos de 1.5B.
5. Aprovecha la memoria unificada con Lapis: Al conectarse directamente con Apple MLX y Metal, Lapis elimina copias innecesarias de memoria entre CPU y GPU, ejecuta la descuantización en paralelo y garantiza un funcionamiento 100% offline sin latencias de red.

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