Bi-direktionaler KV-Transfer senkt Latenz bei mehrstufigen Agent-Workloads

Amazon Web Services hat eine Methode vorgestellt, die die Latenz in mehrstufigen agentischen Anwendungen erheblich senkt, indem sie den bi-direktionalen Transfer von Key-Value-(KV)-Caches innerhalb des vLLM-Serving-Frameworks ermöglicht. Dieser am 19. Oktober 2026 veröffentlichte Ansatz erlaubt es Prefill- und Decode-Nodes, zwischengespeicherte Kontexte in beide Richtungen auszutauschen, wodurch redundante Berechnungen vermieden werden, wenn die Gesprächshistorien wachsen.

Was ist passiert?

In typischen mehrstufigen agentischen Workflows akkumuliert ein Agent Kontext durch Schlussfolgerungen, Tool-Aufrufe und die Einbeziehung vorheriger Ergebnisse. Clients senden üblicherweise die gesamte Gesprächshistorie – einschließlich Systemanweisungen, früherer Prompts, Tool-Ausgaben und Modellantworten – mit jeder neuen Runde erneut. In disaggregierten Serving-Architekturen mit getrenntem Prefill und Decode (P-D) werden Anfragen auf spezialisierte Nodes aufgeteilt: Ein Prefill-Node verarbeitet den Prompt, um den KV-Cache aufzubauen, und ein Decode-Node ruft diese Blöcke ab, um die Antwort zu generieren. Standardimplementierungen übertragen den KV-Cache jedoch nur in eine Richtung, vom Prefill zum Decode.

Dieser unidirektionale Fluss erzeugt Ineffizienzen. Nach der Generierung einer Antwort hält der Decode-Node KV-Einträge sowohl für den ursprünglichen Prompt als auch für die neuen Tokens. Wenn die nächste Runde eintrifft, kann der Prefill-Node nicht auf diese Einträge zugreifen und muss die KV-Projektionen für die vorherige Antwort neu berechnen. Da Decode-Nodes den Sitzungsstatus beibehalten, Prefill-Nodes dies aber nicht tun, sind aktive Sitzungen auf Prefill-Nodes einem höheren Risiko ausgesetzt, dass ihr Cache verworfen wird. Ein vollständiger Cache-Miss zwingt den Prefill-Node dazu, die gesamte Historie neu zu berechnen, was Accelerator-Kapazität verbraucht und die Zeit bis zum ersten Token (TTFT) erhöht.

Um dies anzugehen, haben AWS-Ingenieure den NVIDIA Inference Xfer Library (NIXL) KV-Connector in vLLM erweitert, um bi-direktionalen Transfer zu unterstützen. Dies ermöglicht es Decode-Nodes, zuvor berechnete KV-Blöcke für nachfolgende Runden an Prefill-Nodes zurückzugeben. Die Funktion wurde auf Amazon EC2 P5en-Instanzen validiert, die über AWS Elastic Fabric Adapter (EFA) verbunden sind. Dabei zeigte sich, dass TTFT um bis zu das 1,6-Fache für Qwen3-32B und um bis zu das 3,3-Fache für Modelle von zai-org/GLM-5-FP8 in Multi-Turn-Benchmarks reduziert wird.

Wie es funktioniert

Der bi-direktionale KV-Transfer basiert auf einem KV-Cache-bewussten Router und verbesserten Richtlinien zur Blockretention. Der Router fungiert als leichte, zustandsbehaftete Control Plane, die Client-Gesprächs-IDs auf KV-Transferparameter der Decode-Nodes abbildet. Er speichert nur Metadaten zur Blockposition, nicht die tatsächlichen Tensoren, wobei er diese Informationen aus dem Antwortstrom erhält. Bei der ersten Runde tritt ein Cache-Miss auf, und die Anfrage folgt dem Standardpfad. Der Router speichert anschließend die Metadaten des Decode-Nodes. In nachfolgenden Runden ruft der Router diese Metadaten ab, sodass der Prefill-Node KV-Blöcke vom Decode-Node wiederverwenden kann, anstatt sie neu zu berechnen.

Der Decode-Node behält geeignete KV-Blöcke für eine konfigurierbare Time-to-Live (TTL), standardmäßig 480 Sekunden, bei, anstatt sie unmittelbar nach der Generierung freizugeben. Dies stellt sicher, dass der Kontext für die nächste Runde verfügbar bleibt. Um zu verhindern, dass der Overhead bei kurzen Präfixen die Vorteile übersteigt, steuert die Einstellung kv_recompute_threshold, wann eine Wiederverwendung stattfindet. Liegt die Anzahl der wiederverwendbaren Tokens unter diesem Schwellenwert (Standardwert 64), berechnet der Prefill-Node lokal neu; andernfalls zieht er KV-Daten vom Decode-Node über eine NIXL READ-Operation.

Wichtige Details

• Bi-direktionaler KV-Transfer reduziert TTFT in getesteten Konfigurationen um bis zu das 1,6-Fache für Qwen3-32B und das 3,3-Fache für zai-org/GLM-5-FP8.
• Die Funktion erfordert vLLM v0.21.0 oder neuer mit NixlConnector und muss auf beiden Prefill- und Decode-Servern aktiviert sein.
• AWS EFA unterstützt GPUDirect RDMA und Neuron Direct RDMA, was direkten Speicherzugriff zwischen GPU- oder Trainium-Geräten ermöglicht.
• Decode-Nodes behalten KV-Blöcke für eine konfigurierbare TTL (Standard 480 Sekunden) bei, um die Wiederverwendung über Runden hinweg zu unterstützen.
• Ein kv_recompute_threshold (Standard 64 Tokens) verhindert unnötigen Netzwerk-Overhead bei kurzen wiederverwendbaren Präfixen.
• Der KV-Cache-bewusste Router pflegt eine In-Memory-Zuordnung von Gesprächs-IDs zu KV-Transferparametern, ohne Tensoren zu speichern.

Warum das wichtig ist

Für Ingenieure, die konversationelle Assistenten und agentische Anwendungen entwickeln, ist das Management wachsender Kontextfenster ein primärer Engpass. Wenn Interaktionshistorien länger werden, verbraucht wiederholte Prefill-Berechnung erhebliche Accelerator-Ressourcen und erhöht die Latenz. Indem Prefill-Nodes KV-Blöcke wiederverwenden können, die von Decode-Nodes behalten wurden, mildert der bi-direktionale Transfer diese Redundanz. Dies führt zu stabileren TTFT-Leistungswerten, selbst wenn Gespräche länger werden, und verbessert die Benutzererfahrung sowie die Ressourcennutzung.

Die Architektur unterstreicht zudem die Bedeutung effizienter Interconnects wie AWS EFA für verteiltes Inferencing. Der geringe Overhead beim Transfer von KV-Blöcken (30–130 ms in Tests) wird durch die Einsparungen bei der Rechenzeit deutlich übertroffen, insbesondere bei größeren Modellen wie GLM-5-FP8. Dies deutet darauf hin, dass die Optimierung des Datentransfers zwischen spezialisierten Nodes genauso kritisch ist wie die Optimierung der Modellausführung selbst für skalierbare agentische Systeme.

Was Sie tun können

• Aktualisieren Sie auf vLLM v0.21.0 oder neuer und aktivieren Sie bidirectional_kv_xfer auf beiden Prefill- und Decode-Servern.
• Implementieren Sie einen KV-Cache-bewussten Router, um den Metadatenfluss zwischen Clients und Serving-Nodes zu verwalten.
• Passen Sie den Parameter decoder_kv_blocks_ttl basierend auf der erwarteten Zeit zwischen Nutzerrunden an, um Speichernutzung und Wiederverwendung auszubalancieren.
• Justieren Sie den kv_recompute_threshold entsprechend der Berechnungszeit Ihres Modells und der Leistungsfähigkeit des Interconnects.
• Verwenden Sie AWS EFA-fähige Instanzen wie P5en für Low-Latency-RDMA-Transfers, wenn Sie auf AWS-Infrastruktur bereitstellen.
• Reproduzieren Sie den Benchmark anhand des bereitgestellten Leitfadens, um die Leistungsverbesserungen für Ihren spezifischen Workload und Ihr Modell zu validieren.