Cuando un cliente muestra los requisitos para desplegar un modelo de 70B en local y dispone de un único servidor con dos GPU, la reacción habitual es siempre la misma: "No va a caber." En FP16 es cierto — ese modelo necesita entre 140 y 168 GB de VRAM, una configuración que no está al alcance de cualquiera. Pero con cuantización a 4 bits, el mismo modelo baja a 35–40 GB, lo que equivale a dos tarjetas de gama media. ¿Y la pérdida de calidad? Con el formato adecuado es menor de lo que la mayoría espera.
La cuantización es hoy una de las habilidades prácticas más importantes a la hora de desplegar LLM en hardware propio. Este artículo explica qué ocurre con los pesos del modelo durante la cuantización, cuál es la diferencia entre los formatos GGUF, AWQ y GPTQ, cuánta calidad se pierde realmente en cada nivel y en qué se diferencia de la destilación, con la que se confunde con frecuencia.
Qué hace la cuantización a los pesos
Los LLM modernos se entrenan en formato BF16 o FP16 — cada parámetro ocupa 16 bits. Un modelo de 7 000 millones de parámetros necesita así unos 14 GB solo para los pesos (más la caché KV y las activaciones adicionales).
La cuantización representa esos mismos pesos con menor precisión numérica. En lugar de un float de 16 bits se usa un entero de 8 o 4 bits. La fórmula es directa: VRAM (GB) ≈ (número de parámetros en miles de millones × bits) / 8. Con cuantización a 4 bits de un modelo de 7B obtienes 5–7 GB — cabe en una estación de trabajo convencional.
El precio de ese ahorro es la pérdida de información. La precisión numérica disminuye y algunas diferencias sutiles entre pesos se "aplanan" hasta una misma representación. La consecuencia es una ligera caída de calidad en las salidas — la pregunta es cuánta.
Es importante entender lo que la cuantización no es: no es destilación. La cuantización conserva la arquitectura y el número de parámetros del modelo original; solo cambia el formato numérico de los pesos. La destilación, en cambio, transfiere conocimiento a un modelo más pequeño con una arquitectura diferente — es transferencia de conocimiento, no compresión. Más detalles sobre destilación en el artículo Destilación de modelos: cómo obtener un modelo pequeño y rápido a partir de uno grande.
GGUF — el formato para CPU y despliegue multiplataforma
GGUF es un formato binario desarrollado para llama.cpp y hoy soportado de forma nativa también en Ollama. Su característica clave: el modelo puede ejecutarse puramente en CPU, o en una combinación híbrida CPU+GPU en la que parte de las capas corre en la GPU y el resto en la CPU aprovechando la RAM del sistema.
Para el despliegue empresarial esto supone una ventaja práctica: un desarrollador puede ejecutar un modelo de 13B en una estación de trabajo sin GPU dedicada, o en un servidor con menos VRAM de la que el modelo en FP16 requeriría.
Niveles de cuantización en GGUF
La nomenclatura sigue el esquema Q<bits>_<variante>. Los niveles más relevantes:
- Q8_0 — cuantización a 8 bits, mínima pérdida de calidad (~1–2 % respecto a FP16). Recomendado cuando hay suficiente VRAM y se busca máxima precisión.
- Q4_K_M — 4 bits, variante "medium" con cuantización adaptativa para las capas más sensibles. Conserva ~92–95 % de la calidad FP16. El punto de equilibrio estándar para la mayoría de casos de uso.
- Q4_K_S — 4 bits, variante "small", algo más pequeña que K_M con calidad similar.
- Q3_K_M — 3 bits, huella notablemente menor, degradación perceptible en razonamiento complejo.
- Q2_K — 2 bits, degradación severa. Utilizable solo con hardware extremadamente limitado y tareas no críticas.
La letra K en la nomenclatura significa "k-quants" — un método más sofisticado que aplica mayor precisión a las capas más sensibles a los errores de cuantización (típicamente las capas de embedding y de salida) y una compresión más agresiva a las partes menos críticas. El resultado es una mejor relación calidad/tamaño respecto a la cuantización uniforme simple.
AWQ — cuantización calibrada para stack de GPU
AWQ (Activation-aware Weight Quantization) es un método que durante la cuantización tiene en cuenta la estadística de las activaciones — es decir, qué valores de entrada ve el modelo en la práctica. A partir de esa estadística identifica los pesos "importantes" y les conserva mayor precisión, cuantizando el resto de forma más agresiva.
El resultado: el formato AWQ a 4 bits conserva ~93–96 % de la calidad FP16, algo mejor que GPTQ al mismo tamaño. La diferencia es especialmente visible en generaciones de texto largas y en código, donde la coherencia se degrada más rápido con cuantización no calibrada.
AWQ requiere GPU para la inferencia — no está pensado para entornos solo CPU. Lo soportan de forma nativa vLLM y TGI. Para despliegues NVIDIA en producción es hoy uno de los formatos preferidos.
GPTQ — máximo throughput en GPU NVIDIA
GPTQ (Generative Pre-trained Transformer Quantization) es un método más antiguo y consolidado. Utiliza derivadas segundas (Hessiano) para minimizar el error de cuantización con una calibración por lotes. En la práctica, GPTQ a 4 bits queda ligeramente por detrás de AWQ en preservación de calidad (~90–93 % frente a FP16), pero ofrece el máximo throughput en GPU NVIDIA mediante kernels fusionados.
Para escenarios donde la prioridad es el mayor número posible de tokens por segundo (por ejemplo, serving para múltiples usuarios concurrentes), GPTQ combinado con vLLM ofrece resultados sólidos. Al igual que AWQ, requiere GPU — la inferencia en CPU no está soportada de forma nativa.
Comparación de formatos — cuándo usar cada uno
- GGUF — cuando necesitas despliegue multiplataforma, inferencia en CPU o modo híbrido CPU+GPU, o cuando despliegas vía
Ollamaen estaciones de desarrollo - AWQ — stack puramente GPU (NVIDIA), despliegue en producción vía
vLLMoTGI, prioridad en la coherencia de la salida - GPTQ — stack puramente GPU (NVIDIA), despliegue en producción vía
vLLM, prioridad en el máximo throughput con serving multiusuario
Estos formatos no son intercambiables ni compatibles entre sí — un modelo cuantizado en GPTQ no puede cargarse directamente en llama.cpp, ni al revés. Antes de elegir el formato hay que saber qué stack de serving y qué hardware se va a utilizar.
Pérdida de calidad real — qué dicen los números
La pregunta que los clientes hacen con más frecuencia: "¿Cuánta calidad perderemos?"
La respuesta depende del nivel de cuantización y del tipo de tarea. Las mediciones en distintos modelos (Qwen, DeepSeek, Mistral, Llama) muestran un patrón consistente:
- Q8_0 / 8 bits: diferencia en perplejidad inferior al 1–2 % respecto a FP16. En conversación cotidiana prácticamente imperceptible.
- Q4_K_M / AWQ 4 bits: diferencia en perplejidad típicamente inferior al 5–8 % respecto a BF16. En la mayoría de tareas — extracción de información, resumen, clasificación — la diferencia no es apreciable a simple vista. En razonamiento multietapa complejo (matemáticas, código, cadenas largas de pasos) puede haber una leve caída observable.
- Q3 e inferior: la degradación es perceptible. El modelo empieza a producir salidas menos coherentes, especialmente en generaciones largas o en tareas donde la precisión importa.
- Q2: degradación severa. Adecuado solo bajo restricciones de hardware extremas y para tareas no críticas.
Un matiz importante: la pérdida de calidad no está distribuida de forma uniforme. Los modelos con mayor número de parámetros toleran mejor una cuantización más agresiva — un modelo de 70B en Q4_K_M suele conservar más capacidades que uno de 7B en la misma configuración. En modelos pequeños (7B o menos), la diferencia entre Q8 y Q4 es más visible.
Un segundo matiz: los benchmarks miden promedios. Para un caso de uso de dominio específico (por ejemplo, análisis de documentación técnica) tiene sentido hacer una comparación propia FP16 vs Q4 sobre una muestra de entradas reales — unas pocas decenas de ejemplos suelen bastar para sacar una conclusión orientativa.
Ahorro de VRAM en la práctica
Cifras concretas para los tamaños de modelo más habituales:
- Modelo 7–9B: FP16 ~16–19 GB → Q8_0 ~8–13 GB → Q4_K_M ~5–7 GB
- Modelo 13B: FP16 ~26 GB → Q8_0 ~14 GB → Q4_K_M ~8 GB
- Modelo 27–34B: FP16 ~54–68 GB → Q8_0 ~30–34 GB → Q4_K_M ~17–20 GB
- Modelo 70B: FP16 ~140–168 GB → Q8_0 ~70–75 GB → Q4_K_M ~35–40 GB
A estas cifras hay que añadir la caché KV, que crece con la longitud del contexto y el número de peticiones concurrentes. Un modelo de 70B con contexto largo puede consumir otros 20–40 GB de caché KV con varias conversaciones paralelas. Al planificar la infraestructura no basta con contar solo los pesos — la caché KV es una variable igual de importante. Más detalles en el artículo Qué GPU necesitas para inferencia LLM.
Cuantización y stack de serving — qué saben vLLM y Ollama al respecto
Ollama es una herramienta excelente para despliegues de desarrollo — descargas un modelo GGUF con un único comando y funciona en local sin configuración. Bajo el capó está llama.cpp. La limitación clave: Ollama no es un framework de serving para producción. Con varios usuarios concurrentes puedes registrar un throughput notablemente inferior al de vLLM — y eso independientemente de la cuantización.
vLLM con modelos AWQ o GPTQ está diseñado para entornos de producción con múltiples peticiones concurrentes. Utiliza PagedAttention para la gestión eficiente de la caché KV y continuous batching — el throughput resultante puede ser significativamente mayor que el de Ollama con varios usuarios simultáneos. El coste es una configuración más compleja y el requisito de GPU.
Para el despliegue empresarial, el flujo habitual es: desarrolladores y testers trabajan con modelos GGUF vía Ollama; el servidor de inferencia en producción corre en vLLM con AWQ o GPTQ. Ambos enfoques coexisten — no es una elección excluyente. Comparativa detallada de estas herramientas de serving en el artículo vLLM vs SGLang vs Ollama.
Cuantización vs destilación — una distinción importante
Estos dos conceptos se confunden en la práctica, pero se trata de técnicas fundamentalmente distintas.
La cuantización conserva la arquitectura original del modelo — solo se cambia el formato numérico de los pesos. El proceso es rápido, no requiere entrenamiento y las herramientas de cuantización existentes pueden procesar un modelo de 70B en pocas horas en un servidor convencional. Se pierde información en la precisión numérica.
La destilación crea un modelo nuevo y más pequeño entrenándolo sobre las salidas del modelo más grande (teacher). Es un proceso de entrenamiento completo — requiere datos, tiempo de cómputo y ajuste de hiperparámetros. El resultado es un modelo con menos parámetros y una arquitectura diferente que ha "aprendido" a imitar al teacher. Se pierde capacidad — el modelo más pequeño sencillamente no tiene los parámetros suficientes para algunas tareas complejas.
En la práctica, ambos enfoques son complementarios: un modelo destilado puede cuantizarse a continuación. Por ejemplo, un modelo pequeño creado por destilación a partir de un modelo frontier puede distribuirse como GGUF Q4 para despliegue en el edge.
Cómo abordar la elección de cuantización en un proyecto
Algunas recomendaciones prácticas extraídas de los despliegues que hemos visto:
- 1.Empieza por Q4_K_M — para la mayoría de casos de uso empresariales (extracción, clasificación, Q&A sobre documentos) Q4_K_M ofrece calidad suficiente y una huella de VRAM razonable
- 2.Verifica con tus propios datos — si la aplicación tiene requisitos específicos (por ejemplo, extracción precisa de valores numéricos de informes técnicos), compara FP16 y Q4 sobre una muestra de 50–100 entradas reales antes de tomar la decisión final
- 3.No subestimes la caché KV — al planificar el hardware cuenta con la caché KV por encima del tamaño de los pesos, especialmente si prevés contextos largos
- 4.Ten en cuenta el stack de serving — si vas a vLLM, AWQ es una buena opción; si vas a Ollama o multiplataforma, GGUF; si priorizas el throughput en NVIDIA, GPTQ
- 5.Q2 mejor evitarlo — la degradación es severa; mejor usar un modelo más pequeño en Q4 que uno más grande en Q2
Preguntas frecuentes
¿Puedo cuantizar cualquier modelo yo mismo?
Sí, herramientas como llama.cpp (para GGUF), AutoAWQ y AutoGPTQ son open-source y están disponibles. Para tamaños habituales (7–34B) un servidor convencional puede realizar la cuantización en pocas horas. Para modelos de 70B o más se necesita bastante más RAM (la cuantización parte del modelo en FP16 antes de la conversión). En la práctica, para la mayoría de los equipos es más sencillo recurrir a modelos ya cuantizados en Hugging Face — la calidad está verificada y se ahorra tiempo.
¿Es perceptible la diferencia entre Q4_K_M y Q4_K_S?
En el uso cotidiano, mínima. Q4_K_S produce un archivo algo más pequeño con una calidad muy similar. Q4_K_M es la opción más conservadora, que preserva algo más de precisión en las capas sensibles. Para la mayoría de casos de uso recomendamos Q4_K_M como punto de partida.
Cuantización y GDPR — ¿hay algo que considerar?
Directamente, no — la cuantización no cambia el comportamiento del modelo al procesar datos, solo su huella de VRAM y su velocidad. Las implicaciones del GDPR están relacionadas con *dónde* se ejecuta el modelo y *quién* tiene acceso a los datos. El despliegue on-prem de un modelo cuantizado puede ayudar en términos de localización de datos (los datos no salen de la infraestructura), pero el cumplimiento normativo requiere mucho más — registros de auditoría, controles de acceso, proceso DPA documentado. Más información en el artículo LLM on-prem para sectores regulados.
¿Puedo hacer fine-tuning de un modelo ya cuantizado?
El fine-tuning directo de un modelo cuantizado (por ejemplo, GGUF Q4) no es el procedimiento estándar — la mayoría de los frameworks de fine-tuning trabajan con pesos en FP16 o BF16. QLoRA es la excepción: permite entrenar con pesos base cuantizados a 4 bits mientras los adaptadores LoRA se entrenan con mayor precisión. Más detalles en el artículo LoRA vs QLoRA vs full fine-tuning.
¿Cuál es la diferencia entre NVFP4 y la cuantización estándar a 4 bits?
NVFP4 es un formato nativo de hardware específico de las GPU NVIDIA más recientes con arquitectura Blackwell. A diferencia de los métodos software de 4 bits (GPTQ, AWQ, GGUF Q4), NVFP4 está acelerado directamente en los tensor cores del chip. El resultado son throughputs superiores a los de los formatos genéricos de 4 bits en el mismo hardware. Si no dispones de una GPU Blackwell, este formato no te afecta — AWQ o GPTQ estándar son la opción correcta.
*Elegir el formato de cuantización y el stack de serving adecuados es una decisión que influirá significativamente en los costes y el rendimiento del despliegue en producción. En MP Industrial Solutions ayudamos a las empresas a recorrer el camino desde el primer experimento con un LLM local hasta la infraestructura de producción — incluyendo la evaluación del hardware, la selección del modelo y del formato de cuantización para cada caso de uso concreto. Si estás valorando un despliegue LLM on-prem, estaremos encantados de mantener una consulta inicial.*