Elegir la cuantización (Q4, Q5, Q8, FP16)

#Cuantización: lo que intercambias por memoria

Un modelo es un conjunto de miles de millones de números, los pesos. En FP16, cada uno ocupa 16 bits: un modelo de 8 mil millones de parámetros pesa aproximadamente 16 GB. La cuantización almacena cada peso en menos bits. Según la documentación de la herramienta llama-quantize, este procedimiento reduce el tamaño del modelo y puede acelerar la inferencia, a costa de una pérdida de precisión medida en perplejidad o en divergencia de Kullback-Leibler. El formato GGUF utilizado por llama.cpp, Ollama y LM Studio agrupa estas variantes. La elección adecuada depende de tres cantidades: la memoria de tu tarjeta o de tu Mac, el tamaño del modelo y el contexto que piensas utilizar. Q4_K_M ofrece el mejor equilibrio en la mayoría de los casos, porque la pérdida de calidad se mantiene baja mientras que el tamaño se reduce a aproximadamente el 30 % del tamaño en FP16.

#Decodificar nombres: Q4_K_M, Q5_K_S, Q8_0, IQ3_XXS

El número (Q2 a Q8)

El número nominal de bits por peso. El valor real es mayor, porque los tensores sensibles se mantienen con una precisión superior: Q4_K_M tiene 4,89 bits por peso.

_0 y _1

Formatos antiguos, con un nivel de precisión uniforme. Q8_0 sigue utilizándose porque apenas presenta pérdidas, pero Q4_0 y Q5_0 han sido reemplazados por las variantes K.

_K

Los K-quants, más recientes, distribuyen los bits según la importancia de los tensores.

S, M, L

Small, Medium, Large: para un mismo número de bits, M conserva más bits en los tensores importantes que S, por lo que ocupa un poco más y pierde un poco menos de calidad.

IQ

Los I-quants, con matriz de importancia: a igual tamaño conservan mejor la calidad con un número de bits muy bajo (menos de 4 bits) y requieren un poco más de cálculo durante la decodificación. Se basan en un archivo imatrix.

#Tabla de decisión: tamaños y pérdidas medidas

El README de llama-quantize publica, para Llama 3.1 8B, el número de bits por peso y el tamaño de cada formato. La biblioteca Ollama muestra, para el mismo modelo, el tamaño de los archivos distribuidos. Ambas fuentes coinciden aproximadamente y proporcionan un orden de magnitud aplicable a otros modelos de la misma familia.

Un matiz sobre la última columna: las pérdidas de perplejidad proceden de una discusión del repositorio llama.cpp que reproduce la tabla de ayuda de la herramienta, elaborada en 2023 con un modelo de 7 mil millones de parámetros. Muestran el orden de los formatos, no el comportamiento exacto de los modelos actuales, algunos de los cuales son más sensibles.

#Calcular la memoria de un modelo en unos segundos

El tamaño de un archivo GGUF se deduce de la siguiente fórmula: el número de parámetros en miles de millones, multiplicado por los bits por peso y dividido entre ocho, da el tamaño en gigabytes. Para un 70B en Q4_K_M: 70 × 4,89 ÷ 8 ≈ 42,8 GB, lo que confirma la tabla de llama.cpp para Llama 3.1 70B (43,1 GB). Añade después la caché KV, que crece con el contexto, y un margen para el sistema.

taille du fichier (Go) ≈ paramètres (milliards) × bits par poids ÷ 8

Exemple : 32 milliards en Q5_K_M
32 × 5,70 ÷ 8 ≈ 22,8 Go
+ cache KV (selon le contexte) + 1 à 2 Go de marge

#Cómo afecta realmente la cuantización a la calidad

Las medidas de perplejidad ordenan los formatos de forma consistente: más bits, menos pérdida. Pero la perplejidad predice mal las capacidades específicas. Un estudio publicado en arXiv en enero de 2026 comparó los formatos de llama.cpp en Llama-3.1-8B-Instruct, con pruebas de razonamiento, conocimientos y seguimiento de instrucciones: la perplejidad en WikiText-2 va de 7,32 para FP16 a 8,96 para Q3_K_S, y los autores señalan que la perplejidad no es un predictor completo del comportamiento en tareas posteriores. La puntuación media de Q5_0 supera incluso ligeramente la del FP16 (69,92 % frente a 69,47 %), lo cual se debe al ruido de medida, no a un modelo mejorado.

El resultado relevante se refiere al razonamiento matemático: en GSM8K, la puntuación pasa de 77,63 en FP16 a 68,31 en Q3_K_S. Los autores recomiendan evitar la cuantización agresiva a 3 bits y preferir Q4_K_S o Q5_0 cuando la carga implica razonamiento en varios pasos. Por tanto, las primeras tareas que se resienten con la cuantización son el cálculo, el código y las largas cadenas de razonamiento, no la conversación cotidiana.

De Q8 a Q6

Diferencia no medible en la práctica en las tablas publicadas.

De Q6 a Q4_K_M

Pérdida baja, visible especialmente en tareas de razonamiento largo, en código y en lenguas poco representadas.

Por debajo de 4 bits

Caída marcada en el razonamiento: evitar salvo que sea necesario por limitaciones de memoria.

#¿Por qué un archivo más pequeño genera también más rápido?

Las mediciones del README de llama.cpp, realizadas con Llama 3.1 8B, ilustran un punto que las guías omiten: la generación de texto lee la totalidad de los pesos activos en cada token, por lo que depende principalmente de la cantidad de bytes que hay que leer. En esta tabla, la tasa de generación pasa de unos 51 tokens por segundo en Q8_0 a unos 72 en Q4_K_M y a 90 en Q2_K_S. La lectura del prompt, en cambio, se mantiene estable en torno a 800 tokens por segundo porque está limitada por el cálculo y no por la memoria. Estas cifras proceden de un hardware concreto del repositorio y no corresponden a tu máquina; quédate con la tendencia: menos bits, generación más rápida.

Dos consecuencias prácticas. En primer lugar, pasar de Q4_K_M a Q8_0 para obtener una mejora imperceptible de calidad supone perder aproximadamente un 30 % de velocidad de generación en estas mediciones. En segundo lugar, la cuantización de los pesos y la de la caché KV son dos ajustes distintos: la segunda reduce la memoria necesaria para un contexto largo y se trata en su propia guía.

#Elegir siguiendo tres reglas

1. 01
   Empieza con la memoria disponible que tengas

   VRAM de una tarjeta NVIDIA o AMD, o memoria unificada de un Mac menos aproximadamente un 25 % para el sistema. Si el modelo supera ese límite, el cálculo pasa a la CPU y la velocidad disminuye, a menudo hasta ser varias veces inferior.
2. 02
   Elige el modelo más grande que quepa en Q4_K_M

   A igual memoria, un modelo más grande en 4 bits suele ser mejor que uno más pequeño en 8 bits. Es una regla empírica ampliamente compartida, que debes verificar en tus propias tareas, especialmente en código.
3. 03
   Sube luego la precisión con el margen restante

   Si queda VRAM una vez reservado el contexto, pasa a Q5_K_M y luego a Q6_K. La mejora es menor que la que se obtiene al pasar de un tamaño al siguiente.

ollama run llama3.1:8b-instruct-q5_K_M

Las etiquetas de la biblioteca Ollama indican el formato y el tamaño de cada variante; cuando omites el sufijo, Ollama aplica la etiqueta predeterminada del modelo. En Hugging Face, los archivos GGUF incluyen en su nombre el nombre de la cuantización.

#Los I-quants y formatos de menos de 4 bits

La tabla de llama.cpp permite medir el ahorro real. En Llama 3.1 8B, IQ4_XS ocupa 4,17 GiB frente a 4,58 GiB para Q4_K_M, es decir, aproximadamente un 9 % menos; IQ3_XXS ocupa 3,04 GiB; IQ2_XXS, 2,23 GiB. En las mediciones del repositorio, las velocidades de generación de estos formatos se mantienen cerca de las de los K-quants, con una diferencia de unos pocos tokens por segundo: el costo adicional de decodificación es, por tanto, modesto. Los I-quants dependen, en cambio, de la calidad de la imatrix y del modelo: solo tienen sentido cuando Q4_K_M no cabe en la memoria.

IQ4_XS

De tamaño similar a Q4_K_M, pero aproximadamente un 9 % menor. Útil cuando la VRAM es escasa.

IQ3_XXS y IQ3_S

Un 13B con unos 5 GB de pesos, con una pérdida notable en el razonamiento.

IQ2 y IQ1

Solo para modelos gigantescos, cuando ninguna otra opción cabe. En este tipo de cuantizaciones, la fidelidad se mide: ver el ejemplo de Kimi K3, donde la cuantización dinámica de 1 bit solo alcanza un 78,9 % de concordancia con el original.

#Modelos publicados directamente en 4 bits

Algunos modelos recientes ya no se entrenan en 16 bits y luego se comprimen: sus pesos se generan en 4 bits con un entrenamiento consciente de la cuantización. Kimi K3 es un ejemplo: su ficha indica pesos MXFP4 y activaciones MXFP8, con entrenamiento consciente de la cuantización. Para estos modelos, el archivo nativo ya es la referencia, y una cuantización adicional a un formato de menor precisión degrada más la calidad que la cuantización de un modelo en 16 bits. Lee siempre la ficha del modelo antes de convertirlo.

#¿Qué elegir según tu memoria?

#Para ir más allá

• Q4_K_M, Q5_K_M y Q6_K en la práctica
• Comprender la ventana de contexto
• Cuantizar la caché KV: ahorrar VRAM
• GGUF, safetensors: entender los formatos
• Calculadora de VRAM

• Fuente: README de llama-quantize (llama.cpp)
• Fuente: estudio en arXiv sobre la cuantización en llama.cpp (2026)
• Fuente: etiquetas Ollama de Llama 3.1
• Fuente: discusión en llama.cpp sobre métodos de cuantización