vLLM: Push-basierte KV-Übertragung senkt Latenz bei disaggregierter Inferenz

Amazon Web Services hat einen push-basierten Key-Value-(KV)-Transfer-Mechanismus für die Open-Source-Inferenz-Engine vLLM vorgestellt. Dieses Update zielt auf disaggregierte Prefill-Decode-Architekturen ab, um die Zeit bis zum ersten Token (TTFT) erheblich zu verkürzen und den Durchsatz während der Token-Generierung zu verbessern. Die Funktion wurde auf Amazon EC2 P5en-Instanzen unter Verwendung des Modells Qwen3-32B validiert.

Was ist passiert?

Die Inferenz großer Sprachmodelle besteht aus zwei unterschiedlichen Phasen: dem Prefill, der den Eingabe-Prompt verarbeitet, um den KV-Cache aufzubauen, und dem Decode, der Ausgabetokens unter Verwendung dieses Caches generiert. In disaggregierten Serving-Architekturen laufen diese Phasen auf separaten Engine-Instanzen, um unabhängiges Skalieren und Optimieren zu ermöglichen. Diese Trennung erfordert jedoch die Übertragung des KV-Caches von der Prefill-Instanz zur Decode-Instanz, bevor die Generierung beginnen kann. Daher ist die Effizienz dieser Übertragung entscheidend für die Gesamtlatenz.

Zuvor nutzte vLLM eine pull-basierte Methode über den NVIDIA Inference Xfer Library (NIXL)-Connector. In diesem Standardmodus wartet die Decode-Instanz, bis der Prefill abgeschlossen ist, empfängt Metadaten von einem Router, allokiert Speicher und ruft dann die Daten ab. Diese Schritte erfolgen sequenziell nach Abschluss des Prefills und fügen der kritischen Pfad-Latenz erhebliche Verzögerungen hinzu. Der neue push-basierte Connector ändert diesen Ablauf, indem er Koordinationsaufgaben mit der Prefill-Berechnung selbst überlappt.

AWS-Ingenieure haben diese Funktion auf Clustern entwickelt und getestet, die über AWS Elastic Fabric Adapter (EFA) verbunden sind, welcher Remote Direct Memory Access (RDMA) unterstützt. Obwohl sie ursprünglich für AWS Trainium-Instanzen konzipiert wurde, ist der Beitrag beschleunigerunabhängig und funktioniert auch mit GPUs. Benchmarks zeigen, dass der Push-Modus unter hoher Last die TTFT im Vergleich zum Pull-Modus um bis zu das Dreifache reduzieren kann, während die Zeit pro Ausgabetoken (TPOT) um etwa 30 Prozent verbessert wird.

Wie es funktioniert

Die push-basierte Architektur beseitigt Serialisierungsengpässe, indem sie der Decode-Instanz erlaubt, ihre Ziel-Speicherblöcke im Voraus zu registrieren. Anstatt zu warten, bis der Prefill abgeschlossen ist, bevor man sich auf den Dateneingang vorbereitet, sendet die Decode-Seite eine Registrierungsbenachrichtigung an die Prefill-Instanz, sobald lokale Blöcke allokiert werden. Das bedeutet, dass das Ziel bekannt ist, bevor die Quelldaten überhaupt bereitstehen.

Auf der Prefill-Seite kümmert sich ein dedizierter Hintergrund-Thread um die Vorbereitung der Übertragung. Sobald die Prefill-Berechnung abgeschlossen ist und die Registrierung vom Decoder eingeht, übergibt die Haupt-Engine-Schleife die KV-Blöcke an diesen Hintergrund-Thread. Der Thread stellt die NIXL-Verbindung her, ordnet die Block-IDs zu und initiiert eine NIXL WRITE-Operation, um die Daten direkt in den registrierten Speicher des Decoders zu kopieren. Dies hält die aufwendige Vorbereitung der Deskriptoren und die Übertragungsübermittlung von den latenzkritischen Hauptschleifen beider Instanzen fern.

Das System verwendet ein Rendezvous-Protokoll, um zeitliche Unterschiede zu handhaben. Wenn die Registrierung vor Abschluss des Prefills eingeht, hält der Producer sie zurück. Wenn der Prefill zuerst fertig wird, hält er die Blöcke zurück, bis die Registrierung eingeht. Welches Ereignis als zweites eintritt, löst die sofortige Übertragung aus. Der Decoder zählt die Abschlussbenachrichtigungen von jedem Producer-Rank und fährt erst mit der Token-Generierung fort, wenn alle erwarteten Daten eingetroffen sind.

Wichtige Details

• Leistungssteigerung: Bis zu 3-fache Reduktion der TTFT und 30 % Verbesserung der TPOT für Qwen3-32B in 1P1D-Bereitstellungen bei hohen Anfrage-Raten.
• Getestete Hardware: Amazon EC2 P5en-Instanzen mit EFA, unter Verwendung von GPUDirect RDMA für direkte GPU-zu-GPU-Speicherübertragung.
• Mechanismus: Verwendet NIXL WRITE-Operationen, die von der Prefill-Instanz initiiert werden, statt NIXL READ, die von der Decode-Instanz initiiert werden.
• Threading: Ein Hintergrund-Thread auf dem Prefill-Worker übernimmt die Übertragungs-Einrichtung und verhindert Stalls in der Haupt-Modellausführungsschleife.
• Abwägung: Der Push-Modus erfordert eine frühere Auswahl der Decode-Instanz im Prozess, was die Flexibilität für lastbewusstes Routing im Vergleich zum Pull-Modus einschränken kann.
• Konfiguration: Benutzer aktivieren dies, indem sie sowohl Prefill- als auch Decode-Server so konfigurieren, dass sie NixlPushConnector anstelle des standardmäßigen NixlConnector verwenden.

Warum das wichtig ist

Für Ingenieure, die hochdurchsatzfähige LLM-Dienste entwickeln, ist disaggregiertes Serving eine gängige Strategie, um die Ressourcennutzung effizient zu verwalten. Allerdings kann der Overhead beim Verschieben großer KV-Caches zwischen Knoten die Vorteile zunichte machen, wenn nicht sorgfältig damit umgegangen wird. Das traditionelle Pull-Modul führt eine synchrone Wartezeit ein, in der die Decode-Instanz untätig ist und auf Metadaten wartet, bevor sie Daten abruft. Diese Verzögerung wird ausgeprägter, wenn Kontextlängen wachsen und Anfrage-Raten steigen, was die benutzerwahrgenommene Latenz direkt beeinträchtigt.

Durch die Verlagerung der Koordinationsarbeit in einen Hintergrund-Thread und die Überlappung mit der Prefill-Berechnung stellt das Push-Modell sicher, dass die Decode-Instanz bereit ist, Daten in dem Moment zu empfangen, in dem sie verfügbar sind. Dies reduziert die Leerlaufzeit auf dem kritischen Pfad und führt zu schnelleren Antwortzeiten für Benutzer. Es verhindert zudem, dass der Decode-Worker durch Aufgaben zur Übertragungs-Einrichtung blockiert wird, sodass er konsistente Token-Generierungsgeschwindigkeiten auch unter hoher Nebenläufigkeit beibehalten kann.

Diese Entwicklung unterstreicht die Bedeutung von Infrastruktur-Optimierungen auf niedriger Ebene im AI-Serving. Da Modelle größer und Kontexte länger werden, wird die Effizienz der Datenbewegung zwischen Rechenknoten genauso wichtig wie die Geschwindigkeit der Matrixmultiplikationen selbst. Ingenieure, die vLLM auf AWS oder ähnlicher RDMA-fähiger Infrastruktur einsetzen, sollten diese Option in Betracht ziehen, um die Leistung zu maximieren.

Was Sie tun können

• Bewerten Sie Ihre aktuelle vLLM-Bereitstellung, um festzustellen, ob disaggregiertes Prefill-Decode-Serving für Ihren Workload geeignet ist.
• Testen Sie den NixlPushConnector in einer Staging-Umgebung mit realistischen Traffic-Mustern, um die TTFT-Verbesserungen zu messen.
• Stellen Sie sicher, dass Ihre Infrastruktur RDMA unterstützt, wie z. B. AWS EFA, um Funktionen für direkten Speicherzugriff nutzen zu können.
• Überwachen Sie die Abwägung zwischen früher Decode-Instanz-Auswahl und den Anforderungen an dynamisches Load Balancing in Ihrer Router-Konfiguration.
• Deaktivieren Sie Prefix-Caching während des Benchmarkings, um die Übertragungsleistung zu isolieren, da Caching Übertragungskosten verschleiern kann.
• Prüfen Sie die vLLM-Dokumentation auf spezifische Konfigurationsflags, die erforderlich sind, um vom Pull- in den Push-Modus zu wechseln.