Realizamos pruebas de rendimiento de Qwen3-32B en 4 niveles de precisión (BF16, FP8, GPTQ-Int8, GPTQ-Int4) en una única GPU NVIDIA H100 de 80 GB. Cada configuración se evaluó en 2 pruebas de rendimiento (~12.200 preguntas) que abarcan conocimiento y generación de código, además de más de 2.000 ejecuciones de inferencia para medir el rendimiento. Int4 es 2,7 veces más rápido que BF16, perdiendo menos de 2 puntos en MMLU-Pro, pero la generación de código (HumanEval) pierde 8 puntos.
Resultados de referencia de cuantificación
MMLU-Pro evalúa el razonamiento general en 14 dominios (aproximadamente 12 000 preguntas, 5 opciones). Esta es la versión más difícil de MMLU, con preguntas de 10 opciones en lugar de 4.
HumanEval pone a prueba la generación de código (164 problemas, aprobado en 1). El modelo escribe funciones de Python que se ejecutan contra pruebas unitarias. Este es el único benchmark donde se ejecuta el resultado, no solo se evalúa.
El rendimiento es la cantidad de tokens de salida por segundo con un tamaño de lote de 1.
El tamaño del modelo es la memoria de la GPU consumida únicamente por los pesos, medida después de la carga.
Desglose de MMLU-Pro por categoría
Ingeniería y derecho muestran las mayores caídas en Int4. Matemáticas se mantiene estable en todas las precisiones.
Capacidad de memoria y concurrencia
Las herramientas de monitorización de GPU, como nvidia-smi, informan de una utilización casi completa independientemente del tamaño del modelo, ya que vLLM preasigna toda la memoria disponible. La verdadera cuestión es cómo se divide esa memoria entre los pesos del modelo y la caché KV, puesto que la caché KV determina cuántos usuarios se pueden atender simultáneamente.
El número máximo de usuarios es el límite de memoria antes de que se produzca un error de memoria insuficiente (OOM): capacidad total de tokens dividida por la longitud del contexto por usuario. Este es el máximo teórico. En la práctica, la sobrecarga de la planificació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 de 2K a 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 permite múltiples sesiones de razonamiento concurrentes.
Principales conclusiones
FP8 no pierde precisión medible
FP8 obtiene un 69,64 % en MMLU-Pro frente al 70,24 % de BF16, una diferencia de 0,6 puntos en 12 000 preguntas. En HumanEval, tanto FP8 como BF16 obtienen la misma puntuación, un 39,02 %. FP8 ofrece un rendimiento 1,5 veces mayor y reduce el tamaño del modelo a la mitad por un coste de 0,6 puntos.
GPTQ-Int8 obtiene un 70,32 % en MMLU-Pro, pero baja 1,8 puntos en HumanEval (37,20 %). Si la generación de código es importante, FP8 es la opción más segura.
Int4 degrada la generación de código más que el conocimiento.
MMLU-Pro baja 1,6 puntos en Int4 (del 70,24 % al 68,66 %). HumanEval baja 8 puntos (del 39,02 % al 31,10 %). La generación de código requiere predicciones precisas de tokens, donde pequeños errores de ponderación se acumulan en los cuerpos de las funciones.
La verdadera victoria reside en la concurrencia, no en la velocidad.
Int4 es 2,7 veces más rápido que BF16. Pero el mayor impacto se nota en la memoria. BF16 solo deja 4,4 GB para la caché KV, suficiente para unos 4 usuarios concurrentes con un contexto de 4K. Int4 libera 47,3 GB, suficiente para 47 usuarios, lo que supone un aumento de 12 veces en la capacidad de servicio con la misma GPU.
Las puntuaciones en matemáticas se mantienen constantes en todos los niveles de precisión.
Las calificaciones en matemáticas apenas varían: 81,87% en BF16, 81,87% en FP8, 81,87% en Int8, 80,24% en Int4. Ingeniería (del 49,64% al 43,45%) y derecho (del 43,05% al 40,60%) son más sensibles.
Coste por ficha
Utilizando los precios de H100 SXM en RunPod ($2.69/hora) con un tamaño de lote de 1:
Estas cifras reflejan la generación en tiempo real para un solo usuario. El procesamiento por lotes reduce aún más el coste.
Metodología de referencia para la cuantificación de LLM
Ambiente
- GPU: Single NVIDIA H100 80GB HBM3 (SXM) a través de RunPod ($2.69/hora)
- Software: vLLM 0.17.0, lm-evaluation-harness 0.4.11, PyTorch 2.8.0, CUDA 12.8, Python 3.11
- Modelo: Qwen3-32B (postentrenado/ajustado por instrucciones) de HuggingFace. No se aplicó ningún ajuste fino.
Evaluación de la precisión
- Todas las evaluaciones se ejecutan a través de
lm-evaluation-harnessconbatch_size="auto". - Cada tarea se ejecuta en un subproceso independiente . El modelo se carga desde cero cada vez y la GPU se limpia completamente entre tareas. Esto evita errores de memoria insuficiente (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 un 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 indicaciones formateadas sin aplicar la plantilla de chat del modelo (
apply_chat_template=Falsepor defecto), por lo que el token<think>nunca se inyecta.
Evaluación del desempeño
- 5 preguntas que se irán rotando a través de diferentes áreas (ciencia, programación, conocimientos generales).
- 10 iteraciones de calentamiento (no medidas), luego 500 iteraciones medidas.
- Salida corregida:
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Métricas: rendimiento (tokens/seg), uso de memoria de la GPU (GB)
Configuración vLLM por precisión
Todas las precisiones utilizan gpu_memory_utilization=0.90, max_model_len=4096.
Arquitectura de procesos divididos
Cada prueba de rendimiento se ejecuta como dos procesos separados para evitar errores de memoria insuficiente (OOM):
- Paso 1: Cargar el modelo, calentar, evaluar el rendimiento, guardar en un archivo temporal, salir.
- Limpieza: Finalice forzosamente los procesos vLLM y Ray, espere 10 segundos.
- Paso 2: Cargar el modelo desde cero, ejecutar cada tarea de evaluación en un subproceso separado, combinar con las métricas del paso 1, guardar el JSON final.
Variables controladas
Para eliminar factores externos, se fijaron los siguientes parámetros en todas las ejecuciones:
Indicaciones de prueba
Las 5 preguntas de la prueba:
- “Explica la teoría de la relatividad en términos sencillos.” (Ciencia/Resumen)
- “Escribe una función en Python para encontrar la subcadena palíndroma más larga.” (Programació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 del proceso)
- “¿Cómo aprende una red neuronal a partir de los datos?” (Explicación técnica)
Verificación de datos: telemetría en tiempo de ejecución de vLLM
Las cifras de memoria y concurrencia que aparecen en este artículo se obtuvieron directamente de los registros de inicialización del motor vLLM durante la ejecución de las pruebas de rendimiento.
Inicialización de BF16:
Inicialización de GPTQ-Int4:
Limitaciones
Todas las pruebas utilizan un tamaño de lote de 1. En escenarios de alto rendimiento , la diferencia de rendimiento entre Int4 y BF16 se amplía debido a que la saturación del ancho de banda de la memoria se convierte en el principal cuello de botella.
Los resultados son específicos de la H100 SXM. Las GPU más antiguas (A100, A10) carecen de soporte nativo para FP8. Las GPU para consumidores (RTX 4090) tienen características de ancho de banda de memoria diferentes.
Los modelos GPTQ (JunHowie) son cuantificaciones aportadas por la comunidad. Las versiones oficiales pueden utilizar conjuntos de datos o parámetros de calibración diferentes, lo que puede afectar a la precisión.
Solo probamos GPTQ. Otros métodos de cuantización (AWQ, BitsAndBytes NF4, GGUF, HQQ) podrían ofrecer ventajas e inconvenientes diferentes.
Conclusión
Para Qwen3-32B en un H100, FP8 es la opción predeterminada. Se obtiene 1,5 veces más rendimiento, la mitad de consumo de memoria y una pérdida de precisión de 0,6 puntos.
Int4 tiene sentido cuando se necesita el máximo rendimiento o concurrencia: 2,7 veces más velocidad, 12 veces más concurrencia, a costa de 1,6 puntos en MMLU-Pro y 8 puntos en HumanEval.
Int8 se sitúa en un punto intermedio y no ofrece una clara ventaja sobre FP8 en esta configuración. La mejora en el rendimiento con respecto a FP8 es pequeña (43,3 frente a 37,9 tok/s) y la precisión es comparable. FP8 es más sencillo porque lo proporcionan oficialmente los autores del modelo y no requiere un punto de control cuantizado de terceros.
El mayor impacto práctico de la cuantización no es la velocidad, sino la concurrencia. BF16 puede dar servicio a 4 usuarios con un contexto de 4K en un único H100. Int4 puede dar servicio a 47. A 2,69 $/hora, esto reduce el coste por millón de tokens de 28,73 $ a 10,69 $.
Siguiente para leer
Comparativa de los programas LLM de Agentic: Los 13 mejores programas LLM son una referencia
Motores de inferencia LLM: vLLM vs LMDemploy vs SGLang
El panorama de la evaluación de los másteres en Derecho (LLM) con sus respectivos marcos de referencia.
LCM: De la tokenización LLM a la representación a nivel de concepto
Los mejores másteres jurídicos para ventanas de contexto extendidas en 2026
Simulación de audiencia: ¿Pueden los modelos de aprendizaje lingüístico predecir el comportamiento humano?
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios.