Was ist Prompt-Caching? Best Practices erklärt

Large Language Models (LLMs) haben die Art und Weise, wie wir mit KI interagieren, revolutioniert und komplexe Aufgaben wie Texterstellung, Übersetzung, Beantwortung von Fragen und mehr ermöglicht. Die Interaktion mit diesen leistungsstarken Modellen, insbesondere mit anspruchsvollen Prompts, kann jedoch erhebliche Rechenkosten und Latenz verursachen. Viele Anwendungen beinhalten das wiederholte Senden ähnlicher oder teilweise identischer Prompts. Stellen Sie sich einen Chatbot mit einem festen System-Prompt, ein Dokumentanalyse-Tool, das Chunks mit denselben Anweisungen verarbeitet, oder einen Agenten vor, der konsistente Tool-Definitionen verwendet. In diesen Szenarien verarbeitet das LLM wiederholt dieselben anfänglichen Informationen (das Prompt-Präfix), wodurch Rechenleistung verschwendet und die Antwortzeiten erhöht werden.

Prompt-Caching entwickelt sich zu einer leistungsstarken Optimierungstechnik, um diese Ineffizienz zu beheben. Es ermöglicht LLM-Anbietern, den Zwischenrechenzustand, der mit dem anfänglichen, statischen Teil eines Prompts (dem Präfix) verbunden ist, zu speichern. Wenn nachfolgende Anfragen dasselbe Präfix verwenden, kann das Modell diesen zwischengespeicherten Zustand wiederverwenden, die redundante Berechnung überspringen und nur den neuen, dynamischen Teil des Prompts (das Suffix) verarbeiten. Dies führt zu erheblichen Verbesserungen sowohl bei der Latenz als auch bei den Kosten und macht LLM-Anwendungen schneller und wirtschaftlicher.

Dieser Leitfaden bietet einen umfassenden Überblick über Prompt-Caching, wie es funktioniert, seine Vorteile, Implementierungsdetails (mit Schwerpunkt auf der API von Anthropic, die auch für Claude-Modelle auf AWS Bedrock relevant ist), Preisüberlegungen, Einschränkungen und Best Practices.

Wie Prompt-Caching funktioniert: Der Mechanismus

Im Kern nutzt Prompt-Caching die sich wiederholende Natur vieler LLM-Interaktionen aus. Wenn Sie einen Prompt an ein LLM senden, verarbeitet das Modell die Eingabe-Token sequenziell, um eine interne Darstellung oder einen Zustand zu erzeugen. Prompt-Caching fängt diesen Prozess ab.

1. Cache-Fehlschlag (Erste Anfrage / Geändertes Präfix): Wenn eine Anfrage mit einem Prompt-Präfix eintrifft, das kürzlich nicht gesehen wurde oder mit keinem vorhandenen Cache-Eintrag übereinstimmt, verarbeitet das LLM den gesamten Prompt wie gewohnt. Wenn das Caching jedoch für eine bestimmte Präfixgrenze aktiviert ist, speichert das System den internen Modellzustand, der diesem Präfix entspricht, nachdem es ihn verarbeitet hat. Dies wird oft als Cache-Schreiben bezeichnet. Eine eindeutige Kennung, typischerweise ein kryptografischer Hash des Präfixinhalts (einschließlich System-Prompts, Tool-Definitionen und Nachrichten bis zum Cache-Punkt), wird diesem gespeicherten Zustand zugeordnet und fungiert als Cache-Schlüssel.
2. Cache-Treffer (Nachfolgende Anfrage): Wenn eine nachfolgende Anfrage innerhalb der Time-To-Live (TTL) des Caches eintrifft und ihr Präfix genau mit dem Inhalt übereinstimmt, der einem gespeicherten Cache-Schlüssel zugeordnet ist, ruft das System den gespeicherten internen Zustand ab. Das LLM spult effektiv bis zum Ende des Präfix vor, ohne es erneut zu verarbeiten. Es muss dann nur den neuen Teil des Prompts (das Suffix) verarbeiten. Dies wird als Cache-Lesen oder Cache-Treffer bezeichnet.

Das zwischengespeicherte Präfix:

Was genau das "Präfix" ausmacht, hängt von der API und der Strukturierung Ihrer Anfrage ab. Im Allgemeinen enthält es die statischen Teile Ihres Prompts, die Sie über Aufrufe hinweg wiederverwenden möchten. Zum Beispiel, unter Verwendung der API-Struktur von Anthropic als Referenz:

• Tools: Definitionen der verfügbaren Tools/Funktionen.
• System-Prompt: Anweisungen oder Kontext auf hoher Ebene für das Modell.
• Nachrichten: Ursprüngliche Benutzer-/Assistenten-Nachrichten, wie z. B. Few-Shot-Beispiele oder der Konversationsverlauf.

Die Reihenfolge ist in der Regel wichtig (z. B. verarbeitet Anthropic tools, dann system, dann messages). Sie legen mit bestimmten API-Parametern fest, wo das zwischenspeicherbare Präfix endet.

Cache-Eigenschaften:

• Lebensdauer (TTL): Caches sind nicht dauerhaft. Sie haben eine TTL. Zum Beispiel hat der Cache von Anthropic eine minimale TTL von 5 Minuten, die jedes Mal aktualisiert wird, wenn auf den Cache-Eintrag zugegriffen wird (ein Cache-Treffer). Wenn ein Cache-Eintrag nicht innerhalb seiner TTL verwendet wird, läuft er ab und muss bei der nächsten relevanten Anfrage neu erstellt werden. Derzeit bieten die meisten Implementierungen "ephemeres" Caching mit relativ kurzen Lebensdauern.
• Umfang und Datenschutz: Caching ist unter Berücksichtigung des Datenschutzes konzipiert. Caches werden typischerweise auf Organisationsebene oder auf Kontoebene getrennt. Selbst wenn zwei verschiedene Organisationen genau dasselbe Prompt-Präfix senden, teilen sie sich keinen Cache-Eintrag. Innerhalb einer Organisation können Benutzer, die identische Präfixe senden, potenziell einen Cache-Eintrag teilen, was die Effizienz für Team-Anwendungen verbessert. Die Verwendung kryptografischer Hashes für Schlüssel stellt sicher, dass nur Anfragen mit identischen Präfixen auf einen bestimmten Cache zugreifen können.
• Exakte Übereinstimmung: Caching basiert auf exakten Übereinstimmungen des Präfixinhalts. Jede noch so kleine Änderung (sogar Leerzeichen) innerhalb des festgelegten Präfix führt zu einem Cache-Fehlschlag und erfordert ein neues Cache-Schreiben.

Warum Prompt-Caching verwenden?

Die Implementierung von Prompt-Caching bietet erhebliche Vorteile, die sich in erster Linie auf die Leistung und Kosteneffizienz konzentrieren.

1. Reduzierte Latenz: Dies ist oft der unmittelbarste Vorteil. Durch das Überspringen der erneuten Verarbeitung von potenziell Tausenden von Präfix-Token kann das LLM viel schneller mit der Verarbeitung der relevanten neuen Informationen (dem Prompt-Suffix) beginnen. Dies führt direkt zu schnelleren Antwortzeiten für den Endbenutzer. Für Anwendungen, die eine Echtzeit-Interaktion erfordern, wie z. B. Chatbots oder Code-Assistenten, ist diese Beschleunigung entscheidend. AWS Bedrock meldet potenzielle Latenzreduzierungen von bis zu 85 % für unterstützte Modelle.
2. Reduzierte Kosten: LLM-APIs berechnen in der Regel auf der Grundlage der Anzahl der verarbeiteten Eingabe- und Ausgabe-Token. Wenn ein Cache-Treffer auftritt, werden Ihnen oft deutlich geringere Gebühren für die aus dem Cache gelesenen Token berechnet als für die Standard-Eingabe-Token-Rate. Sie zahlen nur die Standard-Eingabe-Rate für die neuen Token im Suffix (und möglicherweise eine etwas höhere Rate für das anfängliche Cache-Schreiben). Über viele Aufrufe mit großen, statischen Präfixen kann dies zu erheblichen Kosteneinsparungen führen. AWS Bedrock schlägt vor, dass Kostensenkungen von bis zu 90 % möglich sind.
3. Optimierte Leistung für gängige Anwendungsfälle: Caching wirkt sich besonders auf Anwendungen aus, die von Natur aus eine Prompt-Wiederholung beinhalten:

• Retrieval-Augmented Generation (RAG) / Dokument-Q&A: Große Dokumente oder Kontext-Snippets werden oft wiederholt als Teil des Prompts eingespeist, während sich nur die Frage des Benutzers ändert. Das Caching des Dokumentkontexts beschleunigt Q&A über dieses Dokument erheblich.
• Few-Shot-Prompting: Das Bereitstellen mehrerer Beispiele innerhalb des Prompts (Few-Shot-Learning) verbessert die Modellleistung, erhöht aber die Prompt-Länge. Das Caching dieser statischen Beispiele vermeidet die erneute Verarbeitung für jede neue Abfrage.
• Agenten-Workflows: KI-Agenten verlassen sich oft auf komplexe System-Prompts, detaillierte Anweisungen und einen festen Satz von Tool-Definitionen. Das Caching dieser konstanten Elemente beschleunigt die Ausführung von Aufgaben, insbesondere in mehrstufigen Prozessen.
• Chatbots / Multi-Turn-Konversationen: Während der Konversationsverlauf wächst, bleiben der anfängliche System-Prompt und die Anweisungen oft gleich. Das Caching des System-Prompts und möglicherweise das inkrementelle Caching von Konversationsrunden halten die Interaktion flott, selbst wenn sich das Kontextfenster füllt.
• Code-Assistenten: Statischer Code-Kontext, Bibliotheksdokumentation oder Boilerplate-Anweisungen können zwischengespeichert werden, sodass sich der Assistent auf die spezifische Code-Abfrage des Benutzers konzentrieren kann.

1. Nahtlose Integration: Prompt-Caching ist so konzipiert, dass es zusammen mit anderen LLM-Funktionen funktioniert. Es lässt sich beispielsweise in AWS Bedrock-Funktionen wie Agents und Guardrails integrieren, sodass Sie komplexe Setups nutzen können, ohne die volle Latenzstrafe für wiederholte Komponenten zu erleiden.

So aktivieren Sie Prompt-Caching

Die genaue Methode zum Aktivieren von Prompt-Caching variiert geringfügig zwischen LLM-Anbietern und ihren APIs. Hier konzentrieren wir uns auf die Implementierung mit der Messages-API von Anthropic, die für Claude-Modelle direkt über Anthropic oder über Plattformen wie AWS Bedrock gilt.

Allgemeines Prinzip: Strukturieren Sie Ihren Prompt

Der Schlüssel ist, Ihre API-Aufrufe so zu strukturieren, dass der statische, wiederverwendbare Inhalt zuerst und dann der dynamische Inhalt angezeigt wird.

+-------------------------+--------------------------+
|      STATISCHES PRÄFIX      |     DYNAMISCHES SUFFIX       |
| (System-Prompt, Tools,  | (Neue Benutzerabfrage, Letzte  |
|  Few-Shot-Beispiele,     |  Konversationsrunde usw.)|
|  Erster Kontext)       |                          |
+-------------------------+--------------------------+
          ^
          |
   Cache-Haltepunkt hier

Anthropic API-Implementierung (cache_control)

Anthropic verwendet den Parameter cache_control innerhalb des Anforderungstexts der Messages-API, um das Caching zu aktivieren und zu verwalten.

• Aktivieren: Fügen Sie ein cache_control-Objekt in einen der Blöcke ein, die Sie als Ende Ihres zwischenspeicherbaren Präfix einbeziehen möchten. Derzeit ist der einzige unterstützte type "ephemeral".
• Platzierung: Sie können den cache_control-Block platzieren auf:
• Der system-Prompt-Nachricht.
• Einem bestimmten message-Objekt (Benutzer- oder Assistenten-Runde).
• Einem tool-Definitionsblock (weniger üblich, aber möglich).
• Cache-Erstellungsreihenfolge: Das Cache-Präfix wird basierend auf dem Inhalt bis einschließlich des mit cache_control markierten Blocks erstellt, wobei die Standardreihenfolge eingehalten wird: tools -> system -> messages.
• Mehrere Haltepunkte: Sie können bis zu 4 Cache-Haltepunkte in einer einzigen Anfrage definieren, indem Sie cache_control zu mehreren Blöcken hinzufügen. Das System versucht, das längste übereinstimmende zwischengespeicherte Präfix basierend auf diesen potenziellen Haltepunkten zu finden.

Beispiel (Anthropic Python SDK): Zwischenspeichern eines System-Prompts

import anthropic

client = anthropic.Anthropic(api_key="YOUR_API_KEY")

# Erste Anfrage (Cache-Schreiben)
response1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # Dieser System-Prompt ist der Inhalt, den wir zwischenspeichern möchten
            "text": "Sie sind ein hilfreicher Assistent, der sich auf Astrophysik spezialisiert hat. Ihre Wissensbasis umfasst ausführliche Details über Sternentwicklung, Kosmologie und Planetenkunde. Antworten Sie präzise und prägnant.",
            "cache_control": {"type": "ephemeral"} # Zum Caching markieren
        }
    ],
    messages=[
        {
            "role": "user",
            # Dies ist der dynamische Teil, der nicht im Präfix zwischengespeichert wird
            "content": "Was ist die Chandrasekhar-Grenze?"
        }
    ]
)
print("Erste Antwort:", response1.content)
print("Nutzung (Schreiben):", response1.usage)
# Beispielausgabe der Nutzung könnte so aussehen:
# Usage(Write): Usage(input_tokens=60, output_tokens=50, cache_creation_input_tokens=60, cache_read_input_tokens=0)

# Nachfolgende Anfrage (Cache-Treffer - innerhalb der TTL, z. B. < 5 Minuten später)
response2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # GENAU der gleiche System-Prompt wie zuvor
            "text": "Sie sind ein hilfreicher Assistent, der sich auf Astrophysik spezialisiert hat. Ihre Wissensbasis umfasst ausführliche Details über Sternentwicklung, Kosmologie und Planetenkunde. Antworten Sie präzise und prägnant.",
            "cache_control": {"type": "ephemeral"} # Erneut markieren
        }
    ],
    messages=[
        {
            "role": "user",
            # Neue dynamische Abfrage
            "content": "Erklären Sie das Konzept der dunklen Energie."
        }
    ]
)
print("\\\\nZweite Antwort:", response2.content)
print("Nutzung (Treffer):", response2.usage)
# Beispielausgabe der Nutzung könnte so aussehen:
# Usage(Hit): Usage(input_tokens=8, output_tokens=75, cache_creation_input_tokens=0, cache_read_input_tokens=60)

In diesem Beispiel:

1. Der erste Aufruf verarbeitet die 60 Token des System-Prompts und die 8 Token der Benutzernachricht. Er speichert den System-Prompt zwischen (cache_creation_input_tokens: 60).
2. Der zweite Aufruf findet einen Cache-Treffer für den identischen System-Prompt (cache_read_input_tokens: 60). Er muss nur die 8 Token der neuen Benutzernachricht als Standardeingabe verarbeiten (input_tokens: 8).

Beispiel (Inkrementelles Caching in der Konversation):

Um den Konversationsverlauf zwischenzuspeichern, können Sie cache_control auf die letzte Nachricht setzen, die Sie für die nächste Runde im Cache haben möchten.

# Runde 1 (Benutzer fragt, Assistent antwortet - System + Runde 1 zwischenspeichern)
response_turn1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "Behalten Sie eine freundliche Persona bei."}], # Auch dies zwischenspeichern
    messages=[
        {"role": "user", "content": "Hallo Claude!"},
        {"role": "assistant", "content": "Hallo! Wie kann ich Ihnen heute helfen?", "cache_control": {"type": "ephemeral"}} # Bis hierher zwischenspeichern
    ]
)
# Tun Sie so, als ob der Benutzer eine weitere Nachricht für Runde 2 hinzufügt
# Runde 2 (Cache-Treffer für System + Runde 1, Cache-Schreiben für Runde 2)
response_turn2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "Behalten Sie eine freundliche Persona bei."}], # Gleicher System-Prompt
    messages=[
        {"role": "user", "content": "Hallo Claude!"}, # Teil des zwischengespeicherten Präfix jetzt
        {"role": "assistant", "content": "Hallo! Wie kann ich Ihnen heute helfen?"}, # Teil des zwischengespeicherten Präfix jetzt
        {"role": "user", "content": "Erzähl mir eine lustige Tatsache."}, # Neuer dynamischer Inhalt
        {"role": "assistant", "content": "Wussten Sie, dass Honig nie verdirbt?", "cache_control": {"type": "ephemeral"}} # Bis zum Ende von Runde 2 zwischenspeichern
    ]
)
# Die Nutzung von Runde 2 würde cache_read_input_tokens für System+Runde1 anzeigen
# und cache_creation_input_tokens für die neuen Benutzer-/Assistenten-Nachrichten von Runde 2

Verfolgen der Cache-Leistung:

Die API-Antwort enthält Nutzungsmetriken, die zeigen, wie der Cache verwendet wurde:

• input_tokens: Anzahl der nicht zwischengespeicherten Eingabe-Token, die verarbeitet wurden (das dynamische Suffix).
• output_tokens: Anzahl der in der Antwort generierten Token.
• cache_creation_input_tokens: Anzahl der Eingabe-Token, die in dieser Anfrage verarbeitet und in den Cache geschrieben wurden (tritt bei einem Cache-Fehlschlag auf).
• cache_read_input_tokens: Anzahl der Eingabe-Token, die in dieser Anfrage aus dem Cache geladen wurden (tritt bei einem Cache-Treffer auf).

Die Überwachung dieser Felder ist entscheidend, um zu verstehen, ob Ihre Caching-Strategie effektiv ist. Hohe cache_read_input_tokens im Verhältnis zu cache_creation_input_tokens im Laufe der Zeit weisen auf erfolgreiches Caching hin.

AWS Bedrock:

Für Modelle wie Anthropic Claude, auf die über AWS Bedrock zugegriffen wird, wird der Caching-Mechanismus typischerweise mit demselben Parameter cache_control innerhalb des Anforderungstexts des Modellausrufs (application/json-Format, das an InvokeModel oder InvokeModelWithResponseStream übergeben wird) aktiviert. Sie würden den JSON-Text entsprechend den Anforderungen des jeweiligen Modells strukturieren (z. B. das Format der Messages-API von Anthropic) und das Feld cache_control wie oben gezeigt einfügen. Überprüfen Sie die spezifische Bedrock-Dokumentation für den von Ihnen verwendeten Modellanbieter.

Wie ist die Preisgestaltung für Prompt-Caching?

Prompt-Caching führt eine differenziertere Preisstruktur im Vergleich zu Standard-Token-Kosten ein. Obwohl es insgesamt vorteilhaft ist, ist es wichtig, die verschiedenen beteiligten Token-Typen zu verstehen:

1. Basis-Eingabe-Token: Dies sind die Standard-Eingabe-Token, die nicht Teil eines zwischengespeicherten Präfix sind (d. h. das dynamische Suffix in einem Cache-Treffer-Szenario oder der gesamte Prompt, wenn Caching nicht verwendet wird oder Fehlschläge auftreten). Sie werden zum Standard-Eingabe-Token-Satz des Modells berechnet.
2. Cache-Schreib-Token (cache_creation_input_tokens): Wenn ein Präfix zum ersten Mal verarbeitet (oder nach einem Cache-Fehlschlag) und in den Cache geschrieben wird, werden die Token, die diesem Präfix zugeordnet sind, oft zu einem Premium-Satz berechnet. Zum Beispiel berechnet Anthropic 25 % mehr als die Basis-Eingabe-Token-Rate für Cache-Schreibvorgänge. Dies spiegelt die Kosten für die Verarbeitung und Speicherung des Cache-Eintrags wider.
3. Cache-Lese-Token / Cache-Treffer-Token (cache_read_input_tokens): Wenn ein Cache-Treffer auftritt, werden die Token, die dem aus dem Cache geladenen Präfix entsprechen, zu einem deutlich reduzierten Satz berechnet. Zum Beispiel berechnet Anthropic nur 10 % der Basis-Eingabe-Token-Rate (ein Rabatt von 90 %) für Cache-Lesevorgänge. Dies spiegelt die Rechenersparnisse wider.
4. Ausgabe-Token: Vom LLM als Antwort generierte Token werden zum Standard-Ausgabe-Token-Satz des Modells berechnet, unabhängig davon, ob Caching für die Eingabe verwendet wurde.

Beispiel-Preistabelle (Anthropic Claude-Modelle - illustrative Raten):

(Hinweis: Beziehen Sie sich immer auf die offiziellen Preisgestaltungsseiten von Anthropic und AWS Bedrock, um die aktuellsten Preise zu erhalten.)

Die Wirtschaftlichkeit hängt stark davon ab, wie oft Sie Cache-Treffer im Vergleich zu Fehlschlägen für ein bestimmtes Präfix erhalten. Wenn ein großes Präfix viele Male wiederverwendet wird, werden die anfänglichen höheren Kosten des Cache-Schreibvorgangs schnell durch die erheblichen Einsparungen durch nachfolgende Cache-Lesevorgänge ausgeglichen.

Einschränkungen des Prompt-Caching

Obwohl es leistungsstark ist, hat Prompt-Caching Einschränkungen und zu berücksichtigende Faktoren:

Minimale zwischenspeicherbare Länge: Modelle haben oft eine minimale Token-Anforderung, damit ein Präfix für das Caching in Frage kommt. Prompts, die kürzer als diese Grenze sind, können nicht zwischengespeichert werden, selbst wenn sie mit cache_control markiert sind.

• Anthropic Claude 3.7/3.5 Sonnet & Opus: Mindestens 1024 Token.
• Anthropic Claude 3.5/3 Haiku: Mindestens 2048 Token.

Cache-Ungültigkeit (Cache-Busting): Der Cache reagiert extrem empfindlich auf Änderungen im Präfix. Jede Änderung unterbricht den Cache und erzwingt ein neues Schreiben:

• Ändern jeglichen Textinhalts innerhalb der Blöcke system, tools oder messages, die als Teil des Präfix festgelegt sind.
• Ändern der Reihenfolge oder Anzahl der tool-Definitionen.
• Ändern der Parameter tool_choice (z. B. Wechsel von auto zu einem bestimmten Tool).
• Hinzufügen, Entfernen oder Ändern von Bildern innerhalb des Prompts (für multimodale Modelle).
• Die Änderung anderer Modellparameter, die die anfängliche Verarbeitung beeinflussen, könnte auch den Cache unterbrechen (z. B. können die erweiterten Denkeinstellungen von Anthropic Nachrichten-Caches ungültig machen).

Cache-Lebensdauer (TTL): Denken Sie daran, dass der Cache flüchtig ist (z. B. 5 Minuten minimale TTL für Anthropic, aktualisiert bei Verwendung). Präfixe, die nicht innerhalb der TTL wiederverwendet werden, laufen ab. Derzeit gibt es keine Möglichkeit, den Cache manuell zu leeren oder über sein automatisches Verhalten hinaus zu erweitern.

Gleichzeitigkeit: Wenn Sie viele identische Anfragen gleichzeitig senden, die auf ein Präfix abzielen, bevor die erste Anfrage abgeschlossen und der Eintrag in den Cache geschrieben wurde, können nachfolgende Anfragen zu Cache-Fehlschlägen führen, bis das erste Schreiben abgeschlossen ist. Für garantierte Treffer in parallelen Szenarien müssen Sie möglicherweise auf die erste Antwort warten, bevor Sie andere senden.

Unterstützte Modelle: Prompt-Caching ist nicht universell für alle Modelle oder Anbieter verfügbar. Überprüfen Sie immer die Dokumentation für das spezifische Modell, das Sie verwenden möchten. (Derzeit für verschiedene Claude 3- und 3.5-Modelle bestätigt).

Debugging: Das Erkennen subtiler Änderungen, die Cache-Fehlschläge verursachen, kann manchmal knifflig sein. Ein sorgfältiger Vergleich des genauen Präfixinhalts zwischen Aufrufen ist erforderlich.

Best Practices für effektives Caching

Um die Vorteile des Prompt-Caching zu maximieren:

1. Prompts intelligent strukturieren: Platzieren Sie die stabilsten, wiederverwendbaren Informationen (System-Prompts, Anweisungen, Tool-Definitionen, Kontextdokumente, Few-Shot-Beispiele) am Anfang Ihrer Prompt-Sequenz. Platzieren Sie dynamische, sich häufig ändernde Informationen (Benutzerabfragen, letzte Konversationsrunden) nach dem Cache-Haltepunkt.
2. Optimale Haltepunkte identifizieren: Verwenden Sie cache_control (oder den entsprechenden Mechanismus) bewusst. Markieren Sie das Ende des größtmöglichen Blocks wirklich statischen Inhalts. Wenn Sie mehrere Haltepunkte verwenden (wie Anthropic es erlaubt), berücksichtigen Sie unterschiedliche Stabilitätsgrade in Ihrer Prompt-Struktur.
3. Cache-Nutzung überwachen: Überprüfen Sie regelmäßig die cache_creation_input_tokens und cache_read_input_tokens in Ihren API-Antworten. Streben Sie im Laufe der Zeit ein hohes Verhältnis von Lesevorgängen zu Schreibvorgängen an. Wenn Sie hauptsächlich Schreibvorgänge sehen, ändern sich Ihre Präfixe möglicherweise zu oft, oder sie sind möglicherweise kürzer als die minimale zwischenspeicherbare Länge.
4. Vermeiden Sie unnötige Änderungen: Beachten Sie, dass selbst winzige, scheinbar unbedeutende Änderungen am Präfixinhalt (z. B. das Hinzufügen eines Leerzeichens oder das Ändern der Interpunktion) den Cache unterbrechen. Stellen Sie die Konsistenz bei der Generierung von Präfixen sicher.
5. Berücksichtigen Sie Kosten-Trade-offs: Caching ist am effektivsten für lange und häufig wiederverwendete Präfixe. Zwischenspeichern Sie keine sehr kurzen Präfixe, da die potenziellen Einsparungen minimal sind und die Komplexität möglicherweise nicht überwiegen. Vermeiden Sie das Caching von stark variablen Benutzereingaben.
6. Testen und iterieren: Experimentieren Sie mit verschiedenen Prompt-Strukturen und Cache-Haltepunkten, um die optimale Strategie für die Arbeitslast und Nutzungsmuster Ihrer spezifischen Anwendung zu finden.

Fazit

Prompt-Caching ist eine wichtige Optimierungstechnik für alle, die Anwendungen auf der Grundlage von Large Language Models erstellen. Durch intelligentes Speichern und Wiederverwenden des Rechenzustands statischer Prompt-Präfixe werden die Herausforderungen der Latenz und der Kosten, die mit langen oder sich wiederholenden Prompts verbunden sind, direkt angegangen. Das Verständnis, wie Caching funktioniert, seine spezifischen Implementierungsdetails für Ihren gewählten LLM-Anbieter (wie cache_control von Anthropic), die damit verbundenen Preisnuancen und seine Einschränkungen ermöglichen es Ihnen, effizientere, reaktionsschnellere und wirtschaftlichere KI-Anwendungen zu entwerfen. Da die LLM-Anwendungsfälle an Komplexität und Umfang zunehmen, wird die Nutzung von Funktionen wie Prompt-Caching für den Aufbau leistungsfähiger und nachhaltiger Lösungen immer wichtiger sein.