Annonce de Humming : des kernels rapides et flexibles pour l'inférence quantifiée

Ant Group et la communauté vLLM publient en open source Humming, une bibliothèque de kernels généraliste et performante pour l'inférence quantifiée. Humming offre les fonctionnalités suivantes :

• Large support de périphériques: prend en charge les architectures GPU NVIDIA depuis Turing, ainsi que les périphériques compatibles CUDA tels que le Zhenwu 810E de T-Head.
• Support étendu de la quantification: une architecture unifiée prend en charge diverses combinaisons de formats de poids et d'activations pour les charges de travail denses et MoE, couvrant un large éventail de types entiers et flottants, de largeurs en bits et de schémas de mise à l'échelle.
• Fortes performances d'exécution: surpasse significativement les implémentations existantes de vLLM Marlin, FlashInfer et DeepGEMM sur de nombreuses charges de travail représentatives.

Dépôt : github.com/vllm-project/humming

Contexte

À mesure que les modèles et les charges de travail d'inférence augmentent, la capacité mémoire, la bande passante mémoire et les coûts de calcul contraignent de plus en plus le déploiement. Cela est particulièrement visible dans les modèles MoE : chaque token n'active qu'un sous-ensemble d'experts, mais l'ensemble complet des poids doit tout de même être stocké. DeepSeek-V3, par exemple, compte 671 milliards de paramètres, dont 37 milliards activés par token. La quantification réduit la précision des poids et des activations pour diminuer l'utilisation mémoire et le déplacement des données, et peut aussi améliorer l'efficacité du calcul.

Les exigences de quantification varient selon les modèles et les générations de GPU. Les configurations courantes incluent WNA16, W8A8, W4A8 et W4A4, où W et A spécifient les largeurs en bits des poids et des activations, et N désigne une largeur en bits de poids variable. À précision égale, des schémas tels que INT4 et NVFP4 diffèrent par leur format numérique et leur mise à l'échelle. La granularité de mise à l'échelle, la représentation des échelles, la taille de groupe et la quantification symétrique ou asymétrique élargissent encore l'espace de configuration.

Ces économies de stockage et de calcul ne se traduisent en une latence plus faible et un débit plus élevé qu'avec des kernels efficaces. Le prefill, le decode et les charges variables d'experts MoE imposent des exigences différentes en matière de calcul et de mémoire. Les kernels doivent s'adapter à ces charges de tout en maintenant de faibles surcoûts de conversion, de déquantification et d'ordonnancement.

Développer et intégrer un kernel dédié pour chaque combinaison crée une charge de maintenance croissante. Chaque ajout peut exiger son propre prétraitement des poids, sa sélection de kernel, ses adaptateurs de framework et ses tests. Les optimisations doivent ensuite être reportées sur plusieurs implémentations.

Humming résout ce problème en séparant les descriptions de quantification des choix d'exécution et en composant les kernels à partir de composants partagés.

Architecture généraliste

Le chemin d'exécution de Humming comporte trois parties : représenter le calcul quantifié, sélectionner les configurations pour le matériel et la charge de travail, et compiler un kernel à partir de composants CUDA.

Une représentation unifiée de la quantification

Les modèles exportés par différents outils de quantification varient par leur format numérique, l'organisation des paramètres et la disposition des poids. Humming convertit les formats d'exportation pris en charge vers le format standard Humming : une description de quantification commune avec des poids, des échelles, des points zéro et d'autres tenseurs organisés de manière cohérente.

Cette représentation préserve la sémantique de quantification de chaque schéma tout en décrivant le format des poids, la granularité de mise à l'échelle, le type de données des échelles, les points zéro et les échelles secondaires comme paramètres distincts. Les activations ont leur propre format numérique et leurs propres réglages de quantification. Ces paramètres peuvent être combinés sous réserve des contraintes de format et de matériel.

Par exemple, des poids INT4 par groupe peuvent être associés à des activations BF16. Les poids flottants basse précision avec différents schémas de mise à l'échelle utilisent le même système de paramètres. Cela offre aux frameworks d'inférence une interface commune pour les modèles de différentes sources.

Réglage et compilation JIT pour chaque charge de travail

Le format standard fournit une représentation commune entre les formats d'exportation. Le prétraitement valide ensuite les paramètres, complète les dimensions et réorganise ces tenseurs dans des dispositions adaptées au kernel cible. Humming combine la description de quantification avec la forme des poids, le type de GEMM, le GPU cible et les options de calcul pour configurer l'exécution.

Trois configurations décrivent le kernel :

• Layer Config décrit les formes des tenseurs, les types de données, les paramètres de quantification et l'architecture cible.
• Compute Config spécifie le type de GEMM et les options de calcul, telles que l'invariance par lot et la disposition des échelles d'entrée.
• Tuning Config sélectionne les formes de tuiles, le nombre d'étapes de pipeline, la spécialisation des warps, l'accès mémoire et les instructions MMA. Il contrôle également la concurrence et l'ordonnancement ; le TMA peut être configuré par tenseur.

Par défaut, Humming sélectionne les configurations de réglage à l'aide d'heuristiques propres à chaque appareil. Il peut préparer différentes configurations pour des plages de tailles d'entrée et distribuer vers le noyau approprié à l'exécution.

L'architecture unifiée de Humming facilite le réglage des paramètres d'exécution et la sélection des pipelines pour différentes charges de travail. À de petites tailles de lot, un pipeline multi-étapes utilisant des copies asynchrones (cp.async) et MMA peut surpasser un pipeline construit autour de TMA et UMMA. À de plus grandes tailles de lot, TMA et UMMA peuvent offrir un meilleur débit. Humming prend en charge les deux chemins d'exécution au sein d'un même cadre de configuration et de composants, lui permettant de sélectionner la stratégie la plus efficace pour chaque charge de travail.

Ensemble, les trois configurations spécialisent les noyaux compilés avec NVRTC ou NVCC. Les noyaux compilés sont mis en cache pour être réutilisés. L'inférence combine le noyau sélectionné avec les poids prétraités et les activations d'exécution.

Composants CUDA partagés entre les formats et les architectures

Au niveau CUDA, Humming organise l'ordonnancement des tâches, le déplacement des données, la déquantification et la mise à l'échelle, le calcul Tensor Core et le traitement de sortie en composants réutilisables. Il fournit des pipelines standard, spécialisés par warp et dédiés UMMA. Ces pipelines partagent des composants compatibles tout en utilisant le flux de données et la synchronisation requis par chaque stratégie d'exécution.

Chaque groupe de composants gère une source de variation différente :

• Le traitement numérique gère les formats de quantification. Les composants de décodage et d'arithmétique tiennent compte de la largeur en bits, de la représentation entière ou à virgule flottante, des échelles et des points zéro. La déquantification et la mise à l'échelle sont intégrées au calcul du kernel.
• Les backends mémoire et calcul gèrent les architectures GPU. Humming sélectionne les implémentations de déplacement de données et de Tensor Core pour l'architecture cible, en utilisant des copies asynchrones, TMA et multicast lorsque cela est pris en charge.
• Le mappage et l'ordonnancement des tâches gèrent les charges de travail denses et MoE. Chaque type de GEMM utilise la logique d'ordonnancement appropriée. La mise à l'échelle et l'ajout de biais peuvent également être fusionnés dans l'étape de sortie.

La compilation JIT combine ces composants selon les trois configurations et élimine les branches d'implémentation inutilisées. Un nouveau format ou une nouvelle architecture peut donc être pris en charge en étendant les composants concernés. Les améliorations apportées à un composant partagé bénéficient aux configurations compatibles, réduisant le développement et la maintenance dupliqués de kernels spécialisés séparés.

Cette implémentation CUDA est légère et évite les dépendances à des frameworks de kernels lourds, tout en maintenant une compilation JIT rapide. Dans notre test de compilation d'un seul kernel W4A16 sur un serveur H200 avec CUDA 13.4, le temps de compilation est passé de 23,35 secondes pour CUTLASS avec NVCC à 1,82 seconde pour Humming avec NVCC ou 1,88 seconde avec NVRTC, les caches de compilation étant désactivés. Cela réduit le coût de préparation des kernels pour de nouvelles charges de travail et rend le réglage itératif plus pratique. Humming compile également les kernels en parallèle pendant l'échauffement du modèle. Dans nos tests, la compilation et le chargement des kernels couvrant toutes les tailles M prises en charge pour le GEMM d'une seule couche ne prennent que environ 2 à 4 secondes, ce qui rend pratique la préparation de plusieurs kernels spécialisés avant l'inférence.

Réglage des performances basé sur les paramètres du périphérique

Humming optimise profondément les kernels en utilisant à la fois la configuration GEMM et les paramètres du périphérique. Les formats de quantification, les formes de matrices, le support des instructions GPU, le nombre de SM, la mémoire partagée et les ressources de registres informent tous les choix d'exécution, transformant les avantages du stockage basse précision en performances d'inférence pratiques.

Inférence W4A8-MXFP4 efficace sur les GPU existants. Les architectures antérieures à Blackwell ne disposent pas de support natif MXFP4 Tensor Core, et les kernels W4A8-MXFP4 conventionnels peuvent être limités par la surcharge de déquantification et de mise à l'échelle aux grandes valeurs de M. Humming y répond avec un chemin de déquantification rapide MXFP4 vers INT8/FP8 qui convertit les poids MXFP4 dans un format de calcul pris en charge au sein du kernel. Dans ce contexte, ce chemin surpasse nettement les implémentations W4A8 conventionnelles aux petites valeurs de M et approche les performances W8A8 aux grandes valeurs de M. Des GPU tels que le H200 peuvent donc exécuter des kernels W4A8-MXFP4 haute performance tout en conservant les avantages de stockage des poids sur 4 bits.

Chemins de déquantification adaptés à chaque périphérique. Un même format de quantification peut bénéficier d'implémentations différentes selon les GPU. Humming sélectionne les chemins de décodage, de conversion numérique et de mise à l'échelle pour le périphérique, en les associant à des pipelines d'accès mémoire et de calcul appropriés afin de réduire la surcharge d'instructions et de déplacement de données. Les composants partagés rendent ces optimisations réutilisables dans les kernels denses et MoE compatibles.

Contrôles de réglage étendus avec heuristiques spécifiques au périphérique. Humming expose les formes de tuiles, le nombre d'étapes de pipeline, la spécialisation de warp, TMA, les instructions MMA, la concurrence CTA et l'ordonnancement Stream-K. Les heuristiques spécifiques au périphérique combinent les formes GEMM avec les contraintes de ressources pour équilibrer le parallélisme, la réutilisation des données et la surcharge du pipeline, en sélectionnant différentes stratégies d'exécution à mesure que la taille des entrées change. Les développeurs peuvent utiliser les configurations par défaut directement ou les affiner pour des modèles et des scénarios de déploiement particuliers.

Résultats

Large prise en charge des périphériques

L'architecture unifiée de Humming permet une large prise en charge des GPU. Pour les GPU NVIDIA, Humming prend entièrement en charge chaque architecture à partir de Turing, apportant un cadre de calcul quantifié commun à plusieurs générations de matériel.

L'architecture JIT unifiée facilite également l'extension de Humming à d'autres GPU compatibles avec la programmation CUDA. Humming prend déjà entièrement en charge le Zhenwu 810E de T-Head, apportant ses kernels partagés et ses capacités de réglage à davantage de plates-formes matérielles.

La figure ci-dessous montre les types d'activations haute performance pris en charge par Humming sur chaque périphérique : les types qui peuvent pleinement exploiter les capacités de calcul maximales du périphérique. Certains types omis de la figure peuvent néanmoins s'exécuter via d'autres chemins d'instructions. Par exemple, les instructions UMMA sur le B300 (SM103) ne prennent plus en charge le calcul INT8, mais les instructions MMA antérieures peuvent toujours exécuter un GEMM INT8, avec des performances nettement inférieures.

Prise en charge de la quantification

La prise en charge des types de quantization par Humming dépend principalement de la compatibilité entre les types d'activation et de poids. Sa représentation unifiée de la quantization et son architecture de kernels permettent à une large gamme de formats de poids entiers et à virgule flottante de fonctionner avec des activations à différentes précisions, offrant des choix flexibles pour la précision des modèles et les performances de déploiement.

La figure ci-dessous montre les combinaisons de types de poids et d'activations prises en charge par Humming. Les lignes représentent les types de poids, les colonnes représentent les types d'activation, et les coches indiquent les combinaisons prises en charge. Associée à la matrice de prise en charge des périphériques ci-dessus, elle décrit les chemins de calcul quantifié haute performance disponibles sur chaque architecture matérielle.

Humming prend également en charge un format à virgule flottante spécial sans bits d'exposant, dont les valeurs représentables correspondent à celles des entiers symétriques à la même largeur en bits. Par exemple, INT8 à l'exclusion de -128 et float8e0m7 représentent tous deux des entiers allant de -127 à 127. Les poids dans ce format ont la même compatibilité de type d'activation que les poids INT de la même largeur en bits. Humming convertit automatiquement les poids entiers symétriques éligibles vers ce format pour une déquantification plus rapide.

La communauté a également découvert deux capacités cachées des Tensor Cores Blackwell: le support natif de float4e0m3 et float8e3m4, deux formats à virgule flottante spéciaux qui ne sont pas exposés dans le système de types PTX. Humming prend en charge ces fonctionnalités sur toutes les architectures Blackwell, y compris les appareils datacenter SM100/SM103 et les appareils SM120/SM121 pour stations de travail et informatique personnelle. Les deux formats sont intégrés dans son cadre unifié de quantification et de calcul, offrant davantage d'options de calcul natif pour l'inférence en basse précision. Rubin ne prend pas en charge ces deux formats de Tensor Core cachés, de sorte que le support de ces chemins de calcul natif ne s'étend pas à Rubin.

Performances

Les microbenchmarks de kernels ci-dessous, exécutés par la communauté vLLM, mesurent les performances GEMM avec M couvrant chaque puissance de deux de 1 à 8192. Les kernels sont entièrement préchauffés et chronométrés indépendamment avec un cache L2 froid, avec une courte pause entre les échantillons. Les accélérations MoE utilisent la somme des latences GEMM Gateup et Down. Chaque figure identifie sa référence, ses formats de quantification, ses dimensions de matrice et ses versions logicielles.

WnA16

WnA16 est l'une des approches les plus polyvalentes et les plus utilisées pour l'inférence quantifiée. Elle combine des poids en basse précision avec des activations FP16/BF16, réduisant le stockage des poids et le trafic mémoire tout en exploitant les capacités de calcul 16 bits largement disponibles. Cela la rend adaptée à de nombreuses générations de GPU et à de nombreux scénarios de déploiement de modèles. La famille W4A16 a suscité un intérêt particulier de la communauté et constitue un axe majeur du travail d'optimisation de Humming.

Pour le W4A16 dense, Humming égale ou dépasse vLLM Marlin dans la plupart des configurations testées, avec des gains substantiels sur plusieurs charges de travail Hopper et Blackwell. La figure ci-dessous utilise cuBLAS comme référence commune. À petites tailles de lot, Humming offre des accélérations d'environ 3–4× sur plusieurs appareils. À mesure que la taille de lot augmente, il continue d'utiliser le matériel efficacement, atteignant environ deux fois les performances de Marlin sur les charges de travail H200 en grand lot et plus de trois fois ses performances dans certains cas B300.

Ces gains s'étendent au MoE. Humming fournit des chemins Indexed et Grouped efficaces pour les charges de travail où les tokens sont répartis entre les experts et où la quantité de travail par expert varie selon la charge. Dans la figure ci-dessous, MXFP4 W4A16 sur H20 et H200 atteint environ deux fois les performances de Marlin dans plusieurs cas de lots moyens à grands. Sur B300, les chemins MXINT4 et NVFP4 réalisent des gains encore plus importants en grandes tailles de lot, avec le chemin Grouped atteignant environ 5×. Les résultats sur SM120 et SM121 montrent également Humming surpassant Marlin et les implémentations FlashInfer correspondantes sur une gamme de charges de travail.

Les optimisations de Humming s'étendent également au-delà de W4A16 à d'autres combinaisons WnA16. Ses chemins partagés de déquantification et de calcul offrent de fortes performances pour des poids entiers et à virgule flottante de différentes largeurs en bits, notamment INT1, INT2, INT3 et FP4 à FP8. La figure suivante montre des gains étendus sur ces formats en petites et moyennes tailles de lot, avec les configurations aux bits les plus faibles sur SM120 dépassant 5× les performances de BF16 cuBLAS. En grandes tailles de lot sur H20, plusieurs largeurs en bits maintiennent une efficacité de calcul proche de BF16 cuBLAS. Cela offre aux modèles des choix plus fins entre précision, stockage et débit.

W8A8 / W4A8 / W4A4

Avec Hopper, le FP8 W8A8 avec mise à l'échelle par blocs est devenu une approche grand public pour l'inférence quantifiée haute performance. Humming améliore encore ce chemin de calcul établi en optimisant ensemble le déplacement des données, la mise à l'échelle et l'ordonnancement des experts. La colonne de gauche ci-dessous montre les résultats W8A8 sur H20 et H200. En petites et moyennes tailles de lot, Humming atteint environ 2.6× et 2.5× les performances de DeepGEMM Contiguous, respectivement, avec des performances compétitives des dispositions Indexed et Grouped.

À mesure que de plus en plus de modèles adoptent la quantification native des poids MXFP4, convertir la taille réduite des poids en gains d'inférence concrets devient de plus en plus précieux. Humming y répond avec un chemin W4A8 efficace qui déquantifie rapidement les poids MXFP4 au fur et à mesure de leur chargement et utilise les Tensor Cores FP8 pour le calcul, permettant une exécution W4A8-MXFP4 efficace sur Hopper. La colonne de droite ci-dessus conserve DeepGEMM W8A8 comme référence. En petites et moyennes tailles de lot, le W4A8 de Humming atteint environ 4.2× les performances de référence sur H20 et 4.5× sur H200, surpassant également substantiellement les résultats W8A8 de Humming dans la même figure. La réduction du trafic des poids se traduit par une latence GEMM plus faible. FlashInfer CUTLASS W4A8 est également une implémentation basée sur l'approche de Humming, tandis que l'implémentation actuelle de Humming obtient de meilleures performances dans les benchmarks présentés ici.

Blackwell ajoute un support natif des Tensor Cores pour les formats de microscaling tels que MXFP8 et MXFP4. Des appareils datacenter SM100/SM103 aux appareils SM120/SM121 pour stations de travail et informatique personnelle, Humming exploite les capacités de calcul basse précision de chaque architecture pour prendre en charge W8A8, W4A8 et W4A4 au sein d'un même kernel et cadre de réglage.

Sur B300 (SM103), Humming démontre des gains de performance substantiels pour les trois combinaisons de format MX. Chaque panneau ci-dessous utilise DeepGEMM Contiguous à la précision correspondante comme référence. Aux tailles de lot petites et moyennes, W8A8, W4A8 et W4A4 atteignent respectivement environ 1.25×, 1.6× et 1.4× la performance de référence, et surpassent les implémentations FlashInfer correspondantes sur de nombreuses charges de travail. Les chemins Indexed et Grouped bénéficient tous deux du calcul natif en basse précision, offrant des options efficaces pour différentes dispositions d'experts.

Ces gains s'étendent également au SM120 et au SM121. Dans les résultats ci-dessous, le W4A8 MXFP4 × MXFP8 et le W4A4 NVFP4 × NVFP4 de Humming surpassent FlashInfer CUTLASS sur la plupart des points testés. Sur SM121 à petites tailles de lot, les gains de performance atteignent environ 19% pour W4A8 et 9% pour W4A4 ; sur SM120, Humming est également en tête sur la plupart des tailles testées. L'architecture unifiée apporte ces optimisations d'inférence en basse précision à davantage de périphériques, étendant le calcul quantifié efficace au-delà du datacenter.

Performance d'inférence de bout en bout

Les gains en W4A8 de Humming s'étendent au service de modèles. Dans notre test de DeepSeek-V4.1-Flash sur huit GPU H20 avec TP=8, conserver les poids MXFP4 du modèle inchangés et passer l'exécution du MoE de Marlin W4A16 (activations BF16) à Humming W4A8 (activations FP8 tokenwise) améliore le débit de bout en bout d'environ 14%–43% et réduit le temps moyen jusqu'au premier token (TTFT) d'environ 25%–32%. L'avantage en débit augmente avec la concurrence : à une concurrence de 64, le débit de sortie passe de 442.37 à 633.94 tokens/s, tandis que le temps moyen par token de sortie (TPOT) diminue d'environ 31%.

Utilisation

Installation

Installez Humming avec pip :

pip install humming-kernels

Humming utilise un compilateur CUDA pour générer des noyaux à la demande. Si aucun compilateur CUDA n'est disponible sur le système, choisissez l'une des options d'installation suivantes pour inclure les dépendances de compilation correspondant à la version majeure de CUDA de votre environnement :

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

Humming lui-même est extrêmement léger, avec des dépendances simples et un paquet wheel d'environ 500 KB seulement. La compilation à la demande évite d'embarquer une grande collection de noyaux précompilés. En principe, tout environnement capable d'exécuter PyTorch 2.7 peut également exécuter Humming, ce qui facilite son intégration dans les environnements d'inférence existants.

Utiliser Humming dans vLLM

Humming est profondément intégré à vLLM. À partir de vLLM 0.29.0, les installations CUDA incluent Humming comme dépendance, donc aucune installation séparée de Humming n'est nécessaire. Humming prend en charge les GPU NVIDIA sur toutes les architectures à partir de Turing (SM75 et supérieur).

Les options --linear-backend et --moe-backend sélectionnent respectivement Humming comme backend de calcul pour les GEMM denses et les GEMM MoE. Par exemple, activez Humming pour les deux avec une taille de tenseur parallèle de 8 :

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

L' --quantization humming option n'est prévue que comme chemin de compatibilité pour les formats que Humming prend en charge mais que vLLM ne prend plus en charge ou ne prend pas encore en charge nativement, comme GPTQ INT3. Par exemple, chargez un checkpoint GPTQ INT3 via ce chemin de compatibilité :

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

Choix des types d'activation

Par défaut, Humming utilise le type d'activation spécifié dans le checkpoint et adapte l'exécution au périphérique. Si le GPU ne prend pas en charge ce type de calcul, Humming revient à un type de précision supérieure pris en charge. Par exemple, les périphériques sans prise en charge native de MXFP4 peuvent automatiquement utiliser des chemins de calcul FP8, BF16 ou FP16, permettant au même checkpoint quantifié de fonctionner sur plusieurs générations de GPU.

Les utilisateurs peuvent remplacer la valeur par défaut via l'interface de configuration de quantisation de vLLM afin de sélectionner un type d'activation pour leur déploiement. L'exemple suivant définit le type d'activation des couches MoE sur MXFP8 :

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

Plans futurs

Une prise en charge des périphériques plus large et plus approfondie

Humming continuera d'élargir la couverture matérielle tout en s'adaptant aux capacités de calcul et de mémoire des nouveaux périphériques, aidant ainsi davantage de plateformes à réaliser le potentiel de performance de l'inférence quantifiée. Les priorités comprennent :

• La prise en charge de davantage de fonctionnalités de l'architecture Rubin, y compris les Localité Domains (Locality Domains), pour optimiser davantage la répartition des tâches et l'accès aux données.
• L'extension de la prise en charge à davantage de périphériques T-Head PPU, y compris le Zhenwu M890.
• La prise en charge de davantage de périphériques compatibles avec la programmation CUDA, afin d'apporter les formats de quantisation, les composants de noyaux et les capacités d'optimisation existants à des plateformes matérielles supplémentaires.

Ajout d'Autotune

Grâce à un réglage ciblé, Humming peut déjà atteindre des performances de pointe dans la plupart des scénarios. Cependant, la grande variété de formes de modèles, de configurations de quantisation et de ressources des périphériques rend difficile le choix de la configuration optimale dans chaque cas par des heuristiques.

Humming prévoit donc d'introduire l'autotune, en évaluant par benchmark les configurations candidates sur le périphérique cible afin de trouver de meilleurs paramètres d'exécution pour chaque charge de travail. Autotune complétera les heuristiques existantes, réduisant la recherche manuelle de configuration et aidant davantage de charges de travail à approcher les meilleures performances réalisables des noyaux.

Une intégration plus poussée avec les frameworks d'inférence

Humming continuera d'approfondir son intégration avec les frameworks d'inférence tels que vLLM, en élargissant la prise en charge du chargement de modèles quantifiés, de la sélection de backend, de l'inférence parallèle, de l'ordonnancement à l'exécution et de l'adaptation aux périphériques. Nous visons à faire fonctionner davantage de méthodes de quantisation avec l'ensemble des fonctionnalités du framework, y compris des optimisations telles que la communication All-to-All (A2A) quantifiée pour le parallélisme d'experts (EP). Ces efforts rendront les noyaux de quantisation hautes performances plus faciles à utiliser dans divers scénarios de déploiement et aideront à traduire les gains de performance des noyaux en avantages d'inférence de bout en bout.

Remerciements

Nous remercions Jinzhen Lin, Zekai Gu et Zhilin Huang d'Ant Group, ainsi que Michael Goin, Roberto L. Castro, Chauncey Jiang et les autres membres de la communauté vLLM, pour leurs contributions et leur soutien tout au long du développement de Humming.

Nous remercions également la communauté vLLM pour la mise à disposition de ressources de développement, de test et de CI qui ont permis de valider et d'améliorer Humming sur une large gamme de matériels et de charges de travail.

La conception et l'optimisation de Humming s'inspirent de Marlin, vLLM Marlin, LMDeploy, DeepGEMM, FlashInfer, CUTLASS et d'autres projets open source. Nous sommes reconnaissants envers leurs auteurs et contributeurs d'avoir partagé leurs idées et leurs implémentations, contribuant à faire progresser l'inférence quantifiée hautes performances pour l'ensemble de la communauté.