Phase 17 - Lesson 09

Cuantización en Producción: AWQ, GPTQ, GGUF K-quants, FP8, MXFP4/NVFP4

El formato de cuantización no es una elección universal: es una función del hardware, el motor de servicio y la carga de trabajo. GGUF Q4_K_M o Q5_K_M domina en CPU y dispositivos periféricos (edge), entregado a través de llama.cpp y Ollama. GPTQ gana dentro de vLLM cuando se necesita multi-LoRA sobre la misma base. AWQ con kernels Marlin-AWQ ofrece ~741 tok/s en un modelo de clase 7B con el mejor Pass@1 en INT4, el estándar por defecto en 2026 para producción en centros de datos. FP8 se mantiene como el término medio en Hopper, Ada y Blackwell: casi sin pérdidas y ampliamente compatible. NVFP4 y MXFP4 (microescalado de Blackwell) son agresivos y requieren validación por bloque. Dos trampas acechan a los equipos: el conjunto de datos de calibración debe coincidir con el dominio de implementación, y la caché KV es independiente de la cuantización de pesos; la lección de AWQ "mi modelo ahora es de 4 GB" olvida los 10-30 GB de caché KV con tamaños de lote de producción.

Tipo: Learn Idiomas: Python (stdlib, comparación básica de huella de memoria y rendimiento entre formatos) Prerrequisitos: Phase 10 · 13 (Quantization foundations), Phase 17 · 04 (vLLM Serving Internals) Tiempo: ~75 minutos

Objetivos de Aprendizaje

  • Nombrar los seis formatos de cuantización en producción y sus puntos fuertes en 2026.
  • Elegir un formato dado el hardware (CPU frente a GPU, Hopper frente a Blackwell), el motor (vLLM, TRT-LLM, llama.cpp) y la carga de trabajo (chat de rutina, razonamiento, multi-LoRA).
  • Calcular la memoria de peso ahorrada y la caché KV que queda intacta para el formato elegido.
  • Identificar la trampa del conjunto de datos de calibración que degrada los modelos cuantizados en tráfico de dominio específico.

El Problema

La cuantización reduce el uso de memoria y el ancho de banda de HBM, que es exactamente lo que necesita el proceso de decodificación. Un modelo de 70B en FP16 representa 140 GB de pesos. Al cuantizar los pesos a INT4 (AWQ o GPTQ), el modelo se reduce a 35 GB, lo que cabe en una sola H100 con espacio de sobra para la caché KV. Esto es crucial porque con 128 secuencias concurrentes y un contexto de 2k, la caché KV representa por sí sola 20-30 GB.

Pero la cuantización no es gratuita. La cuantización agresiva degrada la calidad, especialmente en tareas que requieren mucho razonamiento. Los diferentes formatos funcionan con diferentes motores. Los diferentes tipos de hardware admiten diferentes precisiones de forma nativa. La variedad de formatos en 2026 es real y no puede copiar la elección de otros: debe elegir en función de su pila.

El Concepto

Los seis formatos

Formato Bits Punto ideal Motores
GGUF Q4_K_M / Q5_K_M 4-5 CPU, edge, laptops llama.cpp, Ollama
GPTQ 4-8 Multi-LoRA en vLLM vLLM, TGI
AWQ 4 Producción GPU en centro de datos vLLM (Marlin-AWQ), TGI
FP8 8 Centro de datos Hopper/Ada/Blackwell vLLM, TRT-LLM, SGLang
MXFP4 4 Blackwell multiusuario TRT-LLM
NVFP4 4 Blackwell multiusuario TRT-LLM

GGUF: el valor predeterminado para CPU y edge

GGUF es un formato de archivo, no un esquema de cuantización en sí mismo: agrupa variantes de cuantización K (Q2_K, Q3_K_M, Q4_K_M, Q5_K_M, Q6_K, Q8_0) en un solo contenedor. Q4_K_M y Q5_K_M son las opciones estándar en producción: calidad cercana a BF16 con 4-5 bits. Es la mejor opción para servir en CPU o edge porque llama.cpp es, con diferencia, el motor de inferencia de CPU más rápido.

Penalización de rendimiento en vLLM: ~93 tok/s en modelos 7B; el formato no está optimizado para kernels de GPU. Use GGUF cuando el objetivo del despliegue sea CPU/edge. En caso contrario, no lo use.

GPTQ: multi-LoRA en vLLM

GPTQ es un algoritmo de cuantización posterior al entrenamiento con un paso de calibración. Los kernels Marlin lo hacen rápido en GPU (aceleración de 2.6x frente a GPTQ sin Marlin). Ofrece ~712 tok/s en modelos 7B.

La ventaja única: GPTQ-Int4 admite adaptadores LoRA en vLLM. Si está sirviendo un modelo base y de 10 a 50 variantes ajustadas (cada una como un LoRA), GPTQ es su mejor opción. NVFP4 aún no admite LoRA a principios de 2026.

AWQ: el estándar de GPU para centros de datos

Activation-aware Weight Quantization. Protege aproximadamente el 1% de los pesos más importantes durante la cuantización. Kernels Marlin-AWQ: aceleración de 10.9x frente a la opción básica. ~741 tok/s en un modelo 7B, con el mejor Pass@1 entre los formatos INT4.

Elija AWQ para los nuevos servicios de GPU, a menos que necesite multi-LoRA (GPTQ) o el agresivo Blackwell FP4 (NVFP4).

FP8: el término medio confiable

Punto flotante de 8 bits. Casi sin pérdidas de calidad. Ampliamente compatible. Los Tensor Cores de Hopper aceleran FP8 de forma nativa, una ventaja que hereda Blackwell. FP8 es el valor predeterminado seguro en 2026 cuando la calidad no es negociable (razonamiento, medicina, generación de código). El ahorro de memoria es la mitad que en INT4, pero el riesgo para la calidad es mucho menor.

MXFP4 / NVFP4: Blackwell agresivo

Microscaling FP4. Cada bloque de pesos tiene su propio factor de escala. Agresivo pero acelerado por hardware en los Tensor Cores de Blackwell. Reduce a la mitad los bytes por token en comparación con FP8: la ganancia económica descrita en Phase 17 · 07.

Advertencias:

  • Aún no se admite LoRA (principios de 2026).
  • Caída de calidad visible en cargas de trabajo que requieren mucho razonamiento.
  • Valide en su propio conjunto de evaluación (eval set) para cada modelo.

La trampa de la calibración

AWQ y GPTQ requieren un conjunto de datos de calibración, normalmente C4 o WikiText. Para modelos orientados a un dominio (código, médico, legal), calibrar con texto genérico de la web hace que el algoritmo tome decisiones incorrectas sobre qué pesos proteger. El Pass@1 en HumanEval puede caer varios puntos.

La solución: realice la calibración con datos específicos de su dominio. Unos pocos cientos de muestras de dominio suelen ser suficientes. Realice pruebas en el conjunto de evaluación antes del envío.

La trampa de la caché KV

AWQ reduce los pesos a 4 bits. La caché KV es independiente y permanece en FP16/FP8. Para un modelo de 70B con AWQ:

  • Pesos: ~35 GB (INT4 frente a 140 GB).
  • Caché KV con 128 secuencias concurrentes × contexto de 2k: ~20 GB.
  • Activaciones: ~5 GB.
  • Total: ~60 GB; cabe en una H100 de 80GB.

Asumir ingenuamente que "cuantizé mi modelo a 4 GB" olvida los otros 30-50 GB. Planifique el presupuesto de HBM de forma holística.

Por otra parte, la cuantización de la caché KV (FP8 KV o INT8 KV) es una opción diferente con sus propios compromisos: afecta directamente la precisión de la atención y no es una ganancia gratuita.

AWQ INT4 es riesgoso para el razonamiento

Chain-of-thought, matemáticas, generación de código con contextos largos: estos sufren de forma visible con la cuantización agresiva. AWQ INT4 pierde aproximadamente entre 3 y 5 puntos en MATH. Para cargas de trabajo que requieren mucho razonamiento, envíe FP8 o BF16; acepte el costo de memoria.

Guía de elección para 2026

  • Servicio en CPU/edge: GGUF Q4_K_M. Resuelto.
  • Servicio en GPU, chat de rutina, sin LoRA: AWQ.
  • Servicio en GPU, multi-LoRA: GPTQ con Marlin.
  • Cargas de trabajo de razonamiento: FP8.
  • Centro de datos Blackwell, calidad validada: NVFP4 + FP8 KV.
  • Casos ambiguos: ejecute una evaluación de 1,000 muestras en cada formato candidato.

Utilízalo

code/main.py calcula la huella de memoria (pesos + caché KV + activaciones) y el rendimiento relativo entre los seis formatos para varios tamaños de modelo. Muestra dónde domina la caché KV, dónde vale la pena la compresión de pesos y cuándo FP8 es la opción segura.

Entrégalo

Esta lección produce outputs/skill-quantization-picker.md. Dados el hardware, el tamaño del modelo, el tipo de carga de trabajo y la tolerancia de calidad, elige un formato y genera un plan de calibración/validación.

Ejercicios

  1. Ejecute code/main.py. Para un modelo de 70B con 128 secuencias concurrentes y un contexto de 2k, calcule la HBM total para cada formato. ¿Qué formato le permite encajar el modelo en una sola H100 de 80GB?
  2. Tiene un modelo de codificación de 7B. Elija un formato y justifique la elección. Si se equivoca respecto a la tolerancia a la calidad, ¿cuál es el plan de recuperación?
  3. Calcule el tamaño del conjunto de datos de calibración necesario para calibrar AWQ en un modelo de dominio médico. ¿Por qué más datos no siempre es mejor?
  4. Lea el artículo científico o las notas de lanzamiento de Marlin-AWQ. Explique en tres frases por qué AWQ alcanza 741 tok/s en 7B mientras que GPTQ básico alcanza ~712.
  5. ¿Cuándo tiene sentido combinar pesos AWQ con caché KV en FP8 frente a mantener la caché KV en BF16?

Términos Clave

Término Lo que la gente dice Lo que realmente significa
GGUF "formato de llama.cpp" Formato de archivo que agrupa variantes de cuantización K; por defecto en CPU/edge
Q4_K_M "Q4 K M" K-quant de 4 bits medio; la opción predeterminada de GGUF en producción
GPTQ "gee pee tee q" Cuantización INT4 posterior al entrenamiento con calibración; admite LoRA en vLLM
AWQ "a w q" INT4 consciente de la activación; kernels Marlin; mejor Pass@1 en INT4
Kernels Marlin "kernels rápidos INT4" Kernels CUDA personalizados para INT4 en Hopper; aceleración de 10x
FP8 "punto flotante de ocho bits" Precisión predeterminada segura en Hopper/Ada/Blackwell
MXFP4 / NVFP4 "microescalado de cuatro bits" Formato FP de 4 bits de Blackwell con factores de escala por bloque
Conjunto de datos de calibración "datos de calibración" Texto de entrada utilizado para elegir parámetros de cuantización; debe coincidir con el dominio
Cuantización de caché KV "KV INT8" Elección independiente de los pesos; afecta directamente la precisión de la atención

Lecturas Adicionales

0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).