Prompt Caching kann wiederholte Verarbeitung grosser, identischer Kontextblöcke reduzieren. Es funktioniert besonders gut bei stabilen Systemanweisungen, Tool-Definitionen, Richtlinien oder umfangreichen Dokumenten, die für viele Anfragen gleich bleiben.
Der schwierige Teil ist nicht das Einschalten. Der schwierige Teil ist eine Promptstruktur, bei der stabile und veränderliche Inhalte sauber getrennt sind.
Welche Inhalte eignen sich?
Ein guter Cache-Kandidat wird häufig wiederverwendet und ändert sich selten. Dazu können gehören:
- Systemanweisungen und Ausgabeformate,
- feste Tool-Schemas,
- freigegebene Richtlinien,
- grosse Referenzdokumente,
- wiederkehrende Beispiele.
Benutzereingaben, aktuelle Daten und aufgabenspezifische Retrieval-Ergebnisse gehören in den variablen Teil. Je früher sich ein Prompt unterscheidet, desto kleiner kann der wiederverwendbare Präfix sein.
Promptaufbau für Cache-Treffer
Ordnen Sie stabile Inhalte zuerst und halten Sie ihre Reihenfolge konsistent. Kleine Änderungen an einem frühen Block können dazu führen, dass nachfolgende Inhalte erneut verarbeitet werden müssen.
Versionieren Sie Systemprompts und Tool-Schemas. So lässt sich ein Cache-Treffer einer bekannten Konfiguration zuordnen und bei Änderungen gezielt ungültig machen.
Invalidierung ist eine fachliche Regel
Ein Cache darf nicht nur nach Zeit ablaufen. Richtlinien, Preise, Berechtigungen oder Produktinformationen können sich ändern. Definieren Sie Ereignisse, die eine neue Version erzwingen.
Besonders kritisch sind Berechtigungen. Ein gecachter Kontext, der für Rolle A erlaubt war, darf nicht automatisch für Rolle B wiederverwendet werden. Der Cache-Key muss die relevanten Zugriffs- und Datenklassen abbilden.
Provider-Caching und semantischen Cache trennen
Provider-Prompt-Caching spart die wiederholte Verarbeitung identischer Präfixe. Ein semantischer Cache kann dagegen eine frühere Antwort für eine ähnliche Anfrage zurückgeben. Das sind verschiedene Risiken.
Semantisches Caching braucht strengere Regeln für Aktualität, Identität und Antwortqualität. Für zeitkritische, personenbezogene oder entscheidungsrelevante Antworten ist es oft ungeeignet.
Was messen?
Cache Hit Rate allein genügt nicht. Messen Sie:
- gesparte Eingabe-Tokens oder Providerkosten,
- Latenz mit und ohne Treffer,
- Anteil veralteter oder falsch berechtigter Resultate,
- Kosten pro erfolgreicher Aufgabe,
- Auswirkungen nach Prompt- oder Modellupdates.
Ein hoher Trefferanteil ist wertlos, wenn Nutzer häufiger korrigieren oder veraltete Antworten erhalten.
Caching bleibt providerspezifisch
OpenAI, Anthropic und Google bieten unterschiedliche Mechanismen, Mindestgrössen, Laufzeiten und Abrechnungsmodelle. Prüfen Sie die aktuelle Dokumentation pro Modell und Route. Ein Gateway kann Nutzung und Messung vereinheitlichen, aber die technischen Unterschiede bleiben bestehen.
Quellen
- OpenAI Prompt Caching: https://platform.openai.com/docs/guides/prompt-caching
- Anthropic Prompt Caching: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
- Google Gemini Context Caching: https://ai.google.dev/gemini-api/docs/caching
- AWS, Caching best practices: https://docs.aws.amazon.com/whitepapers/latest/database-caching-strategies-using-redis/cache-validity.html
Nächster Schritt
Analysieren Sie die zehn teuersten Promptpfade. Markieren Sie stabile Präfixe, variable Nutzerdaten und aktualitätskritische Inhalte. Testen Sie Caching zunächst auf einer Route und messen Sie Treffer, Kosten, Latenz und Fehler nach jeder Inhaltsänderung.
