Ant Group y la comunidad de vLLM han publicado conjuntamente como código abierto Humming, una biblioteca de kernels para inferencia cuantizada. El código está en la organización del proyecto vLLM y se instala directamente con pip install humming-kernels. Desde vLLM 0.29.0, el paquete de instalación de la versión CUDA ya incluye esta dependencia; basta añadir --linear-backend humming o --moe-backend humming para activarla.
El blog enumera como colaboradores de Ant a Jinzhen Lin, Zekai Gu y Zhilin Huang; por parte de la comunidad figuran Michael Goin, de Red Hat, y otros.
Una biblioteca para una larga lista de formatos
El viejo problema de la inferencia cuantizada es la cantidad de formatos: pesos de 4 bits con activaciones de 16 bits requieren un conjunto de kernels, pasar a activaciones de 8 bits exige otro, y FP4, MXFP4 y NVFP4 tienen cada uno su propia forma de escribirse. La idea de Humming es separar la “descripción de la cuantización” de la “ejecución del kernel” y construir los kernels concretos a partir de componentes compartidos. En palabras del texto original, "separating quantization descriptions from execution choices".
Actualmente admite las combinaciones WnA16, W8A8, W4A8 y W4A4, con tipos de datos de INT1 a INT8, de FP4 a FP8, además de MXFP4, MXINT4 y NVFP4. En hardware cubre todas las arquitecturas de Nvidia posteriores a Turing, desde las H20 y H200 de Hopper hasta la B300 de Blackwell y la SM120 de consumo.
Algunas comparaciones en la multiplicación de matrices de una sola capa (todas medidas por el propio equipo del proyecto; las condiciones figuran en los gráficos del texto original):
| Escenario | Comparado con | Aceleración |
|---|---|---|
| W4A16 denso, lotes pequeños | cuBLAS | aproximadamente 3-4 veces en la mayoría de dispositivos |
| W4A8-MXFP4, H200 | DeepGEMM W8A8 | aproximadamente 4,5 veces |
| MoE W4A16, B300, lotes grandes | Marlin | aproximadamente 5 veces |
La prueba de extremo a extremo usó DeepSeek-V4.1-Flash, 8 GPU H20, paralelismo tensorial 8. Al cambiar la parte MoE de Marlin W4A16 a Humming W4A8, el rendimiento de salida aumentó entre un 14% y un 43% y la latencia del primer token bajó entre un 25% y un 32%; cuanto mayor la concurrencia, mayor el beneficio.
Qué significa para quienes despliegan en China
La plataforma de pruebas del blog parece elegida a medida de la realidad de los clústeres de inferencia chinos. La H20 es la tarjeta de Nvidia para el mercado chino: se recortó la potencia de cálculo, pero se mantuvo el ancho de banda de memoria, así que la cuantización de pocos bits es casi obligatoria al ejecutar modelos grandes. La prueba de extremo a extremo usa además el propio modelo MoE de DeepSeek, y muchos equipos del país tienen justo esa combinación.
Otro detalle son los dispositivos nacionales compatibles con CUDA: el blog incluye en su lista de soporte el Zhenwu 810E, de T-Head, la división de chips de Alibaba, y la hoja de ruta menciona adaptar más dispositivos PPU de T-Head, como el Zhenwu M890. Ant y T-Head pertenecen al ecosistema de Alibaba; hasta dónde llegue esta línea dependerá del ritmo de integración en el proyecto principal.
Para los equipos que ya usan vLLM, el coste de migración está sobre todo en la validación: los formatos que Humming puede leer directamente no obligan a recuantizar el modelo; los que vLLM no admite de forma nativa, como GPTQ INT3, pueden seguir la vía de compatibilidad --quantization humming.
Las limitaciones declaradas
El blog enumera las limitaciones con claridad. Las nuevas instrucciones de la B300 ya no admiten cálculo INT8, por lo que la multiplicación de matrices INT8 solo puede usar instrucciones antiguas y rinde notablemente peor; la próxima generación, Rubin, no admite los dos formatos ocultos de Tensor Core de Blackwell. La configuración de los kernels se elige por ahora con reglas heurísticas, y los autores reconocen que no alcanzan el óptimo global; el ajuste automático aún no está terminado.
La velocidad de compilación es otro punto fuerte. En una H200 con la caché desactivada, un solo kernel W4A16 compilado con Humming y NVRTC tarda apenas 1,88 segundos; durante el calentamiento del modelo, los kernels que cubren todos los tamaños de una capa se compilan en unos 2 a 4 segundos. Para los equipos que cambian a menudo de modelo y de formato para experimentar, esto ahorra más tiempo que las cifras de rendimiento.
Fuentes: blog oficial de vLLM, repositorio de Humming en GitHub, CocoLoop; el rendimiento, la latencia y los tiempos de compilación se atienen a los criterios de prueba publicados por el equipo del proyecto.