Helion-Kernel in vLLM: PyTorch FP8 ohne CUDA

Helion ist eine PyTorch-native DSL zur Entwicklung von GPU-Kerneln ohne direkten CUDA-Code. Neun Helion-Kernel wurden in vLLM für die FP8-Inferenz von Qwen3-Modellen integriert: Nicht-GEMM-Kernel verzeichnen Beschleunigungen von bis zu 73 % auf H100, und der Gesamtdurchsatz steigt um rund 5–9 % im Vergleich zu bisherigen Lösungen.

Das PyTorch-Team hat heute in Zusammenarbeit mit Red Hat einen Blog-Beitrag veröffentlicht, der die Integration von neun Helion-Kerneln in vLLM für die FP8-Inferenz von Qwen3-Modellen beschreibt. Die Autoren sind Sean Chen von Red Hat und Yanan Cao von Meta Platforms (PyTorch-Team).

Was ist Helion und warum sollten Entwickler interessiert sein?

Helion ist eine domänenspezifische Sprache (DSL, engl. domain-specific language), die als „PyTorch mit Kacheln” beschrieben wird — sie ermöglicht das Schreiben hochleistungsfähiger GPU-Kernel mit PyTorchs Syntax, erweitert um Kachelungskonzepte (engl. tile-programming), ohne direkten CUDA-Code. Das Ziel ist Hardware-Portierbarkeit: Derselbe Kernel soll auf NVIDIA H100, B200 und zukünftigen Architekturen ohne manuelles Portieren laufen.

Helion bietet eine fortschrittliche Infrastruktur für Ahead-of-Time (AOT) Autotuning — automatische Suche nach optimalen Kachelgrößen und Speicherlayouts für jede Ziel-GPU-Architektur und Eingabedimension. Die Kernel-Entwicklung ist schnell: Die Autoren berichten, dass die meisten der neun Kernel innerhalb eines Arbeitstages implementiert und validiert wurden.

Welche Kernel wurden in vLLM integriert

Neun Kernel decken nahezu den gesamten Forward-Pass der FP8-Inferenz ab:

dynamic_per_token_scaled_fp8_quant
rms_norm_dynamic_per_token_quant
silu_and_mul_dynamic_per_token_quant — neuer Fusion-Kernel
fused_qk_norm_rope
per_token_group_fp8_quant
rms_norm_per_block_quant
silu_and_mul_per_block_quant
scaled_mm
scaled_mm_blockwise

Die Integration reduziert die Anzahl der Kernel-Aufrufe im Forward-Pass von 11+ auf 10 fusionierte Operationen für Per-Token-Quantisierung.

Leistung auf Kernel-Ebene

Nicht-GEMM-Kernel zeigen konsistente und signifikante Beschleunigungen auf H100 im Vergleich zu früheren Implementierungen (torch.ops._C):

rms_norm_per_block_quant: +67 % (2,055× vs. torch.ops._C)
silu_and_mul_per_block_quant: +73 % (2,269× vs. torch.ops._C)
rms_norm_dynamic_per_token_quant: 1,80× vs. torch.ops._C
fused_qk_norm_rope: 1,38× vs. torch.compile

GEMM-Kernel (scaled_mm) zeigen gemischte Ergebnisse: 1,08× auf H100, aber 0,739× auf B200. Die Autoren geben offen an, dass die Ursache eine Einschränkung der Triton-Codegenerierung für die Blackwell-Architektur ist, und dass ein CuteDSL-Backend in Entwicklung ist, das dieses Problem lösen soll.

Beschleunigung auf Modell-Ebene

Tests wurden an Qwen3-Modellen (1,7B, 8B und 32B Parameter) auf H100 und B200 durchgeführt:

Per-Token-Quantisierung (H100): ~1,05× Gesamtdurchsatz für Qwen3-1,7B
Spekulatives Dekodieren, Qwen3-8B, H100: bis zu 1,09× Gesamtdurchsatz (1,15× TTFT-Beschleunigung bei Batch-Größe 16)
Per-Group-Quantisierung (H100 und B200): ~1,05× bei allen Workloads

Für Qwen3-8B mit spekulativem Dekodieren und 3 spekulativen Token wurde eine 1,33× TTFT-Beschleunigung (engl. time to first token) gemessen.

Praktische Einschränkungen

Die Autoren sind transparent über Kompromisse. Das Autotuning großer Kernel wie scaled_mm erfordert rund einen Tag, um alle Eingabeformen abzudecken (168 unterschiedliche Dimensionen für drei Qwen3-Varianten). Helions Runtime-Dispatch führt einige Dutzend Mikrosekunden Latenz pro Kernel-Aufruf ein, daher ist CUDA-Graph-Capture obligatorisch, um optimale Leistung zu erzielen.

Helions Per-Group-Quantisierungs-Kernel sind noch nicht mit dem UE8M0-Format kompatibel, das DeepGEMM auf B200 benötigt — ein weiterer offener Punkt.

Ausblick

Das Projekt wurde als GitHub-Issue vllm-project/vllm#32962 mit Implementierung aller neun Kernel veröffentlicht. Das Ziel ist, die Helion-Unterstützung auf weitere Architekturen auszuweiten und die GEMM-Leistung auf Blackwell durch das CuteDSL-Backend zu lösen. Die Zusammenarbeit von Red Hat und Meta PyTorch-Team an diesem Problem ist ein Signal, dass das PyTorch-Ökosystem das Problem der Hardware-Portierbarkeit hochleistungsfähiger Inferenz-Kernel ernst nimmt.

Häufig gestellte Fragen

Was ist Helion und warum ist es für vLLM relevant?

Helion ist eine PyTorch-native domänenspezifische Sprache (DSL) zur Entwicklung hochleistungsfähiger GPU-Kernel mit Kachelungs-Modell (Tile-Programming), ohne direkten CUDA-Code zu schreiben. Für vLLM ist es relevant, weil es ermöglicht, portable Kernel zu schreiben, die auf mehreren GPU-Architekturen laufen, während hardware-spezifische Leistung erhalten bleibt.

Wie viele Helion-Kernel wurden in vLLM integriert und was sind die Ergebnisse?

Neun Kernel wurden in vLLM integriert. Nicht-GEMM-Kernel verzeichnen Beschleunigungen von 67–73 % auf H100 im Vergleich zu früheren Implementierungen (rms_norm_per_block_quant +67 %, silu_and_mul_per_block_quant +73 %). GEMM-Kernel zeigen 1,08× auf H100, aber 0,739× auf B200 aufgrund von Einschränkungen der Triton-Codegenerierung für die Blackwell-Architektur.

Welche Modelle wurden getestet und wie sind die End-to-End-Leistungswerte?

Getestet wurden Qwen3-Modelle (1,7B, 8B und 32B) auf NVIDIA H100 und B200. Der Gesamtdurchsatz steigt um rund 1,05× auf H100 für Per-Token-Quantisierung, und für spekulatives Dekodieren mit Qwen3-8B wird eine Beschleunigung von bis zu 1,09× erreicht.

Helion in vLLM: PyTorch-natives DSL ersetzt CUDA-Kernel und beschleunigt FP8-Inferenz von Qwen3-Modellen