Context Caching

Context Caching bezeichnet einen Zwischenspeicher (Cache) beim KI-Anbieter, der den vorderen, gleichbleibenden Teil einer Anfrage an ein Sprachmodell (den Prompt-Prefix) über mehrere Aufrufe hinweg wiederverwendet. Statt jede Anfrage von vorn zu berechnen, liest der Anbieter das Zwischenergebnis aus dem Cache. Für den gecachten Anteil sinkt der Preis pro Wortbaustein (Token) typischerweise auf 10 bis 50 Prozent des normalen Satzes, und die erste Antwortsilbe erscheint schneller.

Was ist Context Caching?

Ein großes Sprachmodell (Large Language Model, LLM) rechnet bei jedem Aufruf zunächst eine interne Zwischen-Repräsentation für jeden Wortbaustein (Token) der Anfrage aus. Diese Rechenarbeit heißt in der Fachsprache Key-Value-Aktivierung, wächst linear mit der Länge der Anfrage und ist der teure Teil eines Modell-Aufrufs (Inference). Bleibt der vordere, gleichbleibende Teil einer Anfrage (der Prompt-Prefix, also etwa System-Anweisung plus statische Dokumente) zwischen zwei Aufrufen wortgleich, sind auch diese Zwischenergebnisse identisch. Context Caching nutzt das aus: Der Anbieter legt die Zwischenergebnisse nach dem ersten Aufruf in einem Cache ab und liest sie beim zweiten Aufruf, statt sie neu zu berechnen. Der Schlüssel zum Cache ist eine Prüfsumme (Hash) über den Prefix; ein einziges geändertes Zeichen im Prefix macht den Cache-Eintrag ungültig.

Der Begriff kursiert bei mehreren Anbietern unter unterschiedlichem Produktnamen, bezeichnet aber dieselbe Mechanik. Anthropic nennt das Feature [Prompt Caching](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching) und verlangt Opt-in über Cache-Breakpoints im API-Call, mit 5-Minuten- oder 1-Stunden-TTL (Time-to-Live, Cache-Lebensdauer). Google Gemini bietet [Context Caching](https://ai.google.dev/gemini-api/docs/caching) als explizite Cache-Ressource mit minutengenauer Laufzeit. OpenAI aktiviert [Prompt Caching](https://platform.openai.com/docs/guides/prompt-caching) automatisch für Prompts ab rund 1024 Tokens, ohne Konfiguration im Client. DeepSeek fährt einen ähnlichen automatischen Cache mit Fokus auf disk-basierte Persistenz.

Der Begriff existiert, weil Long-Context-Anwendungen (RAG-Stacks mit großen Dokument-Blöcken, Agenten mit langen System-Prompts, Multi-Turn-Chats mit wachsender Historie) Millionen wiederholter Input-Tokens durch die Token-Abrechnung schicken. Ohne Cache wird jeder identische Prefix bei jedem Call neu berechnet und neu abgerechnet. Context Caching macht diesen wiederkehrenden Anteil als eigene, günstigere Kostenkategorie sichtbar. Preisrelationen liegen bei den großen Anbietern in vergleichbaren Regionen: ein Cache-Write kostet etwa 125 Prozent eines normalen Input-Tokens, ein Cache-Read etwa 10 Prozent. Der Break-Even hängt an der Cache-Hit-Rate über die TTL.

Abgrenzung zu KV-Caching, Semantic Caching, Response Caching und Prompt Caching

Der Begriff wird häufig mit angrenzenden Cache-Konzepten vermischt. Die relevanten Trennlinien:

Die zentrale Trennlinie verläuft zwischen KV-Caching und Context Caching, weil beide dieselbe interne Datenstruktur nutzen. KV-Caching lebt in der Inference-Engine und optimiert die Generierung eines einzelnen Aufrufs; Prefill und Decode teilen sich die berechneten Aktivierungen. Context Caching hebt diese Aktivierungen aus dem Aufruf heraus, persistiert sie über eine TTL und macht sie über die API adressierbar. DeepSeek nennt sein Feature in der Doku explizit „Context Caching on Disk" und macht die Persistenz-Ebene damit sichtbar.

Semantic Caching und Response Caching operieren auf einer anderen Ebene: Sie speichern fertige Modell-Ausgaben, nicht Zwischenzustände. Semantic Caching ist damit sensibel für Halluzinationen (eine falsche Antwort bleibt gecached) und für Modell-Updates (der Cache muss beim Modellwechsel invalidiert werden). Context Caching hat diese Probleme nicht, weil das Modell in jedem Call frisch generiert; nur der Rechenweg zum Prefix wird abgekürzt.

Beispiel: RAG-Assistent mit statischem Kontext

Ein Wissensassistent kombiniert bei jedem Aufruf drei Blöcke: einen 8.000-Token-Systemprompt (Tonalität, Compliance-Regeln, Persona), 4.000 Tokens Tool-Definitionen und einen 30.000-Token-Dokumenten-Block (Top-Chunks aus dem Vektorindex). Die eigentliche Nutzerfrage umfasst 80 Tokens. Ohne Cache werden bei jedem Call 42.080 Input-Tokens abgerechnet; davon sind rund 41.920 Tokens identisch mit dem vorherigen Aufruf.

Mit Anthropic Prompt Caching setzt der Entwickler drei Cache-Breakpoints im API-Call: nach dem Systemprompt, nach den Tool-Definitionen und nach dem Dokumenten-Block. Der erste Call zahlt den Cache-Write-Aufschlag auf die 41.920 Prefix-Tokens (rund 125 Prozent des normalen Input-Preises) plus die 80 Query-Tokens zum normalen Preis. Jeder weitere Call innerhalb der 5-Minuten-TTL zahlt den Cache-Read-Preis auf die 41.920 Tokens (rund 10 Prozent) plus die neue Query. Bei einer stabilen Hit-Rate über 60 Prozent liegt die Kostenreduktion für den gecachten Anteil im Bereich von 50 bis 90 Prozent.

Die Architekturposition ist damit klar: Context Caching sitzt zwischen Prompt-Design und Anbieter-Abrechnung. Es setzt voraus, dass der Prompt in einen stabilen Prefix (System, Tools, statische Dokumente) und eine variable Query (Nutzerfrage, dynamische Filter) getrennt ist. Vermischt das Prompt-Template statische und variable Bestandteile, greift der Cache nicht. Das ist ein Grund, warum Context Caching in produktiven RAG-Stacks oft ein Refactoring des Prompt-Aufbaus nach sich zieht.