Ant Group et la communauté vLLM ont ouvert ensemble Humming, une bibliothèque de noyaux pour l'inférence quantifiée. Le code est hébergé dans l'organisation du projet vLLM et s'installe directement avec pip install humming-kernels. Depuis vLLM 0.29.0, le paquet d'installation de la version CUDA embarque déjà cette dépendance ; il suffit d'ajouter --linear-backend humming ou --moe-backend humming pour basculer.
Le billet de blog cite parmi les contributeurs d'Ant Jinzhen Lin, Zekai Gu et Zhilin Huang ; côté communauté figurent notamment Michael Goin, de Red Hat, et d'autres.
Une seule bibliothèque pour une longue liste de formats
Le vieux casse-tête de l'inférence quantifiée, c'est la multiplication des formats : des poids sur 4 bits avec des activations sur 16 bits demandent un jeu de noyaux, des activations sur 8 bits en demandent un autre, et FP4, MXFP4 et NVFP4 ont chacun leur propre écriture. L'approche de Humming consiste à séparer la « description de la quantification » de « l'exécution du noyau », puis à assembler les noyaux concrets à partir de composants partagés. Selon la formulation du texte d'origine : "separating quantization descriptions from execution choices".
La bibliothèque prend actuellement en charge les combinaisons WnA16, W8A8, W4A8 et W4A4, avec des types de données allant d'INT1 à INT8, de FP4 à FP8, ainsi que MXFP4, MXINT4 et NVFP4. Côté matériel, elle couvre toutes les architectures Nvidia postérieures à Turing, des H20 et H200 de Hopper à la B300 de Blackwell et à la SM120 grand public.
Quelques comparaisons sur la multiplication matricielle d'une seule couche (toutes mesurées par l'équipe du projet elle-même ; les conditions figurent dans les graphiques du texte d'origine) :
| Scénario | Comparé à | Accélération |
|---|---|---|
| W4A16 dense, petits lots | cuBLAS | environ 3 à 4 fois sur la plupart des appareils |
| W4A8-MXFP4, H200 | DeepGEMM W8A8 | environ 4,5 fois |
| MoE W4A16, B300, grands lots | Marlin | environ 5 fois |
Le test de bout en bout a utilisé DeepSeek-V4.1-Flash, 8 GPU H20, parallélisme tensoriel 8. En remplaçant la partie MoE de Marlin W4A16 par Humming W4A8, le débit de sortie a progressé d'environ 14 % à 43 % et la latence du premier token a baissé d'environ 25 % à 32 %, le gain augmentant avec la concurrence.
Ce que cela signifie pour les opérateurs en Chine
La plateforme de test du billet semble choisie pour coller à la réalité des clusters d'inférence chinois. La H20 est la carte de Nvidia conçue pour le marché chinois : la puissance de calcul y est réduite, la bande passante mémoire conservée, si bien que la quantification en faible nombre de bits est presque incontournable pour faire tourner de grands modèles. Le test de bout en bout s'appuie en outre sur le modèle MoE de DeepSeek, et de nombreuses équipes du pays disposent précisément de cette combinaison.
Autre détail : les appareils chinois compatibles CUDA. Le blog place le Zhenwu 810E de T-Head, la filiale puces d'Alibaba, dans sa liste de prise en charge, et la feuille de route prévoit d'adapter d'autres appareils PPU de T-Head, comme le Zhenwu M890. Ant et T-Head relèvent tous deux de l'écosystème Alibaba ; jusqu'où cette piste ira dépendra du rythme des fusions en amont.
Pour les équipes qui utilisent déjà vLLM, le coût de migration se situe surtout dans la validation : les formats que Humming sait lire directement évitent de requantifier le modèle ; ceux que vLLM ne gère pas nativement, comme GPTQ INT3, peuvent passer par la voie de compatibilité --quantization humming.
Les faiblesses clairement indiquées
Le blog énumère les limites sans détour. Les nouvelles instructions de la B300 ne prennent plus en charge le calcul INT8 : la multiplication matricielle INT8 doit passer par les anciennes instructions et affiche des performances nettement plus faibles ; la prochaine génération, Rubin, ne prend pas en charge les deux formats cachés de Tensor Core de Blackwell. La configuration des noyaux est pour l'instant choisie par des règles heuristiques, et les auteurs reconnaissent ne pas pouvoir atteindre l'optimum global ; le réglage automatique n'est pas terminé.
La vitesse de compilation est un autre argument. Sur une H200 avec le cache désactivé, un seul noyau W4A16 compilé avec Humming et NVRTC ne demande que 1,88 seconde ; lors du préchauffage d'un modèle, les noyaux couvrant toutes les tailles d'une couche sont compilés en 2 à 4 secondes environ. Pour les équipes qui changent souvent de modèle et de format pour expérimenter, c'est un gain de temps plus parlant que les chiffres de débit.
Sources : blog officiel de vLLM, dépôt GitHub de Humming, CocoLoop ; le débit, la latence et les durées de compilation s'entendent selon les conditions de test publiées par l'équipe du projet.