Anuncio de Humming: kernels rápidos y flexibles para inferencia cuantizada

Ant Group y la comunidad de vLLM están liberando como código abierto Humming, una biblioteca de kernels de propósito general y alto rendimiento para inferencia cuantizada. Humming ofrece las siguientes características:

• Amplio soporte de dispositivos: Compatible con arquitecturas de GPU de NVIDIA desde Turing en adelante, junto con dispositivos compatibles con CUDA como el Zhenwu 810E de T-Head.
• Extenso soporte de cuantización: Una arquitectura unificada admite diversas combinaciones de formatos de pesos y activaciones para cargas de trabajo densas y MoE, cubriendo una amplia gama de tipos enteros y de punto flotante, anchos de bits y esquemas de escalado.
• Sólido rendimiento de ejecución: Supera significativamente a las implementaciones existentes de vLLM Marlin, FlashInfer y DeepGEMM en muchas cargas de trabajo representativas.

Repositorio: github.com/vllm-project/humming

Antecedentes

A medida que crecen los modelos y las cargas de trabajo de inferencia, la capacidad de memoria, el ancho de banda de memoria y los costos de cómputo limitan cada vez más el despliegue. Esto es especialmente evidente en los modelos MoE: cada token activa solo un subconjunto de expertos, pero aún es necesario almacenar el conjunto completo de pesos. DeepSeek-V3, por ejemplo, tiene 671 mil millones de parámetros, con 37 mil millones activados por token. La cuantización reduce la precisión de los pesos y las activaciones para disminuir el uso de memoria y el movimiento de datos, y también puede mejorar la eficiencia del cómputo.

Los requisitos de cuantización varían según los modelos y las generaciones de GPU. Las configuraciones comunes incluyen WNA16, W8A8, W4A8 y W4A4, donde W y A especifican los anchos de bits de pesos y activaciones, y N denota un ancho de bits de peso variable. Incluso a la misma precisión, esquemas como INT4 y NVFP4 difieren en formato numérico y escalado. La granularidad del escalado, la representación de la escala, el tamaño de grupo y la cuantización simétrica o asimétrica amplían aún más el espacio de configuraciones.

Estos ahorros de almacenamiento y cómputo solo se traducen en menor latencia y mayor rendimiento con kernels eficientes. El prefill, el decode y las cargas variables de expertos MoE imponen demandas diferentes al cómputo y la memoria. Los kernels deben adaptarse a estas cargas de trabajo manteniendo bajos los overheads de conversión, descuantización y planificación.

Desarrollar e integrar un kernel dedicado para cada combinación crea una carga de mantenimiento creciente. Cada adición puede requerir su propio preprocesamiento de pesos, selección de kernel, adaptadores de framework y pruebas. Las optimizaciones deben luego trasladarse entre múltiples implementaciones.

Humming aborda este problema separando las descripciones de cuantización de las decisiones de ejecución y componiendo los kernels a partir de componentes compartidos.

Arquitectura de propósito general

La ruta de ejecución de Humming tiene tres partes: representar el cómputo cuantizado, seleccionar configuraciones para el hardware y la carga de trabajo, y compilar un kernel a partir de componentes CUDA.

Una representación de cuantización unificada

Los modelos exportados por diferentes herramientas de cuantización varían en formato numérico, organización de parámetros y disposición de pesos. Humming convierte los formatos de exportación soportados al formato estándar de Humming: una descripción de cuantización común con pesos, escalas, puntos cero y otros tensores organizados de manera consistente.

Esta representación preserva la semántica de cuantización de cada esquema mientras describe el formato de pesos, la granularidad del escalado, el tipo de dato de la escala, los puntos cero y las escalas secundarias como parámetros separados. Las activaciones tienen su propio formato numérico y configuraciones de cuantización. Estos parámetros pueden combinarse sujetos a restricciones de formato y hardware.

Por ejemplo, pesos INT4 por grupo pueden emparejarse con activaciones BF16. Los pesos de punto flotante de baja precisión con diferentes esquemas de escalado usan el mismo sistema de parámetros. Esto proporciona a los frameworks de inferencia una interfaz común para modelos de diferentes fuentes.

Ajuste y compilación JIT para cada carga de trabajo

El formato estándar proporciona una representación común entre formatos de exportación. El preprocesamiento luego valida parámetros, rellena dimensiones y reempaqueta estos tensores en disposiciones adecuadas para el kernel objetivo. Humming combina la descripción de cuantización con la forma de los pesos, el tipo de GEMM, la GPU objetivo y las opciones de cómputo para configurar la ejecución.

Tres configuraciones describen el kernel:

• Layer Config describe las formas de los tensores, los tipos de datos, los parámetros de cuantización y la arquitectura objetivo.
• Compute Config especifica el tipo de GEMM y las opciones de cómputo, como la invarianza de lote y la disposición de la escala de entrada.
• Tuning Config selecciona las formas de los tiles, el número de etapas del pipeline, la especialización de warps, el acceso a memoria y las instrucciones MMA. También controla la concurrencia y la planificación; TMA puede configurarse por tensor.

De forma predeterminada, Humming selecciona las configuraciones de ajuste mediante heurísticas específicas del dispositivo. Puede preparar diferentes configuraciones para rangos de tamaños de entrada y despachar al kernel apropiado en tiempo de ejecución.

La arquitectura unificada de Humming hace que sea sencillo ajustar los parámetros de ejecución y seleccionar pipelines para diferentes cargas de trabajo. Con tamaños de lote pequeños, un pipeline multietapa que usa copias asíncronas (cp.async) y MMA puede superar a un pipeline construido en torno a TMA y UMMA. Con tamaños de lote mayores, TMA y UMMA pueden ofrecer un mejor rendimiento. Humming admite ambas rutas de ejecución dentro del mismo marco de configuración y componentes, lo que le permite seleccionar la estrategia más eficaz para cada carga de trabajo.

Juntas, las tres configuraciones especializan los kernels compilados con NVRTC o NVCC. Los kernels compilados se almacenan en caché para su reutilización. La inferencia combina el kernel seleccionado con los pesos preprocesados y las activaciones en tiempo de ejecución.

Componentes CUDA compartidos entre formatos y arquitecturas

A nivel de CUDA, Humming organiza la programación de tareas, el movimiento de datos, la desuantización y el escalado, el cálculo con Tensor Cores y el procesamiento de salida en componentes reutilizables. Ofrece pipelines estándar, especializados por warp y dedicados a UMMA. Estos pipelines comparten componentes compatibles mientras utilizan el flujo de datos y la sincronización que requiere cada estrategia de ejecución.

Cada grupo de componentes gestiona una fuente distinta de variación:

• El procesamiento numérico gestiona los formatos de cuantización. Los componentes de decodificación y aritmética tienen en cuenta el ancho de bits, la representación entera o de punto flotante, las escalas y los puntos cero. La desuantización y el escalado están integrados en el cálculo del kernel.
• Los backends de memoria y cómputo gestionan las arquitecturas de GPU. Humming selecciona las implementaciones de movimiento de datos y Tensor Core para la arquitectura objetivo, utilizando copias asíncronas, TMA y multicast cuando están soportadas.
• El mapeo y la programación de tareas gestionan las cargas de trabajo densas y de MoE. Cada tipo de GEMM utiliza la lógica de programación adecuada. El escalado y la adición de sesgo también pueden fusionarse en la etapa de salida.

La compilación JIT combina estos componentes según las tres configuraciones y elimina las ramas de implementación no utilizadas. Por lo tanto, un nuevo formato o arquitectura puede soportarse extendiendo los componentes relevantes. Las mejoras en un componente compartido benefician a las configuraciones compatibles, reduciendo el desarrollo y mantenimiento duplicados de kernels especializados separados.

Esta implementación en CUDA es ligera y evita dependencias de frameworks de kernels pesados, manteniendo también rápida la compilación JIT. En nuestra prueba de compilación de un solo kernel W4A16 en un servidor H200 con CUDA 13.4, el tiempo de compilación pasó de 23.35 segundos para CUTLASS con NVCC a 1.82 segundos para Humming con NVCC o 1.88 segundos con NVRTC, con las cachés de compilación deshabilitadas. Esto reduce el costo de preparar kernels para nuevas cargas de trabajo y hace más práctico el ajuste iterativo. Humming también compila kernels en paralelo durante el calentamiento del modelo. En nuestras pruebas, compilar y cargar los kernels que cubren todos los tamaños de M soportados para el GEMM de una sola capa toma solo entre 2 y 4 segundos aproximadamente, lo que hace práctico preparar múltiples kernels especializados antes de la inferencia.

Ajuste de Rendimiento Basado en los Parámetros del Dispositivo

Humming optimiza profundamente los kernels utilizando tanto la configuración GEMM como los parámetros del dispositivo. Los formatos de cuantización, las formas de las matrices, el soporte de instrucciones de la GPU, el número de SM, la memoria compartida y los recursos de registros informan todas las decisiones de ejecución, convirtiendo los beneficios del almacenamiento de bajo bit en un rendimiento práctico de inferencia.

Inferencia eficiente W4A8-MXFP4 en GPUs existentes. Las arquitecturas anteriores a Blackwell carecen de soporte nativo de Tensor Core para MXFP4, y los kernels convencionales W4A8-MXFP4 pueden verse limitados por la sobrecarga de desuantización y escalado en valores grandes de M. Humming aborda esto con una ruta rápida de desuantización de MXFP4 a INT8/FP8 que convierte los pesos MXFP4 en un formato de cómputo soportado dentro del kernel. En este entorno, la ruta supera sustancialmente a las implementaciones convencionales W4A8 en valores pequeños de M y se acerca al rendimiento W8A8 en valores grandes de M. GPUs como la H200 pueden así ejecutar kernels W4A8-MXFP4 de alto rendimiento conservando los beneficios de almacenamiento de los pesos de 4 bits.

Rutas de desuantización adaptadas a cada dispositivo. El mismo formato de cuantización puede beneficiarse de diferentes implementaciones según las GPUs. Humming selecciona las rutas de decodificación, conversión numérica y escalado para el dispositivo, emparejándolas con pipelines de acceso a memoria y cómputo adecuados para reducir la sobrecarga de instrucciones y movimiento de datos. Los componentes compartidos hacen que estas optimizaciones sean reutilizables en kernels densos y de MoE compatibles.

Amplios controles de ajuste con heurísticas específicas por dispositivo. Humming expone formas de tile, conteos de etapas de pipeline, especialización por warp, TMA, instrucciones MMA, concurrencia de CTA y programación Stream-K. Las heurísticas específicas por dispositivo combinan las formas GEMM con las restricciones de recursos para equilibrar paralelismo, reutilización de datos y sobrecarga del pipeline, seleccionando diferentes estrategias de ejecución a medida que cambian los tamaños de entrada. Los desarrolladores pueden usar las configuraciones predeterminadas directamente o refinarlas para modelos y escenarios de despliegue particulares.

Resultados

Amplio Soporte de Dispositivos

La arquitectura unificada de Humming permite un amplio soporte de GPUs. Para GPUs de NVIDIA, Humming soporta completamente todas las arquitecturas desde Turing en adelante, aportando un framework común de cómputo cuantizado a múltiples generaciones de hardware.

La arquitectura JIT unificada también hace que sea sencillo extender Humming a otras GPUs compatibles con la programación CUDA. Humming ya soporta completamente el Zhenwu 810E de T-Head, llevando sus kernels compartidos y capacidades de ajuste a más plataformas de hardware.

La siguiente figura muestra los tipos de activación de alto rendimiento soportados por Humming en cada dispositivo: tipos que pueden aprovechar al máximo las capacidades de cómputo pico del dispositivo. Algunos tipos omitidos de la figura aún pueden ejecutarse mediante otras rutas de instrucciones. Por ejemplo, las instrucciones UMMA en la B300 (SM103) ya no soportan cómputo INT8, pero las instrucciones MMA anteriores aún pueden ejecutar GEMM INT8, con un rendimiento sustancialmente menor.

Soporte de Cuantización

La compatibilidad de Humming con los tipos de cuantización depende principalmente de la compatibilidad entre los tipos de activación y de pesos. Su representación unificada de cuantización y su arquitectura de kernels permiten que una amplia gama de formatos de pesos enteros y de punto flotante funcione con activaciones a diferentes precisiones, ofreciendo opciones flexibles para la precisión del modelo y el rendimiento del despliegue.

La siguiente figura muestra las combinaciones de tipos de pesos y activaciones compatibles con Humming. Las filas representan los tipos de pesos, las columnas representan los tipos de activaciones, y las marcas de verificación indican las combinaciones compatibles. Junto con la matriz de compatibilidad de dispositivos anterior, describe las rutas de cálculo cuantizado de alto rendimiento disponibles en cada arquitectura de hardware.

Humming también admite un formato especial de punto flotante con cero bits de exponente, cuyos valores representables coinciden con los de los enteros simétricos del mismo ancho de bits. Por ejemplo, INT8 excluyendo -128 y float8e0m7 representan ambos enteros desde -127 hasta 127. Los pesos en este formato tienen la misma compatibilidad de tipos de activación que los pesos INT del mismo ancho de bits. Humming convierte automáticamente los pesos enteros simétricos elegibles a este formato para una desquantización más rápida.

La comunidad también ha descubierto dos capacidades ocultas en los Blackwell Tensor Cores: soporte nativo para float4e0m3 y float8e3m4, dos formatos especiales de punto flotante que no están expuestos en el sistema de tipos de PTX. Humming admite estas características en todas las arquitecturas Blackwell, incluidos los dispositivos datacenter SM100/SM103 y los dispositivos SM120/SM121 para estaciones de trabajo y computación personal. Ambos formatos están integrados en su marco unificado de cuantización y cómputo, proporcionando más opciones nativas de cómputo para la inferencia de baja precisión. Rubin no admite estos dos formatos ocultos de Tensor Core, por lo que el soporte para estas rutas nativas de cómputo no se extiende a Rubin.

Rendimiento

Los microbenchmarks de kernels que se muestran abajo, ejecutados por la comunidad de vLLM, miden el rendimiento GEMM con M cubriendo cada potencia de dos desde 1 hasta 8192. Los kernels se calientan completamente y se miden de forma independiente con una caché L2 fría, con una breve pausa entre muestras. Las aceleraciones de MoE usan la suma de las latencias GEMM de Gateup y Down. Cada figura identifica su línea base, los formatos de cuantización, las dimensiones de las matrices y las versiones de software.

WnA16

WnA16 es uno de los enfoques más versátiles y utilizados para la inferencia cuantizada. Combina pesos de bits bajos con activaciones FP16/BF16, reduciendo el almacenamiento de pesos y el tráfico de memoria mientras aprovecha las capacidades de cómputo de 16 bits ampliamente disponibles. Esto lo hace adecuado para muchas generaciones de GPU y escenarios de despliegue de modelos. La familia W4A16 ha atraído un interés particular de la comunidad y es un foco principal del trabajo de optimización de Humming.

Para W4A16 denso, Humming iguala o supera a vLLM Marlin en la mayoría de las configuraciones probadas, con ganancias sustanciales en varias cargas de trabajo Hopper y Blackwell. La figura siguiente usa cuBLAS como línea base común. En tamaños de lote pequeños, Humming ofrece aceleraciones de aproximadamente 3–4× en varios dispositivos. A medida que crece el tamaño del lote, sigue utilizando el hardware de manera eficiente, alcanzando aproximadamente el doble del rendimiento de Marlin en cargas de trabajo H200 de lote grande y más de tres veces su rendimiento en algunos casos B300.

Estas ganancias se extienden a MoE. Humming proporciona rutas Indexed y Grouped eficientes para cargas de trabajo donde los tokens se distribuyen entre expertos y la cantidad de trabajo por experto cambia con la carga. En la figura siguiente, MXFP4 W4A16 en H20 y H200 alcanza aproximadamente el doble del rendimiento de Marlin en varios casos de lote mediano a grande. En B300, las rutas MXINT4 y NVFP4 logran ganancias aún mayores en tamaños de lote grandes, con la ruta Grouped alcanzando aproximadamente 5×. Los resultados en SM120 y SM121 también muestran a Humming superando a Marlin y a las implementaciones correspondientes de FlashInfer en una variedad de cargas de trabajo.

Las optimizaciones de Humming también se extienden más allá de W4A16 a otras combinaciones WnA16. Sus rutas compartidas de desquantización y cómputo ofrecen un rendimiento sólido para pesos enteros y de punto flotante de diferentes anchos de bits, incluidos INT1, INT2, INT3 y FP4 hasta FP8. La siguiente figura muestra ganancias amplias en estos formatos en tamaños de lote pequeños y medianos, con las configuraciones de bits más bajos en SM120 superando 5× el rendimiento de BF16 cuBLAS. En tamaños de lote grandes en H20, múltiples anchos de bits mantienen una eficiencia de cómputo cercana a BF16 cuBLAS. Esto brinda a los modelos opciones más refinadas entre precisión, almacenamiento y throughput.

W8A8 / W4A8 / W4A4

Con Hopper, FP8 W8A8 con escalado por bloques se convirtió en un enfoque predominante para la inferencia cuantizada de alto rendimiento. Humming mejora aún más esta ruta de cómputo establecida optimizando conjuntamente el movimiento de datos, el escalado y la programación de expertos. La columna izquierda muestra los resultados W8A8 en H20 y H200. En tamaños de lote pequeños y medianos, Humming alcanza aproximadamente 2.6× y 2.5× el rendimiento de DeepGEMM Contiguous, respectivamente, con un rendimiento competitivo tanto en diseños Indexed como Grouped.

A medida que más modelos adoptan la cuantización de pesos MXFP4 nativa, convertir la menor huella de pesos en ganancias prácticas de inferencia se vuelve cada vez más valioso. Humming aborda esto con una ruta W4A8 eficiente que desquantiza rápidamente los pesos MXFP4 a medida que se cargan y usa FP8 Tensor Cores para el cómputo, permitiendo una ejecución eficiente W4A8-MXFP4 en Hopper. La columna derecha mantiene DeepGEMM W8A8 como línea base. En tamaños de lote pequeños y medianos, la W4A8 de Humming alcanza aproximadamente 4.2× el rendimiento de la línea base en H20 y 4.5× en H200, superando también sustancialmente los resultados W8A8 de Humming en la misma figura. La reducción del tráfico de pesos se traduce en una menor latencia GEMM. FlashInfer CUTLASS W4A8 es también una implementación basada en el enfoque de Humming, mientras que la implementación actual de Humming logra un mejor rendimiento en los benchmarks mostrados aquí.

Blackwell añade soporte nativo de Tensor Core para formatos de microescalado como MXFP8 y MXFP4. Desde los dispositivos datacenter SM100/SM103 hasta los dispositivos SM120/SM121 para estaciones de trabajo y computación personal, Humming utiliza las capacidades de cómputo de baja precisión de cada arquitectura para soportar W8A8, W4A8 y W4A4 dentro de un solo kernel y marco de ajuste.

En B300 (SM103), Humming demuestra ganancias sustanciales de rendimiento en las tres combinaciones de formato MX. Cada panel siguiente usa DeepGEMM Contiguous en la precisión correspondiente como línea base. En tamaños de lote pequeños y medianos, W8A8, W4A8 y W4A4 alcanzan aproximadamente 1.25×, 1.6× y 1.4× del rendimiento de la línea base, respectivamente, y superan las implementaciones correspondientes de FlashInfer en muchas cargas de trabajo. Tanto las rutas Indexed como Grouped se benefician del cálculo nativo en baja precisión, proporcionando opciones eficientes para diferentes disposiciones de expertos.

Estas ganancias también se extienden a SM120 y SM121. En los resultados siguientes, el MXFP4 × MXFP8 W4A8 de Humming y el NVFP4 × NVFP4 W4A4 superan a FlashInfer CUTLASS en la mayoría de los puntos probados. En SM121, con tamaños de lote pequeños, las ganancias de rendimiento alcanzan aproximadamente 19% para W4A8 y 9% para W4A4; en SM120, Humming también lidera en la mayoría de los tamaños probados. La arquitectura unificada lleva estas optimizaciones de inferencia en baja precisión a más dispositivos, extendiendo el cálculo cuantizado eficiente más allá del centro de datos.

Rendimiento de Inferencia de Extremo a Extremo

Las ganancias de W4A8 de Humming se extienden al servicio de modelos. En nuestra prueba con DeepSeek-V4.1-Flash en ocho GPUs H20 con TP=8, mantener sin cambios los pesos MXFP4 del modelo y cambiar la ejecución de MoE de Marlin W4A16 (activaciones BF16) a Humming W4A8 (activaciones FP8 por token) mejora el rendimiento de extremo a extremo en aproximadamente 14%–43% y reduce el tiempo medio hasta el primer token (TTFT) en aproximadamente 25%–32%. La ventaja de rendimiento crece con la concurrencia: a una concurrencia de 64, el throughput de salida aumenta de 442.37 a 633.94 tokens/s, mientras que el tiempo medio por token de salida (TPOT) disminuye en aproximadamente 31%.

Uso

Instalación

Instale Humming con pip:

pip install humming-kernels

Humming utiliza un compilador CUDA para generar kernels bajo demanda. Si no hay un compilador CUDA disponible en el sistema, elija una de las siguientes opciones de instalación para incluir las dependencias de compilación de la versión mayor de CUDA de su entorno:

pip install "humming-kernels[cu12]"  # CUDA 12
pip install "humming-kernels[cu13]"  # CUDA 13

Humming en sí es extremadamente ligero, con dependencias simples y un paquete wheel de solo unos 500 KB. La compilación bajo demanda evita incluir una gran colección de kernels precompilados. En principio, cualquier entorno capaz de ejecutar PyTorch 2.7 también puede ejecutar Humming, lo que facilita su integración en entornos de inferencia existentes.

Uso de Humming en vLLM

Humming está profundamente integrado en vLLM. A partir de vLLM 0.29.0, las instalaciones de CUDA incluyen Humming como dependencia, por lo que no se necesita una instalación separada de Humming. Humming es compatible con GPU NVIDIA en todas las arquitecturas desde Turing en adelante (SM75 y superiores).

Las opciones --linear-backend y --moe-backend seleccionan Humming como backend de cómputo para dense GEMM y MoE GEMM, respectivamente. Por ejemplo, habilite Humming para ambos con un tamaño de paralelismo de tensores de 8:

vllm serve deepseek-ai/DeepSeek-V4.1-Flash-1017 \
    --tensor-parallel-size 8 \
    --linear-backend humming --moe-backend humming

La --quantization humming opción está pensada únicamente como una ruta de compatibilidad para formatos que Humming admite pero que vLLM ya no admite o aún no admite de forma nativa, como GPTQ INT3. Por ejemplo, cargue un checkpoint de GPTQ INT3 a través de esta ruta de compatibilidad:

vllm serve hfl/Qwen2.5-VL-3B-Instruct-GPTQ-Int3 --quantization humming

Selección de tipos de activación

Por defecto, Humming utiliza el tipo de activación especificado en el checkpoint y adapta la ejecución al dispositivo. Si la GPU no admite ese tipo de cómputo, Humming recurre a un tipo de mayor precisión compatible. Por ejemplo, los dispositivos sin soporte nativo de MXFP4 pueden usar automáticamente rutas de cómputo FP8, BF16 o FP16, lo que permite que el mismo checkpoint cuantizado se ejecute en distintas generaciones de GPU.

Los usuarios pueden anular el valor predeterminado a través de la interfaz de configuración de cuantización de vLLM para seleccionar un tipo de activación para su despliegue. El siguiente ejemplo establece el tipo de activación para las capas MoE en MXFP8:

vllm serve openai/gpt-oss-20b --moe-backend humming --quantization-config.moe.activation mxfp8

Planes futuros

Soporte de dispositivos más amplio y profundo

Humming seguirá ampliando la cobertura de hardware mientras se adapta a las capacidades de cómputo y memoria de los nuevos dispositivos, ayudando a que más plataformas realicen el potencial de rendimiento de la inferencia cuantizada. Las prioridades incluyen:

• Dar soporte a más características de la arquitectura Rubin, incluidos los Locality Domains, para optimizar aún más el mapeo de tareas y el acceso a datos.
• Ampliar el soporte a más dispositivos T-Head PPU, incluido el Zhenwu M890.
• Dar soporte a más dispositivos compatibles con la programación CUDA, llevando los formatos de cuantización, los componentes de kernels y las capacidades de ajuste existentes a plataformas de hardware adicionales.

Añadir Autotune

Con un ajuste específico, Humming ya puede alcanzar un rendimiento de vanguardia en la mayoría de los escenarios. Sin embargo, la amplia variedad de formas de modelos, configuraciones de cuantización y recursos de dispositivos dificulta que las heurísticas seleccionen la configuración óptima en todos los casos.

Por lo tanto, Humming planea introducir autotune, evaluando configuraciones candidatas en el dispositivo de destino para encontrar mejores parámetros de ejecución para cada carga de trabajo. Autotune complementará las heurísticas existentes, reduciendo la búsqueda manual de configuraciones y ayudando a que más cargas de trabajo se acerquen al mejor rendimiento alcanzable de los kernels.

Integración más profunda con los frameworks de inferencia

Humming seguirá profundizando su integración con frameworks de inferencia como vLLM, ampliando el soporte en la carga de modelos cuantizados, la selección de backends, la inferencia paralela, la planificación en tiempo de ejecución y la adaptación de dispositivos. Nuestro objetivo es hacer que más métodos de cuantización funcionen con toda la gama de capacidades del framework, incluidas optimizaciones como la comunicación cuantizada All-to-All (A2A) para el paralelismo de expertos (EP). Estos esfuerzos harán que los kernels cuantizados de alto rendimiento sean más fáciles de usar en diversos escenarios de despliegue y ayudarán a traducir las ganancias de rendimiento de los kernels en beneficios de inferencia de extremo a extremo.

Agradecimientos

Agradecemos a Jinzhen Lin, Zekai Gu y Zhilin Huang de Ant Group, así como a Michael Goin, Roberto L. Castro, Chauncey Jiang y otros miembros de la comunidad de vLLM, por sus contribuciones y apoyo durante el desarrollo de Humming.

También agradecemos a la comunidad de vLLM por proporcionar recursos de desarrollo, pruebas e integración continua (CI) que hicieron posible validar y mejorar Humming en una amplia gama de hardware y cargas de trabajo.

El diseño y la optimización de Humming se inspiran en Marlin, vLLM Marlin, LMDeploy, DeepGEMM, FlashInfer, CUTLASS y otros proyectos de código abierto. Agradecemos a sus autores y colaboradores por compartir sus ideas e implementaciones, ayudando a avanzar en la inferencia cuantizada de alto rendimiento para toda la comunidad.