Was ist Prompt-Caching? Wie ein wiederholter Prompt wiederverwendet wird

Prompt-Caching bedeutet, dass die API den Anfang deiner Anfrage im Speicher behält und ihn beim nächsten Mal wiederverwendet, wenn du denselben Anfang sendest. Du sendest bei jedem Aufruf weiterhin den vollständigen Text, aber der Anbieter kann sich die Arbeit sparen, den wiederholten Teil erneut zu lesen, und manche Anbieter berechnen diesen Teil zu einem niedrigeren Satz. Es funktioniert nur am Anfang der Anfrage, und nur wenn dieser Anfang identisch ist.

Der Support-Bot, der dieselbe Seite immer wieder liest#

Angenommen, du betreibst einen Support-Bot mit 2.000 Tickets pro Tag. Jede Anfrage beginnt mit denselben 3.000 Tokens: Tonalität, Rückerstattungsregeln, Versandrichtlinie. Danach kommt die einzeilige Kundennachricht, etwa „Wo ist meine Bestellung?“ (Wenn dir Tokens noch unklar sind, beginne mit was ein Token ist.)

Ohne Caching liest der Anbieter alle 3.000 Tokens Regeln erneut für Ticket Nummer 1, Ticket Nummer 2 und Ticket Nummer 2.000. Dieselbe Seite, 2.000-mal gelesen. Mit Caching zahlt die erste Anfrage den vollen Preis für das Lesen, und spätere Anfragen, die mit demselben Text beginnen, können die Arbeit wiederverwenden.

Der API-Leitfaden von DeepSeek (geprüft am 24. Oktober 2026) beschreibt genau das: Context-Caching ist standardmäßig aktiv, erfordert keine Codeänderungen, und eine spätere Anfrage mit einem überlappenden Präfix zählt als „Cache-Hit“. Nur die Eingabe wird gecacht. Die Antwort wird jedes Mal neu generiert.

Was als „gleich“ zählt: die Präfix-Regel#

Der Cache gleicht ab dem ersten Zeichen ab. Sobald deine Anfrage von der gecachten abweicht, ist alles danach neu. Deshalb ist die Reihenfolge deiner Anfrage wichtiger als ihre Länge.

Hier ist der Fehler, der das Caching stillschweigend zunichtemacht. Ein Entwickler möchte, dass der Bot die Uhrzeit kennt, und setzt sie an den Anfang:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

Die Zeit ändert sich jede Sekunde, also unterscheidet sich schon die allererste Zeile bei jeder Anfrage, und nichts danach kann übereinstimmen. Die Lösung ist, alles, was sich ändert, ans Ende zu verschieben:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Jetzt kommen die 3.000 Tokens Regeln zuerst und bleiben identisch. Dieselbe Logik deckt die anderen beiden häufigen Fälle ab: Ein langer Chat sendet bei jedem Zug seine gesamte Historie erneut, sodass die alten Nachrichten einen fertigen, sich wiederholenden Anfang bilden (mehr dazu in warum ein langer Chat mehr kostet), und ein Agent wiederholt seine Tool-Definitionen und Anweisungen bei jedem Schritt.

Caching ist außerdem Best-Effort. DeepSeek sagt, dass der Cache einige Sekunden zum Aufbau braucht, ein Hit eine vollständige Übereinstimmung mit einer vorhandenen Cache-Präfix-Einheit erfordert, es keine garantierte Trefferquote gibt und ungenutzte Caches gelöscht werden, normalerweise innerhalb von Stunden bis Tagen. Eine zweite Anfrage, die eine halbe Sekunde nach der ersten abgeschickt wird, trifft also möglicherweise noch nicht, und der Hit kann weniger als dein gesamtes Präfix abdecken.

So siehst du es: die Cache-Felder in usage#

Du musst nicht raten, ob es funktioniert hat. Jeder Anbieter meldet es im usage-Teil der Antwort, unter seinen eigenen Feldnamen.

DeepSeek verwendet zwei Felder:

• prompt_cache_hit_tokens — Eingabe-Tokens, die im Cache gefunden wurden
• prompt_cache_miss_tokens — Eingabe-Tokens, die nicht gefunden wurden

Angenommen, dein erstes Support-Ticket kommt mit prompt_cache_hit_tokens: 0 und prompt_cache_miss_tokens: 3200 zurück, und ein Ticket eine Minute später zeigt prompt_cache_hit_tokens: 3000 und prompt_cache_miss_tokens: 200. Die 3.000 Tokens Regeln wurden wiederverwendet; nur die neue Kundennachricht und ein paar Tokens wurden von Grund auf gelesen. Wenn die Hit-Zahl bei jedem Aufruf bei null bleibt, schau dir den Anfang deiner Anfrage an: Irgendetwas darin ändert sich.

Anthropic funktioniert anders, weil du markierst, was gecacht werden soll. Du fügst cache_control mit Typ ephemeral zur Anfrage oder zu einem Content-Block hinzu:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Laut der Prompt-Caching-Dokumentation von Anthropic (geprüft am 24. Oktober 2026) meldet die Antwort drei Zahlen: cache_creation_input_tokens (jetzt in den Cache geschrieben), cache_read_input_tokens (daraus gelesen) und input_tokens (was nach dem letzten Cache-Breakpoint kam). Angenommen, der erste Aufruf zeigt cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; der zweite zeigt 0 und 10000. Das ist ein Cache-Schreibvorgang gefolgt von einem Cache-Lesevorgang.

Es gibt eine Falle auf dem Bildschirm. Prompts, die kürzer als das Minimum des Modells sind (512, 1.024 oder 4.096 Tokens, je nach Modell), werden ohne Caching und ohne Fehler verarbeitet. Du siehst Nullen in beiden Cache-Feldern und keine Warnung. Die Standard-Lebensdauer beträgt 5 Minuten und wird bei jeder Nutzung kostenlos erneuert; ein optionales ttl von 1h hält sie länger.

Was es mit deiner Rechnung macht#

Caching ändert den Preis des wiederholten Teils, also lohnt es sich, einmal nachzurechnen. Anthropic nennt Multiplikatoren auf den Basis-Eingabepreis: Ein Cache-Schreibvorgang mit 5-minütiger Lebensdauer kostet 1,25×, ein Lesevorgang kostet 0,1× (0,05× für Opus 5.5 und Sonnet 5.5). Nimm ein 10.000-Token-Präfix, das in 20 Anfragen innerhalb des 5-Minuten-Fensters wiederverwendet wird, mit dem Standard-Lesefaktor 0,1×:

10.000 × 20 = 200.000 Tokens zum Basispreis ohne Caching

10.000 × 1,25 = 12.500 für die erste Anfrage, die den Cache schreibt

19 × 10.000 × 0,1 = 19.000 für die 19 Anfragen, die ihn lesen

12.500 + 19.000 = 31.500 Token-Äquivalente mit Caching

Der wiederholte Teil kostet also deutlich weniger als ein Fünftel des ungecachten Betrags. Der Haken: Wenn die 5 Minuten zwischen den Anfragen verstreichen, schreibt die nächste den Cache erneut mit 1,25×, und ein selten genutztes Präfix kann am Ende mehr kosten als gar kein Caching.

Jetzt der Bot von Anfang an, als einfache Vollpreis-Baseline. 2.000 Anfragen pro Tag, 3.000 Eingabe-Tokens und etwa 300 Ausgabe-Tokens jeweils:

2.000 × 3.000 = 6.000.000 Eingabe-Tokens pro Tag

2.000 × 300 = 600.000 Ausgabe-Tokens pro Tag

Die Tabelle bepreist diese Tageslast auf jedem verfügbaren CheapTokens-Modell neben OpenRouter:

DeepSeek-V4-Flash ist insgesamt günstiger als OpenRouter, wenn man Eingabe und Ausgabe zusammenzählt, und die Last passt problemlos: 380K Kontext und bis zu 32.768 Ausgabe-Tokens pro Antwort. Das sind die Vollpreiskosten der Last: Eingabe-Tokens × Preis pro Token. Ein langes, stabiles Präfix ist der Punkt, an dem dieser Eingabeanteil am größten ist.

Probiere es selbst in fünf Minuten#

Der Plan: Sende denselben langen System-Prompt zweimal mit unterschiedlichen Fragen und schau dir usage an. Setze deinen eigenen Regeltext in support_rules.txt (eine Seite oder zwei Text reichen aus). Der Endpunkt ist die OpenAI-kompatible CheapTokens API, und du kannst den Schlüssel aus deinem Konto nehmen.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

Was du in der Ausgabe prüfen solltest: prompt_tokens sagt dir, wie groß deine Anfrage ist. Beide Anfragen tragen denselben SYSTEM-Text, also wiederholt sich der Großteil dieser Zahl von einer Anfrage zur nächsten — ungefähr die Größe deiner Regeldatei. Dieser wiederholte Anfang ist der Teil, den ein Anbieter mit Caching, wie die DeepSeek-API oder Anthropic oben, wiederverwenden kann. Jetzt eine Übung zur Reihenfolge: Füge eine Zeile mit der aktuellen Zeit (datetime.now()) am Anfang von SYSTEM hinzu und führe es erneut aus. Die beiden Anfragen teilen keinen Anfang mehr, weil sie sich schon in der allerersten Zeile unterscheiden. Setze dieselbe Zeile ans Ende des Prompts, und der gemeinsame Anfang ist wieder da.

Eine kurze Checkliste für deine eigenen Prompts:

1. Stabile Text zuerst: Anweisungen, Regeln, Tool-Definitionen, Beispiele.
2. Ändernder Text zuletzt: Datum, Benutzername, die neueste Nachricht.
3. Halte das Präfix byte-genau identisch — selbst ein zusätzliches Leerzeichen zählt.
4. Prüfe die Mindestgröße des Anbieters, bevor du dich fragst, warum nichts gecacht wird.
5. Schau dir die Usage-Felder nach einer Änderung an, nicht davor.

Um deine eigene Last zu bepreisen, öffne die Preisseite und gib deine Eingabe- und Ausgabegrößen ein, oder beginne mit der DeepSeek-Seite. Sobald die erste Anfrage funktioniert, dauert dieselbe Schätzung für jeden Prompt, den du schreibst, eine Minute. Was die beiden Seiten einer Anfrage kosten, erfährst du unter Eingabe- vs. Ausgabe-Tokens.