Prompt-Cache-Kontrolle in einem Multi-Modell-API-Gateway: Stabile Präfixe, Mandantenisolation und Cache-Hit-Analyse

Promptes Caching ist leicht zu verschwenden. Ein Team verfügt möglicherweise über eine Systemeingabeaufforderung, ein Toolschema, einen Richtlinienblock, eine Repository-Zuordnung oder einen Agentenspeicher mit 40.000 Token, die wiederverwendbar sein sollten, und platziert dann versehentlich einen Zeitstempel, eine Anforderungs-ID, einen Benutzernamen, ein Abruf-Snippet oder eine zufällige Toolreihenfolge oben in der Eingabeaufforderung. Der Anbieter sieht ein anderes Präfix, der Cache fehlt, die Latenz steigt und die Rechnung sieht verwirrend aus.

In einer Einzelanbieteranwendung können Sie dies in der Anwendungsvorlage beheben. Bei einem Gateway mit mehreren Modellen ist das Problem größer: Jeder Anbieter stellt unterschiedliche Cache-Kontrollen, Token-Schwellenwerte, Lebensdauerverhalten, Nutzungsfelder und Abrechnungssemantik zur Verfügung. Das Gateway benötigt ein tragbares Steuerungsebenenmuster zum Zusammenstellen von Cache-sicheren Eingabeaufforderungen, zum Messen des Cache-Verhaltens, zum Isolieren von Mandanten und zum Zuweisen von Kosten.

Dieser Artikel beschreibt eine Referenzarchitektur. Es handelt sich nicht um eine Kundenfallstudie und es werden keine Benchmark-Ergebnisse erhoben. Die folgenden Fakten stammen aus der Dokumentation des Anbieters und aus öffentlichen Untersuchungen. Bei den Designempfehlungen handelt es sich um Betriebsanweisungen auf Gateway-Ebene.

Der Fehlermodus: Cache-brechende Eingabeaufforderungsassembly

Prompt-Caching belohnt im Allgemeinen wiederholte Prompt-Präfixe. Die genauen Mechanismen variieren je nach Anbieter, aber die praktische Auswirkung ist konsistent: Wenn sich die Vorderseite der Eingabeaufforderung ändert, leidet die Wiederverwendung.

Zu den häufigsten Cache-Breakern gehören:

• Anforderungsspezifische Metadaten oben: Zeitstempel, Ablaufverfolgungs-IDs, Sitzungs-IDs, Bereitstellungs-IDs oder generierte Anforderungsbezeichnungen.
• Benutzerspezifische Daten im Präfix: Namen, Kontoattribute, Berechtigungen oder private Einstellungen vor wiederverwendbaren Richtlinien- oder Toolblöcken.
• Instabile Tool-Serialisierung: Tool-Schemata werden in nicht deterministischer Reihenfolge ausgegeben, mit wechselnden Leerzeichen oder generierten IDs.
• Snippets zu früh abrufen: RAG-Kontext vor stabilen Systemanweisungen oder freigegebenem Repository-Kontext eingefügt.
• Template-Drift: Kleine Wortlautänderungen werden häufig ohne Versionierung oder Cache-Diagnose veröffentlicht.

Ein Gateway kann ein instabiles Präfix nicht auf magische Weise zwischenspeicherbar machen, aber es kann einen Prompt-Assembly-Vertrag erzwingen und Cache-Fehler sichtbar machen.

Bieten Sie Fakten zum Design an

Auf die Details kommt es an, denn ein Gateway muss das Verhalten normalisieren, ohne vorzutäuschen, dass die Anbieter identisch sind.

• OpenAI: OpenAI hat das Prompt-Caching für das längste zuvor berechnete Prompt-Präfix dokumentiert. Es beginnt bei 1.024 Token, erhöht sich in Schritten von 128 Token und legt die Anzahl der zwischengespeicherten Token in Nutzungsfeldern offen. OpenAI gibt außerdem an, dass Prompt-Caches in der Regel nach 5–10 Minuten Inaktivität geleert und immer innerhalb einer Stunde nach der letzten Cache-Nutzung entfernt werden.
• Anthropic: Anthropic-Prompt-Caching kann mit cache_control angefordert werden. Die Dokumentation beschreibt den Cache-Abgleich über Eingabeaufforderungskomponenten wie Tools, Systeminhalte und Nachrichten bis hin zu dem mit Cache-Kontrolle gekennzeichneten Block. Anthropic dokumentiert einen ephemeren Cache, einschließlich einer 5-minütigen Dauer und einer 1-stündigen Option gegen Aufpreis.
• Gemini: Das Kontext-Caching von Google Gemini legt die Anzahl der Cache-Treffer-Tokens über Nutzungsmetadaten wie total_cached_tokens offen und in der Dokumentation sind die Mindestanzahlen von Eingabe-Tokens nach Modell aufgeführt.
• Auswirkungen auf die Datenkontrolle: In der API-Datenkontrolldokumentation von OpenAI wird darauf hingewiesen, dass das erweiterte Prompt-Caching die Speicherung von Schlüssel-/Wert-Tensoren als Anwendungsstatus im lokalen GPU-Speicher erfordert. Selbst wenn Anbieter Isolationsgarantien einhalten, sollten Gateways das Cache-Verhalten als sensible Infrastruktur und nicht als gemeinsam genutzten Anwendungsdatenspeicher behandeln.
• Forschungssignal: Öffentliche Untersuchungen haben untersucht, ob Architekturen im Gateway-Stil Schwachstellen beim Prompt-Caching einführen können, die Annahmen zur Cache-Isolation auf Anbieterebene umgehen. Das beweist nicht, dass ein bestimmtes Gateway anfällig ist, aber es unterstützt ein konservatives Mandanten-Isolationsdesign.

Empfehlung: Implementieren Sie die Cache-Steuerung als Gateway-Funktion mit expliziten Richtlinien, nicht als zufälligen Nebeneffekt wiederholter Eingabeaufforderungen.

Ein Prompt-Assembly-Vertrag für drei Regionen

Die wichtigste Entwurfsentscheidung besteht darin, stabile und flüchtige Inhalte zu trennen, bevor die Anfrage einen Anbieteradapter erreicht.

Region 1: stabiles Präfix

Das stabile Präfix ist ein Inhalt, von dem erwartet wird, dass er über viele Anfragen für dieselbe Anwendung, Modellroute und Eingabeaufforderungsvorlagenversion hinweg identisch bleibt. Beispiele hierfür sind:

• Kernsystemanweisungen;
• Sicherheits- und Richtlinienblöcke;
• Tool-Schemata;
• statische Produktdokumentation;
• Repository-Maps für Codierungsagenten;
• Anweisungen zum Ausgabeformat korrigiert.

Diese Region sollte deterministisch sein. Das Gateway sollte es aus versionierten Vorlagen, kanonisiertem JSON und stabilen Ordnungsregeln erstellen. Wenn eine Tool-Registrierung enthalten ist, sortieren Sie die Tools nach der stabilen Tool-ID. Wenn JSON-Schemas enthalten sind, serialisieren Sie diese mit deterministischer Schlüsselreihenfolge und ohne generierte Zeitstempel.

Region 2: Halbstabiler Mandanten- oder Arbeitsbereichskontext

Die halbstabile Region ändert sich seltener als einzelne Anfragen, wird aber nicht global geteilt. Beispiele hierfür sind:

• mandantenspezifische Richtlinienüberschreibungen;
• Tool-Zulassungslisten auf Arbeitsbereichsebene;
• kundenspezifische Terminologie;
• Team-Codierungskonventionen;
• Langlebiger Projektkontext.

Diese Region sollte auf einen Mandanten, einen Arbeitsbereich oder eine Anwendungsgrenze beschränkt sein. Es ist möglicherweise immer noch zwischenspeicherbar, aber das Gateway sollte niemals davon ausgehen, dass ein anderer Mandant es sicher wiederverwenden kann.

Region 3: flüchtiges Suffix

Das flüchtige Suffix ist der Teil pro Anfrage:

• Benutzernachricht;
• Snippets für diese Abfrage abgerufen;
• aktueller Zeitstempel, falls wirklich erforderlich;
• Anfrage-ID und Trace-Metadaten, sofern diese überhaupt in der Eingabeaufforderung enthalten sind;
• kurzfristige Gesprächsrunden;
• Ergebnisse des Laufzeittools.

Die meisten Cache-Fehler, die durch das Anwendungsdesign verursacht werden, passieren, weil flüchtige Suffixdaten versehentlich in das Präfix eingefügt werden. Ein Gateway-seitiger Builder sollte dies erschweren.

Implementierungsmuster: Stable-Prefix-Builder

Eine praktische Gateway-Implementierung kann eine Prompt-Assembly-Schnittstelle bereitstellen, anstatt von jeder Anwendung eine undurchsichtige Prompt-Zeichenfolge zu akzeptieren.

{
  „template_id“: „code-agent-v3“,
  „tenant_id“: „tenant_123“,
  „route“: „coding-long-context“,
  „stable_prefix“: {
    „system_policy_version“: „2026-08-01“,
    „toolset_version“: „tools-v12“,
    „repo_context_version“: „repo-map-8491“
  },
  „semi_stable_context“: {
    „workspace_policy_version“: „workspace-44-v6“
  },
  „volatile_suffix“: {
    „user_message“: „Erklären Sie, warum dieser Test fehlschlägt …“,
    "retrieval_context_ids": ["chunk_7", "chunk_19"],
    „trace_id“: „not_inserted_into_prompt“
  }

Das Gateway rendert dann die anbieterspezifische Anfrage. Dies gibt dem Gateway die Möglichkeit, Regeln durchzusetzen:

• Zeitstempel in stabilen Präfixfeldern ablehnen;
• Tool-Schemata kanonisieren;
• jede Region einzeln hashen;
• Cache-Steuerelemente anhängen, wo ein Anbieter sie unterstützt;
• Behalten Sie die Eingabeaufforderungssemantik bei, während Sie flüchtiges Material später verschieben;
• Aufzeichnungsvorlage und Präfix-Fingerabdrücke für die Diagnose.

Für ältere Anwendungen, die nur Rohnachrichten senden, kann das Gateway weiterhin einen Lint-Modus bereitstellen: Nachrichtenreihenfolge überprüfen, Präfix-Fingerabdrücke berechnen und wahrscheinliche Cache-Breaker melden, ohne die Eingabeaufforderung zunächst neu zu schreiben.

Provider-Adapterschicht: Cache-Nutzung normalisieren, ohne Unterschiede zu verbergen

Ein Multi-Modell-Gateway sollte den Entwicklern nicht drei unabhängige Cache-Berichte zur Verfügung stellen. Außerdem sollte es die anbieterspezifischen wirtschaftlichen Aspekte nicht so aggressiv verflachen, dass Rechnungen nicht mehr erklärbar werden.

Erstellen Sie ein normalisiertes Cache-Ledger mit Feldern wie:

{
  „request_id“: „req_abc“,
  „tenant_id“: „tenant_123“,
  „app_id“: „Code-Agent“,
  „route“: „coding-long-context“,
  „Anbieter“: „Anbietername“,
  „model“: „model_id“,
  „template_id“: „code-agent-v3“,
  „stable_prefix_hash“: „sha256:…“,
  „semi_stable_hash“: „sha256:…“,
  „input_tokens_total“: 58200,
  „input_tokens_uncached“: 8200,
  „cache_write_tokens“: 50000,
  „cache_read_tokens“: 0,
  „output_tokens“: 1300,
  „cache_ttl_class“: „ephemeral_5m“,
  "provider_cache_fields": {
    „raw_field_names“: „stored_or_redacted_provider_usage“
  }

Der Adapter ordnet die Anbieternutzung normalisierten Kategorien zu:

• Nicht zwischengespeicherte Eingabetoken: Token, die ohne Cache-Leserabatt oder Cache-Leseabrechnung verarbeitet werden.
• Cache-Schreibtokens: Token, die einen Anbieter-seitigen Cache-Eintrag erstellt oder aktualisiert haben, wenn der Anbieter diese Unterscheidung meldet.
• Cache-Lese-Tokens: Tokens, die aus dem Cache bereitgestellt werden oder von den Metadaten der Anbieternutzung als zwischengespeichert gezählt werden.
• Ausgabetoken: generierte Token, die von der Wirtschaftlichkeit des Prompt-Cache getrennt bleiben sollten.
• TTL-Option: die ausgewählte Cache-Dauerklasse, in der ein Anbieter eine Auswahl offenlegt.

Empfehlung: Speichern Sie die rohe Anbieternutzung in einer redigierten, schemaversionierten Form neben normalisierten Feldern. Die Normalisierung ist für Dashboards nützlich. Rohfelder sind für den Abgleich erforderlich, wenn sich die Anbietersemantik ändert.

Cache-Beobachtbarkeit: Dashboards, die Fehler erklären

Ein nützliches Cache-Dashboard bietet mehr als nur die Anzeige der gesamten zwischengespeicherten Token. Es sollte den Teams bei der Beantwortung der Frage helfen: „Welche Arbeitslast bricht das Präfix und was hat sich geändert?“

Cache-Metriken verfolgen nach:

• Mieter;
• Arbeitsbereich oder App;
• Modellroute;
• Anbieter und Modell;
• Prompt-Vorlagenversion;
• stabiler Präfix-Hash;
• halbstabiler Kontext-Hash;
• API-Schlüssel oder Dienstkonto, sofern zutreffend;
• Zeitfenster, insbesondere weil Cache-TTLs für viele Arbeitslasten kurz sind.

Nützliche abgeleitete Metriken umfassen:

• Cache-Leserate: zwischengespeicherte Eingabe-Tokens geteilt durch die Gesamtzahl der für das Caching geeigneten Eingabe-Tokens.
• Präfix-Abwanderung: Anzahl unterschiedlicher stabiler Präfix-Hashes pro Vorlagenversion und Stunde.
• Template-Drift: Cache-Treffer-Änderungen nach einer Template-Veröffentlichung.
• Kaltstartkosten: Ausgaben für Cache-Schreibvorgänge oder nicht zwischengespeicherte Eingaben für die erste Anfrage in einem Burst.
• Routenvergleich: Trefferquoten über Anbieterrouten hinweg für die gleiche logische Arbeitslast.

Speichern Sie zum Debuggen nicht standardmäßig rohe Eingabeaufforderungen. Bevorzugen Sie Hashes, Regionslängen, Vorlagen-IDs, Kanonisierungswarnungen und geschwärzte Unterschiede. Wenn ein Team eine umfassendere Fehlersuche benötigt, fordern Sie explizite Zugriffskontrollen und Aufbewahrungsbeschränkungen.

Mandantenisolationsrichtlinie: Nicht für mandantenübergreifende Wiederverwendung entwerfen

Die Annahme des sichersten Gateways ist einfach: Das zwischenspeicherbare Verhalten sollte mandantenspezifisch sein. Selbst wenn zwei Mandanten einen identischen öffentlichen Richtlinienblock teilen, sollte das Gateway den Datenverkehr nicht absichtlich weiterleiten oder so gestalten, dass die mandantenübergreifende Cache-Wiederverwendung ausgenutzt wird.

Zu einer konservativen Politik gehört:

• Mandantenorientiertes Routing: Leiten Sie zwischenspeicherbaren Datenverkehr mithilfe von Mandanten-, Arbeitsbereichs- und Anwendungsgrenzen weiter.
• Keine gemeinsam genutzten, geheimen Präfixe: Platzieren Sie niemals Mietergeheimnisse, Anmeldeinformationen, private Dokumente oder benutzerspezifische Daten in einem wiederverwendbaren, gemeinsam genutzten Präfix.
• Separate Präfix-Fingerabdrücke: Berechnen Sie Fingerabdrücke mit Mandantenbereich, die im Gateway-Ledger enthalten sind, auch wenn der gerenderte Text identisch ist.
• Kontrollen auf Organisationsebene: ermöglichen es Administratoren, Anbieter-Cache-Funktionen für sensible Arbeitslasten zu deaktivieren.
• Anbieterisolation ist keine Produktfunktion zum Weiterverkauf: Behandeln Sie die Provider-Cache-Isolation als Basisschutz und nicht als Erlaubnis zum Aufbau eines kundenübergreifenden Cache-Poolings.

Vorhersage: Mit zunehmender Verbreitung von Agenten mit langem Kontext wird das Cache-Verhalten Teil von Sicherheitsüberprüfungen und nicht nur von Kostenüberprüfungen. Gateways, die eine mandantenbezogene Cache-Richtlinie nachweisen können, sind einfacher zu verwalten.

Abrechnungszuordnung: separate Cache-Lesevorgänge, Schreibvorgänge und normale Token

Promptes Caching kann die Verständlichkeit von Rechnungen erschweren, wenn alle Eingabe-Tokens als eine Zahl angezeigt werden. Das Abrechnungsbuch sollte mindestens fünf Kategorien enthalten:

1. nicht zwischengespeicherte Eingabetokens;
2. Cache-Schreibtokens;
3. Lese-Tokens zwischenspeichern;
4. Ausgabetokens;
5. anbieterspezifische TTL- oder Cache-Kontrollgebühren.

Dies ist wichtig, wenn ein Anbieter zwischengespeicherte Lesevorgänge ermäßigt, ein anderer andere Gebühren für Cache-Schreibvorgänge erhebt und ein anderer eine längere TTL-Option anbietet. Eine Kundenrechnung sollte erklären können, warum zwei Anfragen mit ähnlichen Gesamteingabe-Tokens unterschiedliche Kosten hatten.

Führen Sie für interne Rückbuchungen Cache-Effekte dem Mandanten und der Anwendung zu, die die Anfrage gestellt haben. Vermeiden Sie die Zuweisung eines Cache-Lesevorteils von einem Mandanten zu einem anderen. Wenn ein gemeinsam genutztes internes Plattformteam Eigentümer der stabilen Eingabeaufforderungsvorlage ist, melden Sie die Cache-Leistung auf Vorlagenebene getrennt von den Mandantenrechnungen.

Cache-Linting-Checkliste

Bevor Sie die Cache-Erzwingung aktivieren, führen Sie Eingabeaufforderungsvorlagen anhand einer Lint-Checkliste aus:

• Stabile Systemanweisungen erscheinen vor flüchtigen Benutzereingaben.
• Tool-Schemata werden nach stabiler ID oder Name sortiert.
• JSON wird deterministisch serialisiert.
• Im stabilen Präfix erscheinen keine Zeitstempel, Zufalls-IDs, Anforderungs-IDs oder Trace-IDs.
• In gemeinsam genutzten wiederverwendbaren Blöcken werden keine benutzerspezifischen Geheimnisse angezeigt.
• RAG-Snippets werden nach wiederverwendbaren Richtlinien- und Toolabschnitten platziert, es sei denn, es gibt einen bewussten Grund dagegen.
• Eingabeaufforderungsvorlagen haben explizite Versionen.
• Vorlagenfreigaben können mit Änderungen der Cache-Trefferrate korreliert werden.
• Anbieter-Cache-Steuerelemente werden nur über Adaptercode und nicht über verstreute Anwendungslogik verwendet.
• Die Rohprotokollierung von Eingabeaufforderungen ist standardmäßig deaktiviert oder durch strenge Aufbewahrungs- und Zugriffsregeln geschützt.

Rollout-Plan

1. Beachten Sie, bevor Sie Eingabeaufforderungen ändern

Erfassen Sie zunächst Felder zur Anbieternutzung und normalisierte Cache-Metriken für den vorhandenen Datenverkehr. Berechnen Sie Präfix-Fingerabdrücke für die ersten N Token oder für vom Gateway definierte Eingabeaufforderungsbereiche. Das Ziel besteht darin, Routen mit hohem Volumen und langem Kontext und hoher Präfixabwanderung zu finden.

2. Arbeitslasten klassifizieren

Gruppieren Sie den Datenverkehr in Kategorien: Agentensitzungen, Codierungsassistenten, RAG, Support-Automatisierung, Dokumentenanalyse, Batch-Jobs und Kurzchat. Bei der schnellen Cache-Arbeit wird in der Regel die größte Aufmerksamkeit auf Workloads mit langem Kontext und wiederholten Präfixen gelegt. Kurze Eingabeaufforderungen unterhalb der Schwellenwerte des Anbieters sind möglicherweise nicht von Vorteil.

3. Einführung von Buildern für stabile Präfixe

Verlagern Sie eine Arbeitslast von der Roh-Prompt-Konstruktion zur regionsbasierten Montage. Sorgen Sie dafür, dass die gerenderte Anbieteranforderung semantisch gleichwertig ist. Kombinieren Sie diese Änderung nicht mit einer Modellmigration, einem Tool-Redesign oder größeren Umschreibungen von Eingabeaufforderungen, sonst wissen Sie nicht, was die Metrikänderungen verursacht hat.

4. Kanarische eine Route

Aktivieren Sie Cache-Steuerelemente für einen kleinen Teil eines Mandanten oder einer internen App. Vergleichen Sie die Cache-Leserate, die Präfix-Abwanderung, die Zeit bis zum ersten Token, die Fehlerrate und die Kostenkategorien. Vermeiden Sie die Geltendmachung von Einsparungen, bis die Rechnungen des Anbieters mit den Gateway-Ledgern abgeglichen sind.

5. Schrittweise durchsetzen

Verwandeln Sie Flusenwarnungen nach dem Kanarienvogel in Richtlinienprüfungen. Warnen Sie beispielsweise zunächst bei instabiler Werkzeugreihenfolge und lehnen Sie dann neue Vorlagenversionen ab, die flüchtige Metadaten im stabilen Präfix enthalten.

Kompromisse

• Höhere Cache-Trefferquote im Vergleich zu prompter Flexibilität: Stabile Präfixe verbessern die Wiederverwendung, aber Teams müssen möglicherweise später dynamische Anweisungen verschieben oder Vorlagen neu gestalten.
• Anbieternatives Caching vs. Portabilität: Die Verwendung der Cache-Kontrollen jedes Anbieters kann die Wirtschaftlichkeit verbessern, aber Schwellenwerte, TTLs, Felder und Preissemantik unterscheiden sich.
• Beobachtbarkeit vs. sensible Protokollierung: Eingabeaufforderungsunterschiede helfen beim Debuggen von Fehlern, aber Hashes und geschwärzte Diagnosen sind sicherere Standardeinstellungen.
• Mieterisolation vs. maximale Wiederverwendung: Eine umfassende Wiederverwendung mag attraktiv erscheinen, aber Verhalten auf Mieterebene ist sicherer und einfacher zu erklären.
• Längere Aufbewahrung im Vergleich zu Kosten und Richtlinienkomplexität: Längere TTL-Optionen können Agentensitzungen erleichtern, können jedoch andere Überlegungen zu Preis und Datenkontrolle mit sich bringen.

Umsetzbare Schlussfolgerung

Behandeln Sie das Zwischenspeichern von Eingabeaufforderungen als ein Problem auf der Gateway-Steuerungsebene und nicht als ein Kontrollkästchen des Anbieters. Das praktische Muster lautet: Definieren Sie stabile, halbstabile und volatile Prompt-Regionen. sie deterministisch rendern; anbieterspezifische Cache-Kontrollen hinter einer Schnittstelle anpassen; Normalisieren Sie die Cache-Nutzung in einem Hauptbuch. Stellen Sie Cache-Treffer-Diagnosen nach Mandant, App, Route und Vorlagenversion bereit. und mandantenbezogene Annahmen durchsetzen.

Der erste nützliche Schritt ist kein Umschreiben. Fügen Sie Cache-Beobachtbarkeit zu Ihren längsten Eingabeaufforderungen hinzu, identifizieren Sie die Abwanderung von Präfixen und kennzeichnen Sie die Vorlagen, die die meisten Fehler verursachen. Sobald Sie das Cache-Verhalten erklären können, können Sie es sicher optimieren.

Verwandte Lektüre

• Cache-fähige Kategorien in das Abrechnungsbuch einbauen
• Cache-Metriken mit sicherer LLM-Beobachtbarkeit verbinden
• keep Mandantenbezogener Abrufkontext in RAG-Workloads