AIREITERvLLM Humming es una opción muy prometedora para servir modelos MoE cuantizados con alta concurrencia en hardware de clase Hopper, pero los benchmarks públicos no justifican tratarlo como una actualización universal del backend. Las pruebas con escalado group-32 en H100 y con decodificación batch-1 en Ampere dejan clara una cosa: hay que validar cada combinación de modelo, GPU, formato y tamaño de batch.
En resumen: Humming es una mejora condicionada
Humming es una biblioteca de kernels GEMM compilados con JIT para inferencia cuantizada, desarrollada por la comunidad de vLLM junto con Ant Group. Está orientada a cargas densas y de mixture-of-experts (MoE), con varios formatos de cuantización y generaciones de GPU NVIDIA. El anuncio oficial habla de aceleraciones de hasta 5x en los kernels y de mejoras de entre el 14% y el 43% en determinados escenarios MoE de extremo a extremo, pero esas cifras corresponden a combinaciones concretas de modelo, hardware, formato y concurrencia (anuncio de vLLM).
Mi criterio para adoptarlo es sencillo:
- Prueba Humming primero en servicios MoE W4A8/W4A16 con batches grandes o mucha concurrencia, siempre que uses configuraciones compatibles de Hopper o posteriores.
- No des por hecho que habrá mejoras en decodificación batch-1, en GPU Ampere antiguas o con escalado group-wise poco habitual.
- Conserva una alternativa, porque los issues actuales incluyen errores de selección por dimensiones y rutas lentas específicas del backend.
Un informe independiente sobre DeepSeek-V4.1-Flash alcanzó 5.856 tokens/s de salida con una configuración base de vLLM ajustada, 12.802 con atención en paralelo de datos y 17.634 con kernels Humming W4A8 modificados, todo ello en un único nodo con cuatro GH200 (informe técnico). El resultado necesitó corregir un kernel y ajustar la configuración, así que demuestra el potencial de una clase de cargas concreta, no un rendimiento garantizado nada más instalarlo.
Qué cambia Humming en un despliegue de vLLM
Humming lleva la multiplicación de matrices cuantizadas a una capa flexible de kernels JIT para las rutas GEMM densas y MoE. El proyecto está dirigido a arquitecturas NVIDIA desde Turing en adelante y a varios formatos de baja precisión (repositorio de Humming).
En la prueba citada sobre Hopper, Marlin descomprimía los pesos FP4 a BF16, mientras que Humming convertía internamente los pesos FP4 a FP8 dentro de la SM y utilizaba multiplicación en los tensor cores FP8. Esa diferencia solo resultó decisiva cuando la decodificación pasó a estar limitada por cómputo. En otros casos pueden imponerse el tráfico de memoria, la distribución de tiles, la gestión de escalas, el coste de lanzamiento o la presión sobre los registros.
Dónde aparece la mejora y dónde se esfuma
La mejor forma de leer los datos públicos es como un mapa de los límites de rendimiento, no como un único porcentaje promocional.
MoE con mucha concurrencia: la mejora más clara
El ejemplo oficial con DeepSeek-V4.1-Flash compara Marlin W4A16 con Humming W4A8 en ocho GPU H20 y registra entre un 14% y un 43% más de rendimiento MoE de extremo a extremo, con la mejora más alta en los niveles superiores de concurrencia. Un usuario que volvió a publicar el benchmark concretó la comparación: de 442 a 634 tokens/s de salida con una concurrencia de 64, aunque también señaló que el formato de cuantización había cambiado (debate de usuarios).
El resultado convierte a Humming en una vía de serving muy interesante, pero no en un multiplicador de rendimiento de kernel comparable bajo exactamente el mismo formato.
W4A8 group-32 en H100: una advertencia importante
El issue #38 de Humming probó pesos MXFP4 con activaciones MXFP8 y escalas group-32 en una H100. Todas las rutas comparadas eran numéricamente correctas, pero la ruta fusionada resultó mucho más lenta en las dimensiones analizadas. Para (4096,3072,4096), Humming fusionado tardó 4.969 ms frente a los 0.580 ms de la línea base QDQ; para (4096,14336,4096), tardó 22.298 ms frente a 1.256 ms (issue #38).
Más adelante, el issue registró una sintonización local por encima de 500 TFLOPS, mientras que una implementación experimental alcanzó aproximadamente entre 580 y 665 TFLOPS con preprocesamiento adicional y otro esquema de almacenamiento de pesos. La granularidad de las escalas, la elección de tiles, la presión sobre los registros y el preprocesamiento pueden cambiar por completo el resultado.
Decodificación de una sola petición en SM80: no presupongas mejoras en Ampere
El issue #72 describe una utilización baja de INT3 en NVIDIA SM80 durante decodificación con M=1. En una CMP 170HX, el kernel Humming medido alcanzó unos 691 GB/s frente a un ancho de banda HBM máximo aproximado de 1.591 GB/s, lo que equivale a una utilización del 43,4%. En una RTX 5070 Ti SM120 comparable se obtuvieron unos 753 GB/s frente a 827 GB/s máximos, aproximadamente un 91% de utilización (issue #72).
El mismo informe cita resultados del repositorio en una A800 de 692,4 GB/s con M=1, apenas el 34,0% de los 2.039,04 GB/s máximos indicados. En esa comparación, BF16 sin cuantizar alcanzó 1.232,3 GB/s.
“¿Podría la ruta INT3 actual de Humming para SM80 no estar optimizada para esta carga?” —
yangfangyunyun, issue #72 de vLLM Humming
Instalación y primera prueba sin riesgos
La documentación oficial identifica vLLM 0.29.0 como la versión a partir de la cual las instalaciones CUDA incluyen Humming como dependencia. Usa --moe-backend humming para la ruta MoE, --linear-backend humming para las capas lineales compatibles o la configuración de cuantización de Humming documentada para una ruta específica del modelo (documentación de cuantización de vLLM). Antes de copiar un parámetro entre arquitecturas, revisa la documentación de la versión y del modelo.
Empieza con una prueba controlada:
- Anota las versiones de vLLM, CUDA y PyTorch, la arquitectura de la GPU, la cuantización del checkpoint y las dimensiones del modelo.
- Mantén constantes la longitud del prompt, la longitud de salida, la concurrencia y el número de repeticiones.
- Compara el backend actual con Humming usando el mismo comando de serving y el parámetro de backend correspondiente.
- Mide tokens/s de salida, TTFT, latencia entre tokens, memoria de la GPU y el tiempo de arranque y calentamiento del JIT.
- Repite la prueba cuando la caché de kernels esté caliente y, después, mide batch 1 y la concurrencia de producción.
- Conserva un fallback automático o manual para dimensiones no compatibles y casos en los que no se seleccione correctamente la ruta.
Una mejora de throughput no basta si empeoran el TTFT, la latencia de cola, el coste de calentamiento o el consumo de memoria. El proyecto perf-eval de vLLM recomienda usar recetas YAML, ejecutar varias repeticiones, agregar por mediana y fijar las longitudes de entrada y salida para obtener comparaciones consistentes (repositorio de perf-eval).
El enrutamiento del backend puede bloquear una configuración válida de Humming
Otro issue de vLLM explica por qué las pruebas de fallback son importantes. En el issue #60700, un checkpoint MoE W4A8 de compressed-tensors tenía una dimensión intermedia de 640. CUTLASS exigía dimensiones alineadas a 256, mientras que Humming podía procesar la forma probada; sin embargo, una aserción incondicional se ejecutaba antes de cargar el backend seleccionado. Por eso, incluso especificando --moe-backend humming, el arranque fallaba.
El parche propuesto por quien reportó el problema limitaba la aserción a CUTLASS. Con ese cambio, los 62 shards se cargaron en dos GPU H100 NVL y la prueba registró entre un 12% y un 50% menos de TTFT y entre un 2% y un 13% más de throughput del sistema que su configuración CUTLASS de referencia (issue #60700). Cuando se comprobó, el issue seguía abierto y la PR #60711 aparecía como propuesta para corregir el enrutamiento.
Por tanto, un lanzamiento fallido de Humming puede deberse a una comprobación de capacidades de vLLM y no al kernel. Antes de descartar la configuración, revisa el backend seleccionado, las restricciones de dimensiones y el estado de la corrección.
Tabla de decisión para operadores
| Tu carga de trabajo | Decisión sobre Humming | Motivo |
|---|---|---|
| MoE con mucha concurrencia en Hopper/GH200 | Pruébalo pronto | Un trabajo independiente de serving alcanzó 17.634 tok/s después de aplicar correcciones y ajustes. |
| Decodificación al estilo DeepSeek con batches grandes | Candidato sólido | La ejecución en tensor cores FP8 puede ayudar cuando las GEMM MoE están limitadas por cómputo. |
| Decodificación batch-1 o con batches pequeños en SM80 | No presupongas una mejora | El issue #72 registra entre un 34% y un 43% de ancho de banda efectivo en las rutas INT3 probadas. |
| Escalado de activaciones group-32 en H100 | Haz benchmark con una matriz reducida de dimensiones | El issue #38 muestra regresiones graves en una ruta fusionada. |
| Dimensiones MoE W4A8 no alineadas a 256 | Comprueba la versión de vLLM y las correcciones de enrutamiento | Las aserciones compartidas pueden bloquear Humming antes de cargar los pesos. |
| Producción sin presupuesto para modificar el código fuente | Úsalo solo después de una comparativa representativa | Algunas mejoras independientes necesitaron cambios en el kernel o en las heurísticas. |
Preguntas frecuentes
¿Qué GPU son compatibles con Humming?
El proyecto está orientado a GPU NVIDIA desde Turing en adelante y documenta varias rutas de cuantización. Que exista compatibilidad no significa que todos los formatos y cargas estén igual de optimizados; los casos con SM80 y escalados poco habituales necesitan su propio benchmark.
¿Humming necesita un checkpoint ya cuantizado?
Humming es una biblioteca de kernels de inferencia, no un cuantizador de propósito general. Los flujos de trabajo citados utilizan checkpoints con pesos cuantizados y esquemas de activación compatibles, así que debes comprobar el formato del modelo en la documentación y el repositorio de vLLM antes de ponerlo en producción.
¿Es Humming más rápido que cualquier otro backend de vLLM?
No. Es más rápido en determinadas cargas cuantizadas, especialmente en los casos MoE con mucha concurrencia descritos en los benchmarks. Los resultados cambian según la arquitectura, el formato, las dimensiones, la agrupación de escalas y el tamaño del batch.
La conclusión práctica es clara: Humming puede acelerar de forma notable un servicio vLLM cuantizado cuando la configuración encaja, pero adoptarlo exige una comparativa breve y repetible, porque los resultados públicos dependen de configuraciones muy concretas.