Meter un modelo de 7B en tu teléfono: guía de campo de cuantización
Q4_K_M, AWQ, GPTQ, SmoothQuant — qué importa de verdad cuando solo tienes 4 GB de RAM y 4 W de presupuesto.
En móvil, la cuantización lo es todo
El cuello de botella en móvil no son los FLOPs, son los bytes. Un modelo de 7B en fp16 ocupa 14 GB. Tu teléfono tiene 4–8 GB en total, de los cuales puedes pedir prestados con realismo 1.5–3 GB para una carga de IA antes de que el SO empiece a paginar la app en primer plano. La aritmética no funciona sin cuantización agresiva.
Lo que realmente enviamos
- Q4_K_M (k-quants, mezcla por grupos) para LLMs generales — la mejor calidad por byte que hemos medido por debajo de 4 bits, con modos de fallo sorprendentemente suaves en tokens de cola larga.
- AWQ-int4 (cuantización de pesos consciente de activaciones) para código y razonamiento matemático, donde los outliers de activación pesan y el RTN ingenuo se nota.
- Pesos calientes en fp16 para la tabla de embedding y la proyección final lm_head — son una pequeña parte del total pero contribuyen de forma desproporcionada a la calidad percibida.
- Caché K/V en int8 con escala por token, manteniendo el presupuesto sin la pérdida catastrófica del KV en int4.
- GGUF como contenedor en disco, para poder cambiar el esquema de cuantización sin re-arquitectar el loader.
La perplejidad no es la métrica correcta
Al usuario no le importa la entropía cruzada del siguiente token. Le importa si el resumen es correcto, si la traducción suena natural, si el mensaje de commit describe el cambio. Tenemos un pequeño eval interno que puntúa la calidad de tarea final sobre transcripciones reales, traducciones de menú reales y diffs de commit reales. Discrepa con la perplejidad alrededor del 18% de las veces. A veces un esquema que pierde 0.3 bits de perplejidad gana 4 puntos en calidad de resumen, porque el modo de fallo pasa de "siguiente token sutilmente peor" a "menos descarrilamientos".
Lo que nos sorprendió
- El tamaño de grupo importa más que el ancho de bits en algunas capas. Bajar el group size de 128 a 64 en la FFN salvó más calidad que pasar de 4 a 5 bits en attention.
- Los outliers se agrupan. Un puñado de canales en cada bloque transformer concentra una magnitud de activación desproporcionada. Tratarlos con una rama de mayor precisión (estilo SmoothQuant o escalas por canal) es más eficiente que subir el ancho de bits global.
- Los datos de calibración son palanca. Un set de calibración de 256 muestras tomado de la carga real del producto vence siempre a uno de 8K muestras tomado de C4.
Conclusión
No elijas el esquema por paper. Elígelo por tu eval — y tu eval debe parecerse exactamente a tu producto.