LLM Cuantización: BF16 vs FP8 vs INT4

Ekrem Sarı

con

Sıla Ermut

actualizado el 17 de mar. de 2026

Vea nuestra normas éticas

Citar Esta Investigación

Hemos realizado un benchmark de Qwen3-32B en 4 niveles de precisión (BF16, FP8, GPTQ-Int8, GPTQ-Int4) en una sola NVIDIA H100 80GB GPU. Cada configuración fue evaluada en 2 benchmarks (~12.2K preguntas) que cubren conocimiento y generación de código, además de 2,000+ ejecuciones de inferencia para medir el rendimiento. Int4 es 2.7x más rápido que BF16 mientras pierde menos de 2 puntos en MMLU-Pro, pero la generación de código (HumanEval) cae 8 puntos.

Resultados del benchmark de cuantización

Loading Chart

MMLU-Pro prueba el razonamiento amplio en 14 dominios (~12K preguntas, 5-shot). Esta es la versión más difícil de MMLU con preguntas de 10 opciones en lugar de 4.

HumanEval prueba la generación de código (164 problemas, pass@1). El modelo escribe funciones de Python que se ejecutan contra pruebas unitarias. Este es el único benchmark donde la salida se ejecuta, no solo se puntúa.

Rendimiento es tokens de salida por segundo con tamaño de lote 1.

Tamaño del modelo es la memoria de GPU consumida solo por los pesos, medida después de la carga.

Desglose de MMLU-Pro por categoría

Categoría	BF16	FP8	GPTQ-Int8	GPTQ-Int4
Biología	86.19%	86.47%	86.61%	86.05%
Negocios	75.67%	76.43%	77.44%	77.19%
Química	74.12%	73.41%	73.94%	72.08%
Ciencias de la Computación	74.15%	75.37%	74.39%	73.90%
Economía	81.75%	81.75%	81.40%	80.69%
Ingeniería	49.64%	45.41%	47.06%	43.45%
Salud	73.59%	72.49%	73.72%	71.52%
Historia	62.20%	61.15%	60.63%	62.47%
Derecho	43.05%	41.69%	43.78%	40.60%
Matemáticas	81.87%	81.87%	81.87%	80.24%

Ingeniería y derecho muestran las mayores caídas en Int4. Las matemáticas se mantienen estables en todas las precisiones.

Capacidad de memoria y concurrencia

Las herramientas de monitoreo de GPU como nvidia-smi reportan utilización casi completa independientemente del tamaño del modelo porque vLLM pre-asigna toda la memoria disponible. La verdadera pregunta es cómo se divide esa memoria entre los pesos del modelo y la caché KV, porque la caché KV determina cuántos usuarios puedes atender concurrentemente.

El máximo de usuarios es el límite limitado por memoria antes de OOM: capacidad total de tokens dividida por la longitud de contexto por usuario. Este es el máximo teórico. En la práctica, la sobrecarga de programación lo reduce ligeramente.

Esto tiene implicaciones directas para los modelos de razonamiento. DeepSeek-R1 y Qwen-QwQ generan miles de tokens internos de "pensamiento" (a menudo 2K-5K) antes de producir una respuesta final. En BF16, una sola solicitud de razonamiento podría consumir toda la capacidad de 17K tokens, bloqueando a un segundo usuario. En Int4, la capacidad de 193K cabe múltiples sesiones de razonamiento concurrentes.

Hallazgos clave

FP8 no pierde precisión medible

FP8 obtiene 69.64% en MMLU-Pro vs 70.24% para BF16, una diferencia de 0.6 puntos en 12,000 preguntas. En HumanEval, tanto FP8 como BF16 puntúan idénticamente en 39.02%. FP8 te da 1.5x de rendimiento y reduce a la mitad el tamaño de tu modelo por un costo de 0.6 puntos.

GPTQ-Int8 obtiene 70.32% en MMLU-Pro pero cae 1.8 puntos en HumanEval (37.20%). Si la generación de código importa, FP8 es la opción más segura.

Int4 degrada más la generación de código que el conocimiento

MMLU-Pro cae 1.6 puntos en Int4 (70.24% a 68.66%). HumanEval cae 8 puntos (39.02% a 31.10%). La generación de código requiere predicciones precisas de tokens donde pequeños errores de peso se acumulan a través de los cuerpos de las funciones.

La verdadera ganancia es la concurrencia, no la velocidad

Int4 es 2.7x más rápido que BF16. Pero el efecto mayor está en la memoria. BF16 deja solo 4.4 GB para la caché KV, suficiente para unos 4 usuarios concurrentes con contexto de 4K. Int4 libera 47.3 GB, suficiente para 47 usuarios, un aumento de 12x en la capacidad de servicio desde la misma GPU.

Las puntuaciones de matemáticas se mantienen en todas las precisiones

Las puntuaciones de matemáticas apenas se mueven: 81.87% en BF16, 81.87% en FP8, 81.87% en Int8, 80.24% en Int4. Ingeniería (49.64% a 43.45%) y derecho (43.05% a 40.60%) son más sensibles.

Costo por token

Usando precios de H100 SXM en RunPod ($2.69/hora) con tamaño de lote 1:

Estos números reflejan generación en tiempo real para un solo usuario. El procesamiento por lotes reduce aún más el costo.

Descubre más de nuestros análisis comparativos e insights basados en datos en la Búsqueda de Google.

Añadir como fuente preferida

LLM metodología del benchmark de cuantización

Entorno

GPU: NVIDIA H100 80GB HBM3 (SXM) única vía RunPod ($2.69/hr)
Software: vLLM 0.17.0, lm-evaluation-harness 0.4.11, PyTorch 2.8.0, CUDA 12.8, Python 3.11
Modelo: Qwen3-32B (post-entrenado/ajustado para instrucciones) de HuggingFace. No se aplicó fine-tuning.

Evaluación de precisión

Benchmark	Preguntas	Tipo	Few-shot	Métrica
MMLU-Pro (completo, 14 categorías)	~12K	generate_until	5-shot	exact_match
HumanEval	164	generate_until	0-shot	pass@1

Todas las evaluaciones se ejecutan vía lm-evaluation-harness con batch_size="auto".
Cada tarea se ejecuta en un subproceso separado. El modelo se carga fresco cada vez, GPU completamente limpiada entre tareas. Esto previene OOM por fragmentación de memoria.
HumanEval se ejecuta con HF_ALLOW_CODE_EVAL=1 (ejecución de código habilitada).
Los resultados de MMLU-Pro incluyen desglose por categoría (biología, matemáticas, física, derecho, etc.).
El modo de pensamiento de Qwen3 no estaba activo durante las evaluaciones. lm-evaluation-harness envía prompts formateados crudos sin aplicar la plantilla de chat del modelo (apply_chat_template=False por defecto), por lo que el token <think> nunca se inyecta.

Evaluación de rendimiento

5 prompts rotativos en dominios (ciencia, codificación, conocimiento general)
10 iteraciones de calentamiento (no medidas), luego 500 iteraciones medidas
Salida fija: max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1
Métricas: rendimiento (tokens/seg), uso de memoria de GPU (GB)

Configuración de vLLM por precisión

Precisión	ID de HuggingFace	Configuración de vLLM
BF16	`Qwen/Qwen3-32B`	`dtype="bfloat16"`
FP8	`Qwen/Qwen3-32B-FP8`	`dtype="bfloat16"`
GPTQ-Int8	`JunHowie/Qwen3-32B-GPTQ-Int8`	`dtype="float16", quantization="gptq_marlin"`
GPTQ-Int4	`JunHowie/Qwen3-32B-GPTQ-Int4`	`dtype="float16", quantization="gptq_marlin"`

Todas las precisiones usan gpu_memory_utilization=0.90, max_model_len=4096.

Arquitectura de proceso dividido

Cada benchmark se ejecuta como dos procesos separados para prevenir OOM:

Paso 1: Cargar modelo, calentamiento, benchmark de rendimiento, guardar en archivo temporal, salir.
Limpieza: Forzar cierre de procesos vLLM y Ray, esperar 10 segundos.
Paso 2: Cargar modelo fresco, ejecutar cada tarea de evaluación en un subproceso separado, fusionar con métricas del paso 1, guardar JSON final.

Variables controladas

Para eliminar factores externos, los siguientes parámetros se fijaron en todas las ejecuciones:

Parámetro	Valor	Justificación
Tamaño de lote	1	Simula latencia de usuario único. Los tamaños de lote más grandes magnifican la ventaja de ancho de banda de los modelos cuantizados, pero el tamaño de lote 1 es el peor caso para la utilización de cómputo.
Longitud de salida	256 tokens	Límite de generación fijo para asegurar que el rendimiento se mida sobre una carga de trabajo consistente.
Temperatura	0.7	Parámetro de muestreo estándar.
Top-p	0.9	Umbral de muestreo de núcleo estándar.
Utilización de memoria de GPU	0.90	Ajustado empíricamente. Valores más altos (0.95, 0.98) causaron OOM durante el calentamiento de gráficos CUDA o evaluación por lotes grandes.
Protocolo de limpieza	Estricto	Entre cada ejecución, todos los procesos vLLM y Ray se fuerzan a cerrar y la memoria de GPU se verifica limpia antes de que comience la siguiente ejecución.

Prompts de prueba

Los 5 prompts de prueba:

"Explica la teoría de la relatividad en términos simples." (Ciencia/Abstracto)
"Escribe una función de Python para encontrar la subcadena palindrómica más larga." (Codificación)
"¿Cuáles son las principales causas del cambio climático y sus efectos?" (Razonamiento complejo)
"Describe el proceso de la fotosíntesis paso a paso." (Descripción de proceso)
"¿Cómo aprende una red neuronal de los datos?" (Explicación técnica)

Verificación de datos: telemetría de tiempo de ejecución de vLLM

Las cifras de memoria y concurrencia en este artículo se derivaron directamente de los registros de inicialización del motor vLLM durante la ejecución del benchmark.

Inicialización de BF16:

1INFO ... Model loading took 61.03 GiB memory
2INFO ... Available KV cache memory: 4.38 GiB
3INFO ... GPU KV cache size: 17,952 tokens
4INFO ... Maximum concurrency for 4,096 tokens per request: 4.38x

Inicialización de GPTQ-Int4:

1INFO ... Model loading took 18.14 GiB memory
2INFO ... Available KV cache memory: 47.28 GiB
3INFO ... GPU KV cache size: 193,632 tokens
4INFO ... Maximum concurrency for 4,096 tokens per request: 47.27x

Limitaciones

Todas las pruebas usan tamaño de lote 1. En escenarios de alto rendimiento, la brecha de rendimiento entre Int4 y BF16 se amplía porque la saturación del ancho de banda de memoria se convierte en el cuello de botella dominante.

Los resultados son específicos de la H100 SXM. Las GPU más antiguas (A100, A10) carecen de soporte nativo de FP8. Las GPU de consumo (RTX 4090) tienen características de ancho de banda de memoria diferentes.

Los modelos GPTQ (JunHowie) son cuantizaciones proporcionadas por la comunidad. Las versiones oficiales pueden usar diferentes conjuntos de datos de calibración o parámetros, lo que puede afectar la precisión.

Probamos solo GPTQ. Otros métodos de cuantización (AWQ, BitsAndBytes NF4, GGUF, HQQ) podrían ofrecer diferentes compensaciones.

Conclusión

Para Qwen3-32B en una H100, FP8 es la opción predeterminada. Obtienes 1.5x el rendimiento, la mitad de la huella de memoria y un costo de precisión de 0.6 puntos.

Int4 tiene sentido cuando necesitas máximo rendimiento o concurrencia: 2.7x de velocidad, 12x de concurrencia, a costa de 1.6 puntos en MMLU-Pro y 8 puntos en HumanEval.

Int8 se sitúa en el medio y no ofrece una ventaja clara sobre FP8 en esta configuración. La ganancia de rendimiento sobre FP8 es pequeña (43.3 vs 37.9 tok/s) y la precisión es comparable. FP8 es más simple porque es proporcionado oficialmente por los autores del modelo y no requiere un checkpoint cuantizado de terceros.

El mayor impacto práctico de la cuantización no es la velocidad, es la concurrencia. BF16 puede atender a 4 usuarios con contexto de 4K en una sola H100. Int4 puede atender a 47. A $2.69/hr, eso reduce el costo por 1M de tokens de $28.73 a $10.69.

Cita esta investigación

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

Ekrem Sarı and Sıla Ermut (2026) - "LLM Cuantización: BF16 vs FP8 vs INT4". Publicado en línea en AIMultiple.com. Recuperado el 17 de Marzo de 2026, de: https://aimultiple.com/llm-quantization [Recurso en línea]

Sarı, E., & Ermut, S. (2026, 17 de Marzo). LLM Cuantización: BF16 vs FP8 vs INT4. AIMultiple. https://aimultiple.com/llm-quantization

@misc{sar2026,
  author = {Sarı, Ekrem and Ermut, Sıla},
  title  = {{LLM Cuantización: BF16 vs FP8 vs INT4}},
  year   = {2026},
  month  = mar,
  howpublished    = {\url{https://aimultiple.com/llm-quantization}},
  note   = {AIMultiple. Recuperado el 17 de Marzo de 2026}
}

Ekrem Sarı

Investigador de IA

Ekrem es investigador de IA en AIMultiple, donde se centra en la automatización inteligente, las GPU, los agentes de IA y los marcos de trabajo RAG.

Ver perfil completo

Investigado por

Sıla Ermut

Analista de la industria

Sıla Ermut es analista de la industria en AIMultiple, especializada en marketing por correo electrónico y vídeos de ventas. Anteriormente trabajó como reclutadora en empresas de gestión de proyectos y consultoría. Sıla es licenciada en Psicología Social y en Relaciones Internacionales.

Ver perfil completo