KI SpotlightNewsvLLM erhält Push-Modus für den KV-Transfer bei getrennter Prefill- und Decode-Ausführung
Der neue NIXL-Connector lässt die Prefill-Instanz den KV-Cache per RDMA direkt in den Decode-Speicher schreiben. Messwerte, Versionsangabe und Konfiguration liegen im vorliegenden Material nicht vor.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- Prefill und Decode laufen auf getrennten Engine-Instanzen und lassen sich unabhängig skalieren.
- Der push-basierte NIXL-Connector schreibt KV direkt per RDMA in den Decode-Speicher.
- Auf unterstützten Instanztypen unterstützt EFA GPUDirect RDMA und Neuron Direct RDMA.
- Bi-directional KV Transfer senkt die TTFT bei langen Multi-Turn-Prompts laut Blog um bis zu 3,3x.
- Disaggregated Prefill verbessert laut vLLM-Dokumentation den Durchsatz ausdrücklich nicht.
vLLM lässt die Prefill-Instanz KV-Blöcke direkt in den Decode-Speicher schreiben
Die Inferenz-Engine vLLM bekommt einen push-basierten NIXL-Connector für die Prefill-Decode-Disaggregation. Nach Darstellung des vLLM-Blogs, der auch auf dem AWS-Blog erschienen ist, schreibt die Prefill-Instanz den KV-Cache direkt per RDMA in den Speicher der Decode-Instanz. Drei Schritte fallen damit aus dem kritischen Pfad zur ersten Token-Ausgabe (Time to First Token, TTFT): die Weitergabe der Information über den Router, die Speicherallokation auf der Decode-Seite und das Einrichten des Transfers.
Der Transfer läuft über RDMA-fähige Verbindungen, etwa den Elastic Fabric Adapter (EFA) von AWS. Nach Angaben von AWS unterstützt EFA auf geeigneten Instanztypen GPUDirect RDMA und Neuron Direct RDMA. Die KV-Blöcke ließen sich dann direkt zwischen dem Speicher von GPUs beziehungsweise Trainium-Beschleunigern übertragen, ohne Umweg über den Host-Speicher. Messwerte nennt das vorliegende Material für den Push-Modus nicht.
Pull bleibt der Standard, Push kehrt die Richtung des Transfers um
Bei der Disaggregation laufen Prefill und Decode auf getrennten Engine-Instanzen. Beide lassen sich so unabhängig skalieren und optimieren. Dafür muss der KV-Cache vor dem ersten generierten Token von der Prefill- zur Decode-Instanz wandern. AWS nennt einen effizienten Transfer deshalb entscheidend für die TTFT.
Im bisherigen Standardmodus des NIXL-Connectors, dem Pull, gibt der Router nach dem Prefill die Information an den Decode-Knoten weiter. Dieser holt die Blöcke ab. Beim Push schreibt der Prefill-Knoten sie selbst. Laut llm-d-Dokumentation nutzt vLLM bislang Pull, die Engine SGLang dagegen Push. Dort schiebt die Prefill-Seite die KVs zum Decode-Knoten. Ein Bootstrap-Server neben jeder Prefill-Instanz vermittelt die Verbindung.
Die vLLM-Dokumentation weist ausdrücklich darauf hin, dass Disaggregated Prefill den Durchsatz nicht verbessert. Der Nutzen liegt darin, TTFT und Inter-Token-Latenz (ITL) getrennt zu tunen und die Tail-ITL zu kontrollieren.
Davon zu trennen ist ein weiteres Feature aus dem vLLM-Blog. Bei Bi-directional KV Transfer können Prefill-Knoten zuvor berechnetes KV von Decode-Knoten in späteren Gesprächsrunden wiederverwenden. Laut Blog ließe sich die TTFT bei langen Multi-Turn-Prompts so um bis zu 3,3x senken. Dieser Wert gehört nicht zum Push-Mechanismus.
Messwerte, Versionsangabe und Konfiguration des Push-Modus fehlen
Das vorliegende Material enthält keine konkreten TTFT- oder TPOT-Messwerte für den Push-Modus. Die Textauszüge sind zudem abgeschnitten. Auch die vLLM-Version, in der Push erstmals enthalten ist, nennt es nicht. vllm.ai beschreibt den Betrieb von Disaggregated Serving ab v0.31.0. Ob Push darin enthalten ist, bleibt unklar. Konfigurationshinweise liegen ebenfalls nicht vor.
Potenziell betroffen sind Betreiber disaggregierter Deployments mit RDMA-Netzen sowie Plattformen wie llm-d. Ein Handlungsbedarf ist nicht belegt. llm-d verweist für disaggregiertes Serving allgemein auf zusätzliche Betriebskomplexität: dynamische Verbindungen, Request-Cancellation, Fehlertoleranz und Rollouts. Die Dokumentation bezieht das nicht auf den Push-Modus.
