vLLM Humming im Praxistest: Wann der Geschwindigkeitsvorteil trägt

vLLM Humming ist für quantisiertes MoE-Serving mit hoher Parallelität auf Hopper-Hardware ein vielversprechender Kandidat. Die öffentlich verfügbaren Benchmarks rechtfertigen aber nicht die Annahme, dass es sich um ein universell überlegenes Backend handelt. Die Ergebnisse auf H100 mit Group-32-Skalierung und beim Batch-1-Decoding auf Ampere zeigen vor allem eines: Modell, GPU, Format und Batch-Größe müssen im eigenen Setup getestet werden.

Die kurze Antwort: Humming ist ein Upgrade mit Bedingungen

Humming ist eine JIT-kompilierte GEMM-Kernel-Bibliothek für quantisierte Inferenz. Sie wurde von der vLLM-Community gemeinsam mit Ant Group veröffentlicht und zielt auf Dense- sowie Mixture-of-Experts-(MoE)-Workloads über mehrere Quantisierungsformate und NVIDIA-GPU-Generationen hinweg. Die offizielle Ankündigung nennt bis zu 5x schnellere Kernel und bei ausgewählten MoE-Szenarien 14%–43% mehr End-to-End-Leistung. Diese Werte gelten allerdings jeweils für ganz bestimmte Kombinationen aus Modell, Hardware, Format und Parallelität (vLLM-Ankündigung).

Meine Faustregel für die Einführung ist einfach:

• Humming zuerst testen bei großen Batches oder hoher Parallelität in W4A8-/W4A16-MoE-Setups auf unterstützter Hopper- oder neuerer Hardware.
• Keinen Geschwindigkeitsvorteil voraussetzen bei Batch-1-Decoding, älteren Ampere-GPUs oder ungewöhnlicher Group-wise-Skalierung.
• Ein Fallback bereithalten, denn aktuelle Issues berichten von fehlerhafter Shape-Auswahl und langsamen, backend-spezifischen Fallback-Pfaden.

Ein unabhängiger Bericht zu DeepSeek-V4.1-Flash kam auf einem einzelnen Vier-GH200-Knoten mit einem optimierten vLLM-Baseline-Setup auf 5.856 Output-Tokens/s, mit Data-Parallel-Attention auf 12.802 und mit modifizierten Humming-W4A8-Kerneln auf 17.634 (Engineering-Bericht). Dafür waren allerdings sowohl ein Kernel-Fix als auch Anpassungen am Tuning nötig. Das Ergebnis ist deshalb ein Beleg für eine bestimmte Workload-Klasse – kein Versprechen für eine unveränderte Standardinstallation.

Was Humming in einer vLLM-Bereitstellung verändert

Humming verlagert die quantisierte Matrixmultiplikation für Dense- und MoE-GEMM-Pfade in eine flexible JIT-Kernel-Schicht. Das Projekt richtet sich an NVIDIA-Architekturen ab Turing und unterstützt mehrere Low-Bit-Formate (Humming-Repository).

Im zitierten Hopper-Test dequantisierte Marlin die FP4-Gewichte nach BF16. Humming wandelte die FP4-Gewichte dagegen innerhalb des SM nach FP8 um und nutzte anschließend die FP8-Tensor-Cores für die Multiplikation. Dieser Unterschied zahlte sich erst aus, als der Decode-Workload durch die Rechenleistung und nicht mehr durch den Speicherzugriff begrenzt wurde. Speicherverkehr, Tiling der Shapes, Scale-Verarbeitung, Launch-Overhead und Registerdruck können das Ergebnis ebenso dominieren.

Wo der Geschwindigkeitsvorteil greift – und wo er verschwindet

Die öffentlichen Ergebnisse sollte man eher als Karte der Leistungsgrenzen lesen denn als eine einzelne, allgemeingültige Prozentzahl.

MoE mit hoher Parallelität: der überzeugendste Vorteil

Das offizielle DeepSeek-V4.1-Flash-Beispiel vergleicht Marlin W4A16 mit Humming W4A8 auf acht H20-GPUs und weist für den End-to-End-MoE-Durchsatz 14%–43% mehr Leistung aus. Der größere Vorteil zeigte sich bei höherer Parallelität. Ein Nutzer, der den Benchmark erneut veröffentlichte, nannte als konkreten Vergleich 442 gegenüber 634 Output-Tokens/s bei einer Parallelität von 64 und wies zugleich darauf hin, dass sich auch das Quantisierungsformat geändert hatte (Nutzerdiskussion).

Das spricht für Humming als vielversprechenden Serving-Pfad – nicht für einen reinen Kernel-Faktor bei identischem Format.

H100 mit Group-32-W4A8: ein ernstes Warnsignal

In Humming Issue #38 wurden MXFP4-Gewichte mit MXFP8-Aktivierungen und Group-32-Skalierung auf einer H100 getestet. Alle verglichenen Pfade lieferten numerisch korrekte Ergebnisse, doch der fusionierte Pfad war bei den gemeldeten Shapes deutlich langsamer. Für (4096,3072,4096) benötigte das fusionierte Humming 4.969 ms gegenüber 0.580 ms für die QDQ-Baseline. Bei (4096,14336,4096) waren es 22.298 ms gegenüber 1.256 ms (Issue #38).

Später dokumentierte das Issue ein lokales Tuning-Ergebnis von mehr als 500 TFLOPS. Eine experimentelle Implementierung kam mit zusätzlicher Vorverarbeitung und eigener Gewichtsspeicherung auf etwa 580–665 TFLOPS. Granularität der Skalierung, Tile-Auswahl, Registerdruck und Vorverarbeitung können das Ergebnis also grundlegend verändern.

SM80 und Single-Request-Decoding: Ampere-Vorteile nicht voraussetzen

Issue #72 berichtet von einer schwachen INT3-Auslastung auf NVIDIA SM80 beim M=1-Decoding. Auf einer CMP 170HX erreichte der gemessene Humming-Kernel etwa 691 GB/s bei rund 1.591 GB/s maximaler HBM-Bandbreite – eine Auslastung von 43,4 %. Ein vergleichbarer Lauf auf einer RTX 5070 Ti mit SM120 kam auf etwa 753 GB/s bei 827 GB/s Spitze, also rund 91 % Auslastung (Issue #72).

Im selben Bericht werden außerdem Repository-Ergebnisse für die A800 genannt: 692,4 GB/s bei M=1, also nur 34,0 % der angegebenen Spitzenbandbreite von 2.039,04 GB/s. BF16 ohne Quantisierung erreichte in diesem Vergleich 1.232,3 GB/s.

„Könnte der aktuelle SM80-INT3-Pfad von Humming für diesen Workload suboptimal sein?“ – yangfangyunyun, vLLM-Humming-Issue #72

Installation und der sicherste erste Test

Die offiziellen Unterlagen nennen vLLM 0.29.0 als Version, ab der CUDA-Installationen Humming als Abhängigkeit enthalten. Für den MoE-Pfad verwenden Sie --moe-backend humming, für unterstützte lineare Layer --linear-backend humming oder die dokumentierte Humming-Quantisierungskonfiguration für einen modellspezifischen Pfad (vLLM-Quantisierungsdokumentation). Prüfen Sie vor dem Übernehmen eines Flags zwischen verschiedenen Architekturen die Release- und Modelldokumentation.

Beginnen Sie mit einem kontrollierten Vergleich:

1. Dokumentieren Sie vLLM, CUDA, PyTorch, GPU-Architektur, Checkpoint-Quantisierung und Modell-Shape.
2. Halten Sie Prompt-Länge, Ausgabelänge, Parallelität und Anzahl der Wiederholungen konstant.
3. Vergleichen Sie das bestehende Backend mit Humming und verwenden Sie denselben Serving-Befehl plus das jeweils relevante Backend-Flag.
4. Messen Sie Output-Tokens/s, TTFT, Inter-Token-Latenz, GPU-Speicher sowie Start- und JIT-Aufwärmzeit.
5. Wiederholen Sie den Test bei warmem Kernel-Cache und prüfen Sie anschließend Batch 1 sowie die in Produktion erwartete Parallelität.
6. Halten Sie für nicht unterstützte Shapes und fehlgeschlagene Backend-Auswahl einen automatischen oder manuellen Fallback bereit.

Mehr Durchsatz allein reicht nicht aus, wenn TTFT, Tail-Latenz, Aufwärmkosten oder Speicherverbrauch schlechter werden. Das vLLM-Projekt perf-eval empfiehlt YAML-Rezepte, wiederholte Läufe, die Aggregation des Medians sowie feste Eingabe- und Ausgabelängen für vergleichbare Tests (perf-eval-Repository).

Backend-Routing kann eine gültige Humming-Konfiguration blockieren

Ein separates vLLM-Issue zeigt, warum Tests mit Fallback unverzichtbar sind. In Issue #60700 hatte ein W4A8-MoE-Checkpoint aus compressed-tensors eine Zwischendimension von 640. CUTLASS verlangte Dimensionen mit 256er-Ausrichtung, während Humming die getestete Shape verarbeiten konnte. Allerdings wurde eine uneingeschränkte Assertion ausgeführt, bevor das ausgewählte Backend geladen wurde. Selbst das explizite --moe-backend humming schlug deshalb fehl.

Der Patch des Melders beschränkte die Assertion auf CUTLASS. Danach wurden alle 62 Shards auf zwei H100-NVL-GPUs geladen. Im Test lagen TTFT und Systemdurchsatz gegenüber dem verwendeten CUTLASS-Referenzsetup um 12%–50% beziehungsweise 2%–13% besser (Issue #60700). Zum Prüfzeitpunkt war das Issue noch offen; PR #60711 war als Lösung für das Routing vorgeschlagen.

Ein fehlgeschlagener Humming-Start kann daher auf ein Problem bei der vLLM-Fähigkeitsprüfung und nicht auf ein Kernel-Problem hindeuten. Prüfen Sie das ausgewählte Backend, die Shape-Einschränkungen und den Status des entsprechenden Fixes, bevor Sie die Konfiguration verwerfen.

Entscheidungstabelle für den Betrieb

FAQ

Welche GPUs unterstützt Humming?

Das Projekt zielt auf NVIDIA-GPUs ab Turing und dokumentiert mehrere Quantisierungspfade. Unterstützung bedeutet jedoch nicht, dass jedes Format und jeder Workload gleich gut abgestimmt ist. Für SM80 und ungewöhnliche Skalierungsvarianten ist ein eigener Benchmark erforderlich.

Benötigt Humming einen vorquantisierten Checkpoint?

Humming ist eine Inferenz-Kernel-Bibliothek und kein universeller Quantisierer. Die genannten Workflows verwenden Checkpoints mit kompatiblen quantisierten Gewichten und Aktivierungsschemata. Prüfen Sie deshalb vor dem Serving das Format des Modells in der vLLM-Dokumentation und im Repository.

Ist Humming schneller als jedes andere vLLM-Backend?

Nein. Humming ist bei ausgewählten quantisierten Workloads schneller, insbesondere bei den genannten MoE-Szenarien mit hoher Parallelität. Die Ergebnisse hängen von Architektur, Format, Dimensionen, Gruppierung der Skalierungsfaktoren und Batch-Größe ab.

Das praktische Fazit ist eindeutig: Humming kann einen passend konfigurierten quantisierten vLLM-Service spürbar beschleunigen. Ein kurzer, reproduzierbarer Bake-off gehört aber zur Einführung dazu, weil die öffentlich dokumentierten Ergebnisse stark von der jeweiligen Konfiguration abhängen.