LLM-Prompt-Caching: Der komplette Leitfaden 2026 (50–90 % weniger Input-Kosten)

Wenn du einen Chatbot, eine RAG-Anwendung oder einen AI-Agent auf Basis eines Large Language Models betreibst, ist Prompt-Caching die wirksamste einzelne Optimierung: 50–90 % weniger Input-Kosten und eine 3–10× kürzere Time-to-First-Token, ohne Qualitätsverlust. Das ist kein nachträglich aufgesetzter Trick, sondern ergibt sich direkt aus der Funktionsweise von Transformer Attention. Wer das Prinzip verstanden hat, kann auch TTLs, Provider-Unterschiede und die Prompt-Struktur schlüssig einordnen.

TL;DR

• Prompt-Caching senkt die Input-Kosten um 50-90 % und verkürzt die Time-to-First-Token um den Faktor 3-10, ohne Qualitätsverlust.
• Messung vom 2026-05-25: Claudes cache_control-Marker reduzierten die Input-Kosten um 88-89 %; beim Auto-Cache von GPT-5.4-mini sank die TTFT von 3.6s auf 0.73s; DeepSeek-v4-flash gewährte mit einem festplattenbasierten Cache 74 % Rabatt.
• Die kurzen TTLs sind nötig, weil der KV-State enorm groß ist: bei einem Modell der 70B-Klasse ungefähr 10 GB für einen Kontext mit 32K Tokens.
• DeepSeek cached in Blöcken von 64 Tokens statt mit der üblichen Untergrenze von 1,024 Tokens. Dadurch werden auch teilweise übereinstimmende Präfixe rabattiert.

Diese Seite dient als Einstieg in eine fünfteilige Serie. Sie führt von der Theorie über eine Entscheidungsmatrix für den Produktionseinsatz bis zur Framework-Schicht, in der Prompts tatsächlich zusammengesetzt werden. Steig dort ein, wo es zu deinem Vorwissen passt.

Der passende Einstieg

Jeder Teil funktioniert für sich. In der angegebenen Reihenfolge bauen die Artikel jedoch ohne Wiederholungen aufeinander auf.

Teil 1 — So funktioniert LLM-Prompt-Caching

So funktioniert LLM-Prompt-Caching: KV-Cache und TTL erklärt →

Der Architekturartikel. Er führt Self-Attention anhand einer einzigen Gleichung her, erklärt, warum sich die K- und V-Vektoren eines stabilen Präfixes mathematisch wiederverwenden lassen, und zeigt, wie der Trade-off zwischen Speicherbedarf und Rechenaufwand zu den TTLs führt, die Entwickler bei ihrem Design berücksichtigen müssen.

Die wichtigsten Erkenntnisse:

• Prompt-Caching ist keine zusätzliche Optimierungsschicht, sondern eine direkte Folge von Attention mit kausaler Maskierung. K/V an Position i ist eine deterministische Funktion der Tokens 1…i. Identische Präfixe erzeugen daher bitweise identische K/V-Werte.
• Eingespart wird das Prefill, das Compute-bound ist und O(N²) benötigt. Das Decoding ist Memory-Bandwidth-bound, benötigt O(N) pro Token und wird bereits von jeder Inference Engine optimiert.
• TTLs sind nötig, weil der KV-Cache enorm groß ist: bei einem 32K-Kontext auf einem 70B-Modell etwa 10 GB. 5 Minuten entsprechen dem praktikablen Zeithorizont unter GPU-Speicherdruck. Stunden bis Tage sind nur mit festplattenbasierten Caches möglich, etwa durch die MLA-Architektur von DeepSeek.
• Caching reduziert sowohl die Kosten (50–90 % weniger Input-Kosten bei Cache-Treffern) als auch die Latenz. Bei Prompts mit 5–10K Tokens sinkt die TTFT um den Faktor 3–10, bei mehr als 100K Tokens noch stärker.

Teil 2 — LLM-Prompt-Caching der Provider im Vergleich

Prompt-Caching im Vergleich: Claude, GPT-5, Gemini, DeepSeek und Qwen (2026) →

Der Einkaufsleitfaden. Fünf Provider setzen Prompt-Caching auf fünf sehr unterschiedliche Arten um: mit expliziten Markern bei Claude, vollständig automatisch bei GPT-5 und DeepSeek-v4, als Hybrid aus implizitem und explizitem Caching bei Gemini und Qwen oder mit einem architekturbedingten Festplatten-Backend bei DeepSeeks MLA. Der Artikel vergleicht die Features im Detail und liefert ein Bewertungsmodell mit 5 Dimensionen, mit dem du die Provider für deinen konkreten Workload beurteilen kannst.

Die wichtigsten Erkenntnisse:

• Vergleiche nicht die Basispreise, sondern die anhand deiner Trefferquote gewichteten effektiven Kosten. Die Formel steht in §4.1. Der aktuelle LLM-Preisvergleich und der Kostenrechner liefern konkrete Werte für deinen Workload.
• Claude bietet mit rund 90 % den höchsten Rabatt pro Request, verlangt aber explizite cache_control-Marker.
• DeepSeek-v4 ist der einzige Provider mit festplattenbasierten Caches in großem Maßstab. Wegen der Granularität von 64 statt 1,024 Tokens werden auch teilweise übereinstimmende Präfixe rabattiert.
• Beim expliziten Cache von Gemini fallen stündliche Speicherkosten an. Ab wann er sich lohnt, hängt von der Aufruffrequenz ab.
• Wenn die Trefferquote als konstant angenommen wird, unterscheiden sich die Provider vor allem in fünf Dimensionen: API-Ergonomie, Vorhersagbarkeit der Trefferquote, Eignung der TTL, Latenz bei Cache-Misses und Migrationsaufwand.

Teil 3 — Python-Tutorial mit lauffähigem Code

LLM-Prompt-Caching in Python: Ein Tutorial mit lauffähigem Code →

Der Praxisartikel. Ein OpenAI SDK und ein Anthropic SDK greifen auf dasselbe Gateway zu. Enthalten sind Messwerte vom 2026-05-25 für die gesamte Claude-Familie von haiku-4-5 bis opus-4-7 sowie für GPT-5.x, Gemini 2.5, DeepSeek-v4 und Qwen3.

Die wichtigsten Erkenntnisse:

• Claude mit cache_control-Markern: Bei haiku/sonnet/opus 4-x wurde durchgängig eine Kostenreduktion von 88–89 % gemessen. Verwende das Anthropic SDK mit base_url="https://synthorai.io/".
• Auto-Cache von GPT-5.4-mini: 5× kürzere TTFT, von 3.6 s auf 0.73 s bei einem Prompt mit 7K Tokens, und eine Cache-Trefferquote von 93 % für die System-Tokens.
• Impliziter Cache von Gemini 2.5-flash: 88 % weniger Kosten bei Cache-Treffern, sofern die Usage-Daten beim Streaming erfasst werden.
• DeepSeek-v4-flash: 74 % Rabatt mit einem festplattenbasierten Cache, der auch stundenlange Leerlaufzeiten übersteht.
• TTL-bewusste Patterns: Keep-alive-Heartbeat für Cronjobs, Regeln für stabile Präfixe und die pro Request zu protokollierenden Daten.

Teil 4 — Das beste Modell für den jeweiligen Anwendungsfall

Das beste LLM für Chat, RAG und Agents: Modell- und Kostenmatrix 2026 →

Der Entscheidungsartikel. Je nach Workload wirken die Kosten- und Latenzhebel unterschiedlich. Chats sind von Natur aus Cache-freundlich, bei RAG erschweren wechselnde Präfixe das Caching, und Agents benötigen über alle Schritte hinweg konsistente kumulative Präfixe. Der Artikel empfiehlt anhand der Workload-Struktur passende Modelle und schätzt die Kosten.

Die wichtigsten Erkenntnisse:

• Chatbots: Jedes Modell mit Auto-Cache ist geeignet, da Sessions automatisch Treffer erzeugen. Entscheide nach Kosten und Qualität. gpt-5.4-nano ist am günstigsten, gpt-5.4-mini bietet die kürzeste gecachte TTFT und claude-haiku-4-5 befolgt Anweisungen gegen einen moderaten Aufpreis am besten.
• RAG: Werden abgerufene Dokumente neu sortiert, gehen Cache-Treffer in der Mitte des Prompts verloren. Drei Gegenmaßnahmen: Referenzen ans Ende verschieben, Chunks deterministisch sortieren oder mehrere cache_control-Breakpoints von Claude verwenden.
• Agents: Tool-Aufrufe und Ergebnisse müssen ausschließlich angehängt werden und von Schritt zu Schritt bytegenau identisch bleiben. claude-sonnet-4-5 bietet mit 4 cache_control-Markern den höchsten Rabatt für kumulative Präfixe. gpt-5.4-mini spart ohne Codeänderungen 50 %.
• Passende TTL: 5 min für Chats, 1 Stunde für Agents mit Human-in-the-Loop-Schritten und ein festplattenbasierter Cache für sporadische Batch-Jobs.

Teil 5 — LangChain-Integration

LangChain-Prompt-Caching: Setups mit echten Cache-Treffern →

Der Framework-Artikel. Die Teile 1–4 setzen voraus, dass du die Prompt-Bytes kontrollierst. Bei LangChain werden die Prompts vom Framework zusammengesetzt, und die bequemste Syntax deaktiviert unbemerkt Claudes Cache. Die Messungen wurden mit langchain-core 1.4.8 und einem Systempräfix mit Marker durchgeführt.

Die wichtigsten Erkenntnisse:

• Das String-Tupel-Template ("system", "...") kann kein cache_control transportieren. In den Messungen gab es bei identischen Requests keinerlei Cache-Aktivität. Verwende stattdessen eine SystemMessage mit Content-Blöcken.
• Die Prompt-Reihenfolge bestimmt die Trefferquote: Stand der abgerufene RAG-Kontext vor den statischen Regeln, löste jeder Request einen Cold Write aus. Wegen des Write-Aufpreises von Claude ist das teurer als vollständig deaktiviertes Caching.
• Ein Marker auf dem System-Block deckt auch gebundene Tools ab. bind_tools serialisiert byte-stabil, und ein Marker in einem Tool-Dictionary im Anthropic-Format wird unverändert weitergereicht.
• Agents mit mehreren Turns: Verschiebe den Marker jeweils zur neuesten Nachricht. Dadurch liest jeder Turn das gesamte bisherige Präfix erneut und schreibt nur das Delta. Gemessen wurden: read 1,864, write 15.
• Bei Modellen mit automatischem Cache wie GPT, GLM und DeepSeek bleibt eine falsche Reihenfolge unbemerkt: kein Aufpreis, kein Fehler, aber auch kein Rabatt. Überwache deshalb die Usage-Felder.

So nutzt du die Serie

• Neu im Thema: Lies die Teile der Reihe nach. Mit der Architektur aus Teil 1 werden die Zusammenhänge in den Teilen 2–4 sofort klar.
• PM oder Architekt bei der Provider-Auswahl: Spring direkt zu Teil 2 und Teil 4. Teil 1 liefert den Hintergrund, falls im Team die Frage aufkommt, warum es überhaupt TTLs gibt.
• Engineer mit einem konkreten Workload, der heute produktiv gehen soll: Beginne mit Teil 4 und suche die passende Zeile in der Matrix. Den exakten Code findest du anschließend in Teil 3.
• Bereits mit LangChain unterwegs: Geh direkt zu Teil 5. Die Raw-SDK-Patterns aus Teil 3 lassen sich übertragen, die Fallstricke bei String-Templates, der Positionierung von Variablen und den Namen der Usage-Felder sind jedoch Framework-spezifisch.
• Optimierung einer bestehenden Anwendung: Nutze den Provider-übergreifenden Benchmark aus Teil 3 §6 und wiederhole ihn mit deinem eigenen Prompt. Das dauert einen Tag und erfordert keine mehrwöchige Migration.

Messwerte in dieser Serie

Die Messwerte in den Teilen 1–4 stammen vom 2026-05-25, die LangChain-Messungen in Teil 5 vom 2026-07-04. Gemessen wurde über das Synthorai Gateway (https://synthorai.io/v1 für OpenAI-Kompatibilität, https://synthorai.io/ für die native Anthropic-API), mit einem einzelnen Tenant, in einem einzelnen sequenziellen Lauf und ohne parallele Last. Region, Tageszeit und Last durch andere Tenants beeinflussen die Ergebnisse. Nutze die Werte als Ausgangspunkt und wiederhole die Messungen mit deinem eigenen Traffic, bevor du sie zitierst.

Preistabellen und TTL-Verhalten entsprechen der öffentlich verfügbaren Dokumentation der Provider mit Stand 2026-05. Die Provider ändern diese Angaben alle paar Monate. Die architektonischen Grundlagen aus Teil 1 bleiben stabil, die Vergleichswerte aus Teil 2 und 3 verändern sich.

← Zurück zum Blog