KI SpotlightNewsvLLM-Blog beschreibt Rücktransfer des KV-Caches von Decode- zu Prefill-Knoten
Ein Blogbeitrag beschreibt einen bidirektionalen Transfer für Multi-Turn-Agenten. Mechanik, Messwerte und Release-Status sind in den vorliegenden Auszügen nicht belegt. Die 68-Prozent-Zahl stammt von einem anderen Ansatz.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- Bei Multi-Turn-Agenten-Workloads sendet der Client mit jedem Turn die gesamte Gesprächshistorie erneut.
- Konventionelles disaggregiertes Serving überträgt den KV-Cache nur vom Prefill- zum Decode-Knoten.
- Der Decode-Knoten hält den Session-Zustand, Prefill-Knoten nicht; bei Cache-Miss wird die gesamte Historie neu berechnet.
- Die vLLM-Doku nennt vier KV-Connectoren: ExampleConnector, LMCacheConnectorV1, LMCacheMPConnector und NixlConnector.
- Laut vLLM-Doku verbessert Disaggregated Prefill den Durchsatz nicht.
vLLM-Blog beschreibt Rücktransfer des KV-Caches von Decode- zu Prefill-Knoten
Der Blogpost „Improve TTFT for multi-turn agentic workloads with bi-directional KV transfer in vLLM“ beschreibt, wie der KV-Cache der generierten Tokens nach dem Decode zurück auf den Prefill-Knoten gelangen soll. Dort müsste er im nächsten Turn nicht neu berechnet werden. Das Ziel ist eine niedrigere Time to First Token (TTFT), also eine kürzere Wartezeit bis zum ersten Antwort-Token. Der Text liegt auf vllm.ai und auf aws.amazon.com vor. In den Auszügen unterscheiden sich beide Fassungen bis auf Kleinigkeiten nicht.
Neu ist laut Titel und Problembeschreibung der Rücktransfer von Decode zu Prefill. Die vorliegenden Auszüge enthalten jedoch nur die Problembeschreibung. Wie der Rücktransfer umgesetzt ist, welche Connectoren er nutzt, in welcher vLLM-Version er verfügbar ist und welche Messwerte vorliegen, lässt sich daraus nicht belegen. Wir ergänzen dazu nichts.
Warum Prefill-Knoten bei jedem Agenten-Turn neu rechnen
Agenten bauen auf wachsendem Kontext auf. Mit jedem Turn schickt der Client die gesamte Gesprächshistorie erneut: Systemanweisungen, frühere Prompts, Tool-Ergebnisse und Modellantworten. Der wachsende Kontext wird so immer wieder verarbeitet.
In der klassischen Prefill-Decode-Disaggregation fließt der KV-Cache nur von Prefill zu Decode. Nach der Antwort hält der Decode-Knoten die Einträge für Prompt und neu generierte Tokens. Der Prefill-Knoten kann sie im nächsten Turn nicht abrufen. Er muss die KV-Projektionen der bisherigen Antworttokens neu berechnen. Hinzu kommt: Der Decode-Knoten hält den Session-Zustand, der Prefill-Knoten nicht. Aktive Sessions werden dort deshalb eher aus dem Cache verdrängt. Bei einem vollständigen Cache-Miss muss der Prefill-Knoten die KV-Projektionen der gesamten Historie neu berechnen.
Betroffen sind demnach Betreiber disaggregierter vLLM-Deployments mit langen Agenten-Sessions. Single-Turn-Workloads hätten nach dieser Beschreibung keinen Nutzen. Konkrete Gewinne beziffern die Auszüge nicht.
PPD-Paper setzt anders an: 68 Prozent weniger TTFT, aber nicht in vLLM
Einen konkurrierenden Ansatz verfolgt das Paper „Not All Prefills Are Equal: PPD Disaggregation for Multi-turn LLM Serving“ (ICML 2026, arXiv 2603.13358). Es verarbeitet Append-Prefills ab Turn 2 lokal auf Decode-Knoten mit gecachtem KV, statt den Cache zurückzuschicken. Die Autoren berichten dafür eine TTFT-Reduktion von 68 Prozent für Turn 2+. Diese Zahl gehört nicht zum vLLM-Blogpost. Sie stammt von einem anderen Ansatz, einem vLLM-Prototyp. Dessen Code ist laut Zusammenfassung nicht veröffentlicht.
Die PPD-Autoren kritisieren an klassischer Disaggregation unter anderem, dass wiederholte KV-Transfers zwischen Prefill- und Decode-Knoten die Bandbreite sättigen und den Dienst verschlechtern können. Ob ein Rücktransfer diese Belastung verschärft, ist im vorliegenden Material nicht untersucht.
Offen bleiben damit Connector, Version und Messwerte des bidirektionalen Transfers.
