Prompt-Caching senkt KI-Inferenzkosten um bis zu 90 Prozent, doch die meisten Teams nutzen es falsch

Die meisten Teams, die für den API-Zugriff auf große Sprachmodelle (LLM) bezahlen, lassen 50 bis 90 Prozent potenzieller Einsparungen liegen, obwohl der Mechanismus dafür seit über einem Jahr produktionsreif verfügbar ist. Prompt-Caching erlaubt es einem API-Anbieter, die bereits geleistete Berechnung für die unveränderlichen Teile einer Anfrage — Systemanweisungen, Tool-Definitionen, lange Referenzdokumente — wiederzuverwenden, statt sie bei jedem Aufruf neu zu verarbeiten.

Das Problem ist nicht, dass Prompt-Caching nicht funktioniert. Das Problem ist, dass die meisten Engineering-Teams ihre Prompts so strukturieren, dass es zunichtegemacht wird, bevor es überhaupt helfen kann — und dann schließen sie daraus, das Feature habe "nichts gebracht".

Wie der Cache tatsächlich funktioniert

Wenn ein Transformer-Modell einen Prompt verarbeitet, berechnet es Key-Value-Paare (KV) für jedes Eingabetoken — die internen Repräsentationen, die das Modell zur Vorhersage des nächsten Tokens nutzt. Diese Berechnung ist der teure Teil der Inferenz und skaliert mit der Eingabelänge. Prompt-Caching speichert diese KV-Paare nach einer ersten Anfrage auf den Servern des Anbieters, indiziert exakt nach demselben Token-Präfix, das sie erzeugt hat.

Bei einer nachfolgenden Anfrage überspringt der Anbieter, sofern der neue Prompt dasselbe Präfix teilt, die Neuberechnung der KV-Paare für den gemeinsamen Teil und verarbeitet nur die neu angehängten Tokens am Ende. Anthropics Implementierung berechnet zum Beispiel etwa 10 Prozent des Basis-Eingabetoken-Preises für Cache-Lesevorgänge und rund 25 Prozent mehr als den Basispreis für das anfängliche Cache-Schreiben — ein Kompromiss, der sich für jedes mehr als zweimal wiederverwendete Präfix schnell auszahlt. OpenAIs automatisches Prompt-Caching gewährt einen 50-prozentigen Rabatt auf gecachte Eingabetokens ohne separate Schreibkosten, und Googles Kontext-Caching bei Gemini-Modellen funktioniert ähnlich über ein explizites Cache-Objekt, das man erstellt und referenziert.

Woher die echten Einsparungen kommen

Die Einsparungen sind nicht theoretisch. Ein Kundensupport-Agent, der bei jedem Aufruf einen 3.000-Token-Systemprompt, einen 5.000-Token-Auszug aus der Produktwissensdatenbank und einen 2.000-Token-Satz von Tool-Definitionen enthält, zahlt für 10.000 Eingabetokens, bevor die eigentliche Frage des Nutzers — vielleicht 50 Tokens — überhaupt ins Spiel kommt. Bei einer Hochvolumen-Anwendung, die täglich Zehntausende Anfragen verarbeitet, übersteigt dieser Overhead die Grenzkosten der Anfrage selbst bei Weitem.

Bei korrekt konfiguriertem Caching wird dieses 10.000-Token-Präfix einmal berechnet und dann bei jedem nachfolgenden Aufruf innerhalb des Cache-Gültigkeitsfensters (TTL, typischerweise 5 Minuten bei Anthropics Standardstufe, bei manchen Anbietern auf eine Stunde erweiterbar) aus dem Cache gelesen. Der praktische Effekt für eine RAG-Pipeline mit großem abgerufenem Kontextfenster oder einen Agenten mit umfangreichem Tool-Aufruf-Schema ist eine Reduzierung der effektiven Eingabekosten um 60 bis 80 Prozent — ohne jede Änderung der Modellqualität, des Ausgabeverhaltens oder einer für den Nutzer spürbaren Latenz. Die Latenz verbessert sich sogar leicht, da gecachte Tokens den Forward-Pass vollständig überspringen.

Der Fehler, der die Cache-Trefferquote zerstört

Prompt-Caching funktioniert nur bei exakter Präfixübereinstimmung. Ändert sich auch nur ein einziges Token irgendwo vor der Cache-Grenze, schlägt der gesamte Cache-Eintrag fehl (Miss), und der Anbieter berechnet alles von Grund auf neu. Genau hier sabotieren sich die meisten Implementierungen still und leise selbst.

Das häufigste Fehlermuster: dynamische Inhalte — ein Zeitstempel, eine Session-ID, eine zufällig sortierte Liste abgerufener Dokumente — nahe dem Anfang des Prompts zu platzieren, noch vor den statischen Systemanweisungen und Tool-Definitionen. Dann hat jede Anfrage ein einzigartiges Präfix, und der Cache bekommt nie die Chance, Treffer aufzubauen. Die Lösung ist mechanisch, erfordert aber Disziplin: jeden Prompt so strukturieren, dass statischer Inhalt zuerst kommt (Systemanweisungen, Few-Shot-Beispiele, Tool-Schemas, stabile Referenzdokumente) und variabler Inhalt zuletzt (die tatsächliche Nachricht des Nutzers, aktuelles Datum falls nötig, sitzungsspezifischer Zustand).

Ein zweiter häufiger Fehler ist übermäßige Prompt-Personalisierung. Teams, die nutzerspezifische Präferenzen oder Kontodetails direkt in den Systemprompt einfügen — statt sie als separaten, klar abgegrenzten Block nach dem cachebaren Präfix zu übergeben — zerstören ihre eigene Cache-Trefferquote für eine marginale Qualitätsverbesserung, die oft nicht einmal messbar ist. Wenn sich Personalisierungsdaten pro Nutzer oder pro Sitzung ändern, gehören sie nach die Cache-Grenze, nicht in die gemeinsamen Anweisungen eingewoben.

Abgerufener Kontext ist der schwierigste Fall

RAG-Anwendungen stehen vor einer echten architektonischen Spannung: Der ganze Sinn des Retrievals besteht darin, für unterschiedliche Anfragen unterschiedliche Dokumente zu liefern, was per Definition die Präfixübereinstimmung beim abgerufenen Inhalt selbst zerstört. Die wirkungsvollste Lösung besteht hier nicht darin, die abgerufenen Textabschnitte zu cachen — sondern alles um sie herum. Halten Sie Systemprompt, Retrieval-Anweisungen und Spezifikation des Ausgabeformats in einem stabilen Präfix, und behandeln Sie die abgerufenen Dokumente als variablen Suffix. Teams mit großen Tool-Bibliotheken können zusätzlichen Gewinn erzielen, indem sie den Tool-Definitionsblock separat vom abgerufenen Inhalt cachen, da sich Tool-Schemas innerhalb einer Sitzung selten ändern, selbst wenn sich die Anfrage ändert.

Richtig messen

Anbieter-Dashboards melden Cache-Lese- und Schreibtoken-Zahlen üblicherweise getrennt von den Standard-Eingabetokens, was die Berechnung der tatsächlichen Trefferquote einfach macht: Cache-Lesevorgänge geteilt durch die Gesamtzahl der präfixfähigen Tokens. Teams sollten diese Zahl explizit verfolgen, statt Einsparungen aus der Gesamtrechnung abzuleiten, da sich eine niedrige Trefferquote hinter einer ansonsten plausiblen Rechnung verstecken kann, wenn auch das Anfragevolumen schwankt.

Zum Mitnehmen

• Prüfen Sie zuerst Ihre Prompt-Struktur: statischer Inhalt (Systemanweisungen, Tool-Schemas, Referenzdokumente) muss ausnahmslos vor jedem anfragespezifischen variablen Inhalt stehen.
• Personalisieren Sie nicht innerhalb des cachebaren Präfix — fügen Sie nutzerspezifische Daten als klar abgetrennten Block nach den gemeinsamen Anweisungen ein.
• Cachen Sie bei RAG-Pipelines das stabile Gerüst um den abgerufenen Inhalt, nicht den abgerufenen Inhalt selbst.
• Verfolgen Sie die Cache-Trefferquote als explizite Metrik, nicht als aus den Gesamtausgaben abgeleiteten Wert.
• Prüfen Sie das TTL-Fenster Ihres Anbieters und die Traffic-Muster — Verkehrslücken, die länger sind als das TTL-Fenster, erzwingen unabhängig von der Prompt-Struktur ein neues Cache-Schreiben.