← Resources
By Ren Sugaya
— Performance Engineer, GPU & Inference
·
· INSIGHT
Cuantización de LLM explicada: GGUF, Q4 vs Q8 y calidad
La cuantización reduce el tamaño de un LLM almacenando sus pesos con menor precisión, recortando la VRAM aproximadamente cuatro veces a 4 bits. Esta guía explica el cálculo de VRAM, descifra los nombres de cuantización GGUF como Q4_K_M, compara GGUF con GPTQ y AWQ, y muestra dónde se deteriora realmente la calidad.
Qué es la cuantización y por qué importa
La cuantización reduce la precisión numérica con la que se almacenan los pesos del modelo — normalmente de FP16 (16 bits, 2 bytes por peso) a 8 bits o 4 bits. Como la memoria escala linealmente con los bits por peso, 4 bits usa aproximadamente cuatro veces menos VRAM que FP16. También acelera la inferencia, ya que la generación de tokens está limitada por el ancho de banda de memoria, no solo por el cómputo.
El cálculo del tamaño es sencillo: bytes ≈ (parámetros × bits-por-peso) ÷ 8. Un modelo de 8B en FP16 ocupa unos 16 GB; a 4 bits son aproximadamente 4,5 GB. Esa diferencia es lo que convierte un modelo que requiere una GPU de centro de datos en uno que funciona en un portátil.
GGUF es un formato de archivo, no un método
GGUF es un formato de archivo único que almacena los pesos cuantizados junto con los metadatos del modelo (tokenizador, arquitectura, hiperparámetros). Es el sucesor de GGML del proyecto llama.cpp, optimizado para CPU, Apple Silicon (Metal) e inferencia mixta CPU/GPU — por eso domina la inferencia local y en portátiles a través de llama.cpp, Ollama y LM Studio.
El nivel de cuantización está en el nombre del archivo. El número es el promedio de bits por peso; `_K` significa k-quants (el moderno método de superbloques con factores de escala doblemente cuantizados y asignación de bits según la sensibilidad de cada capa); `_S`, `_M`, `_L` son las variantes pequeña, mediana y grande. `_M` conserva selectivamente las capas sensibles — atención y salida — con mayor precisión, y por eso Q4_K_M supera a una cuantización plana de 4 bits.
Q4 vs Q5 vs Q8: tamaño y calidad, con números
Una evaluación revisada por pares sobre Llama-3.1-8B concreta los compromisos (los tamaños son para ese modelo; las proporciones se generalizan). Frente a una perplejidad base de FP16 de aproximadamente 7,32 (cuanto menor, mejor):
- Q8_0 — 8,5 bits/peso, ~7,95 GiB, perplejidad 7,33: prácticamente sin pérdidas.
- Q6_K — 6,56 bpw, ~6,14 GiB, perplejidad 7,35.
- Q5_K_M — 5,70 bpw, ~5,33 GiB, perplejidad 7,40.
- Q4_K_M — 4,89 bpw, ~4,58 GiB, perplejidad 7,56: el punto óptimo práctico, a menos de medio por ciento de la línea base.
- Q3 y por debajo — degradación pronunciada y consistente, especialmente en tareas de razonamiento.
La franja de 4 a 5 bits es la zona segura. Por debajo de 3 bits se necesitan cuantizaciones por matriz de importancia (IQ), que usan datos de calibración para concentrar la precisión donde más importa — utilizables, pero como último recurso cuando la memoria es muy ajustada.
GGUF vs GPTQ vs AWQ
GGUF no es la única opción; la adecuada depende de dónde ejecutes el modelo.
- GGUF: diseñado para CPU, Mac y offload mixto. Elígelo para inferencia local y de escritorio.
- GPTQ: post-entrenamiento, basado en calibración, usa información de segundo orden para minimizar el error por capa. El más preciso peso por peso para un ancho de bits dado, pero lento de producir y orientado al servicio en GPU (vLLM, TGI, TensorRT-LLM).
- AWQ: protege aproximadamente el 1% de los pesos más relevantes según las magnitudes de activación; más rápido de producir que GPTQ y optimizado para GPU a 4 bits.
- bitsandbytes: cuantiza al vuelo en el momento de carga, sin punto de control precuantizado ni calibración — el camino más sencillo, muy usado para el ajuste fino con QLoRA.
La división práctica: GGUF para local y portátil, AWQ o GPTQ para el rendimiento en servidores GPU.
¿Cuánta calidad pierdes realmente?
Menos de lo que la mayoría teme a 4 bits, y más de lo que esperan por debajo de 3 bits. En la evaluación de Llama-3.1-8B, Q8 quedó dentro del margen de redondeo de la precisión completa, Q4_K_M perdió menos de medio por ciento en los benchmarks promedio, y el desplome apareció a 3 bits, con la degradación más clara en evaluaciones de razonamiento intensivo como las matemáticas de nivel escolar. Recuerda que los valores absolutos de perplejidad y tamaño son específicos de cada modelo — los porcentajes se generalizan, pero verifica siempre las cifras de tu modelo base. Y reserva VRAM más allá del tamaño del archivo: la caché KV y aproximadamente un 10–15% de sobrecarga del framework también necesitan margen.
Cuantización en osFoundry
Elegir una cuantización suele implicar entender los bits por peso, dejar espacio para la caché KV y rebuscar entre un muro de crípticos sufijos GGUF el único archivo que encaja sin fallar. La inferencia local de osFoundry elimina ese paso: detecta tu memoria disponible y selecciona automáticamente la cuantización adecuada — Q4_K_M para VRAM ajustada, Q5_K_M o Q8_0 cuando hay margen — para que el modelo funcione con la mejor calidad que admite tu hardware. El catálogo muestra solo las versiones compatibles en lugar de todas las variantes, y recurre con elegancia a una cuantización más ligera si una más pesada no cabe. Obtienes el punto óptimo entre tamaño y calidad de elegir un GGUF a mano, sin necesidad de saber qué significa Q4_K_M.
Frequently asked questions
- ¿Qué es la cuantización de LLM en términos simples?
- Consiste en almacenar los pesos de un modelo con menor precisión numérica — por ejemplo, 4 bits en lugar de 16 — para reducir su tamaño. Como la memoria escala con los bits por peso, la cuantización a 4 bits usa aproximadamente cuatro veces menos VRAM que FP16 y funciona más rápido, con un coste de calidad pequeño y normalmente aceptable.
- ¿Qué significa GGUF y qué es?
- GGUF es el formato de modelo de archivo único del proyecto llama.cpp (el sucesor de GGML) que agrupa los pesos cuantizados con los metadatos del modelo. Está optimizado para CPU, Apple Silicon e inferencia mixta CPU/GPU, por eso es el estándar de herramientas locales como llama.cpp, Ollama y LM Studio. Es un formato de archivo, no un algoritmo de cuantización.
- ¿Cuál es la diferencia entre Q4, Q5 y Q8?
- El número es el promedio de bits por peso, así que Q8 es más grande y de mayor fidelidad que Q5, que a su vez es más grande que Q4. En un modelo típico de 8B, Q8 es casi sin pérdidas con unos 8 GB, Q5_K_M baja un poco con unos 5,3 GB, y Q4_K_M es el punto óptimo entre tamaño y calidad con unos 4,6 GB y menos de medio por ciento de pérdida.
- ¿Qué cuantización GGUF debería usar?
- Q4_K_M en la mayoría de los casos — es el mejor equilibrio entre tamaño y calidad y el punto de partida estándar. Sube a Q5_K_M o Q8_0 si te sobra VRAM y quieres mayor fidelidad, y solo baja de Q4 (con cuantizaciones IQ por matriz de importancia) cuando la memoria sea realmente ajustada, ya que la calidad cae drásticamente a 3 bits y por debajo.
- ¿Cuánta calidad se pierde con la cuantización a 4 bits?
- Sorprendentemente poca. En una evaluación revisada por pares de Llama-3.1-8B, Q4_K_M quedó a menos de medio por ciento de la línea base de precisión completa en los benchmarks promedio. La degradación notable empieza a 3 bits, sobre todo en tareas de razonamiento y matemáticas. Las cifras exactas varían según el modelo, pero la franja de 4 a 5 bits se considera ampliamente la zona segura.
- GGUF vs GPTQ vs AWQ — ¿cuál debería elegir?
- GGUF para inferencia local, en portátil y Apple Silicon a través de llama.cpp u Ollama. GPTQ y AWQ almacenan una disposición optimizada para GPU y son la mejor opción para el rendimiento en servidores GPU con vLLM o TGI — AWQ es más rápido de producir, GPTQ suele ser el más preciso peso por peso. bitsandbytes es el más sencillo, ya que cuantiza en el momento de carga sin calibración.
- ¿Cómo calculo la VRAM que necesita un modelo cuantizado?
- Usa bytes ≈ (parámetros × bits-por-peso) ÷ 8. A 4 bits son aproximadamente 0,5 a 0,6 GB por cada mil millones de parámetros, así que un modelo de 8B ocupa unos 4,5 GB. Después añade margen para la caché KV y aproximadamente un 10 a 15% de sobrecarga del framework — la huella en ejecución siempre es mayor que el archivo en disco.
Sources