Caching-Strategien im Vergleich

Caching ist eine der wirkungsvollsten Taktiken zur Kostenreduktion bei LLM-Workloads. Die Idee ist einfach: Zahlen Sie nicht für Inferenz, wenn Sie ein gecachtes Ergebnis zurückgeben können. Aber "Caching" ist nicht eine einzige Technik - es sind vier unterschiedliche Strategien mit verschiedenen Kompromissen bei Kostenersparnissen, Latenz, Genauigkeit und Implementierungskomplexität. Die falsche Wahl zu treffen verschwendet Ingenieuraufwand; die richtige Wahl kann 30–70% Ihrer Rechnung einsparen.

Strategievergleich

Strategie	Funktionsweise	Kostenersparnis	Auswirkung auf Latenz	Implementierungsaufwand	Ideal für	Anbieter
Prompt-Cache (Provider-seitig)	Der Anbieter speichert die KV-Berechnung für wiederholte Prompt-Präfixe. Nachfolgende Anforderungen mit demselben Präfix überspringen die Neuverarbeitung.	50% bei gecachten Input-Tokens	60–80% schnellere First-Token-Latenz	Null bis niedrig - automatisch bei den meisten Anbietern	Lange System-Prompts, RAG mit gemeinsamen Kontext, Agent-Schleifen	OpenAI, Anthropic, Google
Semantischer Cache (Embedding-basiert)	Embeddings der Benutzerabfrage generieren, einen Vektor-Store nach ähnlichen früheren Abfragen durchsuchen. Wenn die Ähnlichkeit einen Schwellenwert überschreitet, die gecachte Antwort zurückgeben, ohne das LLM aufzurufen.	20–50% je nach Abfrage-Wiederholung	50–90% schneller (kein LLM-Aufruf)	Mittel - benötigt Embedding-Modell, Vektor-Store, Anpassung des Ähnlichkeitsschwellenwerts	FAQ-Bots, Kundenbetreuung, wiederholte Abfragen	Beliebig (selbst-gehostet via GPTCache, Redis mit Vektorsuche)
Context-Caching (Google-Stil)	Große Kontextdokumente (PDFs, Code-Repositories) serverseitig cachen. Zahlen Sie einmal für die Kontextverarbeitung, verwenden Sie das Ergebnis über viele Abfragen mit reduzierter pro-Abfrage-Kosten.	70–90% bei kontextintensiven Abfragen	Moderate Verbesserung bei Kontextverarbeitung	Niedrig bis mittel - Kontext hochladen, TTL verwalten	Dokument-Q&A, Code-Review über große Repositories, Multi-Turn mit statischem Kontext	Google (Gemini), Anthropic (erweiterter Thinking-Kontext)
Application-Level-Cache (Redis/CDN)	Deterministischer Hash der vollständigen Anforderung (Prompt + Parameter). Speichern Sie die Antwort in Redis oder einem CDN. Geben Sie die gecachte Antwort bei exakter Übereinstimmung zurück.	Bis zu 100% bei Cache-Treffern	90–99% schneller (kein LLM-Aufruf)	Niedrig - Standard-Caching-Infrastruktur	Deterministische Abfragen, Klassifikation, Extraktion mit festen Prompts	Beliebig (Infrastruktur, die Sie kontrollieren)

Prompt-Caching im Detail

Prompt-Caching ist der einfachste Gewinn. OpenAI speichert automatisch Prompts länger als 1.024 Tokens. Anthropic speichert Präfixe von 2.048+ Tokens. Der Cache wird über den exakten Präfix indiziert - gleicher System-Prompt, gleiche Few-Shot-Beispiele, gleicher Dokument-Kontext. Wenn ein Cache-Treffer auftritt, zahlen Sie 50% weniger für den gecachten Teil der Input-Tokens.

Der Haken: Cache-Invalidierung wird vom Anbieter kontrolliert. Wenn sich der Prompt auch nur leicht ändert - eine andere System-Nachricht, eine andere Variable im Präfix - der Cache schlägt fehl. Gestalten Sie Ihre Prompts so, dass Sie stabilen Inhalt am Anfang platzieren und dynamischen Inhalt zum Ende des Prompts verschieben.

Semantisches Caching im Detail

Semantisches Caching überspringt das LLM vollständig, wenn eine ähnliche Frage bereits gestellt wurde. Der Ablauf: Embeddings der Abfrage generieren, einen Vektor-Store durchsuchen (Pinecone, Qdrant, Redis mit Vektorsuche), prüfen, ob das beste Ergebnis einen Ähnlichkeitsschwellenwert überschreitet (typischerweise 0,92–0,97), und die gecachte Antwort zurückgeben, wenn dies der Fall ist.

Das Risiko besteht darin, veraltete oder leicht fehlerhafte Antworten zurückzugeben. Ein Schwellenwert, der zu niedrig ist, gibt falsche Ergebnisse zurück; einer, der zu hoch ist, bedeutet fast keine Cache-Treffer. Passen Sie ihn pro Anwendungsfall an. Für sachliche FAQ-Abfrage ist 0,95+ sicher. Für kreative Generierung ist semantisches Caching selten angebracht - der ganze Punkt ist Neuheit.

Context-Caching im Detail

Google's Context-Caching ermöglicht es Ihnen, ein großes Dokument einmal hochzuladen und eine reduzierte Rate für nachfolgende Abfragen daran zu zahlen. Dies ist leistungsstark für Dokument-Q&A, bei der Sie die gleiche 200-seitige PDF hunderte Male verarbeiten. Das Kostenmodell: Zahlen Sie die vollständige Input-Token-Rate einmal für den Cache-Schreibvorgang, dann eine reduzierte Rate (oft 25% der normalen Rate) für jeden Cache-Lesevorgang.

Der Kompromiss ist die TTL. Gecachte Kontexte verfallen. Wenn Ihre Workload bursty Zugriffsmuster hat - 500 Abfragen in einer Stunde, dann nichts für eine Woche - der Cache kann zwischen Bursts ablaufen. Passen Sie Ihre TTL an Ihr Zugriffsmuster an.

Application-Level-Caching im Detail

Deterministisches Caching ist die aggressivste Strategie. Hashen Sie die vollständige Request-Payload (Prompt, Temperatur, maximale Tokens, Modell, Tools) und speichern Sie die Antwort. Bei exakter Übereinstimmung geben Sie die gecachte Antwort sofort zurück - kein LLM-Aufruf, keine Latenz, keine Kosten.

Dies funktioniert nur, wenn die gleiche Eingabe immer die gleiche Ausgabe produzieren sollte. Klassifikation, Entitätsextraktion, Analyse strukturierter Daten und Template-basierte Generierung sind gute Kandidaten. Konversationsaufgaben oder kreative Aufgaben sind es nicht - Benutzer erwarten unterschiedliche Antworten.

Strategien kombinieren

Die besten Implementierungen layern mehrere Strategien. Ein typischer Stack: Application-Level-Cache als erste Prüfung (billigste, schnellste), semantischer Cache als zweite Prüfung (erfasst Near-Duplicates), dann der LLM-Aufruf mit Provider-seitigem Prompt-Caching aktiviert (reduziert Kosten auch bei Cache-Misses). Dieser gelagerte Ansatz kann die Gesamtausgaben für LLM um 40–70% bei Workloads mit jeglichem Wiederholungsgrad reduzieren.

Verfolgen Sie Cache-Hit-Raten separat für jede Schicht. Wenn Ihre semantische Cache-Hit-Rate unter 10% fällt, lohnt sich der Vektor-Store-Overhead möglicherweise nicht. Wenn Ihre Application-Cache-Hit-Rate über 40% liegt, haben Sie wahrscheinlich deterministische Aufgaben, die auf der Prompt-Ebene optimiert werden sollten.