So entwerfen Sie Cache-fähige LLM-Eingabeaufforderungen für OpenAI, Anthropic und Gemini

Promptes Caching hilft nur, wenn dieselben Token lange genug am richtigen Ort und unter der von Ihnen tatsächlich aufgerufenen Anbietersemantik wiederverwendet werden. Teams verpassen den Vorteil oft, weil sie Caching als Modellfunktion und nicht als Problem der Anforderungsarchitektur betrachten. Sie platzieren Zeitstempel oben in jeder Eingabeaufforderung, verschachteln anforderungsspezifische Abrufergebnisse mit wiederverwendbaren Toolschemata oder optimieren für einen Anbieter, während sie bei einem anderen stillschweigend die Kosten erhöhen.

Die praktische Lösung besteht darin, das Zwischenspeichern von Eingabeaufforderungen zu einem Teil des Gateway-Anforderungscompilers zu machen. Das Gateway sollte stabiles Eingabeaufforderungsmaterial von flüchtigem Anforderungsmaterial trennen, anbieterspezifische Cache-Anweisungen kompilieren und Kosten und Latenz anhand des zwischenspeicherbaren Präfixes messen. Das ist am wichtigsten in einer Umgebung mit mehreren Modellen, in der OpenAI, Anthropic und Gemini unterschiedliche Caching-Verhalten, Abrechnungsfelder, TTLs und Einrichtungskosten aufweisen.

Beginnen Sie mit der zwischenspeicherbaren Einheit, nicht mit dem Anbieter

Die wiederverwendbare Einheit ist normalerweise nicht die gesamte Eingabeaufforderung. Es handelt sich um ein Präfix oder Kontextobjekt aus Eingabeaufforderungsmaterial, das viele Anfragen gemeinsam nutzen. In einem produktiven Enterprise LLM API umfasst dieses Material häufig Plattformrichtlinien, Organisationsrichtlinien, Anwendungsanweisungen, Tooldefinitionen, Antwortformatregeln, Coding-Agent-Anweisungen oder statische Korpusanweisungen.

Der flüchtige Teil ist das Material, das sich pro Anfrage ändert: die aktuelle Aufgabe des Benutzers, Anfrage-IDs, Zeitstempel, Konversationsende, frisch abgerufene RAG-Passagen, kontospezifische Daten und ein einmaliges Tool Ergebnisse. Wenn flüchtiger Inhalt vor stabilem Inhalt erscheint, kann dies die Wiederverwendung von Präfixen unterbrechen oder den Anbieter zwingen, eine große Eingabeaufforderung als neu zu behandeln.

Fakt: Anbieterimplementierungen unterscheiden sich. OpenAI dokumentiert die Zwischenspeicherung von Aufforderungen als Wiederverwendung eines gemeinsam genutzten Präfixes mit zwischengespeicherter Token-Abrechnung. In seinem öffentlichen Artikel zum Prompt-Caching heißt es, dass das automatische Caching bei einem 1.024-Token-Präfix beginnt und in 128-Token-Schritten wächst und dass Cache-Einträge normalerweise nach 5 bis 10 Minuten Inaktivität und innerhalb einer Stunde nach der letzten Verwendung gelöscht werden. Anthropic dokumentiert explizite Cache-Haltepunkte und empfiehlt, cache_control im letzten gemeinsam genutzten Block zu platzieren, z. B. bei Systemeingabeaufforderungen oder Tooldefinitionen. Gemini dokumentiert Kontext-Caching als kostenpflichtige Funktion mit zwischengespeicherten Token-Zählungen, die in Nutzungsmetadaten für Cache-Vorgänge und Generierungsaufrufe zurückgegeben werden, die einen Cache verwenden.

Empfehlung: Entwerfen Sie Ihre interne Eingabeaufforderungsdarstellung um stabile Blöcke und flüchtige Blöcke herum, bevor Sie Anbieter-APIs etwas zuordnen.

Anforderungen von der stabilsten zur flüchtigsten kompilieren

A Der Cache-fähige Anforderungscompiler sollte das Material so anordnen, dass der größte wiederverwendbare Abschnitt vor dem anforderungsspezifischen Abschnitt angezeigt wird. Eine praktische Standardreihenfolge ist:

1. Plattformsicherheits- und Compliance-Richtlinie.
2. Organisations- oder Mieterrichtlinie.
3. Anweisungen für Anwendungsrollen und Aufgaben.
4. Tool-Schemata und Tool-Nutzungsregeln.
5. Statisches Wissen oder langlebiges Referenzmaterial.
6. Konversation Verlauf, der über Runden hinweg wiederverwendet wird.
7. Abgerufene Passagen oder anderer anforderungsspezifischer Kontext.
8. Die aktuelle Benutzeraufgabe.
9. Ephemere Metadaten, die nur für diesen Aufruf benötigt werden.

Diese Reihenfolge ist keine universelle Wahrheit. Einige Anbieter oder Modelle reagieren möglicherweise anders, wenn Anweisungen verschoben werden. Politische Priorität und Verhaltensqualität sind nach wie vor wichtig.Behandeln Sie die Cache-fähige Reihenfolge als kontrollierte Änderung: Führen Sie vor und nach der Änderung des Layouts Prompt-Regressionstests durch.

Beispiele für interne Prompt-Blöcke

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

Der Compiler kann das stabile Präfix nach dem Rendern hashen. Dieser Hash wird zum Verknüpfungsschlüssel für Cache-Analysen: Modell, Mandant, Anwendung, zwischenspeicherbarer Präfix-Hash, Eingabeaufforderungsversion, TTL-Auswahl, nicht zwischengespeicherte Eingabetokens, zwischengespeicherte Eingabetokens, Cache-Schreibtokens, sofern verfügbar, Ausgabetokens, Latenz und Endkosten.

Verwenden Sie Anbieteradapter anstelle einer Cache-Annahme

Ein einzelnes Flag „Cache aktivieren“ ist für mehrere Anbieter zu vage Operationen. Das Gateway sollte eine interne Cache-Richtlinie offenlegen und sie in anbieterspezifisches Verhalten kompilieren.

OpenAI Adapter

Für OpenAI für wiederholte gemeinsame Präfixe und Nutzungsabrechnung optimieren. Der Anforderungscompiler sollte stabiles Material im Vordergrund behalten und kleine Unterschiede innerhalb der ersten zwischenspeicherbaren Spanne vermeiden. Verfolgen Sie zwischengespeicherte Eingabetokens aus Anbieternutzungsfeldern. Verfolgen Sie, sofern verfügbar, auch Cache-Schreibtokens, damit das Kostenbuch die Cache-Erstellung und -Wiederverwendung vergleichen kann.

Da das Caching präfixorientiert ist, besteht die wichtige betriebliche Aufgabe darin, Präfixdrift zu verhindern. Zwei Eingabeaufforderungen, die für Menschen gleich aussehen, können sich unterscheiden, weil oben ein Zeitstempel, eine Build-ID, eine zufällige Toolreihenfolge oder eine Mandantenpersonalisierung gerendert wurde.

Anthropic Adapter

Kompilieren Sie für Anthropic explizite Cache-Haltepunkte. Platzieren Sie cache_control auf dem letzten Block, der mit Folgeanfragen geteilt werden soll. Gute Kandidaten sind umfangreiche Systemanweisungen, Werkzeugdefinitionen oder ein stabiler Referenzkontext. Schlechte Kandidaten sind einmalige Benutzernachrichten, aktuelle Aufgabennutzlasten oder anforderungsspezifische RAG-Snippets.

Fakt: Anthropic dokumentiert eine standardmäßige Cache-Dauer von 5 Minuten und eine gegen Aufpreis verfügbare Cache-Dauer von 1 Stunde. Das macht die TTL-Auswahl zu einer wirtschaftlichen Entscheidung. Ein langer Cache kann für interaktive Codierungsagenten, die Überprüfung von mehrstufigen Dokumenten oder die Unterstützung von Copiloten bei Pausen zwischen den Runden sinnvoll sein. Dies kann für eine einmalige Aufgabe mit wenigen Wiederholungen verschwenderisch sein.

Gemini Adapter

Behandeln Sie für Gemini das Kontext-Caching als Ressourcenentscheidung. Erstellen Sie zwischengespeicherte Inhalte, wenn die erwartete Wiederverwendung die Einrichtungs- und Speicherkosten rechtfertigt, und verweisen Sie dann bei Generierungsaufrufen auf diesen Cache. Dies unterscheidet sich davon, sich nur auf einen automatischen Präfix-Cache zu verlassen. Der Adapter sollte über Cache-Lebenszyklus, TTL, Metadaten und Bereinigungsrichtlinie verfügen.

GeminiKontext-Caches im Stil eignen sich oft am besten für großen, stabilen Kontext, den viele Anfragen wiederverwenden: ein langes Richtlinienhandbuch, ein statischer Produktkatalogauszug, eine feste Coding-Agent-Tool-Umgebung oder ein Überprüfungsworkflow, der wiederholt Fragen zu demselben Dokumentensatz stellt.

Messen Sie die Cache-Ökonomie, nicht nur Treffer Rate

Cache-Trefferrate ist nützlich, aber nicht ausreichend. Eine hohe Trefferquote bei einem winzigen Präfix kann wenig einsparen. Eine niedrigere Trefferquote bei einem sehr großen Policy-and-Tools-Präfix könnte von größerer Bedeutung sein.Bei einigen Anbietern fallen Cache-Schreib- oder Einrichtungskosten an, und diese Kosten können Einsparungen zunichte machen, wenn die Wiederverwendung gering ist.

Erfassen Sie diese Felder für jede Anfrage, wenn der Anbieter sie bereitstellt oder das Gateway sie schätzen kann:

• Anbieter und Modell.
• Mandant, Anwendung, Umgebung und API Schlüsselidentität.
• Prompt-Vorlagenversion und zwischenspeicherbares Präfix Hash.
• TTL-Richtlinie oder Cache-Dauer.
• Nicht zwischengespeicherte Eingabe-Tokens.
• Gespeicherte Eingabe-Tokens.
• Cache-Schreib- oder Cache-Erstellungs-Tokens, sofern verfügbar.
• Ausgabe-Tokens.
• Zeit bis zum ersten Token und Gesamtwert Latenz.
• Anbieterlistenpreisversion, die für die Kostenberechnung verwendet wird.
• Gibt an, ob die Anfrage Teil einer interaktiven Sitzung, eines Batch-Jobs, einer Agent-Schleife oder eines One-Shot-Anrufs war.

Dann wird der Cache-Wert nach Arbeitslast berechnet, nicht global. Ein Support-Copilot, ein Coding-Agent, ein Dokumentprüfer und ein einmaliger Zusammenfassender haben unterschiedliche Wiederverwendungsmuster. Rollups sollten eingesparte Dollars, ausgegebene Cache-Write-Dollars, Latenzänderungen und Trefferquote nach Präfix-Hash anzeigen.

Ein einfaches ROI-Modell reicht für den Anfang aus:

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

Dieses Modell ist bewusst einfach. Es sollte als Tor vor der Aktivierung langlebiger oder expliziter Caches verwendet werden, nicht als Ersatz für die Produktionsmessung.

Lint-Regeln für Cache-Breaker hinzufügen

Die meisten Cache-Fehler sind auf schnelle Konstruktionsgewohnheiten zurückzuführen, nicht auf Anbieterfehler. Fügen Sie Gateway-Lint-Regeln hinzu, die ausgeführt werden, bevor Anfragen den Anbieter erreichen.

Kennzeichnen Sie Zeitstempel oben in den Eingabeaufforderungen. Wenn das Modell die aktuelle Zeit benötigt, platzieren Sie sie nach dem wiederverwendbaren Präfix oder übergeben Sie sie als späten Anforderungsblock.

Kennzeichnen Sie zufällige IDs in Systemnachrichten. Korrelations-IDs gehören in Metadaten oder Protokolle, nicht in das stabile Eingabeaufforderungspräfix.

Kennzeichnen Sie dynamisch geordnete Toolschemata. Sortieren Sie Werkzeuge und Schemaeigenschaften vor dem Rendern deterministisch. Eine Toolliste, die die Reihenfolge bei jeder Anfrage ändert, kann die Wiederverwendung zerstören, selbst wenn der Toolset logisch identisch ist.

Anfragespezifische RAG vor stabilen Tools kennzeichnen. Abgerufene Passagen sind oft flüchtig. Stellen Sie zuerst stabile Anweisungen und Toolschemata und dann abgerufene Passagen ein, es sei denn, sofortige Tests beweisen, dass eine andere Reihenfolge erforderlich ist.

Kennzeichnen Sie benutzerspezifische Personalisierung in der gemeinsamen Richtlinie. Mandantenrichtlinien können möglicherweise für einen Mandanten zwischengespeichert werden, Benutzereinstellungen und der aktuelle Kontostatus jedoch normalerweise nicht.

Abwanderung der Vorlagenversion kennzeichnen. Wenn bei jeder Bereitstellung Leerzeichen, Kommentare oder nicht verwendeter Anweisungstext geändert werden, ändert sich der zwischenspeicherbare Präfix-Hash. Führen Sie Vorlagen bewusst zur Versionsaufforderung aus und vermeiden Sie unnötige Änderungen an großen stabilen Blöcken.

Behandeln Sie RAG-Arbeitslasten sorgfältig

RAG ist der Bereich, in dem Teams häufig zu viel zwischenspeichern. Stabile Retrieval-Anweisungen, Zitierregeln, Tool-Schemata und Korpusbeschreibungen können wiederverwendbar sein. Die abgerufenen Passagen selbst sind in der Regel anforderungsspezifisch. Wenn Sie abgerufene Passagen vor den stabilen Anweisungen platzieren, reduzieren Sie die Wiederverwendung. Wenn Sie den gesamten Kontext zwischenspeichern, wenn es unwahrscheinlich ist, dass sich Passagen wiederholen, zahlen Sie möglicherweise Schreib- oder Einrichtungskosten, ohne dass genügend zukünftige Treffer vorhanden sind.

Es gibt Ausnahmen. Ein Rechtsprüfungsablauf, ein Support-Workflow oder ein Produktdokument-Assistent können in einer Sitzung wiederholt dasselbe Dokumentenpaket abfragen. In diesem Fall kann ein langlebigerer Cache für den Dokumentkontext nützlich sein.Die Entscheidung sollte von der erwarteten Wiederverwendungsanzahl, der Cache-Dauer, der Größe des Dokumentkontexts und davon abhängen, ob Benutzer dazu neigen, mehrere Fragen zum gleichen Material zu stellen.

Empfehlung: RAG-Kontext als einen von drei Typen klassifizieren: statische Korpusführung, wiederverwendbarer Sitzungskontext oder einmalig abgerufene Snippets. Standardmäßig werden nur die ersten beiden zwischengespeichert.

Validieren Sie das Verhalten vor der Kostenoptimierung

Das spätere Verschieben von Inhalten in einer Eingabeaufforderung kann die Wiederverwendung des Caches verbessern, aber auch das Modellverhalten ändern. Beispielsweise kann das Verschieben von Werkzeugregeln nach dem Gesprächsverlauf ihren Einfluss verringern. Das Verschieben der Richtlinie unterhalb des abgerufenen Inhalts kann die Unterrichtspriorität schwächen. Das Normalisieren von Schemata kann sich auf die Werkzeugauswahl auswirken, wenn sich Beschreibungen ändern.

Verwenden Sie Regressionstests, bevor Sie Cache-fähige Layouts einführen. Testen Sie mindestens Folgendes:

• Anweisungspriorität für Sicherheits- und Compliance-Richtlinien.
• Toolauswahl für bekannte Aufgaben.
• Strukturierte Ausgabegültigkeit, wenn Schemata beteiligt sind.
• Antwortqualität an repräsentativen RAG-Beispielen.
• Latenz und Kosten bei wiederholten Aufgaben turns.
• Anbieterspezifische Nutzungsabrechnung.

Führen Sie für Workflows mit hohem Risiko einen Schattenvergleich durch: ursprüngliches Eingabeaufforderungslayout im Vergleich zu Cache-fähigem Layout, dasselbe Modell, dieselben Eingaben, mit menschlichen oder automatisierten Prüfungen auf inakzeptable Ausgabeänderungen. Kosteneinsparungen sind nicht sinnvoll, wenn der Anforderungscompiler das Geschäftsverhalten in einer Weise ändert, die von den Teams nicht genehmigt wurde.

Arbeitslasten selektiv auswählen

Eingabeaufforderungs-Caching ist am wirksamsten, wenn Eingabeaufforderungen lang und wiederholt sind. Gute Ausgangspunkte sind Coding-Agents mit großen Tool-Schemata, Support-Copiloten mit richtlinienintensiven Anweisungen, Dokumentüberprüfungsabläufe mit wiederholten Fragen zum gleichen Material, Tool-lastige Agenten und Unternehmensassistenten mit großen Governance-Blöcken.

Zu den schwachen Kandidaten gehören kurze One-Shot-Eingabeaufforderungen, hochgradig personalisierte Eingabeaufforderungen, bei denen sich der Anfang der Anfrage jedes Mal ändert, seltene Verwaltungsaufgaben und Arbeitsabläufe, bei denen Ausgabetokens die Gesamtkosten dominieren. In diesen Fällen können andere Optimierungen wichtiger sein: kürzere Eingabeaufforderungen, besserer Abruf, Modellrouting, Stapelverarbeitung oder strengere Ausgabebeschränkungen.

Vorhersage: Die Caching-Semantik der Anbieter wird weiterhin voneinander abweichen. Automatisches Präfix-Caching, explizite Haltepunkte, kostenpflichtige Kontextressourcen, Cache-Write-Accounting und TTL-Preise werden wahrscheinlich auf den verschiedenen Plattformen ungleich bleiben.Teams, die die Anfragekompilierung und Telemetrie am Gateway zentralisieren, können sich schneller anpassen als Teams, die anbieterspezifische Caching-Logik in den gesamten Anwendungscode einbetten.

Implementierungscheckliste

• Erstellen Sie ein internes Eingabeaufforderungsblockmodell mit Stabilitätsbezeichnungen: global, Mandant, Anwendung, Workflow, Sitzung und Anfrage.
• Rendern Sie Blöcke deterministisch, einschließlich Werkzeugreihenfolge und Schemaeigenschaften order.
• Verschieben Sie flüchtige Felder aus dem stabilen Präfix.
• Berechnen Sie nach dem Rendern einen zwischenspeicherbaren Präfix-Hash.
• Fügen Sie Anbieteradapter für OpenAI Präfix-Wiederverwendung, Anthropic Cache-Haltepunkte und Gemini Kontext-Cache-Ressourcen hinzu.
• Zeichnen Sie nicht zwischengespeicherte Eingabe-Tokens, zwischengespeicherte Eingabe-Tokens und Cache-Schreiben auf Token, sofern verfügbar, Ausgabetoken, Latenz, Modell, Mandant, Anwendung, Präfix-Hash und TTL.
• Erstellen Sie Dashboards für eingesparte Nettodollar, Schreib-/Einrichtungskosten, Trefferquote und Latenz nach Arbeitslast.
• Fügen Sie Lint-Regeln für Zeitstempel, zufällige IDs, volatile RAG-Platzierung, dynamische Tool-Reihenfolge und Personalisierung in gemeinsam genutzten Blöcken hinzu.
• Ausführen Führen Sie Regressionstests zum Verhalten von Eingabeaufforderungen durch, bevor Sie das Produktionslayout ändern.
• Aktivieren Sie das Caching zunächst für sich wiederholende Arbeitslasten und erweitern Sie es dann basierend auf dem gemessenen ROI.

Fazit

Cache-fähiges Eingabeaufforderungsdesign bedeutet nicht nur Eingabeaufforderungsformatierung. Es handelt sich um eine Gateway-Funktion: deterministisches Rendering, Design mit stabilen Präfixen, anbieterspezifische Kompilierung, Linting und Kostentelemetrie. Am meisten profitieren davon die Teams, die drei Fragen für jede Arbeitslast beantworten können: Welcher Teil der Anfrage ist wirklich wiederverwendbar, wie erhebt dieser Anbieter Gebühren für die Wiederverwendung und hat der Cache die End-to-End-Kosten oder die Latenz verbessert, ohne das Verhalten zu ändern?

Beginnen Sie mit einem Workflow mit vielen Wiederholungen. Trennen Sie stabile Blöcke von flüchtigen Blöcken, fügen Sie anbieterspezifisches Cache-Handling hinzu, messen Sie die Wirtschaftlichkeit und verallgemeinern Sie erst dann. Dieser Weg vermeidet den häufigen Fehlermodus: das Einschalten einer Cache-Funktion, ohne zu wissen, ob sie Geld spart, Latenz erhöht oder einfach Kosten in ein anderes Abrechnungsfeld verlagert.

Verwandte Lektüre

• anbieterneutrale LLM-Beobachtbarkeit