Prompt-Caching erklärt: Wann es Geld spart und wann nicht

Was Prompt-Caching tatsächlich zwischenspeichert

Prompt-Caching ist kein semantisches Gedächtnis. Der Anbieter sagt nicht: „Das sieht ähnlich aus wie etwas, das Sie zuvor gesendet haben.“ Es entspricht eher folgender Aussage:

„Der Anfang dieser Anfrage stimmt für dieses Modell und diese Cache-Richtlinie ausreichend genau mit einer früheren Token-Sequenz überein, sodass wir die interne Berechnung für dieses Präfix wiederverwenden können.“

Diese Unterscheidung ist wichtig.

Prompt-Caching hilft in der Regel, wenn Sie wiederholt dasselbe lange Präfix senden:

• Systemanweisungen
• Tool-Schemas
• Umfangreiche Dokumentationssammlungen
• Produktkataloge
• Kontext aus der Codebasis
• Rechts- oder Richtlinienhandbücher
• Few-Shot-Beispiele
• Statische Retrieval-Ergebnisse, die über viele Anfragen hinweg wiederverwendet werden

Es hilft meist wenig, wenn jede Anfrage anders beginnt:

• Dynamische Zeitstempel am Anfang
• Nutzerspezifische Daten vor gemeinsam genutzten Inhalten
• Zufällige Reihenfolge der Beispiele
• Anfragespezifische UUIDs im cachefähigen Abschnitt
• Retrieval-Abschnitte, deren Reihenfolge oder Formatierung sich ändert
• Chatverlauf vor stabilen Anweisungen

Der entscheidende technische Schritt besteht darin, stabilen, kostenintensiven Kontext an den Anfang und veränderlichen Kontext weiter hinten zu platzieren.

Anthropic vs. OpenAI: Ähnliches Ziel, unterschiedliche Steuerungsmöglichkeiten

Anthropic und OpenAI unterstützen beide Prompt-Caching, unterscheiden sich aber in der Handhabung für Entwickler.

Anthropic bietet explizitere Möglichkeiten für Prompt-Caching. Sie können Inhaltsblöcke mit Cache-Steuerungsoptionen kennzeichnen und anschließend Nutzungsfelder prüfen, beispielsweise cache_creation_input_tokens und cache_read_input_tokens. So lässt sich leichter nachvollziehen, ob Sie Cache-Einträge erstellen oder daraus lesen.

Bei OpenAI funktioniert Prompt-Caching auf unterstützten Modellen stärker automatisch. Wenn ein Prompt-Präfix wiederverwendet wird, können gecachte Eingabe-Tokens anders abgerechnet und in den Nutzungsmetadaten ausgewiesen werden. Normalerweise setzen Sie keine expliziten Cache-Grenzen auf dieselbe Weise; stattdessen strukturieren Sie Anfragen so, dass das wiederverwendbare Präfix auf Byte- und Token-Ebene stabil bleibt.

Der praktische Unterschied liegt zwischen Kontrolle und Komfort.

Die Implementierungsdetails unterscheiden sich je nach Modell und Anbieter und entwickeln sich weiter. Die Architekturregel bleibt jedoch bestehen: Beim Caching geht es um wiederholte Präfixe, nicht um ähnliche Prompts.

Das Preismodell: Erstellung vs. Lesen

Um Prompt-Caching sinnvoll zu betrachten, teilen Sie Eingabe-Tokens in drei Kategorien ein:

1. Normale Eingabe-Tokens: werden zum üblichen Eingabepreis abgerechnet.
2. Tokens zur Cache-Erstellung: Tokens, die zum Erstellen eines Cache-Eintrags verwendet werden und häufig mit einem Aufschlag oder zu einem speziellen Schreibpreis abgerechnet werden.
3. Cache-Lese-Tokens: Tokens, die aus einem bestehenden Cache-Eintrag gelesen und in der Regel zu einem reduzierten Preis abgerechnet werden.

Anthropic weist diese Unterscheidung direkt über Nutzungsfelder aus, beispielsweise:

{
  "usage": {
    "input_tokens": 812,
    "cache_creation_input_tokens": 42000,
    "cache_read_input_tokens": 0,
    "output_tokens": 684
  }
}

Bei einer späteren Anfrage sollten Sie bei einem Cache-Treffer für das Präfix eher Folgendes sehen:

{
  "usage": {
    "input_tokens": 936,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 42000,
    "output_tokens": 711
  }
}

Der erste Aufruf erstellt den Cache. Spätere Aufrufe lesen daraus.

Die Wirtschaftlichkeit hängt von den aktuellen Preisen des Anbieters, der Cache-TTL und dem Modell ab. Da sich Preise ändern, bilde ich dies lieber mit Variablen im Code ab, statt feste Zahlen in Designdokumenten zu hinterlegen.

Hier ist eine kleine Python-Funktion, die ich verwende, um zu entscheiden, ob sich die Implementierung von Caching für eine Route lohnt:

def cache_savings(
    cached_tokens: int,
    normal_input_per_mtok: float,
    cache_write_per_mtok: float,
    cache_read_per_mtok: float,
    requests: int,
) -> dict:
    mtok = cached_tokens / 1_000_000

    no_cache = requests * mtok * normal_input_per_mtok
    with_cache = (
        mtok * cache_write_per_mtok +
        (requests - 1) * mtok * cache_read_per_mtok
    )

    return {
        "no_cache": round(no_cache, 6),
        "with_cache": round(with_cache, 6),
        "savings": round(no_cache - with_cache, 6),
        "savings_pct": round((1 - with_cache / no_cache) * 100, 2),
    }


print(cache_savings(
    cached_tokens=42_000,
    normal_input_per_mtok=3.00,
    cache_write_per_mtok=3.75,
    cache_read_per_mtok=0.30,
    requests=100,
))

Hier werden lediglich Beispielpreise verwendet. Entscheidend ist der Aufbau.

Bei einem wiederverwendbaren Präfix mit 42,000 Tokens und 100 Anfragen lohnt sich Caching meist sehr. Bei demselben Präfix und nur einer Anfrage kann Caching teurer sein, wenn der Schreibpreis über dem normalen Eingabepreis liegt.

Das ist der erste große Stolperstein: Prompt-Caching beruht auf Amortisierung. Wenn Sie das gecachte Präfix nicht wiederverwenden, erzielen Sie keine Einsparung.

Die Formel für den Break-even-Punkt

Sie können den Break-even-Punkt wie folgt abschätzen:

no_cache_cost = N * T * normal_price

cache_cost = T * write_price + (N - 1) * T * read_price

Dabei gilt:

• N ist die Anzahl der Anfragen, die dasselbe Präfix verwenden
• T ist die Anzahl cachefähiger Tokens
• normal_price ist der normale Preis für Eingabe-Tokens
• write_price ist der Preis für die Cache-Erstellung
• read_price ist der Preis für Cache-Lesezugriffe

Caching spart Geld, wenn:

T * write_price + (N - 1) * T * read_price
  <
N * T * normal_price

Das T kürzt sich bei der reinen Berechnung der Kostenschwelle heraus. Das bedeutet, dass die Anzahl der Wiederverwendungen und die relativen Preise die Entscheidung bestimmen. Im Betrieb spielt die Token-Anzahl dennoch eine Rolle: 80 % Einsparung bei 500 Tokens fallen kaum ins Gewicht; bei 80,000 Tokens werden sie zu einem relevanten Kostenposten.

Eine nützliche Faustregel:

break_even_requests =
  (write_price - read_price) / (normal_price - read_price)

Wenn Cache-Schreibzugriffe nur geringfügig teurer als normale Eingaben und Lesezugriffe deutlich günstiger sind, kann der Break-even-Punkt sehr niedrig liegen. Wenn Cache-Schreibzugriffe teuer sind oder sich Ihr Präfix selten wiederholt, ist der Nutzen von Caching unsicher.

So strukturieren Sie Prompts für stabile Präfixe

Die beste Optimierung für Prompt-Caching ist kein API-Flag. Es ist die Anordnung des Prompts.

Ungünstige Anordnung:

Request ID: req_8f19a
Current time: 2026-02-14T09:12:33Z
User: customer_4812
Locale: en-US

SYSTEM INSTRUCTIONS:
...

POLICY MANUAL:
[42,000 tokens of stable text]

USER QUESTION:
Can I get a refund after 45 days?

Dies verhindert Präfix-Caching, weil sich der Prompt gleich am Anfang unterscheidet.

Bessere Anordnung:

SYSTEM INSTRUCTIONS:
...

POLICY MANUAL:
[42,000 tokens of stable text]

DYNAMIC REQUEST METADATA:
Request ID: req_8f19a
Current time: 2026-02-14T09:12:33Z
User: customer_4812
Locale: en-US

USER QUESTION:
Can I get a refund after 45 days?

Der stabile Block steht am Anfang. Der dynamische Block folgt danach.

Bei explizitem Caching wie bei Anthropic kann der Aufbau konzeptionell so aussehen:

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 800,
  "system": [
    {
      "type": "text",
      "text": "You are a support policy assistant..."
    },
    {
      "type": "text",
      "text": "Refund policy manual v2026-02-01:\n\n...",
      "cache_control": {
        "type": "ephemeral"
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "Can I get a refund after 45 days?"
    }
  ]
}

Das genaue Anfrageschema variiert je nach API-Version und SDK. Betrachten Sie dies daher als Strukturbeispiel und nicht als Code zum Kopieren und Einfügen. Entscheidend ist, dass der große stabile Block explizit cachefähig ist und zwischen den Aufrufen unverändert bleibt.

Bei automatischem Caching wie bei OpenAI ist die Prompt-Struktur genauso wichtig, auch wenn Sie keinen Block manuell kennzeichnen:

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "system",
      "content": "You are a support policy assistant...\n\nRefund policy manual v2026-02-01:\n\n..."
    },
    {
      "role": "user",
      "content": "Can I get a refund after 45 days?"
    }
  ]
}

Wenn sich die Systemnachricht bei jeder Anfrage ändert, sollten Sie keine verlässlichen Cache-Lesezugriffe erwarten.

Ein praktisches Architekturmuster

Für Produktionssysteme bilde ich gecachte Prompt-Präfixe gern explizit im Anwendungscode ab.

Ein einfaches Muster:

prompt_prefix/
  support_policy_v17.txt
  tool_schema_v4.json
  examples_v9.md

runtime_request/
  user_question
  user_profile
  retrieved_recent_orders

Setzen Sie Anfragen dann wie folgt zusammen:

from pathlib import Path

POLICY_PREFIX = Path("prompt_prefix/support_policy_v17.txt").read_text()
TOOL_SCHEMA = Path("prompt_prefix/tool_schema_v4.json").read_text()
EXAMPLES = Path("prompt_prefix/examples_v9.md").read_text()

def build_prompt(user_question: str, user_profile: dict) -> str:
    stable_prefix = f"""
You are a support policy assistant.

TOOLS:
{TOOL_SCHEMA}

POLICY:
{POLICY_PREFIX}

EXAMPLES:
{EXAMPLES}
""".strip()

    dynamic_suffix = f"""
USER PROFILE:
{user_profile}

USER QUESTION:
{user_question}
""".strip()

    return stable_prefix + "\n\n--- DYNAMIC REQUEST ---\n\n" + dynamic_suffix

In der Praxis versioniere ich auch das Präfix. Wenn sich das Richtlinienhandbuch ändert, soll dies eine bewusste Cache-Invalidierung auslösen:

sha256sum prompt_prefix/support_policy_v17.txt

Dieser Hash wird zusammen mit dem Modellnamen, den Tokens zur Cache-Erstellung, den Cache-Lese-Tokens und der Anfrageroute protokolliert. Ohne diese Beobachtbarkeit sind Cache-Fehler mühsam, weil die Antwort weiterhin funktioniert; sie kostet nur mehr.

Eine nützliche Protokollzeile sieht so aus:

{
  "route": "support.answer",
  "model": "claude-sonnet-4-6",
  "prefix_hash": "9d3a4a...",
  "input_tokens": 932,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 42000,
  "output_tokens": 688,
  "latency_ms": 1840
}

Optimieren Sie nicht allein anhand der Abrechnung. Protokollieren Sie das Cache-Verhalten pro Route.

Latenz: Oft besser, aber kein Wundermittel

Prompt-Caching kann die Latenz reduzieren, weil der Modellanbieter Berechnungen für das gecachte Präfix wiederverwenden kann. Ich würde bei der Auslegung eines SLA jedoch keine feste Latenzreduzierung annehmen, solange ich sie nicht anhand meines eigenen Workloads gemessen habe.

Was im Produktionsbetrieb tatsächlich passiert, ist weniger geradlinig:

• Bei kurzen Prompts ist möglicherweise keine nennenswerte Änderung der Latenz zu erkennen.
• Lange zwischengespeicherte Präfixe verbessern häufig die Zeit bis zum ersten Token.
• Die Ausgabelänge dominiert weiterhin viele Anfragen.
• Tool-Aufrufe, Netzwerklatenz und Warteschlangen können die Vorteile des Caches verdecken.
• Cache-Misses verursachen Spitzen bei der Tail-Latenz, wenn Schreibvorgänge langsamer als Lesevorgänge sind.

Ein realistischer Benchmark-Aufbau ist einfach:

# warm cache
python run_eval.py --case support_refund --repeat 1

# measure cache reads
python run_eval.py --case support_refund --repeat 50 --jsonl out.jsonl

# inspect p50/p95 by cache_read_input_tokens > 0
python analyze_latency.py out.jsonl

Messen Sie Anfragen mit Cache-Hits und Cache-Misses getrennt. Wenn Sie sie zusammenfassen, erhalten Sie einen Wert, der keines von beiden erklärt.

Fallstricke, die ich in realen Systemen sehe

1. Dynamische Inhalte vor stabilen Inhalten

Das ist der häufigste Fehler. Ein Zeitstempel, eine Anfrage-ID, ein Dump der Feature-Flags, die Gebietsschemaeinstellung des Nutzers oder eine Experimentzuordnung wird an den Anfang des Systemprompts gesetzt.

Verschieben Sie diese Inhalte nach unten.

2. „Äquivalentes“ JSON ist nicht äquivalent

Diese beiden Ausschnitte sind semantisch identisch, aber für den Cache nicht unbedingt identisch:

{"name":"refund_lookup","timeout":3,"strict":true}

{
  "strict": true,
  "timeout": 3,
  "name": "refund_lookup"
}

Wenn Sie Tool-Schemas oder Konfigurationen in das zwischengespeicherte Präfix aufnehmen, serialisieren Sie diese deterministisch:

import json

def stable_json(data: dict) -> str:
    return json.dumps(data, sort_keys=True, separators=(",", ":"))

So vermeiden Sie versehentliche Cache-Misses durch Änderungen an der Schlüsselreihenfolge oder an Leerraumzeichen.

3. Retrieval kann die Cache-Fähigkeit zerstören

RAG-Systeme erstellen Prompts oft so:

Retrieved documents:
[doc A]
[doc B]
[doc C]

Instructions:
...

Wenn sich die Retrieval-Ergebnisse je nach Anfrage unterscheiden, unterscheidet sich auch das Präfix je nach Anfrage. Das ist in Ordnung, wenn der abgerufene Kontext tatsächlich dynamisch ist. Platzieren Sie Ihre stabilen Anweisungen aber nicht dahinter.

Besser:

Instructions:
...

Long-lived product documentation:
[stable docs]

Query-specific retrieved documents:
[doc A]
[doc B]
[doc C]

Bei Systemen mit hohem Anfragevolumen sollten Sie erwägen, den Kontext aufzuteilen in:

• Global stabile Anweisungen
• Mandantenspezifische stabile Dokumentation
• Nutzer- oder anfragespezifisches Retrieval

Jede Ebene zeigt ein anderes Cache-Verhalten.

4. Cache-TTLs sind wichtig

Manche Cache-Einträge laufen ab. Wenn Ihr Anfrageaufkommen in Schüben erfolgt, wird ein Präfix möglicherweise zehn Minuten lang intensiv wiederverwendet und danach nicht mehr genutzt. Längere Cache-Lebensdauern können helfen, sind aber je nach Anbieter und Modell möglicherweise mit anderen Preisen oder einer anderen Verfügbarkeit verbunden.

Hier kommt es auf die Verteilung der Anfragen an. „Wir erhalten 10,000 Anfragen pro Tag“ ist weniger hilfreich als „Wir erhalten zwischen 9 Uhr und 10 Uhr morgens 200 Anfragen pro Minute für genau dieses Präfix“.

5. Modellwechsel machen Annahmen ungültig

Sie sollten nicht davon ausgehen, dass ein für ein Modell zwischengespeichertes Präfix für ein anderes wiederverwendbar ist. Wenn Sie Anfragen zwischen Claude Opus 4.8, Sonnet 4.6, GPT-5.5, Gemini 3 oder offenen Modellen wie Llama, Qwen, DeepSeek, MiniMax oder Kimi verteilen, verfolgen Sie das Cache-Verhalten für jedes Modell separat.

Routing über mehrere Modelle ist nützlich, erschwert aber die Amortisation. Wenn das Anfrageaufkommen auf fünf Modelle verteilt wird, erhält jedes Modell möglicherweise weniger wiederholte Präfixe.

6. Prompt-Personalisierung kann nach hinten losgehen

Teams personalisieren Systemprompts häufig:

You are helping {{customer_name}}, who is on plan {{plan_name}}.

Das wirkt harmlos. Wenn die Personalisierung aber vor den zwischengespeicherten Inhalten steht, erhält jeder Kunde ein anderes Präfix. Platzieren Sie die Personalisierung weiter hinten, sofern sie nicht tatsächlich verändert, wie das Modell den stabilen Block interpretiert.

Wann Prompt-Caching Geld spart

Caching eignet sich in der Regel besonders gut, wenn:

• Das cachefähige Präfix groß ist, oft mit Tausenden oder Zehntausenden von Tokens.
• Genau dasselbe Präfix viele Male wiederverwendet wird.
• Das Präfix über Anfragen hinweg stabil bleibt.
• Anfragen innerhalb der Cache-Lebensdauer eintreffen.
• Sie Tokens für die Cache-Erstellung und das Lesen aus dem Cache beobachten können.
• Die Route eine vorhersehbare Prompt-Zusammensetzung hat.

Konkrete Beispiele:

• Ein Coding-Assistent fügt wiederholt dieselbe Repository-Übersicht und denselben Styleguide ein.
• Ein Support-Bot fügt bei jeder Frage zu Rückerstattungen dasselbe Richtlinienhandbuch ein.
• Ein Agent verwendet bei jeder Anfrage ein großes statisches Tool-Schema.
• Ein interner Rechercheassistent fügt für ein Team dieselbe Korpusübersicht ein.

Bei diesen Workloads kann Prompt-Caching eine der wirkungsvollsten Kostenoptimierungen sein, weil die Kontextqualität nicht reduziert werden muss. Sie behalten den langen Prompt bei; Sie zahlen nur nicht mehr jedes Mal den vollen Eingabepreis.

Wann Prompt-Caching nicht hilft

Caching bringt wenig oder wirkt sich negativ aus, wenn:

• Der Prompt kurz ist.
• Präfixe selten wiederverwendet werden.
• Der Großteil des Kontexts aus anfragespezifischem Retrieval stammt.
• Dynamische Daten vor stabilen Daten stehen.
• Sie während Experimenten ständig Anweisungen ändern.
• Das Anfrageaufkommen sich mit geringer Dichte auf viele Modelle, Mandanten oder Prompt-Varianten verteilt.
• Cache-Schreibvorgänge mehr kosten und Lesevorgänge zu selten sind, um diese Kosten zu amortisieren.

Ein häufiger Fallstrick bei der Evaluierung: Prompt-Caching sieht in einem Notebook schlecht aus, weil Sie jeden Fall nur einmal ausführen. In der Produktion sieht es dann hervorragend aus, weil Tausende von Nutzern dasselbe stabile Präfix verwenden. Auch das Gegenteil kommt vor: Eine Demo wiederholt denselben Prompt 100 Mal und zeigt große Einsparungen, aber in der Produktion verhindern mandantenspezifische Anpassungen die Wiederverwendung.

Testen Sie mit der tatsächlichen Verteilung der Anfragen.

Eine einfache Checkliste zur Cache-Eignung

Bevor ich Prompt-Caching aktiviere oder mich darauf verlasse, prüfe ich:

• Gibt es mindestens ein stabiles Präfix mit mehr als ein paar Tausend Tokens?
• Steht es vor allen dynamischen Inhalten?
• Ist die Serialisierung deterministisch?
• Ist das Präfix versioniert und mit einem Hash versehen?
• Kann ich Tokens für die Cache-Erstellung und das Lesen aus dem Cache protokollieren?
• Kenne ich die erwartete Anzahl der Wiederverwendungen innerhalb der Cache-Lebensdauer?
• Habe ich die Latenz für Cache-Hits und Cache-Misses getrennt gemessen?

Wenn Sie drei oder mehr Fragen mit „Nein“ beantworten, kann Caching trotzdem funktionieren, aber Sie verlassen sich auf Vermutungen.

Praktische Empfehlungen

Prompt-Caching ist keine magische Komprimierung. Es ist die Wiederverwendung eines stabilen Token-Präfixes. Der wirtschaftliche Vorteil entsteht dadurch, dass Sie einmal die Erstellungskosten und viele Male niedrigere Lesekosten zahlen.

Das technische Vorgehen ist unkompliziert:

• Platzieren Sie umfangreiche stabile Inhalte zuerst: Anweisungen, Tools, Dokumentation und Beispiele.
• Verschieben Sie Zeitstempel, Nutzermetadaten, Retrieval-Ergebnisse und Anfrage-IDs hinter das cachefähige Präfix.
• Erfassen Sie cache_creation gegenüber cache_read Tokens pro Route und Modell.
• Verwenden Sie eine deterministische Serialisierung für JSON-Tool-Schemas und Konfigurationen.
• Berechnen Sie den Break-even-Punkt anhand Ihrer tatsächlichen Anbieterpreise und der Verteilung Ihrer Anfragen.
• Seien Sie vorsichtig bei Routing über mehrere Modelle, mandantenspezifischen Anpassungen und kurzen Prompts.
• Messen Sie die Latenz für Cache-Hits und Cache-Misses getrennt, statt sich auf Durchschnittswerte zu verlassen.

Die beste Prompt-Cache-Optimierung, die ich gesehen habe, war überhaupt nicht raffiniert: Wir verschoben 42,000 stabile Tokens vor 12 dynamische Tokens. Das Modellverhalten änderte sich nicht. Die Rechnung schon.