Cache Engineering: Agenten sollen ihren KV-Cache selbst steuern

Agenten steuern ihren KV-Cache selbst: drop und repos statt Kontextkürzung

Ein Autorenteam um Tianyu Fu, Ruoxi Wang, Zihan Min, Zhongqi Ren, Zhihao Li, Tengxuan Liu, Shengxu Mu, Hanling Zhang und Yu Wang hat unter der Kennung arXiv:2610.28577 das Paper „Cache Engineering for Agents“ (AKV) veröffentlicht. Darin führen die Autoren den Begriff „Cache Engineering“ ein. LLM-Agenten steuern dabei ihren aktiven KV-Cache direkt. Die Trajektorie bleibt unverändert, behaltener Kontext muss nicht neu vorbefüllt werden. Dafür stehen zwei Operationen bereit: Drop schließt ausgewählte Cache-Einträge von künftiger Attention aus. Repos passt die Positionskodierungen der behaltenen Keys an.

Abgrenzen wollen sich die Autoren von Context Engineering. Dieses kürzt oder fasst die Historie zusammen. Dadurch verändert sich das Präfix der Trajektorie, nachfolgende Cache-Zustände werden entwertet, und aufwendiges Re-Prefilling wird nötig. Behält man zu wenig Kontext, um diese Kosten zu begrenzen, kann außerdem die Genauigkeit leiden. Ausgangspunkt ist für die Autoren ein Kostenproblem: Bei langen Agenten-Trajektorien dominieren Ein- und Ausgabe sowie die Speicherung des KV-Caches die Kosten.

Laut Kurzfassung auf der Hugging-Face-Seite verbessere AKV Effizienz und Genauigkeit gegenüber Context Engineering. Dabei handelt es sich um eine Herstellerangabe. Zahlen, Benchmarks und Baselines enthält das vorliegende Material nicht. Der Anspruch, Cache Engineering sei ein „neues Schema“, stammt ebenfalls von den Autoren und ist nicht unabhängig geprüft.

Gleiche Tokens, anderer Cache-Zustand: Warum Prefix-Matching nicht reicht

Als Serving-Problem beschreiben die Autoren die Historienabhängigkeit. Identische Token-Folgen können je nach Reihenfolge der Cache-Operationen zu unterschiedlichen Cache-Zuständen führen. Was gedroppt oder neu positioniert wurde, bestimmt, welche Keys künftige Attention sieht und mit welchen Positionen. Reines Prefix-Matching vergleicht nur die Token-Folge. Damit lässt sich ein Cache nicht korrekt wiederverwenden. Die Autoren geben an, die Operationen formalisiert zu haben.

Die mitentworfene AKV-Serving-Engine bietet laut Abstract eine zustandslose Schnittstelle, die mit bestehenden Serving-APIs kompatibel ist. Intern verwaltet sie die Cache-Wiederverwendung zustandsbehaftet. Der Abstract bricht in den vorliegenden Belegen an dieser Stelle ab. Weitere Details zur Funktionsweise lassen sich daraus nicht ableiten.

Öffentlicher Code auf SGLang-Basis: Bausteine und Einschränkungen

Der Code liegt im GitHub-Repository thu-nics/AKV. Er besteht aus zwei Teilen. akv.agent enthält die Policies, die entscheiden, welche Nachrichten gedroppt werden und wann Positionen neu gesetzt werden. akv.system führt die Cache-Operationen über die OpenAI-kompatible Chat-Completions-API von SGLang aus. Das README zeigt Beispiele mit GPT-OSS-120B (tp-size 2) und Qwen3-0.6B.

Einschränkungen gelten an mehreren Stellen. Drop und Repos kompiliert beim Start CPU-Kernel, weshalb ein C++20-Compiler nötig ist. Die PD-Disaggregation, also die Trennung von Prefill und Decode, unterstützt derzeit nur das Mooncake-Backend. Staging-Buffer, KV-Offload und KV-Checksum-Modus fehlen dort. Nach dem Design richtet sich der Code vor allem an Betreiber von Agenten-Plattformen und an Framework-Entwickler, die Modelle selbst über SGLang hosten. Ob API-Anbieter Kosten sparen könnten, ist nicht belegt.

Messwerte zu Speicher, Latenz, Durchsatz und Genauigkeit fehlen im Material. Prüfen lassen sie sich im Volltext des Papers oder durch Reproduktion mit dem Repository. Vorsicht ist außerdem bei der Namensähnlichkeit geboten: „AgentKV“ (LiuTaowen-Tony/agentkv) ist ein separates Projekt. Es bewertet Cache-Einträge phasenabhängig und verdrängt sie.