💬 NLP

Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks

Diese Arbeit präsentiert eine umfassende Evaluierung von Prompt-Caching über drei große LLM-Anbieter hinweg für langwierige agentische Aufgaben und zeigt auf, dass strategische Caching-Techniken – wie das Ausschließen dynamischer Tool-Ergebnisse und das Management der Prompt-Struktur – die API-Kosten im Vergleich zu naivem Full-Context-Caching um 41–80 % senken und die Zeit bis zum ersten Token um 13–31 % verbessern können.

Ursprüngliche Autoren: Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate, Vamse Kumar Subbiah

Veröffentlicht 2026-02-03

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate, Vamse Kumar Subbiah

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie stellen einen brillanten, aber teuren Forschungsassistenten ein, um ein komplexes Rätsel zu lösen. Dieser Assistent muss ein massives Handbuch (den „System-Prompt“) lesen, bevor er mit der Arbeit beginnt. Während er arbeitet, führt er Dutzende von Telefonaten mit verschiedenen Quellen, erhält Antworten und schreibt diese in ein Notizbuch.

Jedes Mal, wenn er einen neuen Telefonanruf tätigt, muss er das gesamte Handbuch von der ersten Seite an neu lesen, um sich zu erinnern, was zu tun ist. Das kostet viel Zeit und viel Geld, weil der Assistent pro gelesener Seite abrechnet.

„Prompt Caching“ ist wie ein magischer Textmarker, den man diesem Assistenten gibt. Wenn sich das Handbuch nicht geändert hat, kann der Assistent den ersten 9en % des Buches überspringen und direkt zum neuen Teil mit den Ergebnissen der Telefonate springen. Das spart Zeit und Geld.

Dieses Paper stellt jedoch eine knifflige Frage: Funktioniert dieser magische Textmarker immer, oder kann man ihn sabotieren?

Die Forscher haben dies bei drei großen „Assistenten-Unternehmen“ (OpenAI, Anthropic und Google) mit einem Benchmark namens DeepResearch Bench getestet, bei dem Agenten komplexe, mehrstufige Websuchen durchführen, um schwierige Fragen zu beantworten. Sie haben drei verschiedene Wege getestet, den Textmarker zu verwenden:

Der „naive“ Ansatz (Vollständiger Kontext): Alles hervorheben, einschließlich der neuen Telefonergebnisse.
Der „Klebezettel“-Ansatz (Nur System-Prompt): Nur das Handbuch hervorheben, aber die neuen Telefonergebnisse unmarkiert lassen.
Der „Saubere Schnitt“-Ansatz (Tool-Ergebnisse ausschließen): Das Handbuch und die Telefonate hervorheben, aber nach jedem neuen Ergebnis ein spezielles „Stoppschild“ setzen, damit der Textmarker nicht versehentlich die unordentlichen Notizen der nächsten Person erfasst.

Was sie herausgefunden haben

1. Es spart viel Geld (Der „Geldbörsen“-Gewinn)
Egal welche Methode sie verwendeten, der magische Textmarker sparte eine enorme Menge Geld. Je nach Unternehmen sparten sie zwischen 41 % und 80 % der Kosten.

Analogie: Es ist, als würde man feststellen, dass man nicht jedes Mal einen neuen Bibliotheksausweis kaufen muss, wenn man die Bibliothek betritt; man benutzt einfach den, den man bereits hat.

2. Geschwindigkeit ist knifflig (Das „Verkehrs“-Problem)
Während das Sparen von Geld einfach war, war das Sparen von Zeit schwieriger.

Die Überraschung: Manchmal machte das Hervorheben alles (der naive Ansatz) den Assistenten tatsächlich langsamer.
Analogie: Stellen Sie sich einen Lieferfahrer vor, der versucht, die Adresse jedes einzelnen Pakets auswendig zu lernen, das er ausliefert. Wenn er versucht, sich ein Paket auswendig zu merken, das nur ein einziges Mal geliefert wird und nie wieder, verschwendet er Zeit mit dem Auswendiglernen. Wenn das nächste Paket kommt, muss er das alte „ent-auswendig lernen“, um Platz für das neue zu machen. Dieses „Schreiben ins Gedächtnis“ verlangsamt ihn.
Das Paper fand heraus, dass der Assistent schnell bleibt, wenn man nur die stabilen Teile (das Handbuch) hervorhebt und die unordentlichen, sich ändernden Teile (die Telefonergebnisse) unmarkiert lässt.

3. Die Regel „Das Cache nicht kaputt machen“
Die wichtigste Lektion betrifft die Frage, wo man die Grenze zieht.

Wenn man dynamische, sich ändernde Informationen (wie „Aktuelle Zeit: 14:00 Uhr“ oder „User-ID: 123“) in das Handbuch einfügt, bricht der magische Textmarker zusammen. Das System denkt, das Handbuch habe sich geändert, und beginnt wieder von vorne mit dem Lesen.
Die Lösung: Halten Sie das Handbuch rein und statisch. Wenn Sie unbedingt wechselnde Informationen einbauen müssen, platzieren Sie diese am Ende des Handbuchs, wie einen Klebezettel auf der letzten Seite. So bleibt die ersten 99 % des Handbuchs hervorgehoben und wiederverwendbar.

Das Fazendeschlusswort

Für Unternehmen, die KI-Agenten bauen, die lange, komplexe Aufgaben erledigen:

Ja, nutzen Sie Prompt Caching. Es wird Ihre Kosten drastisch senken.
Aber seien Sie klug dabei. Aktivieren Sie es nicht einfach für alles.
Die beste Strategie: Cachen Sie nur das stabile „Handbuch“ (den System-Prompt). Lassen Sie die sich ändernden Teile (Tool-Ergebnisse) frei fließen, ohne sie zu cachen. Dies bietet Ihnen die beste Mischung aus niedrigen Kosten und hoher Geschwindigkeit.

Wenn Sie versuchen, die sich ändernden Teile zu cachen, bezahlen Sie unter Umständen für das „Schreiben“ des Caches, ohne die Vorteile des „Lesens“ zu erhalten, was Ihr System sogar verlangsamen kann.

Technisches Resümee: Don't Break the Cache: Eine Evaluierung von Prompt-Caching für langfristige agentische Aufgaben

Problemstellung

Jüngste Fortschritte bei Large Language Model (LLM) Agenten haben komplexe, mehrstufige agentische Aufgaben ermöglicht, die umfangreiche Tool-Aufrufe beinhalten, wie etwa tiefgehende Recherche oder autonomes Programmieren. Diese Workflows erstrecken sich oft über Dutzende von API-Aufrufen mit Kontextfenstern, die zehntausende von Token akkumulieren, was zu erheblichen Betriebskosten und Latenz-Overhead führt. Während große LLM-Anbieter (OpenAI, Anthropic, Google) Funktionen zum Prompt-Caching anbieten, um zuvor berechnete Key-Value-Tensoren wiederzuverwenden und redundante Berechnungen zu reduzieren, bleibt der spezifische Nutzen dieser Funktionen für agentische Arbeitslasten untererforscht. Die bestehende Literatur konzentriert sich auf das Speichermanagement auf Inferenzebene oder Sicherheitsaudits, lässt jedoch eine quantitative Analyse der Kosteneinsparungen oder vergleichende Evaluierungen von Caching-Strategien für dynamische, mehrstufige Agenten-Sitzungen vermissen.

Methodik

Die Autoren führten eine umfassende Evaluierung des Prompt-Caching über drei große LLM-Anbieter hinweg durch: OpenAI, Anthropic und Google. Die Studie nutzte vier Flaggschiff-Modelle: GPT-5.2, GPT-4o (OpenAI), Claude Sonnet 4.5 (Anthropic) und Gemini 2.5 Pro (Google).

Experimentelles Setup:

Benchmark: Die Evaluierung verwendete den DeepResearch Bench, einen mehrstufigen agentischen Benchmark, bei dem Agenten autonom reale Web-Such-Tool-Aufrufe ausführen, um komplexe Forschungsfragen auf PhD-Niveau zu beantworten.
Skalierung: Die Studie umfasste über 500 Agenten-Sitzungen mit 10.000-Token-Systemprompts. Jedes Modell wurde mit 40 unabhängigen Sitzungen pro Cache-Bedingung getestet.
Caching-Strategien: Die Autoren implementierten und verglichen vier verschiedene Bedingungen, um die Cache-Grenzen präzise mittels eindeutiger Identifikatoren (UUIDs) zu steuern:
1. Kein Cache (Baseline): Eine UUID wird vor den Systemprompt gesetzt, um die Neuberechnung aller Token zu erzwingen, was ein Szenario mit dynamischem Inhalt (z. B. Zeitstempel) simuliert, das den Cache unterbricht.
2. Full Context Caching (Vollständiges Kontext-Caching): Es werden keine UUIDs hinzugefügt, wodurch der automatische Caching-Mechanismus des Anbieters auf den gesamten Gesprächsverlauf, einschließlich dynamischer Tool-Ergebnisse, zugreifen kann.
3. System Prompt Only Caching (Nur Systemprompt-Caching): Eine UUID wird am Ende des Systemprompts angehängt, wodurch sichergestellt wird, dass nur die statischen Systeminstruktionen gecacht werden, während der dynamische Gesprächsverlauf und die Tool-Ergebnisse neu berechnet werden.
4. Exclude Tool Results Caching (Ausschluss von Tool-Ergebnissen beim Caching): UUIDs werden nach dem Systemprompt und nach jedem Tool-Ergebnis angehängt, um explizit zu verhindern, dass dynamische Tool-Ausgaben in den Cache gelangen.

Metriken:
Die Studie maß die API-Kosten (unterschieden zwischen Standard-, Cached-Read- und Cache-Write-Token) und die Time to First Token (TTFT) als primäre Latenzmetrik. Die statistische Signifikanz wurde mittels unabhängiger Stichproben-t-Tests ( $\alpha = 0,05$ ) bestimmt.

Zentrale Beiträge

Erste quantitative Evaluierung: Diese Arbeit liefert die erste umfassende Quantifizierung der Vorteile von Prompt-Caching speziell für langfristige agentische Aufgaben über mehrere Anbieter und Modelle hinweg.
Strategievergleich: Sie vergleicht naives Full-Context-Caching mit strategischen Methoden zur Grenzkontrolle (Systemprompt allein, Ausschluss von Tool-Ergebnissen) und zeigt auf, dass „naive“ Ansätze kontraproduktiv sein können.
Anbieterdifferenzen: Die Studie identifiziert signifikante Unterschiede in der Implementierung des Caching durch die Anbieter, insbesondere hinsichtlich des Umgangs mit dynamischen Inhalten und der daraus resultierenden Auswirkungen auf Llatenz versus Kosten.
Ablations-Erkenntnisse: Durch Ablationsstudien über verschiedene Prompt-Größen (500–50.000 Token) und Tool-Aufruf-Anzahlen (3–50) demonstrieren die Autoren universelle lineare Kosten- und TTFT-Vorteile nach Erreichen anbieterspezifischer Token-Minima.

Ergebnisse

Die Evaluierung lieferte drei primäre Erkenntnisse:

Substanzielle Kostensenkungen: Prompt-Caching reduzierte die API-Kosten konsistent um 41 % bis 80 % über alle Anbieter und Modelle hinweg. Der Haupttreiber dieser Einsparungen war das Caching des großen, stabilen Systemprompts.
Variable Latenzverbesserungen: Die TTFT-Verbesserungen variierten zwischen 13 % und 31 %, abhängig vom Anbieter und der Strategie. Die Latenzgewinne waren jedoch nicht einheitlich; bei einigen Modellen (z. B. GPT-4o) führte Full-Context-Caching zu einer Latenz-Regression von 8,8 %.
Strategische Grenzkontrolle ist entscheidend: Die Studie ergab, dass die strategische Kontrolle der Prompt-Cache-Blöcke dem naiven Full-Context-Caching überlegen ist.
- System Prompt Only und Exclude Tool Results Strategien lieferten die konsistentesten Vorteile.
- Full Context Caching verursachte oft einen Overhead durch das Caching von dynamischen Tool-Aufrufen und -Ergebnissen, die in nachfolgenden Sitzungen nicht wiederverwendet werden, was paradoxerweise die Latenz erhöhte.
- Für GPT-4o verbesserte die beste Strategie (System Prompt Only) die TTFT um 30,9 %, während Full Context Caching die Leistung verschlechterte.

Bedeutung und Behauptungen

Das Paper beansprucht, eine nuancierte Anleitung für die Implementierung von Prompt-Caching in produktiven agentischen Systemen zu liefern. Die Autoren betonen, dass Anwender zwar einen Großteil des Caching-Mechanismus abstrahieren, jedoch eine strategische Kontrolle über die Cache-Grenzen ausüben müssen.

Das Kernargument ist, dass in agentischen Arbeitslasten, in denen der Kontext dynamisch und sitzungsspezifisch ist, das Caching des gesamten Kontextes (naiver Ansatz) nachteilig sein kann. Stattdessen sollten Praktiker sicherstellen, dass nur stabile, wiederverwendbare Inhalte (wie der Systemprompt) gecacht werden, während dynamische Elemente (Tool-Ergebnisse, Gesprächsverlauf) durch explizite Grenzen (z. B. UUIDs) ausgeschlossen werden. Dieser Ansatz maximiert die Kosteneffizienz und die Latenzverbesserungen, indem der Overhead vermieden wird, der durch das Caching von Inhalten entsteht, die nicht wiederverwendet werden. Die Arbeit dient als praktischer Leitfaden für die Optimierung unternehmensweiter agentischer Systeme und hebt hervor, dass die „beste“ Caching-Strategie anbieterspezifisch und vom Optimierungsziel (Kosten vs. Latenz) abhängig ist.