vLLM: Push-basierter KV-Transfer senkt TTFT im AWS-Benchmark um bis zu das Dreifache

Warum der KV-Transfer bei disaggregierter Inferenz zählt

vLLM ist eine Open-Source-Engine für Inferenz und Serving großer Sprachmodelle. Die LLM-Inferenz besteht aus zwei Phasen: Prefill verarbeitet den Eingabe-Prompt und baut den Key-Value-Cache (KV-Cache) auf, Decode nutzt diesen Cache, um die Ausgabe Token für Token zu erzeugen. Da sich die Phasen in Rechenbedarf, Speicherverhalten und Skalierung unterscheiden, trennt die Prefill-Decode-Disaggregation (P-D) sie auf getrennte Engine-Instanzen, sodass sich jede für sich skalieren und optimieren lässt. Laut AWS kann das Ressourcennutzung, Durchsatz und Latenz unter Last verbessern.

Der Haken: Der KV-Cache muss von der Prefill- auf die Decode-Instanz wandern, bevor die Token-Generierung beginnen kann. Damit hängt die TTFT maßgeblich von der Effizienz dieses Transfers ab.

vLLM kann das über den Connector der NVIDIA Inference Xfer Library (NIXL) erledigen, der KV-Blöcke über RDMA-fähige Verbindungen wie den AWS Elastic Fabric Adapter (EFA) verschiebt. Auf unterstützten Instanztypen unterstützt EFA GPUDirect RDMA und Neuron Direct RDMA, sodass NIXL Blöcke direkt zwischen dem Speicher von GPUs oder AWS-Trainium-Geräten übertragen kann, ohne den Umweg über den Host-Speicher.

Wo der Pull-Modus bremst und was Push ändert

Der NIXL-Connector arbeitet standardmäßig im Pull-Modus. Nach Abschluss des Prefill leitet der Router Quellmetadaten, darunter die Prefill-Block-IDs, an die Decode-Instanz weiter. Diese reserviert dann Zielblöcke, bereitet den Transfer vor und setzt ein NIXL READ ab. Diese Schritte laufen nacheinander nach dem Prefill und vor dem Decoding ab und verlängern damit den Weg zum ersten Token.

Der Push-basierte Connector ändert die Reihenfolge der Arbeitsschritte. Die Decode-Instanz registriert ihre Zielblöcke vorab, während die Prefill-Instanz den KV-Cache noch berechnet. Der Transfer startet, sobald die Blöcke des Producers bereit sind, wodurch die Runde zur ID-Ermittlung auf Consumer-Seite entfällt. Auch die Transfervorbereitung wandert auf die Prefill-Seite und läuft in einem Hintergrund-Thread, sodass die Decode-Instanz während der Token-Generierung keine Rechenzyklen dafür aufwenden muss. Unterm Strich bedeutet das laut AWS eine niedrigere TTFT und einen höheren Durchsatz an Ausgabe-Token auf der Decode-Instanz.

Das Protokoll umfasst drei Schritte:

• Registrierung (Decode-Seite): Wenn für eine Anfrage mit Remote-Prefill Blöcke reserviert werden, schickt der Decode-Worker der Prefill-Instanz eine NIXL-Benachrichtigung, die beschreibt, wohin der KV-Cache zu schreiben ist.
• Rendezvous (Prefill-Seite): Registrierung und Prefill-Abschluss können in beliebiger Reihenfolge eintreffen. Was als Zweites eintrifft, löst den Transfer aus; Anfragen werden anhand ihrer ID zugeordnet, auch unterbrochene (preempted) oder wiederholte.
• Transfer (Prefill-Seite): Der Producer verbindet sich bei Bedarf mit der Decode-Instanz und setzt ein NIXL WRITE direkt in den registrierten Speicher des Decoders ab. Der Decoder betrachtet den KV-Cache als empfangen, sobald er pro Producer-Rank eine Abschlussmeldung gezählt hat.

Producer und Consumer können intern unterschiedliche Blocklayouts verwenden, die Blockgrößen dürfen daher auf beiden Seiten voneinander abweichen.

Threading-Modell und Routing-Kompromiss

Jeder Prefill-Worker nutzt einen eigenen Transfer-Thread im Hintergrund. Sobald sowohl die Zielregistrierung als auch der Prompt-KV-Cache bereit sind, übergibt die Hauptschleife des Prefill die Blöcke an diesen Thread und kehrt zur Modellausführung zurück. Der Thread baut die NIXL-Verbindung auf oder verwendet sie wieder, ordnet Block-IDs Speicherdeskriptoren zu, fasst zusammenhängende Blöcke zu größeren Transferbereichen zusammen und reicht das WRITE ein. Weil diese anfragebezogene Arbeit aus den latenzkritischen Schleifen herausgehalten wird, verzögert sie die Modellausführung nicht.

Beide Modi nutzen denselben NIXL- und EFA/RDMA-Datenpfad. Der Unterschied: Pull erledigt Metadatenweitergabe und Vorbereitung auf der Decode-Seite nach dem Prefill, während Push die Vorbereitung auf der Decode-Seite mit dem Prefill überlappt.

Dabei gibt es einen Kompromiss beim Routing. Pull erlaubt es dem Router, die Decode-Instanz erst nach Abschluss des Prefill auszuwählen, was mehr Spielraum für lastabhängiges Routing und Quality-of-Service-Steuerung lässt. Push wählt die Decode-Instanz früher, damit sich die Vorbereitung mit dem Prefill überlappen kann. Im Gegenzug kann die Prefill-Instanz bei vergleichbarer Last ihre KV-Blöcke früher freigeben.

Benchmark-Ergebnisse und was sie für vLLM-Nutzer bedeuten

AWS hat die Funktion mit Qwen3-32B in einem 1P1D-Setup auf Amazon-EC2-P5en-Instanzen getestet, die per EFA verbunden sind. Der Push-Modus lieferte eine um bis zu das Dreifache bessere TTFT und eine um bis zu 30 Prozent bessere TPOT als der Pull-Modus; die Ergebnisse hängen laut AWS von Workload und Konfiguration ab. Besonders bei hohen Anfrageraten helfe der Push-Modus, so AWS.

AWS hat die Funktion auf AWS-Trainium-Clustern mit EFA-Anbindung entwickelt und validiert und anschließend als beschleunigerunabhängiges Feature zu vLLM beigesteuert. Die Ergebnisse auf P5en-GPUs sollen zeigen, dass sich die Vorteile auf GPUs übertragen lassen.

Für Teams, die disaggregierte Prefill-/Decode-Inferenz mit vLLM betreiben, ist der Push-Modus eine Option, um die Reaktionsfähigkeit zu verbessern, vor allem unter hoher Last. Wer auf lastabhängiges Routing nach dem Prefill setzt, sollte das gegen die frühere Auswahl der Decode-Instanz abwägen, die Push erfordert.