LLM-Prompt-Caching: Der komplette Leitfaden 2026

Wenn Sie einen Chatbot, eine RAG-Anwendung oder einen KI-Agenten gegen ein großes Sprachmodell ausliefern, ist Prompt-Caching die einzige Optimierung, die Ihnen ohne jeden Qualitätsverlust 50–90 % der Eingabekosten und das 3–10-Fache an Time-to-First-Token zurückgibt. Es ist kein nachträglich aufgesetzter Trick — es ergibt sich direkt daraus, wie die Aufmerksamkeit (Attention) von Transformern definiert ist. Sobald Sie das verstanden haben, fügt sich der Rest des Stacks (TTLs, Anbieterunterschiede, Prompt-Struktur) sauber ein.

Diese Seite ist das Inhaltsverzeichnis einer vierteiligen Serie, die Sie von der Theorie bis zu einer produktionsreifen Entscheidungsmatrix führt. Wählen Sie Ihren Einstiegspunkt je nach dem, was Sie bereits wissen.

Wo einsteigen

Jeder Teil steht für sich, aber sie sind so geschrieben, dass das Lesen in der Reihenfolge das Bild ohne Redundanz aufbaut.

Teil 1 — Wie LLM-Prompt-Caching funktioniert

LLM-Prompt-Caching #1: Wie KV-Cache & TTL funktionieren →

Der architektonische Artikel. Er führt durch die Selbstaufmerksamkeit als eine einzige Gleichung, erklärt, warum die K- und V-Vektoren eines stabilen Präfixes mathematisch wiederverwendbar sind, und zeigt, wie der Kompromiss zwischen Speicher und Rechenleistung das TTL-Verhalten erzeugt, um das herum jeder Entwickler entwerfen muss.

Kernaussagen:

• Prompt-Caching ist keine obenauf gelegte Optimierung — es ist eine direkte Folge der kausal maskierten Attention. Das K/V an Position i ist eine deterministische Funktion der Tokens 1…i, sodass identische Präfixe bit-identische K/V ergeben.
• Was das Caching einspart, ist das Prefill (rechengebunden, O(N²)); das Decode (speicherbandbreitengebunden, O(N) pro Token) optimiert ohnehin jede Inferenz-Engine bereits.
• TTLs existieren, weil der KV-Cache enorm ist (~10 GB für einen 32K-Kontext auf einem 70B-Modell). 5 Minuten sind der Horizont des GPU-Speicherdrucks; Stunden bis Tage sind nur mit plattenbasierten Caches möglich (DeepSeeks MLA-Architektur).
• Caching gewinnt sowohl bei den Kosten (50–90 % Rabatt auf die Eingabe bei Cache-Treffern) als auch bei der Latenz (das TTFT sinkt um das 3–10-Fache bei Prompts im Bereich von 5–10K Tokens und weit mehr bei über 100K).

Teil 2 — LLM-Prompt-Caching über Anbieter hinweg vergleichen

LLM-Prompt-Caching #2: Claude, GPT, Gemini, DeepSeek vergleichen →

Der Kaufratgeber. Fünf Anbieter stellen Prompt-Caching in fünf sehr unterschiedlichen Ausprägungen bereit — explizite Marker (Claude), vollautomatisch (GPT-5, DeepSeek-v4), hybrid implizit+explizit (Gemini, Qwen) oder architektonisch plattengestützt (DeepSeeks MLA). Der Artikel bietet einen Funktion-für-Funktion-Vergleich plus ein 5-dimensionales Bewertungsraster, um sie für Ihre konkrete Last zu bewerten.

Kernaussagen:

• Vergleichen Sie nicht die Basispreise — vergleichen Sie die effektiven Kosten, gewichtet nach Ihrer Trefferrate (Formel in §4.1).
• Claude hat den tiefsten Rabatt bei einem einzelnen Aufruf (~90 %), erfordert aber explizite cache_control-Marker.
• DeepSeek-v4 ist der einzige Anbieter mit plattengestützten Caches im großen Maßstab; Teil-Präfix-Treffer erhalten Rabatte, weil die Granularität bei 64 Tokens statt 1.024 liegt.
• Geminis expliziter Cache verursacht stündliche Speichergebühren — der Break-even hängt von der Aufruffrequenz ab.
• API-Ergonomie, Vorhersagbarkeit der Trefferrate, TTL-Passung, Latenz bei Miss und Migrationskosten sind die fünf Dimensionen, die Anbieter tatsächlich unterscheiden, sobald man die Trefferrate herausrechnet.

Teil 3 — Lauffähiges Python-Tutorial

LLM-Prompt-Caching #3: Lauffähiges Python-Tutorial →

Der praktische Artikel. Ein OpenAI-SDK + ein Anthropic-SDK gegen ein einziges Gateway, mit am 2026-05-25 gemessenen Zahlen über die gesamte Claude-Familie (haiku-4-5 bis opus-4-7), GPT-5.x, Gemini 2.5, DeepSeek-v4 und Qwen3 hinweg.

Kernaussagen:

• Claude mit cache_control-Markern: gemessene 88–89 % Kostensenkung einheitlich über haiku/sonnet/opus 4-x. Verwenden Sie das Anthropic-SDK mit base_url="https://synthorai.io/".
• GPT-5.4-mini Auto-Cache: 5× TTFT-Verbesserung (3,6 s → 0,73 s bei einem 7K-Token-Prompt), 93 % Cache-Trefferrate auf den System-Tokens.
• Gemini 2.5-flash implizit: 88 % Kostensenkung bei Cache-Treffern, wenn der Streaming-Usage erfasst wird.
• DeepSeek-v4-flash: 74 % günstiger, plattengestützt (der Cache übersteht stundenlange Leerlaufzeiten).
• TTL-bewusste Muster: Keep-Alive-Heartbeat für Cron, Regeln zur Präfix-Stabilität, was pro Aufruf zu protokollieren ist.

Teil 4 — Das beste Modell je Anwendungsfall

LLM-Prompt-Caching #4: Das beste Modell für Chat, RAG & Agenten →

Der Entscheidungsartikel. Unterschiedliche Lasten betätigen die Kosten-/Latenzhebel unterschiedlich — Chat ist von Natur aus cache-freundlich, RAG kämpft mit dem Problem der Präfix-Stabilität, Agenten hängen von der Disziplin des kumulativen Präfixes ab. Der Artikel gibt eine Modellempfehlung je nach Lastform samt Kostenschätzungen.

Kernaussagen:

• Chatbots: Jedes Modell mit Auto-Cache funktioniert; Sitzungen treffen den Cache von selbst. Wählen Sie nach Kosten/Qualität. gpt-5.4-nano ist am günstigsten, gpt-5.4-mini hat das schnellste gecachte TTFT, claude-haiku-4-5 bietet die beste Befolgung von Anweisungen bei moderatem Aufpreis.
• RAG: Die Umsortierung abgerufener Dokumente zerstört Cache-Treffer in der Mitte des Prompts. Drei Korrekturen — Referenzen ans Ende verschieben, deterministische Chunk-Reihenfolge oder Claudes Mehrfach-cache_control-Haltepunkte.
• Agenten: Tool-Aufrufe und -Ergebnisse müssen nur angehängt werden (append-only) und von Schritt zu Schritt bit-identisch sein. claude-sonnet-4-5 mit 4 cache_control-Markern liefert den stärksten Rabatt auf das kumulative Präfix; gpt-5.4-mini funktioniert ohne Codeänderungen bei 50 % Ersparnis.
• TTL-Passung: 5 Min. für Chat, 1 Stunde für Agenten mit Human-in-the-Loop-Schritten, plattengestützt für sporadische Batches.

Wie man dies liest

• Ingenieur, neu im Thema: in der Reihenfolge lesen. Die Architektur in Teil 1 lässt die Teile 2–4 sofort einrasten.
• PM oder Architekt bei der Anbieterauswahl: zu Teil 2 + Teil 4 springen. Greifen Sie auf Teil 1 zurück, wenn ein Teammitglied fragt „aber warum gibt es das TTL”.
• Ingenieur mit einer konkreten Last, die heute ausgeliefert werden soll: zuerst Teil 4 (finden Sie Ihre Zeile in der Matrix), dann Teil 3 für den exakten Code.
• Jeder, der eine bestehende App optimiert: der anbieterübergreifende Benchmark in Teil 3 §6 — reproduzieren Sie ihn mit Ihrem eigenen Prompt; das ist eine Tagesaufgabe, keine mehrwöchige Migration.

Die Zahlen in dieser Serie

Alle gemessenen Zahlen wurden am 2026-05-25 gegen das Synthorai-Gateway erfasst (https://synthorai.io/v1 für OpenAI-kompatibel, https://synthorai.io/ für Anthropic-nativ), single-tenant, in einem einzigen sequenziellen Lauf, ohne gleichzeitige Last. Ihre Zahlen verschieben sich mit Region, Tageszeit und konkurrierender Tenant-Last — behandeln Sie sie als Ausgangspunkt und reproduzieren Sie sie mit Ihrem eigenen Traffic, bevor Sie sie zitieren.

Preistabellen und TTL-Verhalten spiegeln die öffentliche Anbieterdokumentation mit Stand 2026-05 wider. Anbieter aktualisieren diese alle paar Monate; die architektonische Argumentation (Teil 1) ist stabil, die Vergleichszahlen (Teile 2 & 3) driften.

← Zurück zum Blog