AIREITERPour servir des modèles MoE quantifiés avec un haut niveau de concurrence sur du matériel de classe Hopper, vLLM Humming mérite clairement d’être testé. En revanche, les benchmarks publics ne permettent pas de le considérer comme une mise à niveau universelle du backend. Les résultats obtenus sur H100 en group-32 comme ceux observés en décodage batch 1 sur des GPU Ampere montrent une chose : il faut valider chaque combinaison de modèle, de GPU, de format et de taille de batch.
En bref : Humming est une optimisation à valider au cas par cas
Humming est une bibliothèque de kernels GEMM compilés à la volée (JIT) pour l’inférence quantifiée, publiée par la communauté vLLM avec Ant Group. Elle vise les workloads denses et mixture-of-experts (MoE), sur plusieurs formats de quantification et générations de GPU NVIDIA. L’annonce officielle évoque jusqu’à 5x d’accélération pour les kernels et des gains de 14 % à 43 % sur certains workloads MoE de bout en bout. Ces chiffres correspondent toutefois à des combinaisons précises de modèles, de matériel, de formats et de niveaux de concurrence (annonce de vLLM).
Ma règle pour décider d’une adoption est simple :
- Tester Humming en priorité pour les déploiements MoE W4A8/W4A16 à gros batch ou forte concurrence, sur des configurations Hopper ou plus récentes compatibles.
- Ne pas partir du principe qu’il sera plus rapide en décodage batch 1, sur les anciens GPU Ampere ou avec des mises à l’échelle par groupes atypiques.
- Prévoir un fallback, car les issues actuelles mentionnent des bugs de routage selon les formes et des chemins d’exécution lents propres à certains backends.
Un rapport indépendant consacré à DeepSeek-V4.1-Flash atteint 5 856 tokens générés/s avec un vLLM de référence optimisé, 12 802 avec l’attention en data parallelism, puis 17 634 avec des kernels Humming W4A8 modifiés, sur un seul nœud équipé de quatre GH200 (rapport technique). Ce résultat a nécessité un correctif de kernel et un ajustement du tuning : il valide donc une catégorie de workloads, pas une promesse de performance immédiate après installation.
Ce que Humming change dans un déploiement vLLM
Humming déporte les multiplications matricielles quantifiées vers une couche de kernels JIT flexible, utilisée pour les chemins GEMM denses et MoE. Le projet cible les architectures NVIDIA à partir de Turing, ainsi que plusieurs formats basse précision (dépôt Humming).
Dans le test Hopper cité, Marlin déquantifiait les poids FP4 en BF16, tandis que Humming convertissait les poids FP4 en FP8 directement dans le SM avant d’utiliser la multiplication par tenseurs FP8. Cette différence n’a porté ses fruits qu’une fois le workload de décodage limité par le calcul. Le trafic mémoire, le découpage des formes en tuiles, la gestion des échelles, le coût des lancements de kernels et la pression sur les registres peuvent prendre le dessus.
Quand l’accélération est réelle — et quand elle disparaît
Les résultats publics doivent être lus comme une cartographie des limites de performance, plutôt que comme un pourcentage d’accélération universel.
MoE à forte concurrence : le cas le plus convaincant
L’exemple officiel consacré à DeepSeek-V4.1-Flash compare Marlin W4A16 à Humming W4A8 sur huit GPU H20 et annonce un débit MoE de bout en bout supérieur de 14 % à 43 %, avec le gain le plus important aux niveaux de concurrence élevés. Un utilisateur ayant relayé le benchmark donne une comparaison concrète de 442 à 634 tokens générés/s à une concurrence de 64, tout en précisant que le format de quantification changeait également (discussion utilisateur).
Ce résultat fait de Humming une piste de serving très prometteuse, mais pas un simple multiplicateur de performance à format strictement identique.
W4A8 group-32 sur H100 : un sérieux signal d’alerte
L’issue #38 de Humming a testé des poids MXFP4 avec des activations MXFP8 et des échelles group-32 sur un H100. Tous les chemins comparés produisaient des résultats numériques corrects, mais le chemin fusionné s’est révélé nettement plus lent avec les formes testées. Pour (4096,3072,4096), Humming fused prenait 4.969 ms contre 0.580 ms pour le baseline QDQ ; pour (4096,14336,4096), il fallait 22.298 ms contre 1.256 ms (issue #38).
L’issue fait ensuite état d’un tuning local dépassant 500 TFLOPS, tandis qu’une implémentation expérimentale atteignait environ 580–665 TFLOPS avec un prétraitement supplémentaire et un stockage spécifique des poids. La granularité des échelles, le choix des tuiles, la pression sur les registres et le prétraitement peuvent donc complètement inverser le résultat.
Décodage mono-requête sur SM80 : ne déduisez pas de gain sur Ampere
L’issue #72 signale une faible utilisation des unités INT3 sur NVIDIA SM80 pour un décodage avec M=1. Sur un CMP 170HX, le kernel Humming mesuré atteignait environ 691 Go/s, contre près de 1 591 Go/s de bande passante HBM théorique maximale, soit 43,4 % d’utilisation. Sur une RTX 5070 Ti en SM120, une exécution comparable atteignait environ 753 Go/s pour un maximum de 827 Go/s, soit environ 91 % d’utilisation (issue #72).
Le même rapport cite des résultats du dépôt sur A800 de 692,4 Go/s à M=1, soit seulement 34,0 % des 2 039,04 Go/s théoriques annoncés. Dans cette comparaison, le BF16 classique atteignait 1 232,3 Go/s.
« Le chemin Humming INT3 actuel sur SM80 pourrait-il être sous-optimal pour ce workload ? » —
yangfangyunyun, issue #72 de vLLM Humming
Installation et premier test sans risque
La documentation officielle indique que vLLM 0.29.0 est la version à partir de laquelle les installations CUDA incluent Humming comme dépendance. Utilisez --moe-backend humming pour le chemin MoE, --linear-backend humming pour les couches linéaires compatibles, ou la configuration de quantification Humming documentée pour un chemin propre à un modèle (documentation de quantification vLLM). Avant de reprendre une option d’une architecture à l’autre, vérifiez la documentation de la version et du modèle concernés.
Commencez par un test contrôlé :
- Notez les versions de vLLM, CUDA et PyTorch, l’architecture du GPU, la quantification du checkpoint et la forme du modèle.
- Gardez constants la longueur du prompt, la longueur de sortie, la concurrence et le nombre de répétitions.
- Comparez le backend existant à Humming avec la même commande de serving, en ajoutant uniquement l’option de backend pertinente.
- Mesurez les tokens générés/s, le TTFT, la latence inter-tokens, la mémoire GPU et le temps de démarrage/échauffement JIT.
- Répétez le test une fois le cache des kernels échauffé, puis mesurez séparément le batch 1 et la concurrence de production.
- Conservez un fallback automatique ou manuel pour les formes non prises en charge et les échecs de sélection.
Un meilleur débit ne suffit pas si le TTFT, la latence de queue, le coût d’échauffement ou la consommation mémoire se dégradent. Le projet perf-eval de vLLM recommande des recettes YAML, des exécutions répétées, une agrégation par médiane et des longueurs d’entrée/sortie fixes pour obtenir des comparaisons fiables (dépôt perf-eval).
Le routage du backend peut empêcher une configuration Humming pourtant valide
Une autre issue de vLLM montre pourquoi les tests de fallback sont indispensables. Dans l’issue #60700, un checkpoint MoE W4A8 en compressed-tensors possédait une dimension intermédiaire de 640. CUTLASS exigeait des dimensions alignées sur 256, alors que Humming pouvait gérer la forme testée. Pourtant, une assertion inconditionnelle s’exécutait avant le chargement du backend sélectionné. Même l’option explicite --moe-backend humming échouait donc.
Le patch proposé par l’auteur de l’issue limitait cette assertion à CUTLASS. Après cette modification, les 62 shards se chargeaient sur deux GPU H100 NVL, et le test indiquait un TTFT inférieur de 12 % à 50 % ainsi qu’un débit système supérieur de 2 % à 13 % par rapport à sa configuration CUTLASS de référence (issue #60700). Lors de la vérification, l’issue était toujours ouverte et la PR #60711 était proposée comme correctif du routage.
Un lancement Humming qui échoue peut donc révéler un problème de vérification des capacités dans vLLM plutôt qu’un problème de kernel. Avant d’abandonner la configuration, vérifiez le backend sélectionné, les restrictions liées aux formes et l’état du correctif.
Tableau de décision pour les opérateurs
| Votre workload | Décision concernant Humming | Pourquoi |
|---|---|---|
| MoE à forte concurrence sur Hopper/GH200 | À tester rapidement | Un test indépendant a atteint 17 634 tok/s après des correctifs et du tuning. |
| Décodage de type DeepSeek avec de gros batchs | Candidat sérieux | L’exécution sur tenseurs FP8 peut aider lorsque les GEMM MoE sont limités par le calcul. |
| Décodage batch 1 ou faible batch sur SM80 | Ne pas présumer d’un gain | L’issue #72 rapporte une bande passante effective de 34 % à 43 % sur les chemins INT3 testés. |
| Mise à l’échelle des activations en group-32 sur H100 | Benchmark sur un ensemble restreint de formes | L’issue #38 montre de fortes régressions sur un chemin fusionné. |
| Formes MoE W4A8 non alignées sur 256 | Vérifier la version de vLLM et les correctifs de routage | Des assertions communes peuvent bloquer Humming avant le chargement des poids. |
| Production sans budget pour modifier le code source | À utiliser uniquement après un bake-off représentatif | Certains gains indépendants ont nécessité des changements de kernel ou d’heuristiques. |
FAQ
Quels GPU Humming prend-il en charge ?
Le projet cible les GPU NVIDIA à partir de Turing et documente plusieurs chemins de quantification. Cette compatibilité ne signifie pas que chaque format et chaque workload sont optimisés au même niveau ; les cas SM80 et les mises à l’échelle atypiques doivent faire l’objet de benchmarks dédiés.
Humming nécessite-t-il un checkpoint préquantifié ?
Humming est une bibliothèque de kernels d’inférence, pas un quantificateur généraliste. Les workflows cités utilisent des checkpoints contenant des poids quantifiés et des schémas d’activation compatibles. Vérifiez donc le format du modèle dans la documentation et le dépôt vLLM avant de le servir.
Humming est-il plus rapide que tous les autres backends vLLM ?
Non. Il accélère certains workloads quantifiés, en particulier les cas MoE à forte concurrence rapportés ici. Les résultats varient selon l’architecture, le format, les dimensions, le regroupement des échelles et la taille du batch.
Le compromis est limpide : Humming peut accélérer sensiblement un service vLLM quantifié qui lui correspond bien, mais un bake-off court et reproductible fait partie du processus d’adoption, car les résultats publics dépendent fortement de la configuration.