Helion bringt automatisch abgestimmte GEMM-Kernel in vLLM und schlägt CUTLASS und DeepGEMM auf Hopper
Das PyTorch-Team hat Helion, seine Python-basierte Kernel-DSL, in das Linear-Backend von vLLM integriert. Laut dem Team übertrifft Helion auf NVIDIA-Hopper-GPUs in allen untersuchten Modellen die in vLLM standardmäßig genutzten Backends CUTLASS und DeepGEMM, bei manchen Workloads mit mehr als 10 % höherem Durchsatz.
- Das PyTorch-Team hat ein Helion-Linear-Backend in vLLM integriert, mit Fokus auf NVIDIA-Hopper-GPUs.
- Ein einziger Helion-GEMM deckt Standard, Split-K und Swap-AB ab, wobei Variante und Konfiguration per Autotuning für jede Eingabeform gewählt werden.
- Laut dem Team schlägt er die vLLM-Standard-Backends CUTLASS und DeepGEMM in allen untersuchten Modellen, bei manchen Workloads mit über 10 % mehr Durchsatz.
- Anvisierte Formate sind FP8_Dynamic, W8A8_INT8 und Block_FP8.
- Zu den Herausforderungen zählen stundenlanges Tuning, Kaltstart-Latenz, CPU-Overhead beim Kernel-Start und die Pflege der Konfigurationen.
Ein Kernel für mehrere GEMM-Varianten
Die Kernidee: Mehrere handgeschriebene Kernel werden durch einen einzigen automatisch abgestimmten ersetzt. Laut dem PyTorch-Beitrag kann eine einzige Helion-Implementierung der allgemeinen Matrixmultiplikation (GEMM) Standard-GEMM, Split-K und Swap-AB abdecken. Die beste Variante samt Konfiguration wird per Autotuning für jede Eingabeform automatisch ausgewählt.
Die beiden spezialisierten Varianten zielen auf bestimmte Eingabeformen. Split-K verteilt die K-Dimension auf mehrere Thread-Blöcke, um die Parallelität zu erhöhen, wenn die M- und/oder N-Dimension zu klein ist. Swap-AB schreibt A@B als ([email protected]).T um und verbessert so die Leistung bei Formen mit kleiner M-Dimension, weil sich günstigeres Tiling und eine bessere GPU-Auslastung ergeben.
Üblicherweise implementieren Kernel-Entwickler jede Variante einzeln, vergleichen sie per Benchmark mit dem Standard-GEMM und schreiben Heuristiken, die für eine gegebene Form die passende Variante auswählen. Wie der Beitrag festhält, leitet das aktuelle Block_FP8-Linear-Backend von vLLM auf Hopper an die Swap-AB-Variante weiter, wenn M < 32 ist. Solche Heuristiken seien aber nicht für jedes Modell oder jeden Workload optimal. Mit Helion werden die algorithmischen Entscheidungen zu einstellbaren Parametern. Im Beispiel-Kernel ist split_k auf Zweierpotenzen bis 256 beschränkt, und swap_ab ist ein boolescher Schalter.
Umfang: Hopper und quantisierte Formate
Die Arbeit konzentriert sich auf NVIDIA-Hopper-GPUs und nutzt das Triton-Backend von Helion. Da FP8 und INT8 auf Hopper die wichtigsten Quantisierungsformate für effiziente Inferenz sind, nimmt das Team drei quantisierte GEMM-Formate ins Visier:
- FP8_Dynamic: FP8 mit Skalierung pro Token bei den Aktivierungen und pro Kanal bei den Gewichten.
- W8A8_INT8: INT8 mit Skalierung pro Token bei den Aktivierungen und pro Kanal bei den Gewichten.
- Block_FP8: FP8 mit 1×128-Skalierung der Aktivierungen und 128×128-Skalierung der Gewichte.
Erste Ergebnisse mit dem CuteDSL-Backend von Helion zeigen nach Angaben des Teams konkurrenzfähige GEMM-Leistung auf NVIDIA-Blackwell-GPUs. Die Arbeit lasse sich auf Blackwell ausweiten, sobald dieses Backend ausgereift ist.
Laut dem Beitrag beruhen die Ergebnisse auf dem Tuning für jede Eingabeform in Kombination mit hybridem Dispatch und liefern durchgängig bessere End-to-End-Werte als die vLLM-Standardeinstellungen.
Warum Helion, und was es kostet
vLLM ist ein leistungsstarkes Framework für Inferenz und Serving großer Sprachmodelle. Für quantisierte Linear-Layer setzt es auf spezialisierte Backends, die Kernel aus Bibliotheken wie CUTLASS, DeepGEMM und FlashInfer einbinden. Helion ist eine PyTorch-native, hardwareunabhängige Kernel-DSL auf Basis eines Tile-Programmiermodells. Entwickler schreiben einen Kernel einmal in pythonartigem Code, und ein Ahead-of-Time-Autotuner (AOT) durchsucht einen breiten Suchraum, von Speicherlayout und Scheduling bis zu algorithmischen Entscheidungen, um die beste Konfiguration zu finden. Helion unterstützt zudem eine LLM-gestützte Suche, die das Tuning effizienter machen soll.
Der Beitrag argumentiert, Helion behandle das Tuning als strukturiertes numerisches Optimierungsproblem über einem klar definierten Suchraum. Das sei robuster und verlässlicher als offene agentische Ansätze, die Kernel immer wieder generieren, profilieren und verfeinern. Außerdem könnten Anwender Kernel für ihre eigenen Deployments ohne spezielles Kernel-Know-how und ohne großen Entwicklungsaufwand abstimmen.
Die Autoren sprechen die Herausforderungen offen an:
- Tuning-Dauer: Feingranulares Tuning kann weiterhin Stunden dauern.
- Startzeit: Die CUDA-Graph-Erfassung beim vLLM-Start löst die JIT-Kompilierung von Helion aus und verlängert die Kaltstart-Latenz. Das Zwischenspeichern kompilierter Artefakte kann dies bei Warmstarts weitgehend beseitigen.
- CPU-Overhead zur Laufzeit: Außerhalb der CUDA-Graph-Erfassung können Kernel-Dispatch und -Start zusätzlichen CPU-Overhead verursachen, der Tuning-Gewinne aufzehren kann. Helion wirkt unter CUDA Graphs am besten.
- Wartung: Vorab abgestimmte Konfigurationen für gängige Modelle mitzuliefern, belastet das Upstream-Projekt, denn große Konfigurationsdateien lassen sich nur schwer pflegen und per Unit-Tests und CI validieren.
Das Team sieht darin einen Zielkonflikt zwischen Leistung, Benutzerfreundlichkeit und Wartbarkeit, bei dem die Optimierung auf zwei Ziele oft zulasten des dritten geht.
Was das für vLLM-Nutzer bedeutet
Für Teams, die quantisierte Modelle auf Hopper-GPUs betreiben, zeigt die Arbeit einen Weg zu mehr Durchsatz, ohne mehrere getrennte GEMM-Kernel und Dispatch-Regeln pflegen zu müssen. Der Preis sind Tuning-Zeit und eine gewisse betriebliche Sorgfalt, etwa der Betrieb unter CUDA Graphs und das Caching kompilierter Artefakte. Wie viel ein konkretes Deployment profitiert, hängt von Modell und Workload ab, denn der berichtete Zuwachs von über 10 % gilt für einige, nicht für alle Workloads.
