🤖 machine learning

Cache-Aware Prompt Compression:A Two-Tier Cost Model for LLM API Caching

Dieses Paper stellt Cache-Aware Prompt Compression (CAPC) vor, eine Strategie, die abfragenunabhängige Kompression mit expliziter Cache-Steuerung und schichtwahrenden Grenzen kombiniert, um die Einschränkungen abfragespezifischer Methoden zu überwinden und dabei signifikante Kostensenkungen (bis zu 90 %) bei gleichbleibender Qualität über vielfältige produktive LLM-Workloads hinweg zu erreichen.

Ursprüngliche Autoren: Yan Song

Veröffentlicht 2026-07-20

📖 3 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yan Song

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 betreiben eine riesige, superintelligente Bibliothek, in der Ihnen ein sehr teurer Bibliothekar (eine KI) hilft, Antworten zu finden. Um Geld zu sparen, nutzt die Bibliothek zwei spezielle Tricks. Erstens gibt es eine „VIP-Lounge“ (Caching): Wenn Sie den Bibliothekar immer wieder nach demselben Buchkapitel fragen, muss er nicht das ganze Kapitel neu aus den Bibliotheksregalen lesen; er wirft nur einen Blick in seine Notizen, was viel günstiger ist. Zweitens gibt es einen „Zusammenfasser“ (Kompression): Anstatt dem Bibliothekar einen 500-seitigen Roman zu übergeben, geben Sie ihm eine 50-seitige Zusammenfassung, was auch günstiger zu verarbeiten ist.

Lange Zeit dachten die Leute, dass man diese beiden Tricks am besten getrennt voneinander anwendet. Man nutzte entweder die VIP-Lounge für große, langweilige Bücher oder den Zusammenfasser für kurze, knifflige Fragen. Aber hier ist der Haken: Der Zusammenfasser verändert die Geschichte meistens ein wenig jedes Mal, wenn eine neue Frage gestellt wird, um sie besser anzupassen. Das Problem ist, dass die VIP-Lounge eine Regelverliebte ist. Wenn sich die Geschichte auch nur ein winziges Stück verändert, sagt der Bibliothekar: „Tut mir leid, das ist ein neues Buch!“ und wirft Ihre Notizen weg, was Sie dazu zwingt, den vollen Preis zu zahlen, um das Ganze erneut zu lesen. Diese Arbeit stellt eine einfache Frage: Können wir beide Tricks gleichzeitig anwenden, ohne die Regeln zu brechen?

Die Forscher bei PayPal beschlossen, dies an einem realen KI-System namens Sonnet 4.6 zu testen. Sie entdeckten, dass die VIP-Lounge nicht so perfekt ist, wie alle dachten. Sie hat eine „heiße Zone“ für kurze Notizen und eine „persistente Zone“ für lange; wenn man mit seinen Zusammenfassungen zu schlau spielt, wirft man seine Notizen versehentlich aus der teuren heißen Zone hinaus. Sie fanden heraus, dass die alte Methode – die Zusammenfassung für jede einzelne Frage zu ändern – tatsächlich Geld verschwendet, weil sie den Bibliothekar daran hindert, die günstigen Notizen zu verwenden.

Um dies zu beheben, erfanden sie eine neue Strategie namens CAPC (Cache-Aware Prompt Compression). Denken Sie an Folgendes: Anstatt die Geschichte für jede Frage neu zu schreiben, erstellen sie einmalig eine perfekte, komprimierte Zusammenfassung der langweiligen Teile und sperren diese in die VIP-Lounge ein. Dann fügen sie für jede neue Frage einfach die spezifische Frage an diese festgeschriebene Zusammenfassung an, ohne die Zusammenfassung selbst zu verändern. Es ist wie ein vorgefertigtes Skript, das sich nie ändert, sodass der Bibliothekar seine günstigen Notizen jedes Mal wiederverwenden kann.

Die Ergebnisse waren überraschend. In Tests mit 16 verschiedenen Arten von Dokumenten war diese neue Methode jedes einzelne Mal die günstigste Option; sie sparte etwa 49 % im Vergleich zur bloßen Nutzung der VIP-Lounge und 64 % im Vergleich zur alten „Ändere-die-Zusammenfassung“-Methode. Sie testeten es auch bei realen Aufgaben, wie einem Roboter, der Werkzeuge benutzt, um Computercode zu reparieren, und einem System, das durch riesige Wissensgraphen sucht. In einem Fall sparten sie über 50 % der Kosten ein, ohne an Qualität einzubüßen. In einem anderen Fall bewiesen sie, dass die alte „Ändere-die-Zusammenfassung“-Methode tatsächlich 40 % mehr kostete, als gar nichts zu tun, weil sie ständig den Cache unterbrach. Die Arbeit kommt zu dem Schluss, dass wir, indem wir klug entscheiden, wann wir komprimieren und was wir cachen, KI viel günstiger nutzbar machen können, ohne sie dümmer zu machen.

Technisches Resümee: Cache-Aware Prompt Compression (CAPC)

Problemstellung

Moderne Implementierungen von Large Language Models (LLMs) verlassen sich zunehmend auf zwei unterschiedliche Kostenreduktions-Primitive: Prompt-Caching (Speichern der KV-Zustände eines Präfix, um für nachfolgende Lesezugriffe vergünstigte Tarife zu berechnagen) und Prompt-Kompression (Reduzierung der Token-Anzahl des Inputs). Historisch wurden diese Techniken als separate Optimierungen behandelt. Die dominante Literatur zur Prompt-Kompression stützt sich jedoch primär auf abfragespezifische (query-aware) Methoden, die für jede spezifische Abfrage ein einzigartiges komprimiertes Präfix generieren.

Diese Designentscheidung erzeugt einen fundamentalen Konflikt mit präfix-strengen Caching-Mechanismen (z. B. Anthropics cache_control). Da sich das komprimierte Präfix mit jeder Abfrage ändert, wird der Cache-Schlüssel bei jedem Aufruf invalidiert. Infolgedessen zahlt das System für jede Anfrage den vollen, nicht rabattierten Input-Tarif, was die Einsparungen durch sowohl Kompression als auch Caching effektiv zunichtemacht. Während die bestehende Literatur oft von einer idealen Cache-Trefferquote ( $\rho = 1.0$ ) ausgeht, berücksichtigt sie nicht die ökonomische Realität realer APIs, in denen das Cache-Verhalten nicht trivial ist und abfragespezifische Kompression zu einem negativen Return on Investment (ROI) führen kann.

Methodik und empirische Charakterisierung

Die Autoren adressieren diese Lücke durch eine Kombination aus empirischer Messung, Kostenmodellierung und algorithmischem Design.

1. Empirische Charakterisierung von Anthropic Sonnet 4.6

Das Paper charakterisiert zunächst das Caching-Verhalten der Anthropic Sonnet 4.6 API durch kontrollierte Experimente ( $n=3$ Versuche, Gesamtkosten $1,91). Zentrale Erkenntnisse sind:

Zweistufige Architektur: Der Cache ist nicht uniform. Er weist eine scharfe Schwelle nahe 3.500 Tokens auf.
- Hot Tier (< 3,5k Tokens): Die Trefferquote ( $\rho$ ) stagniert bei etwa 0,83 (speziell 0,833 für 2k Tokens) selbst nach 30 Aufrufen. Sie ist nicht 1,0.
- Persistent Tier (> 3,5k Tokens): Die Trefferquote liegt ab dem zweiten Aufruf effektiv bei 1,0.
Token-strikte Invaliderung: Die Cache-Invaliderung ist strikt an die Token-Sequenz gebunden. Selbst minimale Mutationen (z. B. eine einzige Zeichenänderung) führen zu einem Cache-Miss, obwohl führende/folgende Whitespaces durch den Tokenizer normalisiert werden.
Preisstruktur: Die API berechnet einen Aufschlag für Cache-Writes ( $c_w$ ) im Vergleich zu ungesuchten Inputs ( $p_{in}$ ) und einen signifikanten Rabatt für Cache-Reads ( $c_r$ ). Bei Sonnet 4.6 gilt $c_w \approx 1,25 \times p_{in}$ und $c_r \approx 0,10 \times p_{in}$ .

2. Kostenmodellierung und Crossover-Analyse

Die Autoren leiten ein Kostenmodell pro Aufruf für vier Strategien ab:

A (Vanilla): Kein Cache, keine Kompression.
B (Nur Cache): Volles Präfix gecacht, keine Kompression.
C (Abfragespezifische Kompression): Pro Abfrage komprimiert, kein Cache (Cache-Miss bei jedem Aufruf).
D (CAPC): Abfrage-agnostische Kompression + Caching.

Das Modell definiert einen Crossover-Schwellenwert ( $\rho_{cross}$ ), bei dem die Kosten des Cachings (Strategie B) den Kosten der abfragespezifischen Kompression (Strategie C) entsprechen:
$\rho_{cross}(r) = \frac{c_w - p_{in}/r}{c_w - c_r}$
Die Analyse zeigt, dass für hohe Kompressionsraten ( $r \ge 6$ ) die erforderliche Trefferquote für das Caching, um die abfragespezifische Kompression zu schlagen, über der empirischen Plateau-Rate des Sonnet 4.6 Hot Tiers ( $\rho \approx 0,89$ ) liegt. Unter realistischen Bedingungen ist abfragespezifische Kompression also oft günstiger als naives Caching, was der gängigen Lehrmeinung widerspricht.

3. Der CAPC-Algorithmus

Die vorgeschlagene Lösung, Cache-Aware Prompt Compression (CAPC), kombiniert drei Komponenten:

Abfrage-agnostische Kompression: Ein statisches Dokument wird einmalig (z. B. via Satzselektion) in ein festes Präfix $D'$ komprimiert, wodurch der Cache-Schlüssel über alle Abfragen hinweg konstant bleibt.
Tier-erhaltende Ratio-Begrenzung: Um zu verhindern, dass eine Überkompression das Präfix in den "Hot Tier" (wo $\rho < 1$ ) drängt, wird die Kompressionsrate $r$ durch $r_{max} = \lfloor |D| / 3500 \rfloor$ begrenzt. Dies stellt sicher, dass das komprimierte Präfix im Persistent Tier ( $\rho \approx 1,0$ ) verbleibt.
AdaptiveCacheBoundary: Für sich entwickelnde Dokumente klassifiziert eine Subroutine Satzpositionen als STATIC, QUASI oder DYNAMIC basierend auf den Mutationsraten über verschiedene Versionen hinweg, wobei nur das stabile Präfix gecacht wird.

Kernergebnisse

1. LongBench-v2 Synthetische Benchmarks

In 16 Konfigurationen (4 Dokumentgrößen $\times$ 4 Raten) war CAPC die günstigste Strategie in 16/16 Fällen.

Einsparungen: Mittlere Einsparungen von 49% gegenüber Cache-only, 64% gegenüber abfragespezifischer Kompression und 90% gegenüber Vanilla.
Qualität: CAPC hielt die Qualität innerhalb von 0,05 des unkomprimierten Baselines bei tier-erhaltenden Raten.
Crossover-Validierung: Bei $r=6$ war abfragespezifische Kompression in allen 4/4 Konfigurationen günstiger als Cache-only, was die Vorhersage des Crossover-Modells validiert.

2. Produktionsvalidierung: Enterprise Tool-Using Assistant

Validiert auf einem 94k-Token statischen Präfix (System Prompt + 287 MCP Tool-Definitionen).

Kostensenkung: CAPC erreichte bei $r=3$ eine Kostensenkung von 51,7% gegenüber Vanilla.
Qualität: Die Qualität der Tool-Auswahl entsprach der von Cache-only (0,700 vs. 0,703).
Erkenntnis: Abfragespezifische Kompression bei $r=3$ performte bei der Tool-Auswahl sogar schlechter (0,603), da sie relevante Tool-Definitionen für die Abfrage verworf. Der abfrage-agnostische Ansatz von CAPC bewahrte den vollständigen Katalog, was die Überlegenheit für tool-augmentierte Agenten beweist.
Implizites Caching: Die Studie zeigte, dass Anthropic große tools= Arrays implizit cacht, selbst ohne explizite Marker, was den Grenznutzen des expliziten Cachings für Vanilla-Strategien reduziert, aber die Kompressionsgewinne von CAPC nicht aufhebt.

3. Knowledge-Graph RAG (Graphify)

Integriert mit graphify für die Codebase-Indizierung (FastAPI und httpx Repositories).

Architektur: Ebene 1 (gecached, abfrage-agnostisch) enthält Graph-Metadaten; Ebene 2 (pro Abfrage) ruft den Quellcode ab.
Performance: CAPC lieferte eine 9,3-fache Kostensenkung bei FastAPI und eine 2,4-fache bei httpx im Vergleich zu "Cache-all" (vollständiges Graph-Skelett), während stabile 85%+ Cache-Trefferquoten beibehalten wurden.
Qualität: CAPC übertraf native Graphify-Abfragen und Embedding-RAG-Baselines, insbesondere bei Codebases, bei denen das Modell schwächeres Vorwissen hatte (httpx), und lieferte einen 142% Qualitätszuwachs gegenüber Vanilla.

4. Öffentlicher Benchmark: $\tau$ -Bench Retail

Evaluiert auf 50 deterministischen Aufgaben mit Datenbank-Status-Belohnungen (kein LLM-Judge).

Ergebnis: CAPC war die günstigste Strategie, sparte 7,9% gegenüber Vanilla ein und erreichte dabei exakt dieselbe Erfolgsrate (36/50) wie Vanilla ( $z=0,00, p=1,00$ ).
Negativer ROI von Query-Aware: Abfragespezifische Kompression war 40,1% teurer als Vanilla, was die erste Bestätigung in der Produktion liefert, dass abfragespezifische Methoden einen negativen ROI auf öffentlichen Benchmarks haben können.

Bedeutung und Ansprüche

Das Paper beansprucht, die erste systematische Charakterisierung der Ökonomie von Prompt-Caching zu liefern, die über die idealisierte $\rho=1,0$ Annahme hinausgeht. Die primären Beiträge sind:

Empirische Realität: Nachweis, dass LLM-Caches eine zweistufige Architektur mit einer nicht-trivialen Trefferraten-Plateau unterhalb eines bestimmten Token-Schwellenwerts besitzen.
Theoretische Inversion: Beweis, dass bei hohen Kompressionsraten abfragespezifische Kompression oft günstiger ist als naives Caching, was die konventionelle Design-Hierarchie umkehrt.
Praktischer Algorithmus: Einführung von CAPC, das abfrage-agnostische Kompression mit explizitem Caching und einer tier-erhaltenden Beschränkung vereint.
Produktionsvalidierung: Validierung dieser Erkenntnisse über synthetische Benchmarks, Enterprise Tool-Use Agenten, Knowledge-Graph RAG-Pipelines und öffentliche deterministische Benchmarks hinweg.

Die Autoren betonen, dass CAPC kein Ersatz für Indexer (wie graphify) ist, sondern eine ergänzende "Last-Mile Delivery"-Schicht, die die ökonomischen Kosten der Bereitstellung von index-basiertem Kontext an ein LLM optimiert. Die Gesamtkosten aller empirischen Arbeiten in diesem Paper beliefen sich auf $98,96, was zeigt, dass diese Ergebnisse mit moderaten Ressourcen reproduzierbar sind.