Cuantizacion para movil: Q4, Q5 y Q8 en dispositivos reales

La cuantizacion es lo que hace que los LLMs quepan en telefonos. Un modelo de 3B parametros a precision completa (FP16) ocupa 6GB. Cuantizado a Q4, ocupa 1.7GB. El modelo es aproximadamente el mismo, solo almacenado mas eficientemente.

Pero "aproximadamente el mismo" esconde matices importantes. Diferentes niveles de cuantizacion intercambian tamano y velocidad por calidad. Elegir el nivel correcto para tu app movil requiere entender estas compensaciones en hardware real.

Que hace la cuantizacion

Los pesos del LLM se almacenan como numeros. La precision completa usa 16 bits por peso (FP16). La cuantizacion reduce los bits por peso, encogiendo el modelo:

El sufijo "_K_M" indica k-quant con calidad media, un metodo de cuantizacion en llama.cpp que aplica diferentes anchos de bits a diferentes capas segun su importancia. Esto preserva la calidad mejor que la cuantizacion uniforme.

El punto optimo: Q4_K_M

Para despliegue movil, Q4_K_M es la eleccion estandar. Aqui esta por que:

Tamano: Aproximadamente 4x mas pequeno que FP16. Un modelo 3B cabe en 1.7GB, bien dentro del presupuesto de almacenamiento para una app movil.

Calidad: Al ~97.5% de la calidad de FP16, la degradacion es apenas medible en la mayoria de tareas. Para tareas especificas de dominio donde el modelo esta fine-tuned, los datos de fine-tuning compensan cualquier perdida por cuantizacion.

Velocidad: Pesos mas pequenos significan menos ancho de banda de memoria usado durante la inferencia. Los modelos Q4 frecuentemente se ejecutan mas rapido que versiones de mayor precision porque el cuello de botella de memoria se reduce.

Compatibilidad: Cabe en dispositivos de 4GB+ RAM (1B) o 6GB+ RAM (3B). Cubre la gran mayoria de smartphones activos.

Niveles de cuantizacion comparados en dispositivos reales

Modelo 3B, iPhone 15 Pro (A17 Pro, 8GB RAM)

Menor perplejidad es mejor. De Q4_K_M a Q8_0 abarca un rango de calidad estrecho (8.12-8.38). Por debajo de Q4, la calidad cae notablemente. Por debajo de Q3, se degrada significativamente.

Modelo 3B, Galaxy S24 (Snapdragon 8 Gen 3, 8GB RAM)

Modelo 1B, iPhone 14 (A15, 6GB RAM)

Cuando usar cada nivel

Q4_K_M (Eleccion por defecto)

Usa este a menos que tengas una razon especifica para no hacerlo. Mejor balance general de tamano, velocidad y calidad. El estandar para despliegue movil.

• Ideal para: Todas las apps moviles enviando modelos GGUF
• Requisito de dispositivo: 4GB+ (1B) o 6GB+ (3B)

Q5_K_M (Prioridad en calidad)

Usa cuando la calidad es critica y tus dispositivos objetivo tienen espacio para el archivo mas grande. La mejora de calidad sobre Q4_K_M es pequena pero medible en tareas que requieren precision de palabras.

• Ideal para: Apps medicas, legales o financieras donde la precision a nivel de palabra importa
• Requisito de dispositivo: 6GB+ (1B) o 8GB+ (3B)
• Aumento de tamano: ~25% sobre Q4_K_M

Q8_0 (Maxima calidad)

Usa solo en dispositivos flagship con amplia RAM. La calidad es casi identica a FP16. La velocidad es menor y el uso de memoria es mayor.

• Ideal para: Pruebas y benchmarking, no despliegue tipico de produccion
• Requisito de dispositivo: 8GB+ (1B) o 12GB+ (3B)
• Aumento de tamano: ~90% sobre Q4_K_M

Q3_K_M (Prioridad en tamano)

Usa cuando necesites ajustar un modelo en dispositivos limitados. La calidad cae notablemente, pero para tareas simples (clasificacion, si/no, respuestas cortas), puede ser aceptable.

• Ideal para: Dispositivos economicos, o ajustar un modelo 3B donde normalmente solo cabria un 1B Q4
• Riesgo de calidad: Degradacion notable en tareas matizadas
• Ahorro de tamano: ~18% sobre Q4_K_M

Q2_K (No recomendado)

Degradacion severa de calidad. El modelo frecuentemente genera salida incoherente o incorrecta. No apto para produccion.

Fine-tuning y cuantizacion

El fine-tuning ocurre a precision completa (FP16 o BF16). La cuantizacion se aplica despues del entrenamiento como paso de exportacion. El flujo de trabajo:

1. Fine-tunea el modelo con LoRA en tus datos de entrenamiento (precision completa)
2. Fusiona el adaptador LoRA en el modelo base
3. Cuantiza a GGUF en tu nivel objetivo (Q4_K_M para la mayoria de casos)
4. Prueba el modelo cuantizado en tu conjunto de evaluacion

Plataformas como Ertas manejan este pipeline de principio a fin. Subes datos de entrenamiento, seleccionas tu modelo base, entrenas y exportas directamente a GGUF en tu nivel de cuantizacion elegido.

La cuantizacion perjudica mas a los modelos fine-tuned?

Ligeramente. Los modelos fine-tuned tienen mas informacion empaquetada en sus pesos (conocimiento especifico de dominio). La cuantizacion agresiva (Q3 e inferior) puede perder algo de este conocimiento especifico.

En la practica, Q4_K_M preserva bien la precision del fine-tuning. La diferencia de calidad entre Q4_K_M y FP16 en benchmarks especificos de dominio es tipicamente menor a 2 puntos porcentuales. Q3_K_M puede mostrar 3-5 puntos de degradacion.

Recomendaciones practicas

1. Por defecto usa Q4_K_M. Es el estandar por una razon. Prueba con este primero.
2. Fine-tunea antes de optimizar la cuantizacion. Un modelo Q4 fine-tuned supera a un modelo Q8 sin fine-tuning en tareas de dominio.
3. Prueba en tu tarea, no en benchmarks generales. La perplejidad es un proxy. Lo que importa es la precision de tu modelo en tu conjunto de evaluacion especifico en tu nivel de cuantizacion elegido.
4. Ofrece un nivel de cuantizacion por tamano de modelo. No hagas que los usuarios elijan entre Q4 y Q5. Envia Q4_K_M para amplia compatibilidad. Si soportas tanto 1B como 3B, eso es suficiente opcionalidad.
5. Mide el rendimiento del mundo real. Ejecuta tu suite de evaluacion en el modelo cuantizado. Si la precision esta dentro del 2% de FP16, envialo.