vLLM führt Humming ein: neue Quant-Kernel, im eigenen Produktivbild nachgesehen

Am 21. Oktober 2026 hat Ant Group gemeinsam mit der vLLM-Community Humming veröffentlicht, eine Kernel-Bibliothek für quantisierte Inferenz. Der Beitrag auf dem vLLM-Blog nennt ausdrücklich die Workstation-Linie SM120, zu der auch unsere RTX 5090 gehört. Wir haben deshalb zwei Dinge geprüft: was das Projekt selbst belegt, und was in unserem laufenden Produktivbild davon ankommt. Die Bibliothek steckt dort bereits, ohne dass wir sie bestellt hätten.

Humming ist eine Open-Source-Bibliothek (Apache-2.0) von Ant Group und der vLLM-Community. Sie erzeugt GPU-Kernel für Matrixmultiplikation mit quantisierten Gewichten erst zur Laufzeit per Just-in-Time-Kompilierung. Unterstützt werden NVIDIA-Karten ab Turing, ganzzahlige und Gleitkomma-Formate von INT1 bis FP8 sowie dichte und Mixture-of-Experts-Schichten. In vLLM ab 0.29.0 wählt man sie mit den Optionen --linear-backend und --moe-backend.

Stand vom 5. November 2026

Dieser Beitrag wurde am 5. November inhaltlich überarbeitet, deshalb steht ein updated-Datum im Kopf. Die Erstfassung vom 21. Oktober enthielt eine Durchsatztabelle (13,1 bis 33,4 Tokens pro Sekunde, "vLLM 0.29.1 gegen 0.33.0") mit Zuschreibung an den vLLM-Blog. Diese Zahlen finden wir in der heutigen Fassung der Blogseite nicht. Die dortige End-zu-End-Tabelle vergleicht zwei MoE-Backends mit anderen Werten; sie steht unten. Die Erstfassung nannte 0.33.0 außerdem eine unveröffentlichte Entwicklungsversion. Das ist überholt: vLLM 0.33.0 erschien am 2. November und pinnt humming-kernels==0.1.19. Weitere Korrekturen: Der Vorsprung von 19 und 9 Prozent gilt für SM121 (GB10, DGX Spark), nicht für die RTX-5090-Linie SM120. Drei Aussagen ohne Beleg (eine Konfigurationszahl, eine Windows-Pipeline, eine Hacker-News-Diskussion) haben wir gestrichen.

Was das Projekt belegt, und was nicht

Alle Messungen stammen vom Projekt, also von dem Team, das die Bibliothek bewirbt. Unabhängige Nachmessungen haben wir nicht gefunden.

Einheit: Ausgabe-Tokens pro Sekunde und Millisekunden. Messdatum: Veröffentlichung am 21.10.2026. Messträger: acht H20-Karten, DeepSeek-V4.1-Flash, Tensor-Parallelität 8. Herstellerzahlen, von uns nicht nachgemessen.

Drei Einschränkungen gehören dazu. Erstens läuft die Tabelle auf Rechenzentrumskarten ohne Blackwell, mit einem Modell, das wir nicht betreiben. Zweitens ist der Vorsprung bei vielen gleichzeitigen Anfragen am größten: Eine einzelne Anfrage gewinnt 14 Prozent, bei 64 gleichzeitigen sind es 43. Wer einen persönlichen Assistenten auf einer Karte betreibt, liegt eher bei der ersten Zeile, wer eine Firma bedient, eher bei der letzten. Drittens vergleicht die Tabelle zwei Backends für dieselben Gewichte und sagt nichts über ein anderes Quantformat.

Für die Linien SM120 und SM121 steht im Beitrag: Humming liegt bei MoE-Schichten mit W4A8 (MXFP4 × MXFP8) und W4A4 (NVFP4 × NVFP4) an den meisten gemessenen Punkten vor FlashInfer CUTLASS. Die genannten Spitzen von etwa 19 Prozent (W4A8) und 9 Prozent (W4A4) bei kleinen Stapeln gelten für SM121. Laut Diagrammbeschriftung ist das ein GB10 (DGX Spark); für SM120 wurde eine RTX PRO 6000 gemessen. Die Achse des SM120-Diagramms für W4A4 reicht nur von 0,99 bis 1,04, der Vorsprung liegt dort also im niedrigen einstelligen Prozentbereich. Die Diagramme sind Bilddateien, Zahlen daraus übernehmen wir nur, wo sie im Text stehen. Eine RTX 5090 ist in keinem Diagramm gemessen.

Zur Kompilierzeit: Auf einem H200-Server mit CUDA 13.4 braucht ein W4A16-Kernel laut Beitrag 1,82 Sekunden mit Humming gegen 23,35 Sekunden mit CUTLASS und NVCC, bei abgeschalteten Zwischenspeichern. Den Kernelsatz einer Schicht kompiliert Humming nach Angabe des Projekts in etwa 2 bis 4 Sekunden parallel zum Warmup. Der Beitrag nennt außerdem zwei bislang ungenutzte Blackwell-Formate (float4e0m3 und float8e3m4), die Humming anspricht. Rubin trägt sie nicht mit; wer darauf aufbaut, baut auf eine einzelne Kartengeneration.

Die Bibliothek ist jung. Die erste PyPI-Version stammt vom 13. Mai 2026. Am 5. November stand das GitHub-Repo bei 349 Sternen, und auf PyPI lag die Version 0.1.19 vom 30. Oktober. Fünf Punkte sind im Issue-Tracker offen. Der älteste (#31) meldet, dass der Indexed-StreamK-Pfad für MXFP4A8 über eine BF16-Ausgabe Genauigkeit verliert. Ein Punkt (#72) nennt für INT3 auf SM80 nur etwa 43 Prozent der Speicherbandbreite bei einer Anfrage, ein weiterer (#69) ein FP8-Modell, das bei Tensor-Parallelität 16 nicht lädt. Am 4. November kam #190 dazu: NVRTC lässt beim NVFP4-MoE-Kernel eine Reduktion fallen, NVCC behält sie. Ein Nutzungssignal außerhalb des Kernelsatzes liefert der vLLM-Blog vom 15. September: Novita AI stellt seinen Chord-Kernel für Kimi-K2.x-Modelle mit einem Humming-kompatiblen Indexed-Pfad vor.

Im eigenen Bild nachgesehen

Am Morgen des 21. Oktober 2026 haben wir nur lesend in unser laufendes Produktivbild geschaut und nichts verändert. Messträger ist der Host 192.168.180.3 mit vier RTX 5090, Container fn-port, Bild vllm-flashnext-hybrid:v032-nvfp4port.

Das sind eigene Messungen der Erstfassung, wir haben sie am 5. November nicht wiederholt. Die Herkunft der Bibliothek lässt sich öffentlich belegen. Wir haben am 5. November die Anforderungsdateien der vLLM-Tags gelesen:

Einheit: Versionspin in requirements/cuda.txt (Extra cu13). Messdatum: 5.11.2026. Quelle: die Dateien im vLLM-Repository, Veröffentlichungsdaten laut PyPI.

Für uns folgt daraus: Die Bibliothek ist seit 0.29.0 im Bild, rechnet aber an der Stelle, an der die Diagramme Gewinne zeigen, nicht mit. Die Expertenschichten laufen über das von uns fest gesetzte FlashInfer CUTLASS. In den linearen Schichten entscheidet auto; welcher Kernel dort gewinnt, wäre nur mit einem Messlauf nachweisbar und bleibt offen.

Was Betreiber daraus mitnehmen

Wer vLLM ab 0.29.0 mit CUDA betreibt, hat die Bibliothek bereits installiert. Wer Backend-Optionen wie wir von Hand gesetzt hat, sollte die Zeile --moe-backend prüfen, denn sie bestimmt, ob Humming für diesen Schichttyp überhaupt zur Wahl steht. Für Besitzer einer RTX-5090-Maschine bleibt der Rat, im Wartungsfenster dieselben Anfragen einmal mit dem bisherigen Backend und einmal mit Humming zu fahren und nur bei messbarem Vorteil bei gleichen Antworten umzustellen. So haben wir bereits zwei vLLM-Builds für Qwen3.8-Flash-Next verglichen; die Versionsfrage rund um 0.33.0 steht in vLLM 0.33.0 ohne CUDA 12.9. Weitere Beiträge zu Betrieb und Grenzen eigener Modelle sammelt das Thema KI im Betrieb. Wer wissen will, ob sich ein eigenes Sprachmodell im Haus lohnt, findet die Beratung zum Unternehmens-LLM.

Der Stand bei uns: Bibliothek installiert, Schalter vorhanden, Vorteil auf unserer Konfiguration ungemessen, MoE-Pfad bewusst anders verdrahtet. Der Durchsatzlauf gegen Humming steht aus. Ein Termin ist nicht beschlossen.

Weiterführende Quellen

• vLLM-Blog: Announcing Humming, 21.10.2026, Herstellerangabe mit allen Messtabellen und Diagrammen
• GitHub-Repo vllm-project/humming, Apache-2.0, Stand 5.11.2026: 349 Sterne
• Issue-Tracker von Humming, Stand 5.11.2026: fünf offene Issues
• humming-kernels auf PyPI, Versionsverlauf
• vLLM auf PyPI, Versions- und Veröffentlichungsdaten, und die Anforderungsdateien v0.29.0, v0.32.0 und v0.33.0