vLLM senkt die Latenz in Multi-Turn-Agenten durch bidirektionale KV-Cache-Übertragung
Imagen generada con gpt-image-2.5-sunburst para InferamaQuelle ↗
01

Die Latenzherausforderung bei entkoppelter Inferenz

Die Inferenz großer Sprachmodelle ist für agentische Anwendungen zu einem zentralen Engpass geworden, weil sich Latenzen über mehrere Dialogrunden hinweg kumulieren und die wahrgenommene Geschwindigkeit unmittelbar beeinflussen. In entkoppelten Architekturen werden die Phasen Prefill und Decode auf getrennten Knoten ausgeführt, um unterschiedliche Ressourcenprofile besser auszunutzen. Diese Trennung erzeugt jedoch eine kritische Abhängigkeit: Der KV-Cache, also die Zwischenspeicherung von Schlüssel- und Wertvektoren der Attention-Mechanismen, muss zwischen den Knoten übertragen werden, damit die Dekodierung ohne vollständige Neuberechnung beginnen kann.

Bisher war die Verwaltung des KV-Caches häufig auf den lokalen Speicher einer Instanz beschränkt. Bei Multi-Turn-Workloads wächst der Gesprächskontext jedoch mit jeder Runde, und die erneute Berechnung desselben Kontexts erzeugt unnötige Rechenlast. Die Entwicklung von vLLM in Richtung bidirektionaler KV-Übertragung zielt darauf ab, diesen Effekt zu reduzieren, indem bereits berechnete Zustände zwischen Prefill- und Decode-Knoten geteilt und wiederverwendet werden. Dadurch sinkt die Wartezeit, bevor der erste Token erzeugt wird, und die Infrastruktur kann weniger redundante Arbeit ausführen.

Für agentische Systeme ist dieser Unterschied besonders relevant, weil ein Agent häufig auf dasselbe Dokument, denselben Code oder dieselbe Aufgabenbeschreibung zurückgreift. Wenn der relevante Kontext nicht erneut berechnet werden muss, kann die Antwort schneller beginnen, während die GPU-Kapazität für neue Anfragen verfügbar bleibt. Die entkoppelte Inferenz wird damit nicht nur zu einer Technik für höheren Durchsatz, sondern auch zu einem Baustein für interaktive Anwendungen mit engen Latenzzielen.

02

Push-basierter und bidirektionaler Übertragungsmechanismus

Der technische Kern der Optimierung liegt in einem push-basierten Connector, der auf NIXL, die NVIDIA Inference Xfer Library, aufbaut. Im Gegensatz zu einem pull-basierten Ansatz, bei dem der Decode-Knoten aktiv Daten anfordert, überträgt der Prefill-Knoten den KV-Cache proaktiv, sobald er verfügbar ist. Damit wird die Koordinierung der Übertragung aus dem kritischen Pfad herausgenommen, weil der empfangende Knoten nicht erst auf eine Anfrage und deren Aushandlung warten muss.

Die bidirektionale Ausrichtung ist für Multi-Turn-Agenten entscheidend. Nicht nur der anfängliche KV-Cache vom Prefill zum Decode wird übertragen, sondern auch Zwischenzustände können aktualisiert und zurückgeführt werden. Am Ende einer Dialogrunde kann der resultierende Cache gespeichert und in der nächsten Runde wiederverwendet werden. So behandelt das System jede Interaktion nicht als isolierte Anfrage, sondern als Teil einer fortlaufenden Sitzung, in der bereits vorhandener Kontext erhalten bleibt.

Diese Vorgehensweise reduziert sowohl Rechenzeit als auch Netzwerklast, weil nur die tatsächlich benötigten Zustände bewegt werden. Wenn ein Teil des Kontexts bereits am Zielknoten vorhanden ist, kann die Übertragung eingeschränkt oder die Neuberechnung vermieden werden. Die Architektur nutzt damit die Eigenschaften moderner Hochgeschwindigkeitsnetze, um die Lücke zwischen lokaler Speicherzugriffsgeschwindigkeit und verteiltem Zustandsaustausch zu verkleinern.

Ablauf der bidirektionalen KV-Cache-Übertragung

Vereinfachter Ablauf der KV-Cache-Verwaltung in einem Multi-Turn-Zyklus.

  1. 01Turn N: Der Prefill-Knoten verarbeitet den neuen Prompt und den aus dem vorherigen Turn übernommenen KV-Cache.
  2. 02Push-Übertragung: Der aktualisierte KV-Cache wird proaktiv an den Decode-Knoten gesendet.
  3. 03Dekodierung: Der Decode-Knoten erzeugt die Antwort, ohne den bisherigen Kontext vollständig neu zu berechnen.
  4. 04Wiederverwendung: Der finale KV-Cache wird für den nächsten Turn N+1 gespeichert.
03

Auswirkung auf Time to First Token

Time to First Token ist eine der empfindlichsten Metriken für die wahrgenommene Geschwindigkeit in konversationellen Schnittstellen. In agentischen Szenarien ist die Eingabe oft lang, weil sie Systemanweisungen, frühere Antworten, Tool-Ergebnisse oder Dokumentauszüge enthält. Wenn dieser Kontext in jeder Runde neu berechnet werden müsste, würde die TTFT-Latenz mit der Länge der Sitzung steigen, selbst wenn die neue Nutzereingabe kurz ist.

Durch die push-basierte Übertragung und die bidirektionale Wiederverwendung kann vLLM die Zeit zwischen dem Empfang einer Anfrage und der Erzeugung des ersten Tokens deutlich verkürzen. Der entscheidende Effekt besteht darin, dass die Koordinierung der KV-Übertragung nicht mehr den Start der Dekodierung blockiert. Gleichzeitig kann das System erkennen, welche Teile des Caches bereits am Zielknoten existieren, und nur die fehlenden Zustände übertragen oder neu berechnen.

Für Workloads mit hoher Kontextwiederverwendung ist die Verbesserung daher nicht konstant, sondern skaliert mit dem Anteil des wiederverwendbaren Kontexts. Je länger der gemeinsame Präfixanteil zwischen den Runden ist, desto größer kann der Nutzen sein. Das macht die Technik besonders attraktiv für Agenten, die wiederholt auf dieselbe Wissensbasis, denselben Codebestand oder dieselbe Aufgabenhistorie zugreifen.

04

Ergebnisse auf Amazon EC2 P5en-Instanzen

Die dokumentierten Benchmarks wurden auf Amazon EC2 P5en-Instanzen mit AWS EFA, dem Elastic Fabric Adapter, durchgeführt. Diese Kombination ist wichtig, weil die Übertragung des KV-Caches zwischen Knoten eine hohe Bandbreite und niedrige Latenz erfordert. Ohne eine leistungsfähige Vernetzung könnte der Zustandsaustausch selbst zum neuen Engpass werden und die Vorteile der entkoppelten Inferenz aufheben.

Für das Modell Qwen3-32B wird eine bis zu 1,6-fache Verbesserung der TTFT gegenüber der herkömmlichen entkoppelten Inferenz angegeben. Für GLM-5-FP8 ist der Effekt noch stärker: Die TTFT-Latenz kann sich laut den Benchmarks um bis zu 3,3-fach verbessern. Diese Unterschiede zeigen, dass der Nutzen von der Modellgröße, der Kontextlänge und dem Grad der Wiederverwendung abhängt, nicht nur von der reinen Rechenleistung.

Die Ergebnisse sollten als belastbare Indizien für die Wirksamkeit der Architektur verstanden werden, nicht als universell übertragbare Konstante. Andere Hardware, andere Netzwerkbedingungen, andere Modellvarianten oder andere Lastprofile können zu anderen Werten führen. Dennoch verdeutlichen die Messungen, dass bidirektionale KV-Übertragung in agentischen Multi-Turn-Szenarien ein erhebliches Latenzpotenzial freisetzen kann, wenn die Infrastruktur die Datenbewegung schnell genug unterstützt.

TTFT-Verbesserung in agentischen Multi-Turn-Workloads

Dokumentierte Verbesserungen auf Amazon EC2 P5en mit AWS EFA.

ModellTTFT-VerbesserungTestkontext
Qwen3-32B1,6xMulti-Turn-Agentik
GLM-5-FP83,3xMulti-Turn-Agentik
05

Implikationen für KI-Architekten

Für Teams, die KI-Agenten in der Cloud betreiben, hat diese Optimierung zwei zentrale Folgen: niedrigere Kosten und eine bessere Nutzererfahrung. Durch die Wiederverwendung des KV-Caches sinkt die Anzahl der benötigten Rechenoperationen pro Dialogrunde, weil bereits berechneter Kontext nicht erneut verarbeitet werden muss. Das kann dazu führen, dass dieselbe GPU-Flotte mehr gleichzeitige Anfragen bedient oder dass für eine gegebene Last weniger Instanzen benötigt werden.

Gleichzeitig verbessert die niedrigere TTFT-Latenz die Möglichkeit, Service Level Objectives in interaktiven Anwendungen zu erfüllen. Copilots, Support-Agenten oder Code-Assistenten profitieren besonders, weil Nutzer auf schnelle erste Antworten warten, während im Hintergrund weitere Tokens erzeugt werden. Wenn die erste Antwort schneller sichtbar wird, wirkt das System reaktionsfreudiger, auch wenn die Gesamtdauer der Generierung ähnlich bleibt.

Aus Architektursicht bedeutet das, dass entkoppelte Inferenz nicht länger nur als Maßnahme für hohen Durchsatz betrachtet werden muss. Sie kann auch als Strategie für niedrige Latenz und hohe Interaktivität eingesetzt werden. Entscheidend ist jedoch die Kombination aus passender Modellwahl, effizienter Cache-Verwaltung, geeigneter Netzwerktechnik und klaren Betriebszielen. Nur so lässt sich das theoretische Potenzial in messbare Produktvorteile übersetzen.

Offene Fragen

  • Die Benchmarks stammen aus der primären AWS-Dokumentation und wurden in diesem Kontext nicht unabhängig in anderen Cloud-Umgebungen oder auf anderer Hardware repliziert.
  • Der genaue Einfluss auf den RAM- und GPU-Speicherbedarf im Vergleich zu monolithischer Inferenz wird in den vorliegenden Quellen nicht detailliert quantifiziert.
  • Die Verfügbarkeit der Funktion in bestimmten vLLM-Versionen und ihre Kompatibilität mit anderen Cloud-Anbietern oder Netzwerktechnologien wird nicht vollständig spezifiziert.
06

Weiter entdecken

06

Verwendete Quellen

03

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.

Korrektur vorschlagen