Q8 vs Q4 sin marketing: qué se pierde de verdad

Cada cuantización tiene un precio. El problema es que el precio no es el mismo para todas las tareas, y casi todo el material que circula habla del promedio, que es justo lo que menos te dice.

Qué es la cuantización, en una frase

Es guardar los pesos del modelo con menos bits para que ocupe menos memoria. Menos bits, menos precisión. La pregunta es cuánta menos y dónde se nota.

Q8: casi sin pérdida

Q8_0 está prácticamente a la altura de FP16: la diferencia de perplejidad ronda centésimas y conserva más del 99,5 % del rendimiento. Si te cabe en memoria, no hay razón técnica para no usarlo.

Q4_K_M: el promedio engaña

Q4_K_M pierde, de media, entre un 1 % y un 3 % en benchmarks generales. Suena a poco. Y para resumir o conversar, lo es: muchas veces es imperceptible.

Pero esa media esconde los casos donde duele. Los estudios coinciden en que Q4 castiga sobre todo:

• Salida estructurada y llamadas a herramientas: hay tareas de tool-calling que pasan de acertar todo a fallar todo al bajar de Q8 a Q4.
• Código.
• Razonamiento de varios pasos.
• Contextos largos e instrucciones estrictas.

Es decir, exactamente lo que necesita un sistema que está integrado en un proceso y tiene que devolver un formato concreto.

Los números de un caso concreto

Para Qwen3.8-27B, los tamaños publicados de los distintos formatos:

Ese salto de 29 a 17,5 GB es lo que te permite pasar de necesitar 32-48 GB de VRAM a caber en una sola GPU de 24 GB. Es una diferencia real de coste. Pero es una diferencia de calidad que, en nuestro tipo de trabajo, preferimos no asumir.

Nuestra postura

Usamos Q8 en producción. No por purismo: porque la IA va dentro de tu proceso y su salida tiene que ser fiable y con formato correcto. Un error de estructura no es un texto raro, es un flujo que se rompe.

Para prototipos, pruebas o tareas que toleran imprecisión, Q5_K_M o Q4_K_M tienen todo el sentido y ahorran hardware. Lo decimos cuando es el caso.