Cuantización de modelos: qué significan Q4, Q5 y Q8

Abres la página de descargas de un modelo y te encuentras quince archivos que se llaman casi igual, con terminaciones tipo Q4_K_M, Q5_K_S o Q8_0. Son el mismo modelo, pesan cosas muy distintas y nadie te explica cuál bajar. Aquí tienes qué es la cuantización de modelos GGUF, qué significan Q4, Q5 y Q8 en la práctica, y cómo elegir el archivo correcto para la memoria que tienes.

Cuantizar es guardar los mismos números con menos detalle

Un modelo de lenguaje es por dentro una lista gigantesca de números llamados pesos. Un modelo de 8.000 millones de parámetros tiene ocho mil millones de esos números. Al entrenarlo, cada peso se guarda con 16 bits de precisión, así que la cuenta sale sola: ocho mil millones de números a 16 bits son unos 16 GB de archivo.

Cuantizar es guardar cada peso con menos bits. En lugar de 16, usas 8, 5, 4 o incluso menos. El modelo sigue siendo el mismo: misma arquitectura, mismo entrenamiento, mismos conocimientos. Lo único que cambia es la fidelidad con la que se almacena cada número. Es la misma idea que bajar un MP3 de 320 kbps a 128. La canción es idéntica, el detalle no.

La comparación con el audio sirve para el principio, pero hay un matiz. La cuantización moderna no redondea cada número por separado: agrupa los pesos en bloques pequeños, calcula un factor de escala para cada bloque y guarda cada valor en relación con esa escala. De ahí salen dos consecuencias prácticas. Un archivo "de 4 bits" ocupa en realidad algo más de 4 bits por peso, porque también hay que guardar esas escalas. Y el resultado es mucho mejor de lo que esperarías al oír que le han quitado tres cuartas partes de la información.

GGUF: el formato que carga casi todo

GGUF es el formato de archivo que usa llama.cpp, el motor en C++ que está debajo de casi todo el ecosistema doméstico. Ollama, LM Studio, Jan, KoboldCpp y muchos otros cargan GGUF. Es el sucesor de GGML, del que heredó la filosofía: un solo archivo autocontenido, pensado para funcionar en CPU y en GPU, con soporte de serie para Apple Silicon.

Dentro de un GGUF viaja todo lo necesario para ejecutar el modelo: los pesos ya cuantizados, el tokenizador, la plantilla de chat y los metadatos de arquitectura. Por eso puedes descargar un archivo suelto, apuntar tu programa a él y empezar a hablar, sin carpetas con veinte ficheros de configuración.

GGUF no es el único mundo. Los modelos originales suelen publicarse en safetensors a 16 bits, y existen otros esquemas de cuantización pensados solo para GPU, como GPTQ, AWQ o EXL2. Si montas un servidor con varias tarjetas y buscas rendimiento máximo, esos formatos entran en la conversación. Para ejecutar modelos en tu ordenador con las herramientas habituales, el debate real es qué cuantización GGUF bajarte, no qué formato usar.

Cómo leer el nombre de un archivo GGUF

Un nombre típico se parece a esto:

NombreDelModelo-8B-Instruct-Q4_K_M.gguf

Cada trozo dice algo:

• NombreDelModelo: la familia y la versión.
• 8B: número de parámetros en miles de millones. Es el factor que más manda en el tamaño y en la calidad.
• Instruct: variante ajustada para conversar y seguir instrucciones. Si pone "Base" es el modelo crudo, que completa texto pero no obedece bien.
• Q4_K_M: la cuantización. Es la parte que nos ocupa.
• .gguf: el formato.

A veces verás también sufijos como -00001-of-00003.gguf. Eso significa que el archivo viene partido en varios trozos porque es demasiado grande para subirlo entero. Necesitas todas las partes en la misma carpeta y apuntar a la primera.

El número después de la Q son los bits

Q4 significa cuatro bits por peso, Q5 cinco, Q8 ocho. Más bits, más fidelidad y más tamaño. Q2 y Q3 existen, pero ahí ya se empieza a notar el destrozo.

La K y las letras S, M, L

La K indica que es un "k-quant", el esquema por bloques que se usa desde hace años y que es bastante mejor que los métodos originales. Las letras finales indican cuánto se afina el reparto:

• S (small): la variante más agresiva dentro de ese nivel.
• M (medium): el equilibrio. Deja algunas capas sensibles con más bits.
• L (large): guarda todavía más capas a mayor precisión, y ocupa más.

Por eso un Q4_K_M pesa más que un Q4_K_S sin ser "Q5". No todos los pesos de un modelo se cuantizan igual: las capas de atención y la de salida suelen conservar más precisión porque son las que más daño hacen al degradarse.

Los IQ y los formatos antiguos

Si ves nombres tipo IQ4_XS, IQ3_M o IQ2_XXS, son i-quants. Usan una matriz de importancia calculada pasando texto por el modelo, para decidir qué pesos merecen más bits. A igualdad de tamaño dan mejor calidad que un k-quant equivalente, sobre todo por debajo de 4 bits. La contrapartida es que exigen más cálculo al descomprimir, así que en CPU pura pueden ir más lentos.

Los formatos Q4_0, Q4_1 y Q5_1 son los originales, anteriores a los k-quants. Si tienes elección, ignóralos. La excepción es Q8_0, que sigue siendo el estándar para 8 bits y está perfectamente vigente.

Cuánto ocupa cada cuantización GGUF, de Q2 a Q8

La regla mental para estimar cualquier caso es esta:

GB aproximados = (parámetros en miles de millones x bits por peso) / 8

Un modelo de 8B a 4 bits te da unos 4 GB, más el pequeño extra de las escalas. Con esa fórmula puedes calcular a ojo cualquier combinación antes de descargar nada. La tabla siguiente usa un modelo de 8B como referencia, que es el tamaño más común en escritorio.

Los tamaños son aproximados y varían unas décimas según la arquitectura del modelo, pero el orden de magnitud es fiable.

Qué se pierde de verdad al bajar de bits

Aquí es donde la gente se pierde, porque la degradación no es lineal ni uniforme. Un modelo cuantizado a 4 bits no responde "un 25% peor". Responde igual de bien casi siempre y se rompe en sitios concretos.

Lo que se estropea primero:

• El formato estricto. Generar JSON válido, respetar un esquema, cerrar las etiquetas. Es lo primero que falla.
• El razonamiento largo. Cadenas de varios pasos donde un error temprano contamina todo lo demás.
• El código. Un carácter mal puesto no compila. Aquí la precisión importa más que en prosa.
• Los idiomas menos representados. Un modelo en Q3 suele degradarse antes en español que en inglés.
• Los datos raros. Nombres poco frecuentes, fechas, cifras. El modelo se vuelve más propenso a inventar.

Lo que casi no se nota hasta niveles muy bajos: conversación normal, resúmenes, reescritura, traducción general y clasificación de textos.

Los síntomas de haberte pasado de agresivo son bastante reconocibles. El modelo empieza a repetir frases en bucle, mezcla idiomas a media respuesta, se inventa palabras que no existen o ignora instrucciones que antes seguía. Si ves eso, sube un nivel de cuantización antes de culpar al modelo.

El archivo no es toda la memoria que necesitas

Este es el error que más veces revienta una configuración. El tamaño del GGUF es solo la parte de los pesos. Al ejecutarlo necesitas además la caché KV, que es donde el modelo guarda el contexto de la conversación, y crece con cada token que entra o sale.

Cuanto más contexto pidas, más memoria come esa caché: pasar de 4.000 a 32.000 tokens puede sumar varios gigas según el modelo. Muchos motores permiten cuantizar también la caché (en llama.cpp, fijando el tipo de caché a 8 bits), lo que casi la reduce a la mitad con poco impacto.

Regla práctica: reserva el tamaño del archivo más un 20% de margen para contexto corto, y bastante más si trabajas con documentos largos. La tabla de VRAM por tamaño de modelo te ahorra un buen rato de prueba y error.

Y un aviso importante: si el modelo no cabe entero en la VRAM, el sistema empieza a mover capas a la RAM del sistema y la velocidad se desploma. No baja un poco, cae en picado. Por eso casi siempre es mejor un Q4 que entra holgado que un Q6 que se sale por medio giga.

Qué cuantización GGUF elegir según tu equipo

Cada casilla sale de aplicar la fórmula de antes y dejar sitio para la caché KV. Puedes rehacer el cálculo tú mismo con cualquier combinación: si el resultado se acerca a tu memoria total, recorta el contexto o baja un escalón.

En Mac la memoria es unificada, así que el modelo comparte pool con el sistema. Cuenta con dejar libres unos gigas para macOS y el resto de aplicaciones. Si vas justo, ejecutar modelos sin tarjeta gráfica dedicada es viable, pero cambia por completo la cuantización que te conviene: en CPU el cuello de botella es el ancho de banda de memoria, así que los archivos pequeños ganan siempre.

Si usas una interfaz gráfica, esto se simplifica mucho. En la guía de LM Studio verás que el propio programa te avisa, con un indicador por archivo, de si un GGUF cabe en tu hardware antes de descargarlo. Es la forma más rápida de no equivocarte mientras aprendes a leer los nombres.

Con Ollama la decisión viene medio tomada: al descargar un modelo sin especificar nada te trae una variante de 4 bits, que es el compromiso razonable por defecto. Si quieres otra, tienes que pedirla con su etiqueta concreta. En la guía de instalación de Ollama paso a paso está explicado cómo se indican esas etiquetas al descargar.

Modelo grande en Q4 o modelo pequeño en Q8

Es la pregunta que aparece en cuanto entiendes lo demás. Tienes 12 GB. Puedes meter un 8B en Q8 o un 14B en Q5. ¿Qué eliges?

En la práctica, casi siempre gana el modelo más grande con menos bits, siempre que no bajes de Q4. Un modelo de 14B en Q4_K_M suele rendir mejor que uno de 8B en Q8, porque el salto de capacidad entre tamaños es mayor que lo que pierdes al cuantizar.

Pero hay excepciones que conviene tener presentes:

• Por debajo de Q4 la regla se invierte. Un 30B en Q2 puede ser peor que un 8B en Q5, y encima más lento.
• Para código y salidas estructuradas, prioriza los bits. La precisión pesa más de lo normal cuando un solo carácter mal lo estropea todo.
• Si el modelo grande no cabe entero, no hay debate. El pequeño que va rápido gana al grande que no arranca.
• Para tareas mecánicas (resumir, clasificar, reescribir), un modelo pequeño bien cuantizado sobra y va bastante más rápido.

Errores habituales y cómo probar una cuantización

Los fallos que más se repiten:

1. Descargar el F16 "por si acaso". Ocupa el doble que Q8 y no aporta calidad perceptible en uso normal. El F16 solo tiene sentido si vas a cuantizar tú mismo o a hacer un ajuste fino.
2. Elegir Q2 de un modelo enorme para presumir. Suele funcionar peor que un modelo mediano decente y va mucho más lento.
3. No contar el contexto. Ver que el archivo cabe justo y llevarse la sorpresa a los diez mensajes.
4. Comparar cuantizaciones con una sola pregunta. Las diferencias aparecen en tareas difíciles, no en "hola, ¿qué tal?".

Para probar en serio, prepara cinco o seis peticiones representativas de lo que vas a hacer de verdad y lánzalas al mismo modelo en dos cuantizaciones distintas, con la misma temperatura y la misma semilla si tu programa lo permite. Si no notas diferencia, quédate con la pequeña.

Si quieres cuantizar tú mismo, el proceso con llama.cpp son dos comandos: convertir el modelo original a GGUF de 16 bits y luego reducirlo al nivel que quieras.

python convert_hf_to_gguf.py ./modelo-original --outfile modelo-f16.gguf --outtype f16
llama-quantize modelo-f16.gguf modelo-Q4_K_M.gguf Q4_K_M

Ojo con el espacio en disco: necesitas sitio para el F16 intermedio, que es lo más pesado del proceso.

Un apunte por si tu uso de la IA local va por otro lado: los modelos de transcripción como Whisper también se distribuyen cuantizados con la misma lógica de bits, y funcionan igual de bien en local. Si lo que quieres es transcribir el audio de un vídeo, primero necesitas el archivo, y para eso está Daun. El modelo hace el resto sin subir nada a ningún servidor.

Preguntas frecuentes

¿Cuantizar hace que el modelo vaya más rápido?

Sí, casi siempre, y por un motivo que no es obvio: generar texto está limitado por el ancho de banda de memoria, no por la potencia de cálculo. Un archivo más pequeño significa mover menos datos por token. El salto grande, eso sí, ocurre cuando el modelo pasa de no caber en la VRAM a caber: ahí la diferencia se mide en veces, no en porcentajes. La excepción son los i-quants más agresivos en CPU, donde descomprimir puede comerse la ventaja.

¿Q4_K_M o Q4_K_S?

Q4_K_M si te cabe, sin dudarlo. La diferencia de tamaño es de unos pocos cientos de megas en un modelo de 8B, y a cambio conserva más precisión en las capas que más importan. Baja a Q4_K_S solo cuando esos megas sean exactamente lo que te falta para que el modelo entre entero en la memoria.

¿Puedo usar un GGUF cuantizado para hacer ajuste fino?

Para entrenar en serio, no. El ajuste fino se hace sobre los pesos originales en 16 bits, y luego cuantizas el resultado. Existen técnicas que entrenan adaptadores sobre un modelo cuantizado, pero salen del uso doméstico habitual y no las cubre el flujo típico de GGUF.

¿Los modelos de imagen o de voz también se cuantizan?

Los de voz sí, y con el mismo criterio: whisper.cpp distribuye modelos de transcripción en varios niveles de bits, y en la práctica las versiones reducidas rinden muy bien. Los de generación de imagen viven sobre todo en otro ecosistema, aunque hay versiones GGUF de algunas arquitecturas. Ahí la memoria se reparte de forma distinta y las reglas de este artículo no se trasladan tal cual.