Cuantización en profundidad

La cuantización encoge los pesos de floats de 16 bits a menos bits,
intercambiando un poco de calidad por mucha memoria. La versión de una
línea (Q8 ≈ sin pérdida, Q4_K_M ≈ punto óptimo, por debajo de Q3 duele)
basta para empezar a correr. Esta página baja un nivel: qué hacen
realmente las etiquetas, en qué se diferencian las K-quants de las
I-quants y dónde aparece primero la pérdida de calidad.

Por qué el 4 bits funciona en absoluto

Los pesos entrenados no son ruido uniforme. Los valores de cada tensor se
agrupan en una distribución estrecha y más o menos acampanada, y el
comportamiento de la red lo porta la forma de esa distribución — no el
último decimal de ningún peso individual. Eso vuelve los pesos
compresibles: guarda cada peso como un entero pequeño más un factor de
escala compartido, y solo pierdes detalle fino.

Una complicación real: los canales atípicos. Una fracción pequeña de
canales carga activaciones mucho mayores que el resto. Una única escala
para todo el tensor gasta su rango entero en esos atípicos y aplasta todo
lo demás hasta convertirlo en barro. Todo esquema serio de cuantización
es en el fondo un esquema de manejo de atípicos — escalas por bloque,
protección consciente de activaciones (AWQ) o calibración contra datos
reales (imatrix).

Mecánica de la cuantización por bloques

El truco esencial: corta cada tensor en bloques pequeños que comparten
una escala. Descuantizar un peso es una sola multiplicación:

w ≈ s · q                       # s: escala del bloque, q: entero almacenado

Q4_0:     bloque = 32 pesos → 1×escala fp16 + 32×enteros de 4 bits ≈ 4.5 bpw
K-quants: superbloque = 256 pesos
          1×súper-escala fp16 + 8×subescalas fp8 + enteros ≈ 4.8 bpw

bpw = bits por peso, escalas incluidas. Esa sobrecarga es la razón de
que nada sea exactamente 4.0: un peso de 4 bits es medio byte, y una
escala de 2 bytes repartida entre 32 pesos añade 0.5 bpw. Las K-quants
amortizan el coste con escalado a dos niveles — superbloques de 256 pesos
cuyos 8 subbloques llevan escalas fp8 baratas — y quedan en ~4.8 bpw con
mejor calidad que Q4_0 a tamaño similar.

Las K-quants y los sufijos _M / _S

Q4_K_M no es «Q4_K con sombrero» — el sufijo es una mezcla. El
cuantizador sube tensores específicos a una cuantización mayor mientras
el grueso se queda en Q4_K: típicamente las proyecciones de atención
(wv, wo) y a veces la tabla de embeddings de tokens suben a Q6_K.
El sufijo ordena la mezcla:

• _S (small) — los menos tensores subidos, el archivo más pequeño
• _M (medium) — la recomendación por omisión, el mejor equilibrio
  tamaño/calidad
• _L (large) — más tensores a mayor precisión, rendimientos
  decrecientes

La mezcla existe porque las capas se degradan de forma desigual: las
proyecciones de atención y los embeddings son más sensibles que las
grandes matrices feed-forward. Unos cientos de MB extra ahí compran
calidad real — por eso _M es el estándar de la comunidad en vez del
Q4_K pelado.

I-quants: calibradas, más pequeñas, lentas en CPU

Las cuantizaciones IQ (IQ4_XS, IQ3_XXS, IQ2_XS…) añaden un paso de
calibración. Primero calcula una matriz de importancia (imatrix)
corriendo el modelo sobre una muestra de texto representativo; luego
coloca los niveles de cuantización donde viven de verdad los pesos que
importan. El pago: una calidad dada a tamaño menor que la K-quant
equivalente — IQ4_XS supera a Q4_K_S con calidad igual o mejor, y las
IQ2/IQ3 hacen posibles siquiera los modelos 7–8B por debajo de 3 GB.

La contrapartida es la velocidad de decodificación. La descuantización de
las I-quant no es una multiplicación simple — necesita búsquedas que no
son potencias de dos y reconstrucción estructurada. En CPU ese cálculo
extra se ve en los tokens/s; en GPU se esconde tras la latencia de
memoria y casi no cuesta. Regla rápida: K-quants para cajas con CPU,
I-quants bien en GPU, IQ2/IQ3 solo cuando la VRAM te obliga.

La escalera de calidad, con honestidad

Tamaños de archivo aproximados para un modelo de 7–8B. Escala más o menos
lineal con los parámetros — un 14B es aproximadamente el doble:

Trata los porcentajes exactos como folclore: la pérdida depende del
modelo, el idioma y la tarea. El orden es estable incluso cuando las
magnitudes no.

Dónde duele primero la cuantización

El daño no es uniforme entre capacidades. Más o menos en orden de caída:

1. Recuerdo de hechos — nombres, fechas, números se desvían primero.
   Un modelo Q3 atribuye mal con confianza.
2. Matemáticas y razonamiento multipaso — los errores pequeños se
   componen a lo largo de la cadena.
3. Coherencia en contexto largo — recuperar desde lo profundo de un
   prompt largo se vuelve más tambaleante de lo que sugiere el
   comportamiento con prompts cortos.
4. Idiomas con menos recursos — el coreano se degrada antes que el
   inglés con cuantizaciones agresivas; los tokens coreanos fueron más
   raros en el entrenamiento, así que hay menos holgura de precisión. Si
   el coreano te importa, mantén Q5+ donde puedas.
5. Fluidez y estilo de chat — apenas se nota. Un modelo Q2 todavía
   suena bien, y esa es la trampa: la fluidez es un mal proxy del daño.

Los modelos pequeños sufren más

El error de cuantización devora redundancia, y los modelos pequeños son
los que menos tienen. Un 70B en Q4 pierde casi nada; un 3B en Q4 pierde
visiblemente más; por debajo de ~2B, las cuantizaciones agresivas pueden
destripar el modelo. Regla práctica: Q6_K o Q8_0 para cualquier cosa
por debajo de ~4B de parámetros — los GB absolutos ahorrados
aplastando un modelo pequeño son minúsculos de todos modos. Consigue la
línea base de tamaño contra capacidad en parámetros
antes de decidir dónde gastar los bits.

La caché KV es una decisión aparte

Cuantizar los pesos no hace nada a la caché KV — esa es su propia línea
de memoria (fp16 por omisión, cuantizable por separado a q8_0/q4_0 en
llama.cpp). A contexto largo la caché puede rivalizar con los pesos en
tamaño; presupuéstala por separado en caché KV.

Una escalera de decisión práctica

Ejemplo resuelto — tarjeta de 12 GB, modelo denso 8B, contexto 8k:

pesos        Q4_K_M                4.9 GB
caché KV     8k tokens, fp16       1.0 GB   (8B GQA ≈ 128 KiB/token)
sobrecarga   búferes de cómputo + ctx  ~1.5 GB
─────────────────────────────────────────
total                              ~7.4 GB  → cabe con margen de sobra

Dado el cálculo de VRAM, la escalera:

1. Presupuesto: VRAM − contexto − sobrecarga = lo que queda para pesos.
2. Cabe Q6_K → corre Q6_K. Solo cabe Q4_K_M → corre Q4_K_M sin culpa.
3. Baja a IQ4_XS/Q3 solo para que quepa el contexto o evitar la descarga
   a CPU — la descarga cuesta más velocidad de lo que cuesta calidad un
   paso de cuantización.
4. Si tu modelo objetivo no cabe en Q4, baja una clase de tamaño antes
   que cuantizar a Q2: un 8B sólido en Q4 suele vencer en la práctica a
   un 14B aplastado.

Relacionados: Cálculo de VRAM · Caché KV · Parámetros · Formatos de modelo