Prompt Caching: Definition, Mechanik, Provider-Vergleich

Prompt Caching ist ein Rabatt-Mechanismus grosser KI-Anbieter: Wiederholt sich der Anfang einer Anfrage an ein Sprachmodell (also der Prompt-Präfix, zum Beispiel Rollen-Anweisung, Werkzeug-Beschreibungen oder feste Hintergrund-Dokumente), speichert der Anbieter das Zwischen-Ergebnis und liest es beim nächsten Aufruf, statt es neu zu berechnen. Der wiederverwendete Anteil wird deutlich günstiger abgerechnet (typisch 10 bis 50 Prozent des normalen Preises pro Wort-Baustein), und die erste Antwort kommt schneller.

Was ist Prompt Caching?

Ein grosses Sprachmodell (Large Language Model, LLM) verarbeitet jeden eingehenden Text zunächst in eine interne Repräsentation: Für jedes Token (die kleinste Verarbeitungseinheit, meist ein Wortteil) berechnet das Modell einen Satz interner Werte, mit denen es später weiterrechnet. Diese Vorbereitung ist der teure Teil eines Modell-Aufrufs und wächst linear mit der Länge der Anfrage. Bleibt der Anfang der Anfrage (also der Präfix) zwischen zwei Aufrufen exakt gleich, ist auch das Zwischen-Ergebnis exakt gleich. Prompt Caching nutzt genau diesen Umstand: Der Anbieter legt das Zwischen-Ergebnis nach dem ersten Aufruf ab und liest es beim zweiten Aufruf aus dem Zwischenspeicher (dem Cache), statt es neu zu berechnen. Der Cache erkennt Treffer über einen Fingerabdruck des Präfix; ein einziges verändertes Zeichen macht den Eintrag ungültig.

Der Begriff ist bei Anthropic und OpenAI der offizielle Produktname. Anthropic verlangt Opt-in über Cache-Breakpoints (cache_control: {"type": "ephemeral"}) mit 5-Minuten- oder 1-Stunden-TTL (Time-to-Live, Cache-Lebensdauer) und einer Mindestlänge von 1.024 Token für Sonnet und Opus. OpenAI aktiviert den Cache laut [OpenAI-Prompt-Caching-Guide](https://platform.openai.com/docs/guides/prompt-caching) automatisch ab rund 1.024 Token Präfix-Länge mit 50 Prozent Rabatt auf den gecachten Anteil und einem optionalen prompt_cache_key als Routing-Hint. Google Gemini bietet dieselbe Mechanik unter dem Namen [Gemini Context Caching](https://ai.google.dev/gemini-api/docs/caching) als explizite Cache-Ressource mit eigener Storage-Abrechnung und einer Mindestlänge von 32.768 Token. Databricks Foundation Model Serving und AWS Bedrock exponieren modell-abhängige Prefix-Caching-Varianten.

Der Begriff existiert, weil Long-Context-Anwendungen (RAG-Stacks mit großen Dokument-Blöcken, Agent-Loops mit langen System-Prompts, Multi-Turn-Chats) Millionen wiederkehrender Input-Tokens durch die Abrechnung schicken. Prompt 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 bei Anthropic rund 125 Prozent eines normalen Input-Tokens, ein Cache-Read rund 10 Prozent; OpenAI verzichtet auf den Write-Aufpreis und rabattiert Reads mit 50 Prozent. Der Break-Even hängt an der Cache-Hit-Rate: Ab dem zweiten Read innerhalb der TTL trägt der Cache.

Abgrenzung zu Context Caching, KV-Caching und Semantic Cache

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

Begriff	Ebene	Verhältnis zu Prompt Caching
Context Caching	Anbieter-API, generischer Oberbegriff	Bezeichnet dieselbe Mechanik provider-übergreifend und ist zugleich der Produktname bei Google Gemini. Terminologische Doppelung ohne technische Trennlinie.
KV-Caching	Inference-Engine (vLLM, TensorRT-LLM, SGLang)	Optimiert die Token-Generierung innerhalb eines einzelnen Aufrufs. Prompt Caching persistiert dieselbe Datenstruktur über mehrere Aufrufe hinweg.
Semantic Caching	Antwort-Ebene, Vektor-Vergleich	Speichert fertige Antworten und liefert sie bei semantisch ähnlicher Anfrage aus. Prompt Caching operiert auf Präfix-Ebene, das Modell generiert weiterhin frisch.
Response Caching	Antwort-Ebene, exakte Übereinstimmung	Cache-Treffer nur bei bit-identischer Anfrage. Kollidiert mit RAG-Patterns, die jede Anfrage einzeln beantworten.
Context Window	Modell-Eigenschaft	Die maximale Prompt-Länge. Prompt Caching senkt Kosten innerhalb eines gegebenen Windows, erweitert es aber nicht.

Die zentrale Trennlinie verläuft zwischen Prompt Caching und KV-Caching, weil beide dieselbe interne Datenstruktur nutzen. Der KV-Cache lebt in der Inference-Engine und optimiert die Generierung eines einzelnen Aufrufs. Prompt Caching hebt diese Aktivierungen aus dem Aufruf heraus, persistiert sie über eine TTL und macht sie über die API adressierbar. Unter dem Produktnamen von Anthropic, OpenAI und Google Gemini liegt jeweils ein KV-Cache mit Prefix-Sharing.

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

Beispiel: Agent-Loop mit stabilem System-Prompt und Tool-Spec

Ein Agent kombiniert bei jedem Tool-Call drei Blöcke: einen 6.000-Token-System-Prompt (Rolle, Tonalität, Compliance-Regeln), eine 2.000-Token-Tool-Spec (Function-Signaturen für die verfügbaren Tools) und einen 200-Token-User-Input mit der Zwischenfrage. Ohne Cache werden pro Call 8.200 Input-Tokens abgerechnet, davon 8.000 identisch mit dem vorherigen Aufruf.

Mit Anthropic Prompt Caching setzt der Entwickler einen Cache-Breakpoint hinter der Tool-Spec. Der erste Call zahlt den Write-Aufpreis auf 8.000 Präfix-Token (rund 125 Prozent) plus 200 Query-Tokens zum normalen Preis. Jeder weitere Call innerhalb der 5-Minuten-TTL zahlt den Read-Preis auf die 8.000 Präfix-Tokens (rund 10 Prozent) plus die neue Query. Bei zehn Tool-Calls pro Agent-Session liegt die Kostenreduktion für den Präfix-Anteil im Bereich von 70 bis 90 Prozent. Beobachten lässt sich das Ergebnis über die Response-Felder cache_creation_input_tokens und cache_read_input_tokens.

Die Architekturposition ist damit klar: Prompt Caching sitzt zwischen Prompt-Design und Anbieter-Abrechnung. Es setzt voraus, dass der Prompt in einen stabilen Präfix (System, Tools, statische Dokumente) und eine variable Query getrennt ist. Vermischt das Template statische und variable Bestandteile (Timestamp im System-Prompt, Session-ID vor der Tool-Spec), greift der Cache nicht. Ein weiterer Bruch entsteht bei Modell-Wechseln: Jedes Ziel-Modell hält seinen eigenen Cache, jeder Routing-Switch schreibt einen frischen Eintrag und verliert die bisherige Hit-Rate.