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 fügt dann versehentlich einen Zeitstempel, eine Anforderungs-ID, einen Benutzernamen, ein Abruf-Snippet oder eine zufällige Toolreihenfolge oben in der Eingabeaufforderung ein. 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:

• Metadaten pro Anfrage oben: Zeitstempel, Trace-IDs, Sitzungs-IDs, Bereitstellungs-IDs oder generierte Anfragelabels.
• 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.
• Vorlagendrift: Kleinere Formulierungsä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.

Anbieterfakten, um die es sich zu gestalten gilt

Die Details sind wichtig, denn ein Gateway muss das Verhalten normalisieren, ohne vorzutäuschen, dass die Anbieter identisch sind.

• OpenAI: OpenAI hat das Zwischenspeichern von Eingabeaufforderungen für das längste zuvor berechnete Eingabeaufforderungsprä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 besagt außerdem, dass Prompt-Caches in der Regel nach 5–10 Minuten Inaktivität gelöscht 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 flüchtigen Cache, einschließlich einer 5-minütigen Dauer und einer 1-stündigen Option gegen Aufpreis.
• Gemini: Google Gemini Beim Kontext-Caching werden die Anzahl der Cache-Treffer-Tokens über Nutzungsmetadaten wie total_cached_tokens offengelegt, und in der Dokumentation werden die Mindestanzahlen der Eingabe-Tokens nach Modell aufgeführt.
• Auswirkungen auf die Datenkontrolle: OpenAIs API Datenkontrolldokumentation weist darauf hin, dass das erweiterte Prompt-Caching die Speicherung von Schlüssel-/Wert-Tensoren als Anwendungsstatus im GPU-lokalen Speicher erfordert. Auch 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 Mandantenisolationsdesign.

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 Designentscheidung 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 sind:

• Kernsystemanweisungen;
• Sicherheits- und Richtlinienblöcke;
• Tool-Schemas;
• statische Produktdokumentation;
• Repository-Zuordnungen für Coding-Agents;
• 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 Schemata enthalten sind, serialisieren Sie sie 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 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;
• Anforderungs-ID und Trace-Metadaten, falls überhaupt in der Eingabeaufforderung enthalten;
• kurzfristige Gesprächsrunden;
• Laufzeittool-Ergebnisse.

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 das 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": "Explain why this test fails...",
    "retrieval_context_ids": ["chunk_7", "chunk_19"],
    "trace_id": "not_inserted_into_prompt"
  }
}

Das Gateway rendert dann die anbieterspezifische Anfrage. Dadurch erhält das 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;
• Vorlage und Präfix-Fingerabdrücke für die Diagnose aufzeichnen.

Für Legacy-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 auszublenden

Ein Multi-Modell-Gateway sollte Entwicklern keine drei unabhängigen Cache-Berichte zur Verfügung stellen. Es sollte außerdem 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",
  "provider": "provider_name",
  "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 Eingabe-Tokens: Tokens, die ohne Cache-Leserabatt oder Cache-Lese-Abrechnung verarbeitet werden.
• Cache-Schreibtokens: Token, die einen anbieterseitigen 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.
• Ausgabe-Tokens: 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 Teams bei der Beantwortung der folgenden Fragen 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 die Zwischenspeicherung geeigneten Eingabe-Tokens.
• Präfix-Abwanderung: Anzahl unterschiedlicher stabiler Präfix-Hashes pro Vorlagenversion und Stunde.
• Template-Drift: Cache-Hit-Ä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 nicht standardmäßig rohe Eingabeaufforderungen zum Debuggen. Bevorzugen Sie Hashes, Regionslängen, Vorlagen-IDs, Kanonisierungswarnungen und geschwärzte Unterschiede. Wenn ein Team eine umfassendere Fehlerbehebung benötigt, fordern Sie explizite Zugriffskontrollen und Aufbewahrungsbeschränkungen.

Mandantenisolationsrichtlinie: Nicht für mandantenübergreifende Wiederverwendung entwerfen

Die sicherste Gateway-Annahme ist einfach: Zwischenspeicherbares 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.

Eine konservative Politik umfasst:

• Mandantenorientiertes Routing: Leiten Sie zwischenspeicherbaren Datenverkehr mithilfe von Mandanten-, Arbeitsbereichs- und Anwendungsgrenzen weiter.
• Keine gemeinsam genutzten, geheimen Präfixe: Platzieren Sie niemals Mandantengeheimnisse, 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: erlauben Administratoren, Anbieter-Cache-Funktionen für sensible Arbeitslasten zu deaktivieren.
• Provider-Isolation 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. Schreibtokens zwischenspeichern;
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 bei internen 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:

• Anweisungen für ein stabiles System erscheinen vor volatilen 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, dies nicht zu tun.
• Eingabeaufforderungsvorlagen haben explizite Versionen.
• Vorlagenfreigaben können mit Änderungen der Cache-Trefferrate korreliert werden.
• Provider-Cache-Steuerelemente werden nur durch Adaptercode verwendet, nicht durch verstreute Anwendungslogik.
• 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 Anbieternutzungsfelder 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, Dokumentanalyse, Batch-Jobs und Kurzchat. Bei der schnellen Cache-Arbeit wird in der Regel die größte Aufmerksamkeit auf Arbeitslasten mit langem Kontext und wiederholten Präfixen gelegt. Kurze Aufforderungen unterhalb der Schwellenwerte des Anbieters sind möglicherweise nicht von Vorteil.

3. Stable-Prefix-Builder einführen

Verschieben Sie eine Arbeitslast von der Roh-Prompt-Konstruktion zur regionsbasierten Assembly. 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. Canary eine Route

Aktivieren Sie Cache-Steuerelemente für einen kleinen Teil eines Mandanten oder einer internen Anwendung. 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 Prompt-Flexibilität: Stabile Präfixe verbessern die Wiederverwendung, aber Teams müssen möglicherweise später dynamische Anweisungen verschieben oder Vorlagen neu entwerfen.
• 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.
• Mandantenisolation vs. maximale Wiederverwendung: Eine umfassende Wiederverwendung mag attraktiv aussehen, aber mandantenbezogenes Verhalten 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 Eingabeaufforderungsbereiche. 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
• Behalten Sie den Abruf Kontext mandantenbezogen in RAG-Arbeitslasten