Ant Group und die vLLM-Community haben gemeinsam Humming veröffentlicht, eine Kernel-Bibliothek für quantisierte Inferenz. Der Code liegt unter dem Dach des vLLM-Projekts und lässt sich direkt per pip install humming-kernels installieren. Ab vLLM 0.29.0 bringt das CUDA-Installationspaket diese Abhängigkeit bereits mit; mit --linear-backend humming oder --moe-backend humming lässt sich umschalten.
Als Beitragende von Ant nennt der Blogbeitrag Jinzhen Lin, Zekai Gu und Zhilin Huang, auf Seiten der Community unter anderem Michael Goin von Red Hat.
Eine Bibliothek für eine lange Liste von Formaten
Das alte Problem der quantisierten Inferenz ist die Formatvielfalt: Gewichte mit 4 Bit und Aktivierungen mit 16 Bit brauchen einen Kernel-Satz, bei 8-Bit-Aktivierungen wird ein anderer fällig, und FP4, MXFP4 und NVFP4 haben jeweils ihre eigene Schreibweise. Humming trennt deshalb die Beschreibung der Quantisierung von der Art der Ausführung und setzt die konkreten Kernel aus gemeinsamen Bausteinen zusammen. Im Originalwortlaut heißt das "separating quantization descriptions from execution choices".
Unterstützt werden derzeit die Kombinationen WnA16, W8A8, W4A8 und W4A4, mit Datentypen von INT1 bis INT8 und von FP4 bis FP8 sowie MXFP4, MXINT4 und NVFP4. Bei der Hardware deckt die Bibliothek alle Nvidia-Architekturen ab Turing ab, von H20 und H200 (Hopper) bis zur B300 (Blackwell) und der Consumer-Variante SM120.
Einige Vergleiche für die Matrixmultiplikation einzelner Schichten (durchweg Eigenmessungen des Projektteams, Bedingungen siehe Diagramme im Originalbeitrag):
| Szenario | Vergleich mit | Beschleunigung |
|---|---|---|
| Dichtes W4A16, kleine Batches | cuBLAS | auf den meisten Geräten etwa das 3- bis 4-Fache |
| W4A8-MXFP4, H200 | DeepGEMM W8A8 | etwa das 4,5-Fache |
| MoE W4A16, B300, große Batches | Marlin | etwa das 5-Fache |
Der End-to-End-Test lief mit DeepSeek-V4.1-Flash auf 8 H20-GPUs bei Tensor-Parallelität 8. Wird der MoE-Teil von Marlin W4A16 auf Humming W4A8 umgestellt, steigt der Ausgabedurchsatz um rund 14 bis 43 Prozent, die Latenz bis zum ersten Token sinkt um etwa 25 bis 32 Prozent. Je höher die Parallelität, desto größer der Gewinn.
Was das für Betreiber in China bedeutet
Die Testplattform im Blogbeitrag wirkt, als wäre sie nach der Realität chinesischer Inferenz-Cluster ausgewählt worden. Die H20 ist Nvidias Spezialkarte für den chinesischen Markt: Die Rechenleistung ist beschnitten, die Speicherbandbreite blieb erhalten, sodass niedrige Bitbreiten bei der Inferenz großer Modelle praktisch Pflicht sind. Der End-to-End-Test nutzt zudem DeepSeeks eigenes MoE-Modell, und genau diese Kombination steht vielen Teams in China zur Verfügung.
Ein weiteres Detail betrifft CUDA-kompatible Hardware aus China: Der Blog führt den Zhenwu 810E von Alibabas Chipsparte T-Head in der Support-Liste auf, und die Roadmap nennt die Anpassung weiterer T-Head-PPU-Geräte, etwa des Zhenwu M890. Ant und T-Head gehören beide zum Alibaba-Umfeld; wie weit diese Linie getragen wird, hängt vom Tempo der Upstream-Integration ab.
Für Teams, die bereits vLLM einsetzen, liegt der Migrationsaufwand vor allem in der Validierung: Formate, die Humming direkt lesen kann, erfordern keine erneute Quantisierung des Modells; Formate, die vLLM nativ nicht unterstützt, etwa GPTQ INT3, lassen sich über den Kompatibilitätspfad --quantization humming betreiben.
Ausdrücklich genannte Schwächen
Der Blog listet die Einschränkungen offen auf. Die neuen Instruktionen der B300 unterstützen keine INT8-Berechnung mehr, INT8-Matrixmultiplikationen müssen daher über ältere Instruktionen laufen und fallen deutlich langsamer aus. Die nächste Generation Rubin unterstützt die beiden verborgenen Tensor-Core-Formate von Blackwell nicht. Die Kernel-Konfiguration wird derzeit über Heuristiken gewählt; die Autoren räumen ein, dass sich so kein globales Optimum finden lässt, und das automatische Tuning ist noch nicht fertig.
Die Kompilierzeit ist ein weiteres Verkaufsargument. Auf einer H200 mit deaktiviertem Cache braucht ein einzelner W4A16-Kernel mit Humming und NVRTC nur 1,88 Sekunden; beim Aufwärmen eines Modells sind die Kernel für alle Größen einer Schicht in etwa 2 bis 4 Sekunden kompiliert. Für Teams, die häufig Modelle und Formate wechseln und experimentieren, spart das mehr Zeit als jede Durchsatzzahl.
Quellen: offizieller vLLM-Blog, GitHub-Repository von Humming, CocoLoop; Durchsatz, Latenz und Kompilierzeiten beziehen sich auf die vom Projektteam veröffentlichten Messbedingungen.