Guía de cuantización de modelos: de los fundamentos al serving en producción

Viacheslav Dubrov

2026-07-05 · Actualizado 2026-07-22 · 30 min · Ingeniería de modelos · Infraestructura de IA

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

La cuantización utiliza menos bits para representar los valores del modelo. Un flujo de serving puede cuantizar los pesos, las activaciones, la caché KV o una combinación de estos elementos, y cada objetivo resuelve un problema distinto de serving.

Elige el objetivo a partir del cuello de botella actual: memoria de los pesos, cómputo de activaciones, tamaño de la caché KV, kernels, hardware, datos de calibración o calidad. Un modelo de 4 bits puede caber en la VRAM y, aun así, ejecutarse lentamente con un kernel no optimizado, como demuestra el benchmark de vLLM de JarvisLabs. FP8 funciona bien en hardware NVIDIA Hopper con un runtime compatible, pero no ofrece ningún beneficio nativo en GPU no compatibles. La matriz de hardware de TensorRT-LLM muestra las rutas compatibles. Para contextos largos o una concurrencia elevada, la cuantización de la caché KV puede ahorrar más memoria que la cuantización de pesos.

Si eres ingeniero de ML o de plataforma y tienes que elegir una estrategia de cuantización para un modelo que necesitas servir, esta guía es para ti. Al terminar, deberías poder relacionar un cuello de botella con un formato candidato, un runtime y un plan de validación antes del despliegue.

Para consultar una comparación breve de artefactos y métodos, ve a Formatos de cuantización de LLM.

1. Empieza por el cuello de botella

Antes de elegir el número de bits, determina qué limita la carga de trabajo. La respuesta puede ser la memoria de los pesos del modelo, el cómputo del prefill, el ancho de banda del decode o la caché KV, y no necesariamente la precisión numérica.

Cuellos de botella habituales y sus puntos de partida:

Usa esta tabla como mapa. Las secciones siguientes explican por qué esos puntos de partida difieren.

Notación utilizada en las recetas de serving

• W{x}A{y} indica la precisión para el cálculo compatible de pesos y activaciones, normalmente en las rutas GEMM de los motores de serving. W4A16 almacena los pesos en formato de 4 bits y mantiene las activaciones con precisión de 16 bits. W8A8 utiliza pesos y activaciones de 8 bits en las rutas de cómputo compatibles, pero no define automáticamente el dtype de almacenamiento persistente de todos los tensores del runtime.
• FP8, INT8, INT4, NF4 son formatos numéricos. Determinan qué valores se pueden representar.
• GPTQ, AWQ, SmoothQuant, QuaRot son algoritmos. Determinan cómo convertir un modelo entrenado a un formato de menor precisión.
• GGUF es un formato de archivo que almacena tensores y metadatos para GGML y runtimes de tipo llama.cpp. Un archivo GGUF puede contener tipos de tensor sin cuantizar, como F16, BF16 o F32, además de codificaciones cuantizadas. Entre los presets se incluyen Q4_K_M, Q5_K_M, Q8_0, IQ*, TQ* y MXFP4. La codificación del tensor determina la opción de cuantización. Por sí solo, GGUF no describe una receta de serving CUDA-style FP8 W8A8.
• KV cache es la caché de atención utilizada durante la generación. Almacena las keys y values anteriores para que el modelo no tenga que recalcular toda la conversación en cada token.
• KV-cache quantization almacena los tensores de activación key/value de la caché en un formato de menor precisión, como FP8, INT8, INT4 o INT2, según la compatibilidad del runtime. Esto es distinto del prefix caching, PagedAttention o el offload, que determinan si se reutilizan las entradas de la caché, cómo se asignan o dónde residen.
• GEMM significa general matrix multiply. La mayor parte del tiempo de inferencia de un transformer se dedica a multiplicaciones de matrices.

2. La cuantización es un redondeo controlado

La cuantización asigna valores de alta precisión a un conjunto más pequeño de valores representables; esta es la definición fundamental que utilizan tanto Hugging Face Optimum como TensorRT-LLM. Ahorras memoria y ancho de banda. También introduces error de redondeo.

INT4 solo proporciona 16 valores discretos, por lo que asignar pesos BF16 a esa rejilla genera error de redondeo. Métodos como GPTQ, AWQ y SVDQuant se centran en preservar los outliers y reducir el error de reconstrucción. Una buena asignación ahorra memoria con una pérdida de calidad mínima. Una mala puede perjudicar el razonamiento, el seguimiento de instrucciones o la fidelidad visual.

Mapeo simétrico y asimétrico

Siguiendo el mapeo afín utilizado en las guías de cuantización habituales, la cuantización asigna un valor float continuo $x \in [\beta, \alpha]$ a una rejilla discreta.

• $x$ es el valor original de alta precisión.
• $x_q$ es el valor cuantizado.
• $s$ es la escala, o tamaño del paso.
• $z$ es el punto cero, la posición entera que representa 0.0.
• $[q_{\min}, q_{\max}]$ es el rango entero objetivo. Los valores con signo de 4 bits suelen usar $[-7, 7]$.

La cuantización simétrica centra la rejilla alrededor de cero y establece $z = 0$:

Esto resulta adecuado para el hardware porque las operaciones en tiempo de ejecución no necesitan restar un desplazamiento de punto cero. La pila de cuantización de PyTorch expone estas opciones afines de escala y punto cero como parámetros de cuantización primitivos en torchao.

La cuantización asimétrica desplaza la rejilla para cubrir rangos sesgados:

Esta rejilla desplazada puede conservar mejor las activaciones exclusivamente positivas, pero el desplazamiento añade operaciones salvo que el kernel lo gestione correctamente.

La granularidad de la escala es importante

El factor de escala puede abarcar todo un tensor de pesos, un canal o un grupo pequeño de valores. La documentación de la caché KV en FP8 de vLLM utiliza la misma distinción entre estrategias de escala por tensor y por cabeza de atención. Los grupos más pequeños suelen conservar mejor la calidad, pero requieren más metadatos de escala.

Los pesos son estáticos, por lo que sus escalas pueden calcularse offline antes de cargar el modelo. Las activaciones cambian con cada token, lo que hace que sus rangos dependan de la carga de trabajo.

La KV cache se sitúa entre ambos casos. Las keys y values comienzan como tensores de activación del runtime: cada capa los calcula a partir de los estados ocultos durante el forward pass. Una vez generados, dejan de ser intermediarios transitorios de las operaciones matmul y se convierten en estado persistente de serving que la atención lee para los tokens posteriores.

Un motor de serving puede almacenar ese estado con menor precisión y conservar los metadatos de escala junto a él. vLLM’s Quantized KV Cache, TensorRT-LLM’s FP8 KV Cache y Transformers QuantizedCache exponen esta opción de almacenamiento.

La precisión de almacenamiento de la cache sigue siendo independiente de la precisión de activación utilizada dentro de los kernels lineales. «KV-cache quantization» designa una optimización concreta de la cache, no todas las técnicas que reutilizan, asignan o mueven entradas de la cache.

PTQ y QAT se aplican en etapas diferentes

La quantization post-training, o PTQ, comprime un modelo entrenado una vez finalizado el entrenamiento. La quantization-aware training, o QAT, expone el modelo al ruido de cuantización durante el entrenamiento para que pueda adaptarse.

Los datos de calibración deben parecerse al tráfico que vas a servir. La ruta de calibración de la KV-cache de vLLM, por ejemplo, utiliza un dataset seleccionado mediante llm-compressor. Si los prompts de producción son trazas RAG largas, usar párrafos cortos de Wikipedia te dará cifras de benchmark impecables y un despliegue defectuoso. El modelo ajustará sus escalas de activación en torno a textos cortos y después encontrará patrones de activación distintos cuando lleguen prompts reales de contexto largo. Las evaluaciones de cuantización para contextos largos miden este riesgo directamente.

3. Los formatos numéricos determinan los requisitos de hardware

El formato numérico define qué valores puede representar el modelo en memoria. Para calcular de forma eficiente se necesitan kernels de ejecución y compatibilidad de hardware con el mismo ancho de bits y formato. TensorRT-LLM documenta tanto la lista de recetas como la matriz de compatibilidad de hardware.

BF16 y FP16 utilizan 16 bits, pero distribuyen la precisión de forma diferente y, por tanto, fallan de manera distinta. BF16 conserva el rango del exponente de 8 bits de FP32 y es más difícil que sufra overflow. FP16 tiene más bits de mantisa y un rango de exponentes más estrecho, por lo que los picos de activación requieren mayor cuidado. La evaluación de Kurtic et al. utiliza explícitamente BF16 como baseline al comparar los formatos de serving FP8, INT8 e INT4.

FP8 tiene dos variantes habituales. E4M3 ofrece más precisión y suele utilizarse para los pesos y las activaciones del forward pass. E5M2 proporciona un mayor rango dinámico y resulta más útil para gradientes o rutas de activación volátiles. vLLM expone ambos dtypes de caché KV FP8 E4M3 y E5M2. En el estudio de ACL 2025 de Kurtic et al., «Give Me BF16 or Give Me Death», FP8 W8A8 fue prácticamente lossless en la familia Llama-3.1 tras más de 500.000 evaluaciones. El resultado se limita a esa familia de modelos, esa suite de evaluación y esa configuración de serving. Cada despliegue necesita, aun así, su propio quality gate.

Blackwell añade formatos de microscaling como MXFP8 y NVFP4. En lugar de utilizar una única escala para todo un tensor o una fila, el microscaling emplea bloques muy pequeños. El explicador de NVFP4 de NVIDIA describe valores de coma flotante de 4 bits en bloques de 16, con factores de escala FP8 y una escala FP32 de nivel superior. Este enfoque busca ofrecer un footprint cercano a INT4, pero con comportamiento de coma flotante. Sin embargo, requiere una arquitectura de hardware, un compilador y soporte del runtime compatibles; por eso TensorRT-LLM enumera el soporte de FP4 y FP8 por generación de GPU.

4. Cuantización solo de pesos frente a cuantización de pesos y activaciones

La notación WxAy describe la precisión de los pesos y las activaciones, que ejercen distintos tipos de presión sobre la GPU durante la inferencia.

Durante el prefill, el modelo procesa el prompt de entrada. Esta fase suele estar limitada por el cómputo, porque la GPU ejecuta multiplicaciones de matrices grandes; por eso las recetas W8A8 FP8/INT8 son importantes en serving orientado al throughput.

Durante el decode, el modelo genera un token cada vez. Esta fase suele estar limitada por el ancho de banda de memoria, porque la GPU carga continuamente los pesos desde la VRAM para producir el token siguiente. Los trabajos de weight-only, como GPTQ y AWQ, abordan esa presión reduciendo los bytes de los pesos.

W4A16 comprime los pesos y mantiene las activaciones en BF16 o FP16. La GPU carga menos bytes de pesos y después los descuantiza a un formato de mayor precisión para realizar la multiplicación. Esto ayuda durante el decode y en escenarios con problemas de capacidad de memoria. El prefill limitado por el cómputo puede beneficiarse poco, porque las operaciones matriciales siguen ejecutándose en 16 bits.

W8A8 comprime los pesos y los tensores de activación utilizados por los kernels de matmul compatibles. Si el hardware dispone de tensor cores nativos de baja precisión, el motor de serving puede ejecutar las operaciones matriciales directamente en FP8 o INT8. Por tanto, FP8 puede mejorar el serving de alto throughput al reducir el tráfico de memoria y utilizar aritmética más rápida. La caché KV tiene su propia configuración de almacenamiento, así que hay que comprobar por separado el cache dtype o la implementación de caché del runtime.

Si el modelo apenas cabe en la VRAM, empieza con la cuantización solo de pesos para reducir la huella de memoria. Si el modelo cabe, pero tiene problemas de throughput con cargas de batch elevadas, evalúa FP8 o INT8 W8A8 para acelerar la fase de cómputo. Si los problemas de memoria solo aparecen durante conversaciones largas, estima primero el término de la caché KV. Prueba la cuantización de la caché KV cuando ese término sea el dominante. Activa la caché de prefijos cuando predominen los prefijos repetidos.

5. Algoritmos frente a kernels de runtime

Los algoritmos de cuantización (como GPTQ o AWQ) definen cómo se mapean los pesos del modelo a una precisión inferior. Los kernels de runtime (como Marlin o los kernels personalizados de vLLM) son el código de bajo nivel para GPU que ejecuta la multiplicación de matrices. Un modelo muy comprimido solo se ejecutará rápido si existe un kernel optimizado para su formato de cuantización específico.

El benchmark de vLLM de JarvisLabs sobre Qwen2.5-32B-Instruct con una NVIDIA H200 hace visible el efecto del kernel:

No traslades estas cifras directamente a tu propio stack. Proceden de un único modelo, una única clase de GPU y una configuración de software concreta. Muestran algo más específico: el nombre del algoritmo del checkpoint no indica a qué velocidad se ejecutará el serving.

Por ejemplo, AWQ y Marlin-AWQ utilizan los mismos pesos de 4 bits. La implementación de Marlin es mucho más rápida porque su kernel CUDA fusiona la dequantization y la multiplicación de matrices en una única operación de GPU altamente optimizada.

Haz benchmark del baseline y de las variantes comprimidas con la misma mezcla de prompts y la misma herramienta, como vllm bench serve:

vllm bench serve \
  --model ./outputs/Qwen2.5-32B-Instruct-AWQ-W4A16 \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --input-len 1024 \
  --output-len 256

Registra el throughput, el TTFT, la latencia entre tokens, el uso de memoria y la calidad de la tarea. Cuando algunos de estos indicadores evolucionen en direcciones opuestas, ese trade-off es precisamente lo que debes conocer antes de pasar a producción.

El menú de algoritmos

Usa esta tabla como mapa, no como clasificación:

El toolchain está evolucionando activamente. AutoGPTQ fue archivado en abril de 2025, y AutoAWQ fue archivado y declarado oficialmente obsoleto en mayo de 2025. Para nuevos checkpoints de compressed-tensors consumidos por vLLM, empieza con llm-compressor. Usa GPTQModel cuando necesites la ruta GPTQ activa con Marlin, Machete, opciones de memoria para MoE o descarga a disco.

La poda y la destilación también reducen el coste de serving mediante workflows independientes. La esparsidad estructurada 2:4 elimina pesos siguiendo un patrón que pueden utilizar los tensor cores dispersos de NVIDIA. La destilación entrena un modelo student más pequeño para imitar a uno más grande, lo que puede funcionar bien en tareas específicas. Incluye cualquiera de estas opciones en la lista corta solo cuando el proyecto pueda asumir el trabajo adicional de poda o entrenamiento.

6. La memoria de serving es algo más que los pesos

El checkpoint comprimido solo representa una parte de la huella de memoria del serving. Dimensiona todo el runtime antes de decidir si basta con cuantizar los pesos. PagedAttention identifica la KV cache como uno de los principales componentes de la memoria de serving.

La cuantización offline puede hacerse acotándola por capa. Herramientas como llm-compressor pueden cargar un bloque del transformer, ejecutar los cálculos de calibración y cuantización, escribir el bloque comprimido y continuar con el siguiente. Así, la memoria máxima de la GPU se mantiene más cerca del tamaño de la capa activa más grande, junto con los buffers de calibración. Aun así, necesitas RAM de la CPU y espacio en disco para el checkpoint de origen, pero la GPU no siempre tiene que contener el modelo BF16 completo.

La memoria máxima de la GPU durante la cuantización offline puede parecerse más a esto:

El serving es más exigente. Todo el checkpoint comprimido debe permanecer residente junto con la KV cache y los buffers del runtime. La KV cache crece con la longitud del contexto y el tamaño del batch activo:

Donde:

• $L$ es el número de capas.
• $H_{\text{kv}}$ es el número de cabezas de atención key-value. La atención grouped-query lo reduce al permitir que muchas cabezas de consulta compartan un número menor de cabezas KV.
• $D$ es la dimensión de cada cabeza, normalmente 128 o 256.
• $S_{\text{ctx}}$ es el número de tokens del prompt más el número de tokens generados.
• $B_{\text{batch}}$ es el batch activo del serving.
• $\text{BytesPerValue}$ es 2 para BF16 o FP16 y 1 para FP8 o INT8. El modo de KV cache FP8 de vLLM es el ejemplo de stack de serving que utiliza este artículo.

La cuantización de la KV cache cambia el almacenamiento, mientras que la reutilización cambia la asignación

La KV cache se puede cuantizar durante la inferencia. Cada paso de decode produce tensores de activaciones K y V para el token nuevo. Un modelo W8A8 puede usar ya FP8 o INT8 para los cálculos de proyección compatibles, pero la cache sigue siendo un objeto de almacenamiento independiente.

Muchos stacks de serving mantienen ese objeto en el dtype del modelo o de la cache. Para cambiarlo, activa un dtype de la KV cache, usa un checkpoint con escalas para la cache o elige una implementación de cache cuantizada.

Cuando se activa la cuantización de la KV cache, el motor escribe las entradas como una representación de menor precisión junto con sus escalas. Más adelante, la atención descuantiza la cache dentro de su kernel o, en algunos backends, ejecuta parte de la operación de atención en el dominio cuantizado.

La documentación estable de Quantized KV Cache de vLLM lo expone directamente mediante kv_cache_dtype="fp8" o --kv-cache-dtype fp8. vLLM admite los formatos de cache FP8 E4M3 y E5M2, además de estrategias de escalado por tensor y por cabeza de atención. Ofrece tres formas de obtener las escalas: valores predeterminados, estimación durante el warmup y calibración con un dataset mediante llm-compressor. Con FlashAttention 3, vLLM también puede ejecutar operaciones de atención en el dominio FP8 cuantizando las queries además de las keys y values.

TensorRT-LLM expone la caché KV en FP8 mediante KvCacheConfig(dtype='fp8') y enumera la caché KV en FP8 y la caché KV en NVFP4 como recetas de cuantización independientes de la cuantización de pesos/activaciones. Hugging Face Transformers también dispone de una ruta QuantizedCache mediante cache_implementation="quantized", donde hqq admite formatos de caché int2, int4 e int8, y quanto admite int2 e int4.

La caché KV convencional almacena las claves y los valores anteriores para evitar recalcularlos. La caché de prefijos reutiliza bloques de caché entre solicitudes que comparten el mismo prefijo. PagedAttention reduce la fragmentación y mejora la asignación, mientras que el offload de KV mueve bloques de caché entre distintos niveles de memoria. Estas combinaciones dependen del runtime. La QuantizedCache de Hugging Face no admite offloading. vLLM documenta su caché KV cuantizada por separado de la caché de prefijos y de otras funciones de gestión de caché. Verifica cada combinación en el runtime que vayas a desplegar.

El riesgo para la calidad también difiere del PTQ exclusivamente de pesos. La cuantización de la caché KV introduce errores en el estado de atención que se lee en cada paso de decodificación posterior. Prueba por separado la recuperación en contextos largos, el comportamiento en conversaciones de varios turnos, la seguridad y las respuestas de rechazo, el formato del uso de herramientas y la latencia de generación. KVQuant, KIVI y el estudio de vLLM sobre caché KV en FP8 evalúan la cuantización de la caché KV como un problema independiente.

El tamaño del modelo y la longitud del contexto, por sí solos, no determinan si comprimir la caché supera a otra ronda de compresión de pesos. Calcula los bytes de caché con la ecuación anterior usando el número de cabezas KV del modelo, la dimensión de cada cabeza, el batch activo y el tipo de datos de la caché. Después, compara ese resultado con los bytes ahorrados entre dos formatos de pesos concretos, como BF16 e INT4. Si la caché es mayor, probar la cuantización de la caché KV en FP8 puede liberar más memoria de serving que volver a reducir los pesos.

7. El hardware acota las opciones

La huella de memoria de los pesos es fácil de estimar a partir del número de parámetros y la precisión de almacenamiento, la misma idea de dimensionamiento que se utiliza en los análisis de memoria de serving relacionados con la caché KV:

Los modelos de mixture-of-experts pueden activar menos parámetros por token, pero el conjunto completo de pesos debe residir en algún sitio, salvo que el runtime admita offload. La matriz de compatibilidad de cuantización de TensorRT-LLM trata las familias de modelos MoE como objetivos de despliegue con sus propias recetas compatibles.

El hardware de despliegue restringe qué formatos de cuantización son viables:

• La inferencia en CPU depende de instrucciones vectoriales como AVX-512 o AMX. Cargar un archivo GGUF mediante llama.cpp es la opción práctica.
• Apple Silicon utiliza memoria unificada, por lo que los modelos locales pueden usar una gran cantidad de RAM compartida en lugar de VRAM dedicada. GGUF y llama.cpp siguen siendo la vía habitual para ejecutar modelos localmente porque GGUF está diseñado para ejecutores GGML.
• NVIDIA Ampere admite vías de inferencia con tensor cores INT8, pero no operaciones nativas FP8 W8A8 en tensor cores. Las opciones habituales son la cuantización weight-only W4A16 o INT8 estático, de acuerdo con la matriz de compatibilidad de hardware de TensorRT-LLM.
• NVIDIA Ada y Hopper admiten vías de inferencia FP8 en TensorRT-LLM. Merece la pena probar la inferencia FP8 W8A8 en estas GPU.
• NVIDIA Blackwell añade compatibilidad con NVFP4 y microscaling, pero la vía de software sigue siendo importante. Considera que los primeros stacks de coma flotante de baja precisión son sensibles a la versión.

8. Calibración y evaluación antes del despliegue

Un modelo que carga correctamente ha superado una prueba de humo. El despliegue requiere comprobaciones de calidad y de serving para la carga de trabajo objetivo. Las evaluaciones recientes de cuantización muestran resultados distintos para serving de LLM, tareas con contexto largo y modelos centrados en el razonamiento.

Para la calibración, utiliza prompts que se parezcan a los de producción:

• Incluye trazas de RAG, consultas SQL, historiales de agentes, tareas de código, payloads de llamadas a herramientas y system prompts de la carga de trabajo objetivo. Static PTQ depende de que los datos de calibración coincidan con la distribución de producción.
• Ajusta las longitudes de secuencia. Los prompts cortos de un solo turno no mostrarán el comportamiento de las activaciones en contextos largos.
• Mantén embed_tokens y lm_head con mayor precisión si el método o el runtime lo permite; es un patrón de exclusión habitual en las recetas de LLM Compressor.
• Utiliza suficientes muestras para estabilizar los rangos de activación. El ejemplo de caché KV de vLLM establece NUM_CALIB_SAMPLES = 512. Tómalo como un ejemplo documentado, no como una cantidad universal. El número adecuado de muestras depende del método, el modelo, la longitud de secuencia y la carga de trabajo de producción.
• Elimina secretos y datos privados de los usuarios antes de utilizar logs de producción.

Para la evaluación, comprueba tanto la calidad lingüística como el comportamiento del serving:

• La perplejidad en un corpus estándar detecta una degradación general del lenguaje, pero el benchmark de JarvisLabs recuerda que la perplejidad y el throughput pueden evolucionar de forma distinta.
• Las tareas de dominio detectan fallos que la perplejidad oculta. Usa HumanEval para programación, MMLU para conocimiento general y AIME o MATH-500 para razonamiento matemático cuando esos dominios sean relevantes.
• Las comprobaciones de formato son importantes para los sistemas agentic. Prueba el cumplimiento del esquema JSON, la salida en Markdown, la estructura de las llamadas a herramientas y el comportamiento de rechazo, porque las evaluaciones de modelos cuantizados pueden pasar por alto fallos a nivel de aplicación aunque la precisión agregada en los benchmarks se mantenga estable.
• Las pruebas de contexto largo detectan daños en la cuantización de la caché KV. Needle-in-a-haystack es una prueba rudimentaria, pero los resultados de cuantización con contexto largo muestran por qué estas comprobaciones deben formar parte del gate de despliegue.
• Las pruebas de carga deben informar del throughput, TTFT, la latencia entre tokens, la capacidad máxima de batch y la memoria máxima. vLLM expone estas mediciones mediante vllm bench serve.

Evalúa con rigor los modelos centrados en el razonamiento. La cuantización sub-4-bit o W4A4 sin rotación puede perjudicar la precisión del razonamiento aunque la perplejidad base parezca estable; esa es la advertencia principal del estudio sobre modelos de razonamiento cuantizados.

9. Flujo de trabajo del repositorio complementario

El repositorio complementario, slavadubrov/model-compression-demo, está pensado para que el proceso de decisión sea reproducible. Utiliza uv y se centra en la planificación, las recetas, las ejecuciones en seco y las configuraciones de benchmarks basadas en las mismas fuentes utilizadas aquí: vLLM, LLM Compressor, TensorRT-LLM y los artículos sobre los algoritmos.

El README público de la revisión 8b45003849e830bed2ff341a9f027b017d932c1f se comprobó el 2026-08-16. El checkout complementario no está presente en este workspace, por lo que no pude ejecutar aquí su CLI. Los comandos siguientes son ilustrativos hasta que los ejecutes desde ese checkout fijado, y el plan de benchmarks aún necesita el hardware de serving objetivo.

No copies la salida de la receta FP8 de esa revisión fijada. Su comando recipe --algorithm fp8-dynamic genera un modelo y una ruta de salida internamente incoherentes. El comando se omite aquí hasta que se repare el repositorio complementario.

Clónalo e inspecciona los algoritmos compatibles:

git clone https://github.com/slavadubrov/model-compression-demo.git
cd model-compression-demo
git checkout 8b45003849e830bed2ff341a9f027b017d932c1f
uv run python demo.py list-algorithms

Empieza por la planificación y el dimensionamiento:

uv run python demo.py plan \
  --model-preset qwen3-8b \
  --goal fit-memory \
  --hardware ampere \
  --context 4096 \
  --concurrency 4

uv run python demo.py estimate \
  --model-preset qwen3-8b \
  --scheme w4a16 \
  --context 4096 \
  --concurrency 4

uv run python demo.py plan \
  --model-preset qwen3-0.6b \
  --hardware cpu

A continuación, genera una receta y previsualiza la cuantización antes de consumir tiempo de GPU:

uv run python demo.py recipe --algorithm gptq-w4a16

uv run python demo.py quantize --dry-run
uv run python demo.py quantize \
  --algorithm gptq-w4a16 \
  --model Qwen/Qwen3-8B \
  --dry-run

Para la planificación del serving y de los benchmarks:

uv run python demo.py serve-command \
  --algorithm fp8-dynamic \
  --fp8-kv-cache \
  --enable-prefix-caching

uv run python demo.py benchmark-plan \
  --model Qwen/Qwen3-8B \
  --algorithms gptq-w4a16,rtn-w8a16,fp8-dynamic \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --input-len 1024 \
  --output-len 256 \
  --output-json reports/quantization-benchmark-plan.json

Por último, compara los modelos base y comprimido con umbrales explícitos:

uv run python demo.py quality-eval \
  --base-model Qwen/Qwen3-8B \
  --compressed-model outputs/Qwen3-8B-W4A16 \
  --mode all \
  --lm-eval-task hellaswag \
  --lm-eval-limit 50 \
  --max-perplexity-delta-pct 5 \
  --output-json reports/qwen3-8b-w4a16-quality.json

Ejecuta el trabajo en orden: planifica el objetivo, estima la memoria, ejecuta la receta en seco, haz el benchmark del serving y, después, compara la calidad con los umbrales. Esta secuencia refleja la separación que establece este artículo entre el dimensionamiento de memoria, el benchmarking del runtime y la evaluación de calidad.

10. Los modelos de difusión necesitan una ruta independiente

Las pipelines de difusión y de diffusion-transformers presentan un comportamiento de las activaciones distinto al de los LLM autoregresivos. SVDQuant trata la cuantización de difusión como un problema independiente de outliers en las activaciones.

Los LLM autoregresivos generan un token cada vez. Los modelos de difusión ejecutan pasos repetidos de eliminación de ruido, y las distribuciones de activaciones cambian durante el proceso. Una pasada de cuantización estándar de LLM a 4 bits puede reducir la memoria del modelo de difusión, pero introducir artefactos visuales graves. Métodos específicos para difusión, como SVDQuant / Nunchaku y NVIDIA ModelOpt diffusion quantization, abordan ese patrón de activaciones diferente.

Usa lo siguiente como heurísticas conservadoras, no como valores predeterminados universales. La pipeline, cada componente, el modelo y el runtime requieren pruebas independientes:

1. Mantén el VAE en 16 bits para la primera comparación. Esta heurística conservadora reduce una posible fuente de artefactos de imagen. Prueba precisiones inferiores solo cuando el método y la pipeline objetivo lo hayan validado.
2. Prueba primero el backbone DiT o U-Net, porque a menudo concentra la mayor parte de los parámetros. Es una heurística, así que verifica la memoria, la latencia y la calidad de imagen en la pipeline objetivo. Los métodos de cuantización para difusión siguen el mismo enfoque por componentes.
3. Trata los codificadores de texto por separado. Cuantizar T5-XXL o CLIP puede afectar a la alineación con el prompt o a la representación del texto en una pipeline concreta, así que evalúalos de forma independiente en lugar de asumir el comportamiento genérico de un transformer.
4. Usa métodos adaptados a difusión, como SVDQuant, cuando los outliers de las activaciones sean el problema principal.
5. Evalúa con imágenes, no con métricas de texto. Comprueba el seguimiento del prompt, la representación del texto, los tonos de piel, el equilibrio de color, el nivel de detalle, la latencia y la VRAM.

Si el conjunto de evaluación solo contiene prompts sencillos o habituales, pasarás por alto fallos en casos límite. Incluye casos difíciles: texto pequeño, manos, objetos repetidos, composiciones estructuradas y prompts con restricciones negativas, porque los fallos de la cuantización de difusión aparecen visualmente, no en la perplejidad del modelo de lenguaje.

11. Valores predeterminados para producción

Para el serving de LLM en entornos empresariales, empieza con una línea base en BF16 en el motor de serving exacto que tengas previsto utilizar. Si el objetivo es el throughput y el hardware lo admite, prueba FP8 W8A8. Si el modelo no cabe en memoria, prueba AWQ o GPTQ W4A16 con kernels de la clase de Marlin. Si el problema es el contexto largo o la concurrencia, prueba la cuantización FP8 de la KV cache. Si el problema son los prefijos repetidos, activa también el caching de prefijos. Publica la versión comprimida solo cuando supere tanto las pruebas de calidad como los benchmarks de serving.

Para la inferencia local y en el edge, empieza con un archivo GGUF usando Q4_K_M o Q5_K_M. Pasa a un GGUF Q8_0 cuando la memoria lo permita y la calidad sea más importante que el footprint. Bajar de 4 bits es un último recurso, no un valor predeterminado.

Para el fine-tuning, utiliza NF4 con QLoRA para entrenar adaptadores de forma económica. Evalúa el adaptador en la aplicación antes de fusionarlo. Después de la fusión, expórtalo al artefacto de serving que realmente necesites: un archivo GGUF compatible con llama.cpp, un checkpoint AWQ/GPTQ/compressed-tensors, un checkpoint de serving FP8 o BF16.

Para diffusion, empieza con esas heurísticas conservadoras y prueba visualmente cada combinación de pipeline, modelo y runtime. La perplexity del texto no te indicará si se ha roto un pipeline de imágenes, así que utiliza evidencias específicas de diffusion, como SVDQuant y la evaluación visual.

Referencias

• Benchmarks de vLLM de JarvisLabs: JarvisLabs, Guía completa y benchmarks de cuantización de vLLM, 2026. JarvisLabs.
• Guía de cuantización de Optimum de Hugging Face: Hugging Face, Guía conceptual de cuantización. Documentación.
• Documentación de cuantización de vLLM: proyecto vLLM, Cuantización. Documentación.
• Documentación de la KV cache cuantizada de vLLM: proyecto vLLM, KV cache cuantizada. Documentación.
• Documentación de benchmarks de vLLM: proyecto vLLM, vllm bench serve. Documentación.
• Documentación de LLM Compressor: proyecto vLLM, LLM Compressor. Documentación.
• GPTQModel: ModelCloud, GPTQModel. GitHub.
• Cuantización de TensorRT-LLM: NVIDIA, Cuantización de TensorRT-LLM. Documentación.
• NVIDIA NVFP4: NVIDIA, Introducing NVFP4 for Efficient and Accurate Low-Precision Inference. Blog.
• QuantizedCache de Hugging Face: Hugging Face, Estrategias de caché: caché cuantizada. Documentación.
• NVIDIA Model Optimizer: NVIDIA, Model Optimizer. GitHub.
• Cuantización de torchao: PyTorch, torchao quantization overview. Documentación.
• Cuantización de bitsandbytes: Hugging Face, bitsandbytes. Documentación.
• HQQ: Dropbox, Half-Quadratic Quantization. GitHub.
• PEFT: Hugging Face, Parameter-Efficient Fine-Tuning. Documentación.
• Ollama: runtime local de modelos de Ollama. Sitio web.
• LM Studio: runtime local de IA de LM Studio. Sitio web.
• Estado de AutoGPTQ: repositorio de AutoGPTQ, archivado en abril de 2025. GitHub.
• Estado de AutoAWQ: repositorio de AutoAWQ, archivado y obsoleto desde mayo de 2025. GitHub.
• GPTQ: Frantar et al., GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers, NeurIPS 2023. arXiv:2210.17323.
• Marlin: Frantar et al., MARLIN: Mixed-Precision Auto-Regressive Parallel Inference on Large Language Models, arXiv:2408.11743. arXiv:2408.11743.
• AWQ: Lin et al., AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration, MLSys 2024. arXiv:2306.00978.
• SmoothQuant: Xiao et al., SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models, ICML 2023. arXiv:2211.10438.
• QuaRot: Ashkboos et al., QuaRot: Outlier-Free 4-Bit Inference in Rotated LLMs, NeurIPS 2024. arXiv:2404.00456.
• SpinQuant: Meta AI Research, SpinQuant: LLM Quantization with Learned Rotations, arXiv:2405.16406. arXiv:2405.16406.
• QLoRA / NF4: Dettmers et al., QLoRA: Efficient Finetuning of Quantized LLMs, NeurIPS 2023. arXiv:2305.14314.
• SVDQuant / Nunchaku: MIT HAN Lab, SVDQuant: Absorbing Outliers by Low-Rank Components for 4-Bit Diffusion Models, ICLR 2025. arXiv:2411.05007, Nunchaku.
• vLLM PagedAttention: Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP 2023. arXiv:2309.06180.
• Grouped-Query Attention: Ainslie et al., GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints, EMNLP 2023. arXiv:2305.13245.
• Caché KV FP8 de vLLM: Kubler, Kurtic, Wilkinson et al., The State of FP8 KV-Cache and Attention Quantization in vLLM, vLLM Blog, abril de 2026. vLLM Blog.
• KIVI: Liu et al., KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache, ICML 2024. arXiv:2402.02750.
• KVQuant: Hooper et al., KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, NeurIPS 2024. arXiv:2401.18079.
• Evaluación del serving de LLM: Kurtic et al., “Give Me BF16 or Give Me Death”? Accuracy-Performance Trade-Offs in LLM Quantization, ACL 2025. arXiv:2411.02355.
• Evaluación de la cuantización en contextos largos: Mekala et al., Does quantization affect models’ performance on long-context tasks?, arXiv:2505.20276. arXiv:2505.20276.
• Evaluación del razonamiento: Quantization Hurts Reasoning? An Empirical Study on Quantized Reasoning Models, arXiv:2504.04823. arXiv:2504.04823.
• SlideSparse: SlideSparse: Fast and Flexible (2N-2):2N Structured Sparsity, arXiv:2603.05232v1. arXiv:2603.05232v1.
• HumanEval: OpenAI, HumanEval. GitHub.
• MMLU: Hendrycks et al., Measuring Massive Multitask Language Understanding. arXiv:2009.03300.
• MATH-500: Hugging Face H4, MATH-500. Dataset.
• GGUF y llama.cpp: ggml-org, GGUF file format y llama.cpp. GGUF, llama.cpp.
• Documentación de GGUF de Hugging Face: Hugging Face, GGUF. Docs.
• Repositorio de referencia: slavadubrov/model-compression-demo.