¿Qué método de cuantización conviene usar en una GPU NVIDIA?

Para GPU NVIDIA con poca VRAM suele ganar AWQ en 4-bit , porque conserva mejor la calidad en tareas exigentes; GPTQ 4-bit también funciona bien si tu stack ya lo soporta. Para GPU grandes, SmoothQuant o AWQ en INT8 dan más estabilidad y calidad.

¿Qué diferencia hay entre GPTQ y AWQ?

Ambos son weight-only 4-bit, pero AWQ (Activation-aware Weight Quantization) identifica qué canales y capas son más sensibles, por lo que suele conservar mejor la calidad en razonamiento y código. GPTQ es el enfoque 4-bit "clásico", útil si ya tienes un ecosistema maduro que lo soporte.

¿Por qué cuantizar a 4-bit no siempre soluciona la falta de memoria?

Porque los pesos no son la única memoria que consume un LLM: el KV cache crece con el contexto y los tokens generados, y suele seguir en FP16/BF16. Si usas contextos largos, ese cache puede convertirse en el verdadero cuello de botella, aunque los pesos ya estén en 4-bit.

¿Cómo se mide la pérdida real de calidad al cuantizar un modelo?

La forma honesta es crear un golden set de 30 a 200 casos representativos de tus tareas reales y comparar el modelo FP16 contra el cuantizado en modo determinista (temperatura baja, mismo prompt y seed), usando exact match, rúbrica humana o perplexity como métricas.

Cuantización de LLM (GPTQ, AWQ, SmoothQuant): guía práctica para correr modelos baratos (y bien)

GUÍAS & TUTORIALES · INFERENCIA LOCAL · OPTIMIZACIÓN

⏱️ 12–16 min de lectura Qué método usar según GPU/CPU, latencia y calidad (con checklist de errores típicos y cómo medir la pérdida real).

Idea central

Cuantizar reduce el peso del modelo, pero el rendimiento real depende de kernels, KV cache y tu caso de uso.

Decisión rápida

Si tienes GPU NVIDIA: suele ganar AWQ (4-bit). Si vas a CPU: mira SmoothQuant (INT8).

Error típico #1

Confundir “cabe en VRAM” con “va rápido”. Cuantización arregla lo primero, no siempre lo segundo.

¿Te ha pasado esto? Descargas un modelo “7B”, le pones 4-bit… y aun así te falta VRAM, o la latencia es peor de lo esperado.

La cuantización es la herramienta más rentable para correr LLMs localmente, pero hay tres trampas: elegir mal el método, medir la calidad “a ojo” y olvidar que la memoria no es solo pesos. Vamos a poner orden con una guía práctica.

1) Qué es cuantizar un LLM (y qué NO es)

Cuantizar, en la práctica, es representar números con menos bits para reducir memoria y acelerar operaciones. En LLMs, el ahorro más directo viene de bajar la precisión de los pesos (weight-only) y, en algunos enfoques, también de las activaciones (W8A8, por ejemplo).

Lo que suele confundir a todo el mundo al principio: no todo lo que ocupa memoria son los pesos. En inferencia hay tres grandes “bolsas”:

Pesos: lo que cuantizas (normalmente).
KV cache: memoria que crece con el contexto y los tokens generados (a menudo sigue en FP16/BF16, aunque depende del motor).
Overhead: escalas, ceros, tablas, buffers y el coste del runtime.

Por eso la cuantización es magia… hasta que metes un contexto largo o subes el batch. Si te interesa decidir arquitectura completa (local vs nube, latencia, coste), encaja perfecto con esta guía de nube vs local.

2) GPTQ, AWQ y SmoothQuant: qué hace cada uno (sin humo)

GPTQ: 4-bit “clásico” para comprimir pesos

GPTQ es un enfoque de post-training quantization que suele usarse como weight-only INT4 (o 3/2-bit en experimentos). La idea es sencilla: reduces memoria de pesos de forma agresiva y luego dependes de kernels optimizados para que la GPU haga el trabajo rápido.

Cuándo lo elegiría: si ya tienes un ecosistema que lo soporta bien (por ejemplo, un motor con kernels maduros para GPTQ), y buscas un buen equilibrio memoria/latencia con un pipeline conocido.

AWQ: 4-bit pensado para “romper menos” la calidad

AWQ (Activation-aware Weight Quantization) también suele ser weight-only 4-bit, pero pone mucho foco en qué canales y capas son más sensibles. En la práctica, a igualdad de bits, AWQ suele conservar mejor calidad en tareas exigentes (razonamiento, código, instrucciones largas) y además tiene muy buen soporte en motores modernos.

Cuándo lo elegiría: cuando quieres 4-bit, pero te importa que el modelo siga “fino” en tareas reales (no solo en chat casual) y quieres kernels rápidos en GPU.

SmoothQuant: INT8 práctico cuando CPU y throughput mandan

SmoothQuant es otra filosofía: intenta hacer viable una inferencia W8A8 (pesos y activaciones en INT8) “suavizando” (rescalando) activaciones para que la cuantización sea más estable. Esto puede ser muy atractivo para CPU (y también para GPU en escenarios de throughput), donde INT8 está muy optimizado.

Cuándo lo elegiría: cuando el objetivo es servir muchas peticiones con latencia consistente, o correr decentemente en CPU sin depender de kernels INT4 muy específicos.

3) Qué método usar según GPU/CPU, latencia y calidad

Aquí va la parte útil. No es “cuál es mejor”, sino cuál te conviene con tu hardware y tu objetivo.

Tu escenario	Prioridad	Recomendación	Notas rápidas
GPU NVIDIA (8–12GB VRAM)	Que quepa + latencia decente	AWQ 4-bit (o GPTQ 4-bit si tu stack lo prefiere)	Busca kernels rápidos; vigila KV cache si usas contexto largo.
GPU NVIDIA (24GB+)	Calidad y estabilidad	SmoothQuant INT8 o AWQ	INT8 puede ser muy sólido para servir; AWQ si quieres bajar memoria con buena calidad.
CPU (sin GPU o GPU muy justa)	Que vaya “usable”	SmoothQuant INT8	Aprovecha librerías INT8; controla threads y afinidad para latencia estable.
Te obsesiona la calidad	Minimizar degradación	SmoothQuant INT8 o AWQ bien calibrado	La calibración manda. Y mide en tu “golden set”, no en sensaciones.
Te obsesiona la velocidad	Tokens/s y throughput	Depende del motor: AWQ/GPTQ con kernels top, o INT8 si tu stack está optimizado	No compares “modelo vs modelo”: compara backend+kernels+config.

Si estás en la fase de elegir modelo antes de optimizarlo, te puede ayudar esta guía para comparar modelos y elegir el mejor, porque cuantizar un modelo mediocre no lo convierte en bueno: solo lo hace más barato.

4) Regla de oro de memoria: por qué “4-bit” no siempre salva

Un cálculo mental útil para los pesos:

Tamaño de pesos ≈ parámetros × (bits / 8) (más un overhead pequeño por escalas y metadatos)

Esto te da una intuición de por qué 4-bit es tan popular: reduce los pesos aproximadamente a una cuarta parte respecto a FP16. Pero el golpe de realidad es el KV cache: si usas contexto largo, el KV cache puede convertirse en el “elefante en la habitación”.

Traducción práctica: si tu plan es trabajar con contextos grandes, no basta con cuantizar; tienes que optimizar motor de inferencia, configuración de contexto, y cómo alimentas el prompt (RAG, resúmenes, ventanas). Ahí conecta con este mapa de decisión entre RAG, fine-tuning y agentes: muchas veces el “truco barato” no es bajar bits, sino bajar contexto.

5) Guía práctica: cómo hacerlo sin perder una tarde

Te dejo un proceso que funciona en la vida real (y que evita el clásico bucle de “quantizo, pruebo dos prompts, me engaño”).

Paso 1: define tu objetivo en una línea

Ejemplos buenos (concretos):

“Quiero que un 7B me quepa en 8GB VRAM con contexto moderado y latencia razonable.”
“Quiero servir 50 req/s y me vale INT8 si la calidad se mantiene en mis tareas.”
“Quiero correrlo en CPU sin que tarde un siglo por respuesta.”

Paso 2: elige el “combo” método + motor (esto es más importante que el método solo)

La experiencia suele mejorar mucho cuando el motor tiene kernels maduros para tu formato. Como regla práctica:

AWQ/GPTQ brillan cuando el motor tiene kernels rápidos y estables para INT4.
SmoothQuant INT8 brilla cuando el stack aprovecha INT8 de verdad (CPU optimizada o GPU con buen soporte).

No te cases con el formato: cásate con el resultado (latencia, memoria, calidad) en tu hardware.

Paso 3: calibración: usa texto que se parezca a lo tuyo

La calibración es el punto donde se gana o se pierde calidad. Si cuantizas para soporte técnico y calibras con literatura clásica, luego te extraña que el modelo “se vuelva raro” en tickets reales.

Regla práctica: prepara un pequeño corpus con tus prompts típicos (sin datos sensibles) y fragmentos representativos de tu dominio: estilo, longitud, vocabulario, estructura.

Paso 4: ejecuta con configuración de test (determinista)

Si mides calidad con muestreo creativo, vas a confundir variabilidad con degradación. Para comparar:

Temperatura baja (o 0 si el motor lo permite), top_p desactivado o alto.
Mismo prompt, mismo contexto, mismo seed (si aplica).
Mismo motor y settings, cambiando solo el “peso” (FP16 vs cuantizado) cuando sea posible.

Paso 5: optimiza lo que de verdad manda en latencia

La latencia suele dividirse en dos: prefill (procesar el prompt) y decode (generar tokens). Si tu prompt es enorme, tu optimización no es “más bits”: es menos prompt, mejor RAG, y caché. Si generas mucho, entonces sí: kernels, batch, KV cache y cuantización importan más.

6) Cómo medir la pérdida real (sin autoengañarte)

La degradación por cuantización no siempre se ve en “chatear un rato”. Se ve cuando el modelo está bajo presión: instrucciones largas, contextos ruidosos, tareas con precisión (código, extracción, formatos), o prompts donde una palabra importa.

La forma más honesta de medir “pérdida”: un golden set pequeño (30–200 casos) de tus tareas reales, con criterios de evaluación claros. Luego comparas FP16 vs cuantizado en modo determinista.

Tres métricas prácticas (elige una o combina):

Exact match / pass-fail: perfecto para extracción, JSON, formatos, tests de unidad.
Rubrica humana rápida: 0–2 o 0–3 por caso (precisión, seguimiento de instrucciones, alucinación). 50 casos ya dan señal.
Perplexity/score en texto de tu dominio (si tienes pipeline), útil como termómetro, no como juez único.

Si quieres hacerlo “bien” (y evitar trampas tipo contaminación o comparar cosas que no son comparables), te recomiendo esta pieza sobre evaluación de LLM sin autoengaño y cómo montar un golden set. Es literalmente el antídoto contra “me parece que va igual”.

7) Checklist de errores típicos (y cómo arreglarlos)

1) “He cuantizado a 4-bit, así que ya no tendré problemas de memoria.”

Arreglo: revisa KV cache y contexto. Reduce contexto, usa RAG/resúmenes, o configura el motor para cache más eficiente si lo soporta.

2) Comparo calidad con prompts distintos (o con temperatura alta).

Arreglo: modo determinista, mismo prompt, mismo seed, misma plantilla. Si no, estás midiendo aleatoriedad, no degradación.

3) Calibro con texto genérico y luego el modelo falla en mi dominio.

Arreglo: calibra con un corpus representativo (estilo, longitud, vocabulario). Si tu uso es “código”, calibra con código; si es “tickets”, calibra con tickets.

4) “Va lento” porque en realidad no estás usando kernels optimizados.

Arreglo: verifica que el motor está usando el backend correcto (y no un fallback). Muchas “decepciones” son un fallback silencioso.

5) Ajustas “group size / config” y asumes que siempre mejora.

Arreglo: cada ajuste tiene trade-off entre calidad, memoria y velocidad. Cambia una cosa cada vez y mide con tu golden set.

6) Crees que “cuantización = menos alucinaciones” o “más alucinaciones”.

Arreglo: no lo des por hecho. La cuantización puede afectar estabilidad, pero el efecto depende del modelo y de tus prompts. Mide: alucinación es un fenómeno de comportamiento, no solo de bits.

8) Recetas rápidas por caso real

Caso A: “Tengo una GPU de 8GB y quiero algo usable ya”

Empieza por AWQ 4-bit. Mantén contexto moderado, y prioriza un motor con kernels rápidos. Mide primero en tu golden set. Si la calidad cae en tus tareas “difíciles”, prueba un ajuste más conservador o sube a INT8 si te cabe.

Caso B: “Voy a CPU (o quiero estabilidad) y me importa el throughput”

Ve a SmoothQuant INT8. Ajusta threads, fija afinidad si puedes y mira latencia p95, no solo el promedio. En CPU, INT8 suele darte una experiencia más predecible que pelearte con INT4.

Caso C: “Tengo GPU grande y quiero que responda bien en tareas serias”

Prueba INT8 (SmoothQuant) como baseline “sólido”, y solo baja a 4-bit si necesitas memoria o si el stack te da una ventaja clara en tokens/s. La calidad suele ser más estable en INT8, especialmente en tareas delicadas.

Cierre: lo barato sale bien… si lo mides

Si me obligas a resumir todo en una frase: la mejor cuantización es la que pasa tu golden set con tu motor y tu hardware. AWQ suele ser el “camino feliz” para 4-bit en GPU, GPTQ sigue siendo muy útil según el stack, y SmoothQuant brilla cuando INT8 está bien aprovechado (especialmente en CPU y serving).

Hazlo en orden: objetivo claro, método + motor, calibración representativa, comparación determinista y evaluación honesta. Con eso, la cuantización deja de ser un experimento y se convierte en una ventaja competitiva: mismo valor, menos coste.