Prompt Caching bei OpenAI, Anthropic und Gemini: Architektur und Auswahl

Prompt Caching verwendet Berechnungen für einen identischen Anfrageanfang erneut: Systemanweisungen, Tool-Schemas, Few-Shot-Beispiele oder einen großen gemeinsamen Kontext. Es ist kein Semantic Cache fertiger Antworten. Das Modell erzeugt für den variablen Teil weiterhin ein neues Ergebnis, daher darf Caching Prüfungen auf Qualität, Aktualität oder Berechtigungen nicht ersetzen.

Ein brauchbares Design hat drei Zonen: einen langlebigen gemeinsamen Präfix, versionierten Team- oder Tenant-Kontext und einen dynamischen Tail mit Nutzeranfrage und frischen Daten. Stabiles Material gehört nach vorn, variables nach hinten. Ein Timestamp, eine zufällige ID, instabile Reihenfolge von JSON-Feldern oder personenbezogene Daten am Anfang können den Match zerstören und erwartete Einsparungen in dauerhafte Cache Writes verwandeln.

• Nur einen wiederverwendbaren Präfix cachen, der groß genug für die Regeln des gewählten Modells ist.
• Anweisungen, Tools, Schemas und Corpus-Revisions versionieren statt unsichtbar zu mutieren.
• Reads, Writes, Misses, Uncached Input, Latenz und Qualität separat messen.
• Tenants oder Zugriffsebenen nicht für eine bessere Hit Rate vermischen.
• Aktuelle Model-, Region-, Retention- und Pricing-Regeln vor dem Rollout prüfen.

OpenAI dokumentiert automatisches Caching geeigneter exakter Präfixe und liefert Cached-Token-Telemetrie; neuere Modelle bieten zusätzlich Cache Keys, Cache Points und Modussteuerung. Anthropic unterstützt Top-Level Automatic Caching und explizite Cache Breakpoints über cache_control mit getrennten Cache-Creation- und Cache-Read-Tokens. Gemini bietet Implicit Caching und im kompatiblen Generate Content API explizite Cached Content Objects mit verwalteter TTL; die Verfügbarkeit hängt von API und Modell ab.

Verbergen Sie diese Unterschiede nicht hinter einem generischen cache=true. Ein Provider Adapter sollte Capabilities beschreiben: implicit oder explicit, Mindestpräfix, zulässige Breakpoints, TTL, Write/Read Billing, Telemetrie, Region und Data-Retention Constraints. Ist eine Capability unbekannt, führt das System einen normalen Request aus und markiert den Cache Status als unsupported oder unknown, statt einen Hit zu erfinden.

Bauen Sie den Request deterministisch auf: unveränderliche Policy- und Systemanweisungen, stabil sortierte Tool Definitions, Schemas, geprüfte Beispiele, danach gemeinsame Dokumente und erst dann User-spezifischen Input. Die Serialisierung sollte innerhalb des Provider Contract byte-stabil sein. Selbst semantisch identisches JSON mit anderer Feldreihenfolge kann als exakter Präfix nicht matchen.

Leiten Sie die Cache Identity aus Provider, Model Family, Prompt Version, Tool-Schema Version, Policy Version, Locale, Tenant oder Access Scope und Corpus Revision ab. Geheimen Text weder loggen noch in Cache Keys ablegen; verwenden Sie einen opaken Digest kontrollierter Identifikatoren. Ändern sich Modell, Berechtigungen, System Policy oder eine Quelle, die sofort widerrufen werden muss, entsteht eine neue Version; alter Cache-Traffic stoppt und das Objekt läuft aus oder wird über eine verfügbare API gelöscht.

Modellieren Sie einen logischen Cohort: Cache-Write-Tokens und Storage, Cache-Read-Tokens, Uncached Input, Output, Anzahl der Wiederverwendungen, Time to First Token und Cost per Successful Task. Der Break-even hängt von den konkreten Model-Preisen, der TTL und der beobachteten Wiederverwendungszahl ab. Übertragen Sie keinen Discount eines Providers oder Modells auf einen anderen Vertrag und setzen Sie einen Hit nicht allein wegen identischen Textes voraus.

Eine niedrige Hit Rate weist oft auf eine ungeeignete Workload-Form statt auf einen schwachen Service hin: kurze Prompts, seltene Wiederholung, fragmentierte Cache Keys, häufige Änderungen nahe am Präfix oder ein paralleler Burst vor Abschluss des ersten Writes. Vergleichen Sie kontrollierte Varianten auf demselben Traffic Slice. Wenn Canonicalization mehr Komplexität, Write Spend oder Revocation Delay erzeugt als sie spart, ist ein normaler Uncached Request die bessere Lösung.

Cache Reuse erlaubt keine schwächere Authorization. Ein gemeinsamer Präfix darf nur Daten enthalten, die für jeden Request seines Scope zulässig sind. Tenant-spezifische Dokumente, personenbezogene Daten und Tool-Ergebnisse mit unterschiedlichen ACLs brauchen getrennte Identities oder müssen hinter der sicheren Grenze bleiben. Ein Cache Key ist Routing-Hinweis oder Resource Identifier, kein Berechtigungsmechanismus; der Server muss den Request weiterhin autorisieren und den erlaubten Kontext erzeugen.

Explizites Caching kann für die TTL persistenten Application State erzeugen. Prüfen Sie Data Residency, Zero-Data-Retention-Kompatibilität, Verschlüsselung, Löschung und Incident Response in aktueller Dokumentation und in Verträgen. Für Legal Hold oder dringenden Revocation brauchen Sie einen dokumentierten Pfad: neue Reads stoppen, Version oder Scope wechseln, das Cache Object löschen, wo unterstützt, und prüfen, dass spätere Traces die retired Revision nicht mehr verwenden.

Ein Trace sollte Provider, Model, Cache Mode, einen sicheren Prefix Fingerprint, Version, Breakpoint, angeforderte TTL, Read/Write/Uncached Token Counts, Latenz, Outcome und Miss Reason erfassen, ohne den privaten Raw Prompt zu speichern. Normalisieren Sie Provider Fields in gemeinsame Kategorien, behalten Sie aber das Original Usage Payload in einem geschützten Audit Layer zur Prüfung der Billing Semantics.

Das Dashboard sollte Eligible Requests, Hit Rate unter den Eligible Requests, Cached-Token Share, Write Amplification, Cost per Accepted Outcome sowie Latenz für Hits und Misses zeigen. Alarmieren Sie bei einem starken Abfall nach Deploy, unerwartetem Cross-Scope Fingerprint, Writes ohne spätere Reads oder Nutzung einer retired Version. Hit Rate allein ist kein Qualitäts-KPI: Auch ein unveränderter, aber falscher System Prompt lässt sich perfekt cachen.

Messen Sie zuerst die Wiederholung von Präfixen, ohne das Verhalten zu ändern. Aktivieren Sie danach Canonical Rendering und vergleichen Sie exakte Fingerprints, während sensitive Cohorts vom Caching ausgeschlossen bleiben. Der Canary sollte einen Provider/Model und einen Low-Risk Workload abdecken; ein Quality Eval muss bestätigen, dass die Umordnung von Blöcken Instruction Precedence, Tool Behavior oder Groundedness nicht verändert hat.

Das Release Gate sollte null Cross-Tenant Defects, korrekte Usage Attribution, akzeptable Write Amplification und Non-Regression der Task Quality verlangen. Rollback deaktiviert explizite Breakpoints oder Cache-Resource-Referenzen, stellt den vorherigen Renderer wieder her und routet Traffic auf normale Requests. Alte Cache Objects gelten ohne Provider Evidence nicht als gelöscht; Expiry oder Deletion werden getrennt vom Application Rollback verfolgt.