Cuantización GGUF para Ollama: qué significan Q4_K_M, Q8_0 e IQ4_XS y cuál elegir para tu hardware

Se ejecuta modelos a través de Ollama u otros tiempos de ejecución locales, ya se ha encontrado con nombres como Q4_K_M, Q8_0 o IQ4_XS. ¿Qué significan? ¿Cuál elegir? ¿Por qué Q4 es a menudo mejor que Q8, y cuándo no lo es?

En este artículo, analizo la cuantización sin exceso de teoría, con tablas, números reales y ejemplos de mis propios proyectos en un MacBook M1 de 16 GB.

¿Qué es la cuantización de un modelo de lenguaje — explicación en lenguaje sencillo

Un modelo de lenguaje es un conjunto de pesos numéricos. Cada peso determina cómo reacciona una neurona a los datos de entrada. En precisión completa (FP16), cada peso ocupa 16 bits — dos bytes. Un modelo de 7 mil millones de parámetros pesa alrededor de 14 GB.

Cuantización — es la reducción del número de bits por peso. Q8 — 8 bits, Q4 — 4 bits, Q2 — solo 2. Cuantos menos bits, menor es el archivo y menos memoria se necesita para ejecutarlo.

Una buena analogía es JPEG frente a foto RAW. RAW — máxima detalle, pero ocupa 25 MB. JPEG con calidad 85% — 3 MB, y la mayoría de la gente no nota la diferencia. Pero si amplías la imagen o la recortas bruscamente — los artefactos se vuelven visibles. Lo mismo ocurre con los modelos: en un chat normal, Q4 y Q8 son prácticamente idénticos, pero en matemáticas o código complejo, la diferencia ya es perceptible.

Idea principal: la cuantización es compresión, no degradación. Una cuantización elegida correctamente conserva el 92–95% de la calidad con una reducción de tamaño de 3 a 4 veces.

Ejemplo práctico: en mi proyecto AskYourDocs, un sistema RAG procesa documentos corporativos a través de Ollama local en un M1. El modelo Qwen3-14B en Q4_K_M ocupa ~8.5 GB y cabe en 16 GB de memoria unificada, dejando espacio para el contexto y el modelo de incrustación. En FP16, ocuparía ~28 GB y simplemente no se ejecutaría.

Por qué es necesaria la cuantización para la IA local

Sin cuantización, la IA local en hardware de consumo simplemente no es posible. Aquí están las cifras:

• Llama 3.3 70B en FP16 — ~140 GB. Este hardware cuesta decenas de miles de dólares.
• El mismo Llama 3.3 70B en Q4_K_M — ~40 GB. Se ejecuta en Mac Studio o dos RTX 4090.
• Modelo 7B en FP16 — 14 GB. En Q4_K_M — 4.1 GB. Se ejecuta incluso en una tarjeta gráfica con 6 GB de VRAM — qué modelos se abren en 8 y 16 GB de RAM.

Además de ahorrar memoria, la cuantización también proporciona un inicio más rápido: un archivo más pequeño se carga más rápido en la memoria. Y debido al menor volumen de datos leídos, la generación de tokens también se acelera (más detalles en la sección sobre Q4 vs Q8).

Idea principal: la cuantización no es un compromiso, sino la única forma de ejecutar LLM modernos en un PC doméstico o portátil.

Dónde se aplica: sistemas RAG locales, asistentes personales, agentes autónomos sin nube, herramientas corporativas en servidores aislados — en cualquier lugar donde el modelo deba funcionar sin claves API y sin transferir datos al exterior.

¿Qué es el formato GGUF y por qué ha ganado

GGUF (GPT-Generated Unified Format) es un contenedor de archivos para modelos cuantizados. Fue creado por Georgi Gerganov, autor de llama.cpp, en 2023 como reemplazo del antiguo formato GGML.

La principal ventaja de GGUF es la autosuficiencia: un solo archivo contiene todo lo necesario para la ejecución:

• pesos del modelo cuantizados;
• tokenizador y su configuración;
• metadatos de la arquitectura;
• hiperparámetros.

Con el antiguo GGML, era necesario mantener archivos separados para los pesos y la configuración, lo que complicaba la distribución. GGUF resolvió este problema y rápidamente se convirtió en un estándar: hoy en día es compatible con Ollama, LM Studio, Open WebUI, Jan, KoboldCpp y la mayoría de los demás tiempos de ejecución locales.

Personalmente, para el trabajo diario con modelos GGUF, utilizo LM Studio — en mi MacBook M1, la generación es notablemente más rápida que en Ollama, además de una interfaz conveniente para cambiar rápidamente entre modelos y cuantizaciones. Si aún no lo has probado, te lo recomiendo como punto de partida.

En resumen: GGUF no es un tipo de cuantización, sino un contenedor. La cuantización (Q4, Q8, etc.) es lo que está dentro del archivo GGUF.

Ejemplo: cuando ejecutas ollama pull qwen3:14b, Ollama descarga un archivo GGUF con cuantización Q4_K_M por defecto. Pero puedes especificar explícitamente otra: ollama run hf.co/bartowski/Qwen3-14B-GGUF:Q8_0.

De FP16 a Q2: niveles de cuantización en una tabla

Cada nivel de cuantización es un compromiso entre calidad y tamaño. Así se ve un modelo 7B en diferentes niveles:

Los datos sobre el tamaño de los archivos provienen de mediciones reales de llama.cpp. Los porcentajes de calidad son valores aproximados de perplejidad en relación con FP16.

Lo importante aquí: la diferencia de calidad entre Q4_K_M y Q8_0 es de aproximadamente 4%. La diferencia de tamaño es casi el doble. Es por eso que Q4_K_M gana en la mayoría de los escenarios.

Ejemplo: investigaciones de principios de 2026 confirman que el razonamiento lógico es muy resistente a la cuantización, mientras que la aritmética comienza a degradarse por debajo de Q4. Para un chat normal y traducción, Q4 es absolutamente suficiente.

¿Qué significan Q4_K_M, Q5_K_M, Q8_0 — descifrando los sufijos

Esta es una de las preguntas más frecuentes entre los principiantes, y casi ningún artículo la explica correctamente. Vamos a desglosarla en detalle.

Estructura del nombre: Q[bits]_[método]_[variante]

Q4 — número de bits por peso (aproximadamente). No siempre es un número entero: Q4_K_M utiliza realmente ~4.5 bits debido a la precisión mixta.

_K — K-Quants. Este es un esquema de cuantización más inteligente que distribuye los bits de manera desigual: las capas que más influyen en la calidad (atención, proyección de salida) reciben más bits, el resto — menos. Esto permite, con el mismo tamaño promedio, mantener una mayor calidad que el antiguo enfoque uniforme.

_M / _S / _L — tamaño de la variante dentro de un nivel:

• _S (Small) — tamaño mínimo en su clase, calidad ligeramente inferior.
• _M (Medium) — equilibrio entre tamaño y calidad. Esta es la recomendación estándar.
• _L (Large) — máxima calidad en la clase, archivo ligeramente más grande.

_0 — esquema uniforme antiguo (por ejemplo, Q4_0, Q8_0). Todos los pesos se cuantizan de la misma manera, sin prioridades. Q8_0 se usa ampliamente por su simplicidad, pero Q4_0 ya ha sido prácticamente reemplazado por Q4_K_M con el mismo tamaño.

Tabla comparativa de cuantizaciones populares

Recuerda: el sufijo _M en el nombre es la letra más importante. Es la que indica que el modelo utiliza precisión mixta y conserva las capas más importantes con mayor detalle.

Ejemplo: si ves dos archivos en Hugging Face — model-Q4_0.gguf y model-Q4_K_M.gguf de tamaño aproximadamente igual — elige Q4_K_M. El antiguo esquema Q4_0, con el mismo volumen, ofrece una calidad notablemente peor.

Cuantizaciones IQ: ¿qué es IQ4_XS y por qué es importante en 2026

Este es un tema que casi no aparece en ningún artículo. Y sin embargo, los cuantizadores IQ ya han aparecido en las descargas estándar de bartowski y se discuten activamente en la comunidad de llama.cpp.

¿Qué es imatrix (importance matrix)

La cuantización estándar procesa todos los pesos por igual. Importance matrix (imatrix) es un análisis previo: se pasan datos de calibración a través del modelo y se mide qué pesos influyen más en la calidad de la salida. Estos pesos se cuantizan con más cuidado, el resto — de forma más agresiva.

Resultado: un archivo más pequeño con una calidad similar o incluso mejor que los K-quants del mismo nivel.

IQ4_XS vs Q4_K_M: comparación práctica

*IQ4_XS solo ofrece una ventaja si se utiliza un archivo imatrix de alta calidad. Un IQ-quant mal calibrado puede ser inferior a Q4_K_M.

Para un modelo 70B, la diferencia entre IQ4_XS y Q4_K_M es de 3–4 GB, lo que puede ser crucial para que el modelo quepa en la memoria.

Dónde obtener IQ-quants verificados

No todos los archivos GGUF en Hugging Face son iguales. Tres fuentes verificadas:

• bartowski — el cargador más activo y fiable, incluye imatrix.
• mradermacher — amplia cobertura de modelos.
• TheBloke — archivo clásico, menos activo en 2026, pero aún fiable.

Idea principal: IQ4_XS no siempre es mejor que Q4_K_M. Pero si necesitas que un modelo más grande quepa en la misma memoria, IQ4_XS ofrece una ventaja de 3–4 GB con una calidad similar.

Escenario práctico: tengo un MacBook M1 con 16 GB. Qwen3-14B en Q4_K_M ocupa ~8.5 GB — cabe. Pero si añades nomic-embed-text (~280 MB) y un contexto de 8K — comienza el swapping. IQ4_XS del mismo Qwen3-14B ocupa ~7.9 GB, y el sistema respira más libremente.

En mi trabajo, utilizo una estrategia de dos etapas: para pruebas, redacción de artículos y tareas generales — un modelo más ligero en Q4_K_M, que se inicia rápidamente y no sobrecarga el sistema. Pero cuando el agente pasa a llamar a herramientas externas o lógica compleja con tool calling — cambio a un modelo más potente en Q5_K_M o Q6_K, donde la precisión del esquema JSON y la consistencia de los pasos son cruciales. Q4 aquí a veces "pierde" la lógica en medio de la cadena.

¿Cuánta RAM y VRAM se necesita: tabla y fórmula

Aquí tienes una tabla práctica con los tamaños de modelos populares en diferentes cuantizaciones. Datos basados en mediciones de willitrunai.com y archivos GGUF oficiales:

Fórmula para cálculos propios

RAM (GB) = Parámetros (miles de millones) × Bytes_por_peso × 1.2

Bytes por peso:
  FP16   → 2.0
  Q8_0   → 1.0
  Q5_K_M → 0.69
  Q4_K_M → 0.55
  Q3_K_M → 0.41

Adicionalmente:
  + 1–2 GB para el caché KV (con contexto de 4K)
  + 2 GB para el SO y otros procesos

Fuente de la fórmula: localaimaster.com.

Ejemplo de cálculo: Qwen3-14B en Q4_K_M → 14 × 0.55 × 1.2 = 9.24 GB para pesos + ~1.5 GB de caché KV con contexto de 4K = se necesitan al menos 11–12 GB de VRAM.

En resumen: el tamaño del archivo son solo los pesos. Añade el caché KV (depende del contexto) y 2 GB para el sistema — y obtendrás la necesidad real de memoria.

Importante para MacBook Apple Silicon: la memoria unificada se comparte entre la CPU y la GPU, por lo que aproximadamente el 75–80% del volumen total está realmente disponible. En un M1 de 16 GB — aproximadamente 12–13 GB efectivos para el modelo.

Qué cuantización elegir para tu hardware

Una guía práctica rápida:

Qué hacer si el modelo no cabe completamente en la VRAM

Si el modelo es más grande que la VRAM, llama.cpp y Ollama mueven automáticamente parte de las capas a la CPU. Esto se llama offloading parcial (layer offloading).

Cuándo elegir Q4_K_S en lugar de Q4_K_M

Con el offloading parcial, cada capa que va a la CPU pasa por el bus PCIe. Un archivo más pequeño = menos tráfico. Por lo tanto, con offloading parcial se recomienda Q4_K_S, es aproximadamente un 8% más pequeño que Q4_K_M con una diferencia insignificante en la calidad.

Cuantización de la caché KV: una ganancia oculta en memoria

Pocos saben que, además de cuantizar los pesos del modelo, también se puede cuantizar la caché KV. Esta es la memoria que el modelo utiliza para almacenar el contexto durante la generación.

En Ollama, esto se controla con una variable de entorno:

OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

Resultados de mediciones reales basadas en llama.cpp Discussion #20969:

Conclusión de la tabla: la caché KV q8_0 es una ganancia casi gratuita: el doble de memoria con una pérdida de calidad imperceptible. La caché KV q4_0 es peligrosa con contexto largo: con 110K tokens, la velocidad de generación cae un 37% y la calidad de la salida estructurada y el código se degrada.

Idea principal: si tienes problemas de memoria, primero prueba OLLAMA_KV_CACHE_TYPE=q8_0. Esto proporciona un ahorro de ~47% en memoria KV sin pérdidas notables. Solo entonces considera una cuantización de pesos menor.

Dónde es especialmente importante: en sistemas RAG como AskYourDocs, donde se cargan fragmentos grandes de documentos en el contexto, la caché KV puede ocupar tanta memoria como el propio modelo.

Por qué Q4_K_M se recomienda más que Q8

A primera vista, la lógica es simple: Q8 es mejor calidad. Pero hay tres argumentos a favor de Q4_K_M que generalmente no se mencionan.

1. Q8_0 es más lento que Q4_K_M

La generación de LLM está limitada por el ancho de banda de la memoria, no por los cálculos. La GPU pasa más tiempo leyendo pesos de la VRAM que multiplicando matrices. Un archivo más grande = más bytes para leer por cada token.

Según el README oficial de llama.cpp para Llama-3.1-8B: Q8_0 genera tokens un 29% más lento que Q4_K_M.

2. Un modelo más grande en Q4 > un modelo más pequeño en Q8

Esta es la regla más importante para elegir la cuantización que la mayoría ignora:

70B en Q4 supera significativamente a 7B en FP16 con un tamaño de archivo similar.

La estrategia correcta es: primero, toma el modelo más grande posible que quepa en la memoria, y solo luego reduce la precisión. No al revés.

3. Q4_K_M conserva el 92-95% de la calidad de FP16

Para chat doméstico, traducción, resumen y la mayoría de las tareas de texto, una diferencia del 5% en la calidad es prácticamente imperceptible. Por eso Q4_K_M es la cuantización predeterminada de Ollama: Ollama ya elige esta opción por defecto. No tienes que pensar en ello, solo ejecuta el modelo.

Lo principal aquí: Q4_K_M gana no porque Q8 sea malo, sino porque la memoria liberada permite ejecutar un modelo el doble de grande, lo que proporciona un mayor aumento de calidad.

Ejemplo con números: en una RTX 4070 de 12 GB, la elección es entre Qwen3-7B Q8_0 (~7.7 GB) y Qwen3-14B Q4_K_M (~8.5 GB). La segunda opción, en pruebas reales, da resultados notablemente mejores en tareas complejas a pesar de una cuantización menor.

Cuándo vale la pena pagar por Q5, Q6 o Q8

Hay escenarios en los que un nivel de cuantización más alto está realmente justificado:

Código y salida estructurada → Q5_K_M o Q6_K

La generación de código requiere un cumplimiento estricto de la sintaxis. Un paréntesis perdido o una indentación incorrecta y el código no compila. Q5_K_M reduce significativamente la frecuencia de errores de sintaxis en comparación con Q4.

Matemáticas y razonamiento → Q5_K_M como mínimo

Estudios de 2026 confirman: el razonamiento aritmético se degrada drásticamente por debajo de Q4. Para tareas con cálculos paso a paso, especialmente con largas cadenas lógicas, usa Q5_K_M o Q6_K.

Sistemas RAG con contexto largo → Q5_K_M

Al cargar documentos grandes en el contexto, el modelo debe "retener" los hechos desde el principio del texto hasta el final de la respuesta. Q4 lo maneja, pero Q5_K_M es más fiable con un contexto de 16K+.

Agentes con tool calling → Q5_K_M+

Los agentes deben cumplir estrictamente el esquema JSON para llamar a las herramientas. Q4 a veces genera JSON no válido bajo carga. En mi sistema de agentes, ya he pasado a Q5_K_M precisamente por esto.

Modelos pequeños (3B–7B) con VRAM grande → Q8_0

Si tienes 16 GB de VRAM o más y ejecutas un modelo pequeño de 7B, Q8_0 está justificado: el modelo cabe completamente y la ganancia en calidad es perceptible.

Idea principal: aumenta la cuantización no "por la calidad en general", sino para una tarea específica. Para código y agentes, Q5_K_M como mínimo. Para chat y traducción, Q4_K_M es suficiente.

¿La cuantización degrada la calidad de las respuestas? Ejemplos reales

Comparé Q4_K_M y Q8_0 en Qwen3-14B a través de Ollama en M1. Esto es lo que obtuve en diferentes tipos de tareas:

Recuerda: el 80% de las tareas no requieren Q8. Pero si tu tarea es código, agentes o matemáticas, Q5_K_M será una mejora notable incluso sin pasar a Q8.

Matiz importante: la diferencia entre Q4_K_M y Q8_0 en un modelo de 14B es menor que la diferencia entre 7B Q8_0 y 14B Q4_K_M. El tamaño del modelo es más importante que el nivel de cuantización: elige siempre un modelo más grande con cuantización inferior si tienes la opción.

GGUF vs GPTQ vs AWQ vs EXL2: qué elegir en 2026

GGUF no es el único formato de cuantización. Aquí tienes el panorama completo:

Más detalles sobre GPTQ y AWQ: Guía de cuantización de LLM 2026 — tensorrigs.com.

Si eres un usuario doméstico o un desarrollador en MacBook/PC, GGUF Q4_K_M a través de Ollama es el único formato en el que necesitas pensar. GPTQ y AWQ son para servidores GPU e infraestructura de producción.

Dónde se aplica qué: GGUF — desarrollo local, prototipos RAG, asistente personal. AWQ — API de producción, servidor vLLM con docenas de solicitudes paralelas. EXL2 — entusiastas que sacan el máximo partido a una sola RTX 4090.

Cómo descargar el archivo GGUF correcto de Hugging Face

Lo mostraré con mi propio ejemplo: descargo modelos de aquí regularmente. Puede obtener más detalles en la página bartowski/Qwen_Qwen3-14B-GGUF — allí encontrará todas las cuantizaciones con descripción del tamaño y recomendaciones:

Paso 1. Abra la página del modelo en Hugging Face. Busque repositorios de bartowski, mradermacher o TheBloke — tienen imatrix y calidad probada.

Paso 2. En la pestaña "Files and versions", filtre los archivos por la extensión .gguf.

Paso 3. Determine la cuantización necesaria según la tabla anterior. Para la mayoría, es Qwen3-14B-Q4_K_M.gguf.

Paso 4. Descargue directamente a través de Ollama:

ollama run hf.co/bartowski/Qwen3-14B-GGUF:Q4_K_M

O a través de la CLI de Hugging Face:

pip install huggingface_hub
huggingface-cli download bartowski/Qwen3-14B-GGUF --include "Qwen3-14B-Q4_K_M.gguf"

Para verificar la cuantización de un modelo ya descargado en Ollama:

ollama show qwen3:14b

En la salida, busque la línea quantization — allí se indicará el tipo (por ejemplo, Q4_K_M).

Recuerde: no descargue GGUF de autores desconocidos sin verificar la tarjeta del modelo. Un imatrix deficiente hace que los IQ-quant sean peores que los K-quant normales. Tres fuentes confiables son bartowski, mradermacher, TheBloke.

Errores comunes al elegir la cuantización

• Tomar Q2 o Q3 por su pequeño tamaño. Por debajo de Q4, la calidad se degrada de forma desigual: el modelo puede hablar coherentemente, pero "perder la lógica" en medio de la respuesta. Es mejor tomar un modelo más pequeño en Q4 que uno más grande en Q2.
• Descargar Q8 en hardware sin VRAM de sobra. Q8 no solo ocupa más memoria, sino que también es más lento. Si el modelo apenas cabe, Q8 provocará swapping y, en la práctica, menos tokens/s que Q4_K_M.
• Confundir los parámetros del modelo y la cuantización. "14B Q4" y "7B Q8" son cosas muy diferentes. Los parámetros (7B/14B/70B) afectan la calidad mucho más que el nivel de cuantización.
• Ignorar la caché KV al calcular la memoria. Un modelo de 8.5 GB en 12 GB de VRAM parece normal. Pero con un contexto de 32K, la caché KV puede añadir otros 4-6 GB, y el sistema se colgará.
• Tomar IQ-quants sin verificar la fuente del imatrix. IQ4_XS de un autor desconocido sin un conjunto de datos de calibración puede ser inferior a Q4_K_M. Verifique la tarjeta del modelo en busca de imatrix.
• Recuantizar un modelo ya cuantizado. Si toma un archivo Q8_0 y lo cuantiza a Q4, los errores se acumulan. Siempre cuantice desde el FP16 original.

📬 No se pierda los nuevos artículos

Reciba materiales útiles sobre desarrollo web en su correo

Suscribirse

Sin spam • Solo contenido de calidad • Puede darse de baja en cualquier momento