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

Viacheslav Dubrov

2026-07-05 · Actualizado 2026-07-22 · 29 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 de un modelo. Una ruta de serving puede cuantizar los pesos, las activaciones, el KV cache o una combinación de estos, y cada objetivo resuelve un problema de serving diferente.

Elige el objetivo a partir del cuello de botella actual: memoria de los pesos, cómputo de activaciones, tamaño del KV cache, 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 GPUs no compatibles. La matriz de hardware de TensorRT-LLM muestra las rutas compatibles. Para contextos largos o una concurrencia alta, la cuantización del KV cache puede ahorrar más memoria que la cuantización de pesos.

Los ingenieros de ML y de plataformas pueden utilizar el cuello de botella para seleccionar un formato y un runtime candidatos, y después validar esa ruta de serving exacta antes del despliegue.

Para consultar el artefacto breve y la comparación de métodos, véase Formatos de cuantización de LLM.

1. Empieza por el cuello de botella

Averigua qué limita la carga de trabajo antes de elegir el número de bits. La respuesta puede ser la memoria de los pesos del modelo, el cómputo de prefill, el ancho de banda de decode o el KV cache, y no necesariamente la precisión numérica por sí sola.

Cuellos de botella habituales y puntos de partida:

Utiliza esta tabla como mapa. Las secciones siguientes explican por qué esos puntos de partida son diferentes.

Notación utilizada en las recetas de serving

• W{x}A{y} indica la precisión para el cálculo de pesos y activaciones compatibles, 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 transformar un modelo entrenado a un formato de menor precisión.
• GGUF es un formato de archivo que almacena tensores y metadatos para runtimes de estilo GGML y llama.cpp. Un archivo GGUF puede contener tipos de tensor no cuantizados, 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 elección de cuantización. GGUF por sí solo 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.
• Cuantización del KV cache almacena los tensores de activación key/value en un formato de caché de menor precisión, como FP8, INT8, INT4 o INT2, según el soporte del runtime. Esto es diferente del prefix caching, PagedAttention o el offload, que determinan respectivamente 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 realizar multiplicaciones de matrices.

2. La cuantización es redondeo controlado

La cuantización asigna valores de alta precisión a un conjunto más pequeño de valores representables, que es la definición fundamental utilizada tanto por la guía conceptual de cuantización de Hugging Face Optimum como por TensorRT-LLM. Ahorras memoria y ancho de banda, pero 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 reasoning, el seguimiento de instrucciones o la fidelidad visual.

Asignación simétrica y asimétrica

Siguiendo la asignación afín utilizada 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 de paso.
• $z$ es el zero point, la posición entera que representa 0.0.
• $[q_{\min}, q_{\max}]$ es el rango entero objetivo. Los valores signed de 4 bits suelen utilizar $[-7, 7]$.

La cuantización simétrica centra la rejilla en torno a cero y establece $z = 0$:

Esto resulta favorable para el hardware porque el cálculo del runtime no necesita restar un offset de zero point. La pila de cuantización de PyTorch expone estas opciones afines de escala y zero point como parámetros primitivos de cuantización en torchao.

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

Esta rejilla desplazada puede preservar mejor las activaciones exclusivamente positivas, pero el offset añade trabajo salvo que el kernel lo gestione correctamente.

La granularidad de la escala es importante

El factor de escala puede cubrir un tensor de pesos completo, un canal o un grupo pequeño de valores. La documentación del KV cache FP8 de vLLM utiliza la misma distinción entre estrategias de escala per-tensor y per-attention-head. Los grupos más pequeños suelen preservar mejor la calidad, pero requieren más metadatos de escala.

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

El KV cache se encuentra entre ambos casos. Keys y values comienzan como tensores de activación del runtime: cada capa los calcula a partir de los hidden states durante el forward pass. Una vez generados, dejan de ser intermedios transitorios de 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 mantener los metadatos de escala junto a él. La Quantized KV Cache de vLLM, la FP8 KV Cache de TensorRT-LLM y Transformers QuantizedCache exponen esta opción de almacenamiento.

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

PTQ y QAT tienen lugar en etapas diferentes

La cuantización post-entrenamiento, o PTQ, comprime un modelo entrenado a posteriori. El 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 del KV cache de vLLM, por ejemplo, utiliza un dataset seleccionado mediante llm-compressor. Si los prompts de producción son trazas RAG largas, unos párrafos breves de Wikipedia producirán cifras de benchmark impecables y un despliegue roto. La calibración selecciona escalas y rangos estáticos de activaciones o de la caché a partir de esa distribución de textos breves; no ajusta los parámetros fijos del modelo. Los prompts reales de contexto largo pueden producir patrones de activación diferentes. Las evaluaciones de cuantización en contextos largos miden directamente este riesgo.

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

El formato numérico define qué valores puede representar el modelo en memoria. Para un cálculo eficiente, el runtime y el hardware deben ofrecer kernels y soporte para el mismo número de bits y formato. TensorRT-LLM documenta tanto la lista de recetas como la matriz de compatibilidad de hardware.

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

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

Blackwell añade formatos de microscaling como MXFP8 y NVFP4. En lugar de utilizar una escala para todo un tensor o una fila, el microscaling utiliza 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. El objetivo es ofrecer una huella cercana a INT4 con comportamiento de coma flotante. Sin embargo, requiere una arquitectura de hardware, un compilador y un runtime compatibles, por lo que TensorRT-LLM enumera el soporte de FP4 y FP8 por generación de GPU.

4. Cuantización weight-only frente a cuantización de pesos y activaciones

La notación WxAy describe la precisión de los pesos y las activaciones, que ejercen presiones diferentes 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 realiza grandes multiplicaciones de matrices; por eso son importantes las recetas W8A8 FP8/INT8 para un 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 siguiente token. Los trabajos weight-only como GPTQ y AWQ se dirigen a 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 vuelve a descomprimirlos a un formato de mayor precisión para realizar la multiplicación. Esto ayuda con el decode y con los problemas de ajuste a memoria. El prefill limitado por cómputo puede obtener pocos beneficios, porque las operaciones matriciales siguen ejecutándose en 16 bits.

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

Si el modelo cabe justo en la VRAM, empieza con cuantización weight-only para reducir la huella de memoria. Si el modelo cabe, pero tiene problemas de throughput con batches grandes, evalúa FP8 o INT8 W8A8 para acelerar la fase de cómputo. Si los problemas de memoria solo aparecen durante conversaciones largas, calcula primero el término del KV cache. Prueba la cuantización del KV cache cuando ese término sea dominante. Activa el prefix caching cuando predominen los prefijos repetidos.

5. Algoritmos frente a kernels del runtime

Los algoritmos de cuantización, como GPTQ o AWQ, definen cómo se asignan los pesos del modelo a una precisión menor. Los kernels del runtime, como Marlin o los kernels personalizados de vLLM, son el código GPU de bajo nivel 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 copies estas cifras directamente en tu stack. Proceden de un solo modelo, una sola clase de GPU y una única configuración de software. Muestran un punto más concreto: 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 descuantización y la multiplicación de matrices en una sola 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. Inicia cada variante como servidor y asígnale un nombre de modelo estable en la API; vllm bench serve envía peticiones a esa API en lugar de cargar el checkpoint por sí mismo:

vllm serve ./outputs/Qwen2.5-32B-Instruct-AWQ-W4A16 \
  --served-model-name qwen2.5-32b-awq \
  --host 127.0.0.1 \
  --port 8000

vllm bench serve \
  --backend openai \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/completions \
  --model qwen2.5-32b-awq \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --input-len 1024 \
  --output-len 256

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

El catálogo de algoritmos

Utiliza esta tabla como mapa, no como ranking:

La toolchain evoluciona activamente. AutoGPTQ fue archivado en abril de 2025, y AutoAWQ fue archivado y oficialmente deprecated en mayo de 2025. Para nuevos checkpoints compressed-tensors consumidos por vLLM, empieza con llm-compressor. Utiliza GPTQModel cuando necesites la ruta GPTQ activa con Marlin, Machete, opciones de memoria para MoE u offload a disco.

La poda y la destilación también reducen el coste de serving mediante flujos de trabajo independientes. La esparsidad estructurada 2:4 elimina pesos siguiendo un patrón que pueden utilizar los sparse tensor cores de NVIDIA. La destilación entrena un modelo student más pequeño para imitar a otro mayor, lo que puede funcionar bien en tareas específicas. Incluye cualquiera de estas rutas 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 el runtime completo antes de decidir si basta con cuantizar los pesos. PagedAttention identifica el KV cache como un término importante de la memoria de serving.

La cuantización offline puede estar limitada por capas. Herramientas como llm-compressor pueden cargar un bloque del transformer, ejecutar la calibración y las operaciones matemáticas de cuantización, escribir el bloque comprimido y continuar con el siguiente. Esto mantiene la memoria GPU máxima más cerca de la capa activa más grande y los buffers de calibración. Aun necesitas RAM de la CPU y disco para el checkpoint de origen, pero la GPU no siempre tiene que contener el modelo BF16 completo.

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

El serving es más estricto. El checkpoint comprimido completo debe permanecer residente junto con el KV cache y los buffers del runtime. El 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 heads de atención key-value. La Grouped-query attention lo reduce al permitir que muchos heads de query compartan menos heads KV.
• $D$ es la dimensión de cada head, normalmente 128 o 256.
• $S_{\text{ctx}}$ son los tokens del prompt más los tokens generados.
• $B_{\text{batch}}$ es el batch activo de serving.
• $\text{BytesPerValue}$ es 2 para BF16 o FP16 y 1 para FP8 o INT8. El modo FP8 KV cache de vLLM es el ejemplo de stack de serving que utiliza este artículo.

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

El KV cache se puede cuantizar durante la inferencia. Cada paso de decode produce tensores de activación K y V para el token nuevo. Un modelo W8A8 puede utilizar ya FP8 o INT8 para las operaciones de proyección compatibles, pero la caché sigue siendo un objeto de almacenamiento independiente.

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

Cuando se activa la cuantización del KV cache, el motor escribe las entradas como una representación de menor precisión acompañada de escalas. En los pasos posteriores, la atención descomprime la caché 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 expone esta opción directamente mediante kv_cache_dtype="fp8" o --kv-cache-dtype fp8. vLLM admite formatos de caché FP8 E4M3 y E5M2, además de estrategias de escala per-tensor y per-attention-head. Puede utilizar escalas predeterminadas o calibración basada en datasets mediante llm-compressor. Con FlashAttention 3, vLLM también puede ejecutar las operaciones de atención en el dominio FP8 cuantizando las queries además de las keys y values.

TensorRT-LLM expone la caché KV FP8 mediante KvCacheConfig(dtype='fp8') y enumera la caché KV FP8 y la caché KV 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"; hqq admite formatos de caché int2, int4 e int8, y quanto admite int2 e int4.

La caché KV convencional almacena keys y values anteriores para evitar recalcularlos. El prefix caching reutiliza bloques de caché entre peticiones con el mismo prefijo. PagedAttention reduce la fragmentación y mejora la asignación, mientras que el offload del KV mueve bloques de caché entre niveles de memoria. Estas combinaciones dependen del runtime. La QuantizedCache de Hugging Face no admite offloading. vLLM documenta su KV cache cuantizado por separado del prefix caching y de otras funciones de gestión de caché. Verifica cada combinación en el runtime que vayas a desplegar.

El riesgo de calidad también difiere del PTQ weight-only. La cuantización del KV cache inyecta error en el estado de atención que se lee en cada paso posterior de decode. Prueba por separado la recuperación en contextos largos, el comportamiento multi-turn, la seguridad y las negativas, el formato del tool use y la latencia de salida. KVQuant, KIVI y el estudio de la caché KV FP8 de vLLM evalúan la cuantización del KV cache 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 la caché con la ecuación anterior utilizando el número de heads KV del modelo, la dimensión de los heads, el batch activo y el dtype 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 del KV cache FP8 puede liberar más memoria de serving que volver a reducir el tamaño de los pesos.

7. El hardware reduce el catálogo de opciones

La huella de pesos es fácil de estimar a partir del número de parámetros y la precisión de almacenamiento, siguiendo la misma idea de dimensionado utilizada en los análisis de memoria de serving en torno al KV cache:

Los modelos mixture-of-experts pueden activar menos parámetros por token, pero el conjunto completo de pesos sigue teniendo que residir en algún lugar 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:

• El serving en CPU depende de instrucciones vectoriales como AVX-512 o AMX. Un archivo GGUF cargado mediante llama.cpp es la ruta práctica.
• Apple Silicon utiliza memoria unificada, por lo que los modelos locales pueden usar un gran pool compartido de RAM en lugar de VRAM dedicada. GGUF y llama.cpp siguen siendo la ruta habitual de los runtimes locales porque GGUF está diseñado para ejecutores GGML.
• NVIDIA Ampere admite rutas de serving con tensor cores INT8, pero no operaciones matriciales tensor-core nativas FP8 W8A8. 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 rutas de serving FP8 en TensorRT-LLM. Merece la pena probar el serving FP8 W8A8 en estas GPUs.
• NVIDIA Blackwell añade soporte para NVFP4 y microscaling, pero la ruta de software sigue siendo importante. Trata las primeras stacks de coma flotante de pocos bits como dependientes de la versión.

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

Un modelo que carga ha superado un smoke test. El despliegue requiere comprobaciones de calidad y serving para la carga de trabajo objetivo. Las evaluaciones recientes de cuantización informan de resultados diferentes para el serving de LLM, las tareas de contexto largo y los modelos centrados en reasoning.

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

• Incluye trazas RAG, consultas SQL, historiales de agentes, tareas de código, payloads de tool calls y system prompts de la carga de trabajo objetivo. La PTQ estática depende de que los datos de calibración coincidan con la distribución de producción.
• Igualar las longitudes de secuencia. Los prompts cortos de un solo turno no revelará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 runtime lo permite, un patrón habitual de exclusión en las recetas de LLM Compressor.
• Utiliza suficientes muestras para estabilizar los rangos de activación. El ejemplo de KV cache 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 usuarios antes de utilizar logs de producción.

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

• La perplexity sobre un corpus estándar detecta degradación lingüística general, pero el benchmark de JarvisLabs recuerda que la perplexity y el throughput pueden evolucionar de forma diferente.
• Las tareas de dominio detectan fallos que la perplexity oculta. Utiliza HumanEval para coding, MMLU para conocimiento general y AIME o MATH-500 para reasoning matemático cuando esos dominios sean relevantes.
• Las comprobaciones de formato son importantes en sistemas agentic. Prueba el cumplimiento del JSON Schema, la salida Markdown, la forma de los tool calls y el comportamiento de rechazo, porque las evaluaciones de modelos cuantizados pueden pasar por alto fallos a nivel de aplicación incluso cuando la precisión agregada del benchmark permanece estable.
• Las pruebas de contexto largo detectan daños causados por la cuantización del KV cache. Needle-in-a-haystack es una prueba rudimentaria, pero los resultados de cuantización en contextos largos muestran por qué estas comprobaciones deben formar parte del quality gate de despliegue.
• Las pruebas de carga deben informar de throughput, TTFT, latencia entre tokens, capacidad máxima de batch y memoria máxima. vLLM expone estas mediciones mediante vllm bench serve.

Evalúa rigurosamente los modelos centrados en reasoning. La cuantización sub-4-bit o W4A4 sin rotaciones puede perjudicar la precisión del reasoning aunque la perplexity del baseline parezca estable, que es la advertencia principal del estudio sobre modelos de reasoning cuantizados.

9. Flujo de trabajo del repositorio complementario

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

El README público en la revisión 8b45003849e830bed2ff341a9f027b017d932c1f se comprobó el 16-08-2026. El checkout complementario no está presente en este workspace, por lo que no pude ejecutar su CLI aquí. Los comandos siguientes son ilustrativos hasta que los ejecutes desde ese checkout fijado, y el plan de benchmark todavía 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 sigue omitido aquí hasta que se repare el complemento.

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 con la planificación y el dimensionado:

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

Después genera una receta y previsualiza la cuantización antes de invertir 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, haz un dry run de la receta, realiza el benchmark del serving y compara después la calidad con los umbrales. Esta secuencia refleja la separación que establece el artículo entre el dimensionado de memoria, el benchmark del runtime y la evaluación de calidad.

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

Las pipelines de difusión y los diffusion transformers tienen un comportamiento de activación diferente al de los LLM autoregresivos. SVDQuant trata la cuantización de difusión como un problema independiente de outliers de activación.

Los LLM autoregresivos generan un token cada vez. Los modelos de difusión ejecutan pasos repetidos de denoising y sus distribuciones de activación cambian durante el proceso. Una pasada estándar de cuantización de LLM a 4 bits puede ahorrar memoria en un modelo de difusión y, al mismo tiempo, introducir artefactos visuales graves. Los métodos específicos para difusión, como SVDQuant / Nunchaku y la cuantización de difusión de NVIDIA ModelOpt, abordan ese patrón de activación diferente.

Utiliza lo siguiente como heurísticas conservadoras, no como valores predeterminados universales. La pipeline, el 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 fuente de artefactos de imagen. Prueba una precisión menor solo cuando el método y la pipeline objetivo la hayan validado.
2. Prueba primero el backbone DiT o U-Net, porque suele contener la mayor parte de los parámetros. Es una heurística, así que verifica la memoria, la latencia y la calidad de imagen para la pipeline objetivo. Los métodos de cuantización de difusión siguen el mismo enfoque por componentes.
3. Trata los text encoders por separado. Cuantizar T5-XXL o CLIP puede afectar a la alineación con el prompt o al renderizado de texto en una pipeline concreta, por lo que debes evaluarlos de forma independiente en lugar de asumir el comportamiento genérico de un transformer.
4. Utiliza métodos adaptados a difusión, como SVDQuant, cuando los outliers de activación sean el problema principal.
5. Evalúa con imágenes, no con métricas de texto. Comprueba la adherencia al prompt, el renderizado de texto, los tonos de piel, el equilibrio de color, el detalle fino, la latencia y la VRAM.

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

11. Valores predeterminados para producción

Para el serving empresarial de LLM, empieza con un baseline 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, prueba AWQ o GPTQ W4A16 con kernels de la clase Marlin. Si el problema es el contexto largo o la concurrencia, prueba la cuantización del KV cache FP8. Si el problema son los prefijos repetidos, activa también el prefix caching. Publica la versión comprimida solo cuando supere tanto los benchmarks de calidad como los de serving.

Para la inferencia local y edge, empieza con un archivo GGUF utilizando 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 la huella. Bajar de 4 bits debe ser el último recurso, no el valor predeterminado.

Para el fine-tuning, utiliza NF4 con QLoRA para entrenar adapters de forma económica. Evalúa el adapter en la aplicación antes de fusionarlo. Después de fusionarlo, exporta 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 difusión, empieza con esas heurísticas conservadoras y prueba visualmente cada combinación de pipeline, modelo y runtime. La perplexity de texto no te indicará si una pipeline de imágenes se ha roto, así que utiliza evidencias específicas de difusión, como SVDQuant, y evaluación visual.

Referencias

• Benchmarks de vLLM de JarvisLabs: JarvisLabs, vLLM Quantization Complete Guide and Benchmarks, 2026. JarvisLabs.
• Guía de cuantización de Hugging Face Optimum: Hugging Face, Quantization conceptual guide. Documentación.
• Documentación de cuantización de vLLM: proyecto vLLM, Quantization. Documentación.
• Documentación de Quantized KV Cache de vLLM: proyecto vLLM, Quantized KV Cache. 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, TensorRT-LLM Quantization. Documentación.
• NVIDIA NVFP4: NVIDIA, Introducing NVFP4 for Efficient and Accurate Low-Precision Inference. Blog.
• QuantizedCache de Hugging Face: Hugging Face, Cache strategies: Quantized cache. 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 de modelos locales de Ollama. Sitio web.
• LM Studio: runtime local de AI 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 deprecated en 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.
• PagedAttention de vLLM: 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.
• KV Cache FP8 de vLLM: Kubler, Kurtic, Wilkinson et al., The State of FP8 KV-Cache and Attention Quantization in vLLM, blog de vLLM, abril de 2026. Blog de vLLM.
• 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 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 de reasoning: 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. Documentación.
• Repositorio de referencia: slavadubrov/model-compression-demo.