In den meisten produktiven LLM-Anwendungen macht der System-Prompt, die Kontext-Dokumentation oder der Gesprächsverlauf den Großteil des Eingabetexts bei jedem Aufruf aus. Hat Ihr System-Prompt tausend Tokens und Sie bedienen täglich zehntausend Anfragen, zahlen Sie für zehn Millionen Tokens — von denen die meisten jedes Mal derselbe Text sind. Prompt Caching löst dieses Problem auf Infrastrukturebene: Der Provider speichert die KV-Repräsentation wiederkehrender Prefixe und berechnet sie bei weiteren Aufrufen nicht erneut.
Dieser Artikel erklärt, wie Prompt Caching unter der Haube funktioniert, unter welchen Bedingungen es Kosten und Latenz spürbar senkt, was konkret zu cachen ist und wann Caching umgekehrt nicht hilft — oder sogar Mehrkosten erzeugt. Das hängt auch damit zusammen, wie man Prompts entwirft, die sich gut cachen lassen — ein Punkt, den viele Teams übersehen.
Wie Prompt Caching funktioniert
Wenn Sie einen Request an die LLM-API senden, berechnet das Modell für jeden Eingabe-Token den sogenannten KV-Cache (Key-Value-Vektoren) — das ist die Grundlage des Self-Attention-Mechanismus, über den das Modell Zusammenhänge zwischen Tokens auswertet. Diese Berechnung ist nicht kostenlos: Es ist GPU-Arbeit, die Preis und Time to First Token (TTFT) direkt beeinflusst.
Prompt Caching (auch Context Caching oder Prefix Caching genannt) besagt: Ist der Anfang des Prompts — das Prefix — über mehrere Aufrufe hinweg identisch, berechnet der Provider die KV-Repräsentation einmal, speichert sie auf dem Server und lädt sie bei weiteren Requests einfach, anstatt sie neu zu berechnen. Aus Sicht des Aufrufers ist das transparent — die Antworten sind genauso korrekt, nur günstiger und schneller.
Was das in Zahlen bedeutet:
- Bei Anthropic: Cache Read = 10 % des normalen Eingabe-Token-Preises (90 % Ersparnis); Cache Write = 125–200 % des normalen Eingabe-Token-Preises (leichter Aufpreis beim ersten Schreibvorgang)
- Bei OpenAI: automatisch, Cache Read = 50 % des Eingabe-Token-Preises; kein expliziter Code seitens des Aufrufers nötig
- Reale Einsparung in Produktion: typischerweise 50–70 % der Gesamtkosten für Eingabe-Tokens bei Workloads mit langen, wiederkehrenden Prefixen
Die Ökonomie sieht also so aus: Beim ersten Aufruf zahlen Sie etwas mehr für den Cache Write, doch jedes weitere Lesen desselben Prefix ist deutlich günstiger. Der Gewinn setzt ab dem zweiten Lesezugriff ein — bei Tausenden Aufrufen täglich ist die Ersparnis erheblich.
TTL und Prefix-Konsistenz
Ein gecachtes Prefix hält nicht ewig. Anthropic bietet TTL (Time-to-Live) von 5 Minuten oder 1 Stunde an — nach Ablauf wird der Cache invalidiert und das Prefix beim nächsten Aufruf neu berechnet (erneut Cache Write). OpenAI verwaltet die TTL automatisch ohne explizite Einstellung.
Daraus ergeben sich zwei praktische Konsequenzen. Erstens: Wenn Requests mit demselben Prefix in kurzen Abständen eintreffen (etwa innerhalb von Sekunden oder Minuten), funktioniert Caching gut. Kommen die Requests über den Tag verteilt mit stündlichen Pausen und Sie verwenden einen 5-Minuten-TTL, wird der Cache regelmäßig invalidiert. Zweitens: Das Prefix muss byte-for-byte identisch sein. Selbst eine kleine Änderung (ein anderes Leerzeichen, ein anders formatiertes Datum im System-Prompt) macht die gesamte gecachte Repräsentation ungültig und löst einen neuen Cache Write aus.
Was sich zu cachen lohnt
Nicht jeder Text im Prompt lohnt das Cachen. Die Auswahl folgt einer einfachen Logik: Cachen lohnt sich für das, was lang, statisch und wiederholt verwendet wird.
System-Prompt. Der offensichtlichste Kandidat. Haben Sie 500–2 000 Tokens System-Anweisungen (Rolle, Kontext, Verhaltensregeln, Few-Shot-Beispiele), ändern sich diese in den meisten Anwendungen überhaupt nicht oder nur selten. Legen Sie sie als festes Prefix am Anfang des Prompts ab — Caching deckt sie automatisch ab.
Gemeinsame Dokumente und Normen. Enthält jeder Request dieselbe technische Dokumentation, ISO-Norm, Unternehmensvorschriften oder ein juristisches Dokument als Referenzkontext, ist das ein idealer Kandidat. Wir haben Deployments gesehen, bei denen ein 300-seitiges technisches Handbuch in jeden Aufruf eines Kunden-Chatbots eingefügt wurde — Caching hat die Kosten dort um mehr als 80 % gesenkt.
Langer Gesprächsverlauf. Bei Multi-Turn-Chats sendet die Anwendung mit jedem neuen Request den gesamten bisherigen Verlauf. Der ältere Teil des Verlaufs ändert sich nicht — es ist ein wachsendes, stabiles Prefix. Caching funktioniert hier, solange die Anwendung die Konversation konsistent formatiert und Nachrichten nicht umsortiert.
Few-Shot-Beispiele. Verwenden Sie in Ihrem System-Prompt mehrere längere Eingabe-Ausgabe-Beispiele (sogenanntes Few-Shot Prompting), sind auch diese statisch und wiederholbar. Nehmen Sie sie in das gecachte Prefix auf.
Was sich umgekehrt nicht zu cachen lohnt:
- Kurze oder einmalige Prompts — Sie zahlen den Cache Write, ziehen aber nie einen Gewinn heraus
- Prompts, bei denen sich jeder Request von Anfang an unterscheidet (etwa bei der Generierung variabler Reports ohne gemeinsames Prefix)
- Systeme mit inkonsistenter Formatierung — eine zufällige Änderung der Parametreihenfolge im System-Prompt genügt, um den Cache zu invalidieren
Wie man Prompts für Caching entwirft
Eines der häufigsten Versäumnisse, auf das wir bei der Überprüfung bestehender Anwendungen stoßen: Teams schalten Caching ein, aber die Prompt-Struktur ist nicht dafür ausgelegt, es effektiv zu nutzen.
Grundregel: Statisches vor Dynamischem. Caching deckt das Prefix ab — den Anfang des Prompts. Daher muss alles, was sich per Request ändert (die konkrete Frage des Nutzers, variable Parameter, das aktuelle Datum), am Ende des Prompts stehen. Fügen Sie ein dynamisches Element in die Mitte eines statischen Kontexts ein, ändert sich das Prefix bei jedem Aufruf, und Caching greift nicht.
Beispiel für die falsche Reihenfolge:
System-Prompt (statisch)
↓
Aktuelles Datum und Nutzername (dynamisch — ändert sich bei jedem Request)
↓
Technisches Handbuch (statisch, 800 Tokens)
↓
Nutzerfrage (dynamisch)In diesem Beispiel macht das dynamische Element in der Mitte das Caching für das gesamte technische Handbuch darunter wirkungslos.
Richtige Reihenfolge:
System-Prompt (statisch)
↓
Technisches Handbuch (statisch, 800 Tokens)
↓
Aktuelles Datum und Nutzername (dynamisch)
↓
Nutzerfrage (dynamisch)Der statische Block ist jetzt ein zusammenhängendes Prefix — der Provider cached es, und dynamische Elemente beeinflussen es nicht.
Stabile Formatierung. Generiert Ihr System-Prompt Code, vermeiden Sie es, variable Werte (Timestamp, Version) direkt in den statischen Teil einzubetten. Statt Aktuelle Systemversion: 2.4.1 (deployed 2026-03-20) verwenden Sie Aktuelle Systemversion: {version} und fügen den Wert erst in den dynamischen Teil oder besser in die User Message ein.
Auf On-Prem (vLLM, SGLang) gelten dieselben Prinzipien. Sowohl vLLM als auch SGLang implementieren Prefix Caching auf eigene Weise — SGLang über RadixAttention (LRU-Baum von KV-Caches), vLLM über PagedAttention mit prefix-bewusstem Block-Management. Beide Frameworks erkennen wiederkehrende Prefixe automatisch und wiederholen deren Berechnung nicht. Details unterscheiden sich, aber das Designprinzip — Statisches vor Dynamischem — gilt gleichermaßen. Mehr zur Wahl des Serving-Frameworks finden Sie in vLLM vs SGLang vs Ollama.
Wann Caching deutlich hilft — und wann nicht
Ein einfacher Test: Berechnen Sie, wie viel Prozent der Eingabe-Tokens ein wiederkehrendes statisches Prefix ausmacht. Liegt der Wert über 50 %, ist Caching wahrscheinlich eine sinnvolle Investition. Ist jeder Request einzigartig, hilft Caching nicht.
Szenarien mit hoher Ersparnis:
- RAG mit langem Kontext. Anwendungen, die bei jedem Aufruf dieselbe gemeinsame Dokumentation als Kontext einfügen (Unternehmensvorschriften, Handbücher, Normen). Der gecachte Kontext wird für 10 % des Preises geladen.
- Kundensupport mit langen System-Prompts. Ein typischer produktiver Kunden-Chatbot hat einen System-Prompt von 500–1 500 Tokens, der Produkt, Regeln, Ton und Beispiele beschreibt. Bei Tausenden Aufrufen täglich ist die Ersparnis erheblich.
- Multi-Turn-Agenten mit wachsendem Verlauf. Konversationssitzungen, bei denen der Verlauf in den Kontext geschrieben wird. Der ältere Teil des Verlaufs wird zum stabilen Prefix — Caching wächst hier organisch mit der Länge der Konversation. Das hängt direkt damit zusammen, wie man Kosten eines KI-Agenten in Produktion steuert.
- Batch-Verarbeitung von Dokumenten mit gemeinsamen Anweisungen. Verarbeiten Sie Tausende von Rechnungen, Serviceberichten oder Bestellungen mit denselben Extraktionsanweisungen, werden die Anweisungen gecacht, und Sie zahlen nur für die eigentlichen Dokumente.
Szenarien mit geringer oder keiner Ersparnis:
- Generative One-Shot-Aufgaben. Schreiben Sie mir eine Annotation zu diesem Video, übersetzen Sie diesen Text, generieren Sie einen Bericht — jeder Request ist auch im Systemteil einzigartig. Den Cache Write zahlen Sie extra, ziehen aber nie einen Gewinn heraus.
- Workload mit niedrigem Volumen. Macht die Anwendung hundert Aufrufe am Tag, sind die absoluten Einsparungen gering. Der Aufwand für die Implementierung (Refaktorisierung der Prompts, Monitoring der Hit Rate) amortisiert sich möglicherweise nicht.
- Kurze System-Prompts. Hat Ihr System-Prompt 50 Tokens, ist die Mindestgröße für Caching (Anthropic verlangt ein Prefix von mindestens 1 024 Tokens) nicht einmal erfüllt.
Effizienz des Cachings messen
Ein Deployment ohne Messung ist Navigation im Blindflug. Drei Metriken, die es zu verfolgen gilt:
Cache Hit Rate. Das Verhältnis von Requests, bei denen das Prefix aus dem Cache geladen wurde, zur Gesamtzahl der Requests. Anthropic gibt in der API-Antwort cache_read_input_tokens und cache_creation_input_tokens zurück. OpenAI liefert cached_tokens im Usage-Objekt. Ziel: Bei korrekt strukturierten Prompts sollte die Hit Rate bei stabilem Workload 80–95 % betragen.
Durchschnittliche Eingabe-Tokens pro Request. Funktioniert Caching, sinkt der effektive Preis der Eingabe-Tokens — Cache-Read-Tokens werden günstiger verrechnet. Verfolgen Sie den gleitenden Durchschnitt der Eingabekosten pro Request über die Zeit.
TTFT (Time to First Token). Ein gecachtes Prefix eliminiert die Neuberechnung und verkürzt damit die TTFT. Sehen Sie eine bimodale Latenzverteilung (manche Requests schneller, andere langsamer), ist das wahrscheinlich eine Folge des Unterschieds zwischen Cache Hit und Cache Miss.
Nehmen Sie diese Metriken in Ihre Observability-Pipeline auf — etwa über strukturierte Logs oder das Tracking in Agent Observability und Tracing.
Vergleich der Cloud-Provider
Die Ansätze unterscheiden sich auch in Implementierungsdetails, was beeinflusst, wie Sie Caching gestalten.
Anthropic (Claude): Explizit — im Request müssen Sie die Blöcke, die Sie cachen möchten, mit dem Parameter cache_control markieren. Das gibt Ihnen Kontrolle darüber, was genau gecacht wird. TTL 5 Minuten oder 1 Stunde (je nach Einstellung). Minimum für Caching: 1 024 Tokens. Cache Write kostet 125–200 % des normalen Eingabe-Token-Preises; Cache Read 10 %.
OpenAI (GPT): Implizit — automatisch, ohne Code. Der Provider erkennt wiederkehrende Prefixe selbstständig und cached sie. Cache Read = 50 % des Eingabe-Token-Preises. Einfacher zu aktivieren, weniger Kontrolle darüber, was gecacht wird.
Google (Gemini): Explizites Context Caching über API, ähnlich wie Anthropic. Längerer TTL — Stunden bis Tage. Geeignet für sehr stabile, lange Kontexte (vollständige Handbücher, Codebasen).
On-Prem (vLLM, SGLang): Prefix Caching ist eingebaut und läuft bei wiederkehrenden Prefixen automatisch. Sie zahlen keinen Aufpreis für den Write — die Compute-Kosten sind Ihre eigenen, aber bei wiederholten Prefixen spart das Serving-Framework GPU-Zeit, was den Durchsatz erhöht und die Latenz senkt. Dieser Vorteil ist entscheidend beim privaten Deployment mit eigener Hardware.
Häufige Fragen
Ist Prompt Caching sicher — bleiben meine Daten auf dem Server des Providers?
Ja, die gecachte KV-Repräsentation verbleibt während des TTL-Fensters auf den Servern des Providers. Für die meisten Unternehmen ist das kein Problem — API-Aufrufe gehen ohnehin dorthin. Für Organisationen mit strengen Data-Residency-Anforderungen (Krankenhäuser, Banken, regulierte Branchen) ist On-Prem-Serving mit vLLM oder SGLang die bessere Wahl, bei der der Cache vollständig unter Ihrer Kontrolle bleibt. Mehr dazu in On-Prem LLM für regulierte Branchen.
Kann Caching die Antwortqualität negativ beeinflussen?
Nein — Caching beeinflusst nur, wie schnell die KV-Vektoren für das Prefix in den Speicher gelangen, nicht deren Werte. Das Modell erhält denselben Kontext, unabhängig davon, ob das Prefix neu berechnet oder aus dem Cache geladen wurde. Die Antworten sind identisch.
Lohnt sich Caching für eine kleine Anwendung mit ein paar Hundert Aufrufen täglich?
Das hängt von der Länge des System-Prompts und dem Modellpreis ab. Bei einem 1 000-Token-System-Prompt und 500 Aufrufen täglich mit einem Frontier-Modell liegen die monatlichen Einsparungen im einstelligen Euro-Bereich — an der Grenze, ob sich das Refaktorisieren des Codes lohnt. Bei 50 000 Aufrufen täglich und einem 2 000-Token-Prompt sind die Einsparungen im dreistelligen Euro-Bereich monatlich und mehr — dort macht es eindeutig Sinn.
Was, wenn mein System-Prompt stündlich aktualisiert werden muss (etwa weil ich aktuelle Uhrzeit oder Lagerbestand einfüge)?
Das ist eine klassische Falle. Befindet sich der dynamische Wert innerhalb des gecachten Blocks, macht jede Änderung den Cache ungültig. Lösung: Ziehen Sie den dynamischen Wert aus dem gecachten Prefix heraus, in die User Message oder in einen nicht gecachten Block am Ende des Prompts. Der gecachte System-Prompt bleibt unverändert, der dynamische Wert wird separat daneben eingefügt.
Funktioniert Prompt Caching auch bei Verwendung von strukturiertem Output (JSON Mode)?
Ja. Caching ist unabhängig vom Ausgabeformat. Das gecachte Prefix kann eine Kombination aus System-Anweisungen und JSON-Schema sein, solange dieses statisch ist — das Modell generiert danach, die Cache Hit Rate ändert sich nicht. Mehr zu strukturiertem Output in Structured Outputs und JSON Mode.
Fazit
Prompt Caching ist keine Revolution — es ist eine Infrastrukturoptimierung, die still und zuverlässig funktioniert, sofern die Anwendung dafür ausgelegt ist. Drei Dinge sind entscheidend: das statische Prefix in den eigenen Prompts identifizieren, es konsistent an den Anfang stellen und die Hit Rate messen. Bei Workloads mit Tausenden täglichen Aufrufen und langen gemeinsamen Kontexten kann diese Änderung die LLM-API-Rechnung um Dutzende Prozent senken — ohne jeden Eingriff in die Anwendungslogik.
*Bei MP Industrial Solutions stoßen wir bei der Überprüfung von LLM-Anwendungen unserer Kunden regelmäßig auf Prompt-Strukturen, bei denen Caching nicht genutzt wird — oder bei denen ein dynamisches Element inmitten des statischen Kontexts den gesamten Effekt zunichtemacht. Wenn wir uns Ihre Anwendung ansehen und konkrete Einsparungspotenziale identifizieren sollen, kommen wir gerne zu einem Beratungsgespräch zusammen.*