vLLM und Tencent Hunyuan streamen zwei HPC-Backends für NVIDIA-Hopper-GPUs upstream

Das Tencent-Hunyuan-AI-Infra-Team und das vLLM-Team haben gemeinsam zwei hochleistungsfähige Backends in das Mainstream-vLLM-Projekt upstream gestellt. Es handelt sich um den HPC_ATTN-Attention-Backend und den hpc-MoE-Backend, verfügbar als First-Class-Komponenten ohne Forken oder Modifizierung des vLLM-Kerns. Dieser Beitrag markiert eine der seltenen Instanzen, in denen ein Industrieteam produktionsreife Kernel-Optimierungen direkt in das offene Projekt upstream stellt, auf das es sich stützt, statt sie als internen Vorteil zu behalten.

Zwei neue HPC-Backends im vLLM-Ökosystem

Die Zusammenarbeit zwischen Tencents Network-Platform-Abteilung, dem Hunyuan-AI-Infra-Team und den vLLM/Inferact-Maintainern liefert Lösungen für zwei chronische Engpässe moderner LLM-Inferenz: dynamisches Lastenausgleich in der Decode-Phase und Overhead des FP8-MoE-Routings. Beide Backends sind über die Standard-Registrierungsmechanismen von vLLM integriert – PR #46020 für Attention und PR #45924 für MoE-Backend – was bedeutet, dass Benutzer das neue Backend über Konfigurationsparameter auswählen, ohne jegliche Kernmodifikationen.

Das Referenzmodell, auf dem die Backends validiert wurden, ist Hy3, Tencents Hunyuan-Modell mit 295 Milliarden Gesamtparametern und 21 Milliarden aktiven Parametern. Das Modell enthält 192 Experten mit Top-8-Routing, 64 Query- und 8 KV-Heads, Head-Dimension 128 sowie ein Kontextfenster von 256K Token. Die spekulative Dekodierungsschicht (MTP) fügt weitere 3,8 Milliarden Parameter hinzu.

Warum ist dynamisches Scheduling entscheidend für Attention?

Statische Split-KV-Zeitpläne setzen einheitliche Sequenzlängen innerhalb eines Batches voraus. In Produktionsumgebungen gilt das selten – eine Mischung kurzer und langer Anfragen erzeugt Leerlaufwarten auf Recheneinheiten, die ihre Arbeit abgeschlossen haben, während andere noch lange Sequenzen verarbeiten. Das Ergebnis sind verlorene GPU-Zyklen proportional zur Längenstreuung im Batch.

Der HPC_ATTN-Backend löst dieses Problem durch einen per-Step-lastausgeglichenen Decode-Scheduler, der 64-Token-Kacheln proportional zur tatsächlichen Länge jeder Sequenz im aktuellen Generierungsschritt auf Recheneinheiten verteilt. Ein fusionierter Prolog vereint RoPE-Rotation, QK-Norm-Normalisierung und KV-Write-Operation in einem einzigen Kernel-Durchlauf und eliminiert redundante Speicherlese- und Schreibvorgänge zwischen diesen Operationen.

Auf einem gemischten Workload aus einer Sequenz von 128K Token und 31 Sequenzen von 4K Token erzielt dynamisches Scheduling einen 2,95×-Speedup gegenüber dem statischen Äquivalent. Der durchschnittliche Vorteil gegenüber FlashInfer- und FlashAttention-Implementierungen beträgt 2,25× auf Mixed-Length-Decode-Batches. Der Backend unterstützt BF16- und FP8-Präzision.

FP8-MoE-Pipeline als einzelner Ausführungspfad

Standard-MoE-Inferenz durchläuft eine Reihe separater Kernel-Aufrufe: Routing, Gate-Up GEMM, Aktivierungsfunktion, Quantisierung, Down GEMM und Top-k-Reduktion. Jeder Übergang zwischen Kerneln bedeutet einen Hin- und Rückweg zum High Bandwidth Memory (HBM), was bei decode-dominanten Workloads – bei denen der Batch klein und die Latenz kritisch ist – zum dominanten Overhead wird, der die tatsächliche Rechengeschwindigkeit der Hardware maskiert.

Der hpc-Backend fusioniert diese gesamte Pipeline in einem einzigen Ausführungspfad unter Verwendung von Programmatic Dependent Launch (PDL). Routing-Tabellen werden im Shared Memory statt im HBM gespeichert, was das kostspielige Abrufen von Experten-Indizes zwischen Phasen eliminiert. Die Architektur ist FP8-only, konsistent mit den Hardware-Fähigkeiten der Hopper-Generation.

Gemessene Ergebnisse auf NVIDIA-H20-GPUs

End-to-End-Messungen wurden auf einer Konfiguration mit 8× H20 und dem Hy3-Modell durchgeführt. Die Time to First Token (TTFT) wurde um durchschnittlich 24% reduziert. Die Time Per Output Token (TPOT) verbesserte sich um durchschnittlich 17%, und bei der größten Batch-Größe von 64 wächst die Verbesserung auf 30%.

Der MoE-Backend erzielt 1,59× niedrigere Latenz als die beste Baseline-Lösung (Triton/CUTLASS) bei der Konfiguration TP8/EP1 und 1,21× bei TP1/EP8. Der Vorteil ist am ausgeprägtesten bei kleinen und mittelgroßen Batch-Größen, was typischen Produktions-Decode-Szenarien entspricht, in denen eine geringe Anzahl gleichzeitiger Anfragen mit minimaler Latenz bedient werden muss.

Fork-freie Integration und Hopper-Spezifität

Beide Backends sind ausschließlich für GPUs mit Hopper-Architektur bestimmt – H20 ist als optimale Plattform angegeben. Die Abhängigkeit von PDL-Mechanismen und Hopper-spezifischen Anweisungen bedeutet, dass eine Erweiterung auf ältere Architekturen nicht trivial ist und nicht angekündigt wurde.

Durch das Upstream-Stellen über den formalen PR-Prozess folgt das Tencent-Hunyuan-Team einem Beitragsmodell, das allen vLLM-Benutzern Zugang zu Optimierungen gibt, ohne Forks bei jedem neuen Upstream-Release verwalten zu müssen. Für Betreiber, die MoE-Inferenz auf Hopper-Clustern skalieren, ist dies eine direkt anwendbare Verbesserung, die über den Standard-vLLM-Upgrade-Zyklus zugänglich ist.