Welcher LLM-Prompt-Cache ist am günstigsten? 5 Anbieter im Vergleich (2026)
Inhalt
- 1. Eine Taxonomie der LLM-Cache-Typen
- 1.1 Steuerung: explizit, implizit oder hybrid
- 1.2 Persistenz: im Arbeitsspeicher oder mit Disk-Backend
- 1.3 Granularität: Auflösung des Abgleichs
- 1.4 Objektmodell: Marker pro Aufruf oder benannte Cache-Objekte
- 2. Die Anbieter im Detail
- 2.1 Anthropic Claude — explizit, im Arbeitsspeicher, Granularität von 1,024 Tokens
- 2.2 OpenAI GPT-5.x — automatisch, im Arbeitsspeicher, Granularität von 1,024 Tokens
- 2.3 Google Gemini — hybrid, im Arbeitsspeicher, benannte Cache-Objekte
- 2.4 DeepSeek-v4 — automatisch, mit Disk-Backend, Granularität von 64 Tokens
- 2.5 Alibaba Qwen3 — hybrid, im Arbeitsspeicher, benannte Cache-Objekte und impliziter Cache
- 3. Direkter Vergleich
- 3.1 Rabattstruktur laut Anbieterdokumentation, 2026-05
- 3.2 TTL, Granularität und Persistenz
- 3.3 Gemessene Latenz bei einem Präfix mit 7K Tokens (2026-05-25)
- 4. Bewertungsmodell mit 5 Dimensionen
- 4.1 Effektive Kosten pro Million Tokens, gewichtet nach Hit-Rate
- 4.2 Vorhersagbarkeit der Hit-Rate
- 4.3 Zusammenspiel von TTL und Traffic-Muster
- 4.4 Latenz bei einem Cache-Miss
- 4.5 API-Ergonomie und Migrationsaufwand
- 5. Kurzempfehlungen nach Workload
- 6. Hinweise zur Migration
- 7. Was sich im Lauf der Zeit ändert
- FAQ
TL;DR — Die fünf großen LLM-Anbieter setzen Prompt-Caching sehr unterschiedlich um: mit expliziten Markern (Claude), vollständig automatisch (GPT-5.x, DeepSeek-v4), hybrid aus implizitem und explizitem Caching (Gemini, Qwen) oder architekturseitig mit persistentem Disk-Backend (DeepSeeks MLA). Dieser Artikel vergleicht die Funktionen im Detail und liefert ein Bewertungsmodell mit 5 Dimensionen, mit dem Sie die Anbieter für Ihren Workload bewerten können: Kosten, Vorhersagbarkeit der Hit-Rate, Latenz, Eignung der TTL und API-Ergonomie. Die technischen Grundlagen stehen in Teil 1: Grundlagen des Cachings. Messwerte und lauffähiger Python-Code folgen in Teil 3: Tutorial.
Serie: Teil 2 von 5 · Zuvor: Teil 1 — Grundlagen des Cachings · Als Nächstes: Teil 3 — Tutorial mit lauffähigem Code · Teil 4 — Das beste LLM nach Anwendungsfall · Teil 5 — LangChain-Integration
1. Eine Taxonomie der LLM-Cache-Typen
Bevor wir die einzelnen Anbieter betrachten, müssen vier zentrale Designachsen geklärt werden:
1.1 Steuerung: explizit, implizit oder hybrid
- Explizit — der Entwickler markiert, welche Teile des Prompts gecacht werden sollen (Anthropic Claude
cache_control). Bietet maximale Kontrolle, erfordert aber Codeänderungen. - Implizit / automatisch — der Anbieter erkennt übereinstimmende Präfixe automatisch (OpenAI GPT-5.x, DeepSeek-v4). Keine Codeänderungen nötig, ein Hit lässt sich jedoch nicht erzwingen.
- Hybrid — beide Modi stehen zur Verfügung und können pro Aufruf gewählt werden (Gemini, Qwen).
1.2 Persistenz: im Arbeitsspeicher oder mit Disk-Backend
Die Persistenz ergibt sich aus der KV-Cache-Architektur des Anbieters, nicht aus der API.
- Im Arbeitsspeicher (HBM) — die Caches liegen im GPU-Speicher, bleiben nur kurz erhalten und erfordern große Mindestblöcke von 1,024 Tokens. Das ist bei den meisten Anbietern der Standard.
- Mit Disk-Backend — die Caches werden auf SSD/NVMe persistiert. Dadurch sind deutlich längere TTLs und eine feinere Granularität möglich. DeepSeek betreibt dieses Verfahren im großen Maßstab. Grundlage ist die Multi-head Latent Attention (MLA), die den KV-Cache um etwa den Faktor 4 komprimiert (DeepSeek-AI, 2024).
1.3 Granularität: Auflösung des Abgleichs
Wie kurz darf ein Präfix sein, damit es bereits rabattiert wird?
- 64 Tokens — DeepSeek, der feinste Wert am Markt
- 128 Tokens — OpenAI, als Schrittweite für den Abgleich
- 1,024 Tokens — kleinster cachebarer Block bei Claude, OpenAI, Gemini und Qwen
Bei einer feineren Granularität zählen auch teilweise übereinstimmende Präfixe. Kleine Änderungen am Prompt wirken sich dadurch wesentlich weniger stark aus.
1.4 Objektmodell: Marker pro Aufruf oder benannte Cache-Objekte
- Marker pro Aufruf — jede Anfrage enthält den zu cachenden Inhalt. Der Anbieter bildet daraus einen Hash (Claude, OpenAI, DeepSeek, Qwen implizit).
- Benannte Cache-Objekte — der Entwickler erstellt den Cache über einen separaten API-Aufruf, erhält eine
cache_idund referenziert sie später (Gemini explizit, Qwen explizit). Das erfordert zusätzliche Schritte, bietet dafür aber direkte Kontrolle über den Lebenszyklus.
Diese vier Achsen beeinflussen sich gegenseitig. Das Angebot eines Providers lässt sich anhand seiner Position auf jeder Achse beschreiben. Der nächste Abschnitt betrachtet die Anbieter einzeln.
2. Die Anbieter im Detail
2.1 Anthropic Claude — explizit, im Arbeitsspeicher, Granularität von 1,024 Tokens
Führende Modelle (2026-05): claude-haiku-4-5, claude-sonnet-4-5 / 4-6, claude-opus-4-5 / 4-6 / 4-7.
GPT-5.6-Update (2026-06): Mit der GPT-5.6-Familie haben sich die folgenden Regeln geändert. Cache-Schreibvorgänge werden nun mit dem 1.25-Fachen des Input-Tarifs abgerechnet. Für zuverlässiges Matching ist ein
prompt_cache_keyerforderlich, außerdem gibt es neue explizite Breakpoints mit 30 Minuten TTL. Die Tabellenzeilen in diesem Artikel beschreiben das Verhalten von GPT-5.5/5.4. Details zu 5.6 stehen im Kostenleitfaden für GPT-5.6 und in unseren Messungen der Cache-Mindestgrößen.
Cache-API. Im System-Prompt oder Messages-Array können bis zu vier cache_control-Breakpoints gesetzt werden. Cache-Hits kosten etwa 10% des normalen Input-Tarifs, Schreibvorgänge 125% und damit 25% Aufschlag. Die Standard-TTL beträgt gleitende 5 Minuten und wird bei jedem Hit zurückgesetzt. Optional sind 1 Stunde möglich.
Preismodell. Anthropic veröffentlicht für jedes Modell Preise pro Million Tokens. Der Cache-Rabatt ist innerhalb der Modellfamilie einheitlich. Bei einem System-Prompt mit 8,000 Tokens und 100K Aufrufen pro Tag über claude-sonnet-4-5 sinken die Kosten pro Aufruf um etwa den Faktor 8 bis 10, sobald das Präfix im Cache liegt. Der Break-even wird bereits nach einem einzigen Hit erreicht.
TTL-Verhalten. Standardmäßig gilt eine gleitende TTL von 5 Minuten. Jeder Hit verlängert die Gültigkeit um weitere 5 Minuten. Bei der TTL von 1 Stunde verdoppeln sich die Schreibkosten. Für Workloads mit Leerlaufzeiten von mehr als 5 Minuten ist sie jedoch unverzichtbar.
Granularität. Mindestens 1,024 Tokens. Der Hash wird über die exakte Tokenfolge gebildet. Schon eine Änderung um ein Zeichen am Anfang macht das gesamte Präfix ungültig.
API-Ergonomie. Am besten. Mit mehreren Breakpoints lassen sich Abschnitte, die sich „nie ändern“, „selten ändern“ oder „pro Task ändern“, unabhängig voneinander cachen. Für Agents und RAG-Workloads, deren Prompt-Abschnitte sich in unterschiedlichen Intervallen ändern, ist das die beste Lösung am Markt.
Fallstricke.
- Ohne
cache_controlfindet überhaupt kein Caching statt. Anders als bei GPT oder DeepSeek gibt es keinen impliziten Fallback. - Beim Hashing spielt selbst innerhalb von Tool- oder Function-Arrays die Reihenfolge eine Rolle. Sortieren Sie diese daher deterministisch.
- Mit der standardmäßigen TTL von 5 Minuten eignet sich Claude ohne explizites Keep-alive schlecht für sporadische Batch-Jobs.
- Wenn Sie Claude über ein Gateway aufrufen, prüfen Sie, ob es Anthropics nativen
/v1/messages-Pfad mitcache_control-Markern unterstützt. Über den OpenAI-kompatiblen Pfad/chat/completionswerden die Marker in der Regel nicht weitergegeben. Verwenden Sie stattdessen das Anthropic SDK und setzen Sie die Base-URL des Gateways.
Am besten geeignet für. Agents mit langem Kontext, mehrstufige Chats mit stabilem System-Prompt und strukturiertes RAG mit mehreren Cache-Ebenen.
2.2 OpenAI GPT-5.x — automatisch, im Arbeitsspeicher, Granularität von 1,024 Tokens
Führende Modelle (2026-05): gpt-5.4-nano, gpt-5.4-mini, gpt-5.2, gpt-5.4-pro, gpt-5.5-pro. Codex-Varianten für Code: gpt-5.2-codex, gpt-5.3-codex.
Cache-API. Es ist keine Konfiguration nötig. Das Caching erfolgt automatisch bei jeder Anfrage mit mindestens 1,024 Tokens. Cache-Hits werden mit 50% des Input-Tarifs abgerechnet, ohne Aufschlag für Schreibvorgänge. Die Schrittweite für den Abgleich beträgt 128 Tokens.
Preismodell. OpenAI veröffentlicht die Preise pro Million Tokens. Gecachter Input ist um 50% günstiger, der Output-Preis bleibt unverändert.
Gemessen (2026-05-25, System-Prompt mit etwa 6,900 Tokens):
| Modell | Gesamtkosten bei Miss | Gesamtkosten bei Hit | Cache-Rate bei Hit | Streaming-TTFT bei Hit |
|---|---|---|---|---|
gpt-5.4-nano | $0.00131 | $0.00074 (−44%) | 5,888 / 6,887 (85%) | 1.00 s |
gpt-5.4-mini | $0.00267 | $0.00257* | 6,400 / 6,887 (93%) | 0.73 s |
* Beim Hit-Durchlauf von gpt-5.4-mini war die Completion deutlich kürzer als beim Miss-Durchlauf. Die Kostendifferenz vermischt daher den Cache-Rabatt mit der abweichenden Completion-Länge. Das 5-Fache bei der Latenzverbesserung (3.63 → 0.73 s) ist der aussagekräftigere Wert.
TTL-Verhalten. Der genaue Wert ist nicht dokumentiert. Erfahrungsberichte deuten je nach Auslastung und Popularität des Präfixes auf 5 bis 60 Minuten hin. Häufig verwendete Präfixe bleiben länger erhalten, weil LRU sie bevorzugt.
API-Ergonomie. Einfacher geht es nicht: Bestehender Code funktioniert unverändert weiter. Protokollieren Sie prompt_tokens_details.cached_tokens, um die Hit-Rate zu messen.
Fallstricke.
- Ein Hit lässt sich nicht erzwingen. Wenn Ihr Traffic hauptsächlich eindeutige Präfixe enthält, bringt der Cache nichts.
- Der Rabatt von 50% fällt geringer aus als die 90/75% bei Claude und DeepSeek und liegt ungefähr auf dem Niveau von Gemini implicit mit ~25%.
- Beim Streaming werden Cache-Hits manchmal erst im letzten Chunk gemeldet. Die Instrumentierung muss dies berücksichtigen. Setzen Sie außerdem
stream_options={"include_usage": True}.
Am besten geeignet für. Bestehende Codebasen mit GPT, bei denen der Migrationsaufwand mögliche zusätzliche Einsparungen übersteigt. Ebenso für Traffic-Spitzen mit natürlich hoher Präfixwiederholung.
2.3 Google Gemini — hybrid, im Arbeitsspeicher, benannte Cache-Objekte
Führende Modelle (2026-05): gemini-2.5-flash, gemini-2.5-pro, gemini-3-flash-preview, gemini-3.1-pro-preview, gemini-3.1-flash-lite-preview.
Cache-API. Es gibt zwei Modi:
- Implizit: automatisch wie bei GPT. Gecachte Tokens werden mit etwa 25% des Input-Tarifs abgerechnet. Es fallen weder Speicherkosten noch Einrichtungsschritte an.
- Explizit: Über einen separaten API-Aufruf wird ein
cachedContent-Objekt erstellt. Nachfolgende Anfragen referenzieren es über seinen Namen. Gecachte Tokens kosten etwa 10% und sind damit günstiger, zusätzlich fällt jedoch eine stündliche Speichergebühr pro Million Tokens an.
Preismodell. Geminis Stärke liegt bei langen Kontexten. Die Preise richten sich nach der Kontextlänge, mit unterschiedlichen Token-Tarifen unterhalb und oberhalb der Schwelle von 200K Tokens.
Gemessen (2026-05-25):
| Modell | Kosten bei Miss | Kosten bei Hit (Streaming) | Cache-Rate bei Hit |
|---|---|---|---|
gemini-2.5-flash | $0.00198 | $0.00024 (−88%) | 7,140 / 7,322 (97%) |
gemini-2.5-pro | $0.00824 | $0.00205 (−75%) | 6,120 / 7,328 (84%) |
TTL-Verhalten. Implizit: wenige Minuten, nicht veröffentlicht. Explizit: vom Entwickler festgelegt, standardmäßig 1 Stunde und maximal 24 Stunden.
API-Ergonomie. Explizite Caches erfordern zwei Schritte: erstellen und anschließend referenzieren. Sie sind selbst für den Lebenszyklus von cachedContent verantwortlich, also für Erstellung, TTL-Aktualisierung und Löschung.
Fallstricke.
- Bei expliziten Caches mit geringem Volumen frisst die Speichergebühr die Ersparnis auf. Berechnen Sie den Break-even immer anhand Ihrer Aufruffrequenz.
- Die Hit-Rate des impliziten Caches schwankt. Für Kostenmodelle sollten Sie sich nicht darauf verlassen.
- Cache-Objekte sind an eine Region gebunden. Anwendungen mit mehreren Regionen benötigen getrennte Caches.
gemini-*-proist ein Reasoning-Modell. Bei kleinen Werten fürmax_tokenswird die Completion für internes Reasoning verbraucht, sodasscompletion_tokens=0zurückkommt. Setzen Siemax_tokensin allen nutzerseitigen Pfaden auf mindestens 256.
Am besten geeignet für. Ein großes Dokument mit mehr als 20K Tokens, das mindestens zehnmal pro Stunde abgefragt wird, Video-Q&A und multimodales RAG über Unternehmens-PDFs.
2.4 DeepSeek-v4 — automatisch, mit Disk-Backend, Granularität von 64 Tokens
Führende Modelle (2026-05): deepseek-v4-flash für allgemeine Aufgaben und in dieser Generation auch für Coding-Workloads.
Cache-API. Das Caching funktioniert wie bei GPT automatisch, basiert aber auf MLA-Kompression. Dadurch ist der Cache kompakt genug, um auf Disk persistiert zu werden. Cache-Hits werden mit etwa 25% des Input-Tarifs abgerechnet. Es gibt keinen Aufschlag für Schreibvorgänge. Für einen Match reichen 64 Tokens.
Preismodell. DeepSeek veröffentlicht die Preise in Yuan. Ein Hit reduziert die Input-Kosten ungefähr um 75%.
Gemessen (2026-05-25):
| Modell | Kosten bei Miss | Kosten bei Hit | Cache-Rate bei Hit | TTFT bei Hit |
|---|---|---|---|---|
deepseek-v4-flash | $0.00091 | $0.00023 (−74%) | 6,784 / 7,101 (96%) | 2.93 s |
TTL-Verhalten. Mehrere Stunden, bei stark genutzten Präfixen mitunter länger. Durch das Disk-Backend überstehen die Caches auch Engpässe im GPU-Speicher, die bei anderen Anbietern zu einer Verdrängung aus In-Memory-Caches führen würden.
Granularität. Mit 64 Tokens bietet DeepSeek die kleinste Mindestgröße am Markt. Bei kleinen Änderungen am Prompt bleibt der größte Teil des Präfixes gültig, statt wie bei Anbietern mit 1,024 Tokens vollständig ungültig zu werden.
API-Ergonomie. Die API folgt dem OpenAI-Schema; es muss nur die Base-URL ausgetauscht werden. Der Standardwert prompt_tokens_details.cached_tokens steht zur Verfügung.
Fallstricke.
- Das Verfahren ist auf Modelle der DeepSeek-Familie beschränkt. Der Cache lässt sich nicht mit anderen Modellfamilien verwenden.
- Die Qualität bei englischen Aufgaben ist sehr hoch, liegt bei den schwierigsten Reasoning-Benchmarks aber hinter Claude und GPT-5.x.
Am besten geeignet für. Chinesischsprachige Workloads mit Fokus auf niedrige Kosten. Workloads mit häufig wiederkehrenden Präfixen, bei denen die Granularität wichtig ist, etwa RAG mit wechselnder Reihenfolge der Retrieval-Ergebnisse. Ebenso für kostenkritische Batch-Jobs.
2.5 Alibaba Qwen3 — hybrid, im Arbeitsspeicher, benannte Cache-Objekte und impliziter Cache
Führende Modelle (2026-05): qwen3-max, qwen3.5-plus, qwen3.5-flash. Vision-Varianten: qwen3-vl-plus, qwen3-vl-flash.
Cache-API. Es gibt zwei Modi:
- Implizit: immer aktiv, wie bei GPT. Der gecachte Teil wird mit etwa 20% des Input-Tarifs abgerechnet.
- Explizit: Der Cache wird per API mit einer individuellen TTL erstellt. Hits kosten etwa 10%, Schreibvorgänge 125%.
Gemessen (2026-05-25):
| Modell | Kosten bei Miss | Kosten bei Hit | Cache-Rate bei Hit | TTFT bei Hit | Hinweise |
|---|---|---|---|---|---|
qwen3-max | $0.00553 | $0.00549 | 7,040 / 7,234 (97%) | 1.53 s | Cache-Hit wurde gemeldet, das Kostenfeld des Gateways zeigte an diesem Datum jedoch keinen Rabatt. Vor dem Produktiveinsatz prüfen. |
TTL-Verhalten. Standardmäßig 5 Minuten, pro Cache-Objekt konfigurierbar. Explizite Caches verwenden ein gleitendes Zeitfenster, implizite Caches eine kurze feste TTL.
API-Ergonomie. Der implizite Modus folgt dem GPT-Schema und erfordert keine zusätzlichen Schritte. Der explizite Modus besteht aus zwei Schritten und benötigt ein Lifecycle-Management für den Cache.
Fallstricke.
- Explizites Caching wird derzeit nur von
qwen3-maxundqwen3.5-plusunterstützt. - Die Verfügbarkeit in mehreren Regionen wie Singapur und den USA wird schrittweise ausgebaut. Prüfen Sie die Region, bevor Sie sich für Daten außerhalb Chinas darauf verlassen.
- Im Vergleich zu Anthropic und OpenAI weist die Dokumentation Lücken auf. Eigene Tests sind empfehlenswert.
Am besten geeignet für. Chinesische Enterprise-Workloads, die eine genaue Cache-Steuerung benötigen, sowie Kunden, die bereits Alibaba Cloud einsetzen.
3. Direkter Vergleich
3.1 Rabattstruktur laut Anbieterdokumentation, 2026-05
| Anbieter | Aufschlag für Cache-Schreibvorgänge | Tarif für gecachten Input | Effektiver Rabatt |
|---|---|---|---|
| Anthropic Claude | +25% | 10% des Basistarifs | ~90% günstiger |
| OpenAI GPT-5.5 / 5.4 | keiner | 50% des Basistarifs | 50% günstiger |
| Google Gemini (implizit) | keiner | ~25% des Basistarifs | ~75% günstiger |
| Google Gemini (explizit) | keiner, aber stündliche Speichergebühr | ~10% des Basistarifs | ~90% günstiger, wenn amortisiert |
| DeepSeek-v4 | keiner | ~25% des Basistarifs | ~75% günstiger |
| Alibaba Qwen3 (implizit) | keiner | ~20% des Basistarifs | ~80% günstiger |
| Alibaba Qwen3 (explizit) | +25% | ~10% des Basistarifs | ~90% günstiger |
3.2 TTL, Granularität und Persistenz
| Anbieter | Standard-TTL | Maximale TTL | Persistenz | Kleinste Match-Einheit |
|---|---|---|---|---|
| Claude | 5 min, gleitend | 1 Stunde | Im Arbeitsspeicher (HBM) | 1,024 Tokens |
| GPT-5.5 / 5.4 | ~5 min | ~60 min | Im Arbeitsspeicher (HBM) | 1,024 Tokens / Schritte von 128 Tokens |
| Gemini (implizit) | Minuten | nicht veröffentlicht | Im Arbeitsspeicher | 1,024 Tokens |
| Gemini (explizit) | 1 Stunde | 24 Stunden | Im Arbeitsspeicher | 1,024 Tokens |
| DeepSeek-v4 | Stunden | mehrere Stunden oder länger | Disk (SSD) | 64 Tokens |
| Qwen3 | 5 min | konfigurierbar | Im Arbeitsspeicher | ~1,024 Tokens |
3.3 Gemessene Latenz bei einem Präfix mit 7K Tokens (2026-05-25)
| Anbieter / Modell | Gesamtdauer bei Miss | TTFT bei Hit (Streaming) | Latenzgewinn |
|---|---|---|---|
claude-haiku-4-5 † | ~3.0 s | 1.31 s | ~2× |
claude-sonnet-4-5 † | ~2.0 s | 1.76 s | ~1.2× |
claude-opus-4-5 † | ~2.2 s | 2.08 s | ~1.05× |
gpt-5.4-mini | ~3.6 s | 0.73 s | ~5× |
gpt-5.4-nano | ~2.2 s | 1.00 s | ~2× |
gemini-2.5-flash | ~2.5 s | ~1.4 s | ~1.8× |
gemini-2.5-pro | ~3.0 s | ~1.8 s | ~1.7× |
deepseek-v4-flash | ~4.0 s | 2.93 s | ~1.4× |
qwen3-max | ~4.8 s | 1.53 s | ~3× |
† Die Claude-Werte wurden mit cache_control-Markern über den nativen Anthropic-Endpunkt /v1/messages gemessen, siehe Teil 3 §2. Claudes größter Vorteil liegt bei den Kosten: etwa 88–89% weniger für Input. Die vollständige Kostentabelle steht in Teil 3 §2. Nach den veröffentlichten Zahlen von Anthropic fällt die TTFT-Verbesserung bei Prompts mit mehr als 100K Tokens wesentlich deutlicher aus.
Gemessen wurde ein einzelner sequenzieller Durchlauf ohne parallele Last. Die Werte variieren je nach Region, Tageszeit und Auslastung durch andere Mandanten.
4. Bewertungsmodell mit 5 Dimensionen
Aussagen wie „Claude spart 90%“ sind interessant, helfen bei der Auswahl aber selten weiter. Bewerten Sie jeden Anbieter für Ihren Workload anhand der folgenden fünf Dimensionen und gewichten Sie diese nach Ihren Anforderungen.
4.1 Effektive Kosten pro Million Tokens, gewichtet nach Hit-Rate
Vergleichen Sie nicht die Basispreise, sondern die erwarteten Kosten bei Ihrer tatsächlichen Hit-Rate. Setzen Sie Ihre eigenen Werte in den LLM-Kostenrechner ein oder vergleichen Sie die aktuellen LLM-Preise verschiedener Anbieter:
effective_cost = base × (1 - hit_rate × (1 - discount)) + write_premium × write_rate
Beispielrechnung bei 70% Präfixwiederholung, typisch für einen Chatbot:
- Claude: ~90% Rabatt × 0.7 Hits + 25% Schreibaufschlag × 0.3 → effektiv ≈ Basistarif × 0.45
- GPT-5.5: ~50% × 0.7 + 0 → effektiv ≈ Basistarif × 0.65
- Gemini implizit: ~75% × 0.7 + 0 → effektiv ≈ Basistarif × 0.48
- DeepSeek-v4: ~75% × 0.7 + 0 → effektiv ≈ Basistarif × 0.48
Multiplizieren Sie das Ergebnis mit dem tatsächlichen Basistarif des jeweiligen Anbieters, um vergleichbare Dollarbeträge zu erhalten. Bewertung: Berechnen Sie effective_cost für Ihren Workload. Je niedriger, desto besser.
4.2 Vorhersagbarkeit der Hit-Rate
- Explizite Caches (Claude, Qwen explizit, Gemini explizit) — gut vorhersagbar. Wenn der Bereich markiert wurde, gibt es innerhalb der TTL einen Hit.
- Automatische Caches (GPT-5.x, DeepSeek-v4, Gemini implizit, Qwen implizit) — abhängig von der Ähnlichkeit des Präfixes und der Auslastung beim Anbieter, etwa durch LRU-Verdrängung.
Wenn Kosten an SLAs gekoppelt sind, sollten Sie explizites Caching bevorzugen. Für Optimierungen nach dem Best-Effort-Prinzip reicht automatisches Caching aus.
4.3 Zusammenspiel von TTL und Traffic-Muster
| Traffic-Muster | Anforderung |
|---|---|
| Kontinuierlich, Sekunden zwischen Aufrufen | Die Standardwerte aller Anbieter reichen aus |
| Sitzungsgebunden, Minuten zwischen Aufrufen | TTL von 5–60 min (Claude, GPT-5.x, Qwen) |
| Schubweise, Stunden zwischen Lastspitzen | TTL ab 1 Stunde (Claude 1h, Gemini explizit, DeepSeek-v4) |
| Sporadisch, wenige Anfragen pro Tag | TTL von 24 Stunden (Gemini explizit) oder Cold Writes akzeptieren |
4.4 Latenz bei einem Cache-Miss
Ein Anbieter mit schnellen Hits, aber langsamen Misses bleibt problematisch, wenn Ihre Hit-Rate nicht hoch ist. Vergleichen Sie beide Werte aus §3.3 und gewichten Sie sie mit der erwarteten Hit-Rate.
4.5 API-Ergonomie und Migrationsaufwand
- Geringster Migrationsaufwand: GPT-5.x ↔ DeepSeek-v4. Beide verwenden OpenAI-kompatible APIs und automatisches Caching.
- Mittel: GPT-5.x → Gemini implizit. Anderes SDK, aber der Cache-Code muss nicht angepasst werden.
- Hoch: GPT-5.x → Claude.
cache_controlmuss ergänzt und der Prompt in Ebenen strukturiert werden. - Am höchsten: Migration von einem Anbieter auf mehrere ohne Gateway. Dann müssen mehrere Cache-APIs unterstützt werden.
5. Kurzempfehlungen nach Workload
| Workload | Empfehlung | Begründung |
|---|---|---|
| Englischer Chat, globale Nutzer | claude-haiku-4-5 oder gpt-5.4-nano | Hoher Cache-Rabatt und kleines, schnelles Modell |
| Chinesischer Chat, Festlandchina | deepseek-v4-flash oder qwen3.5-flash | Cache über mehrere Stunden und niedrige Kosten für chinesische Inhalte |
| Englisches RAG mit hohen Qualitätsanforderungen | claude-sonnet-4-5 + mehrere Breakpoints | Prompt-Strukturen mit mehreren Ebenen lassen sich effizient cachen |
| Chinesisches RAG mit Kostenfokus | deepseek-v4-flash | Die Granularität von 64 Tokens verkraftet eine geänderte Reihenfolge der Retrieval-Ergebnisse |
| Q&A über lange Dokumente, sporadische Nutzung | gemini-2.5-pro explizit | TTL von 24 Stunden, für diesen Anwendungsfall ausgelegt |
| Bestehende GPT-Codebasis, keine Anpassungen | gpt-5.4-mini wie bisher | ~50% Ersparnis ohne Zusatzaufwand |
| Komplexe Agents mit mindestens 15 Schritten | claude-sonnet-4-5 + cache_control mit 4 Breakpoints | Mindestens 85% Hit-Rate bei Agent-Traffic |
| Portabilität zwischen mehreren Anbietern | Gateway, beliebiges Modell | Ein SDK, ein Auth-Header |
6. Hinweise zur Migration
Wenn Ihre Bewertung für einen Wechsel spricht, müssen Sie drei Punkte einplanen:
Datenübertragung. Gecachte Präfixe lassen sich nicht zwischen Anbietern übertragen. Jeder Wechsel beginnt mit einem leeren Cache. Planen Sie während der Aufwärmphase mehrere Stunden mit höheren Kosten als üblich ein.
Umbau der Prompt-Struktur. Anthropics Design mit mehreren Breakpoints fördert eine mehrstufige Prompt-Struktur, die auch für andere Anbieter besser geeignet ist. Eine einmalige Umstrukturierung verbessert daher auch die Pfade außerhalb von Claude.
Hedging über ein Gateway. Wenn die Entscheidung noch offen ist, können Sie über ein Token Gateway routen. Damit bleiben Sie flexibel und binden sich nicht an einen einzelnen Anbieter. Dafür kommt ein zusätzlicher Hop hinzu. Je nach Gateway verlieren Sie möglicherweise auch den Zugriff auf anbieterspezifische Cache-Steuerungen. Teil 3 §9 zeigt, was das Synthorai Gateway tatsächlich leistet und bei welchen Versprechen Skepsis angebracht ist.
7. Was sich im Lauf der Zeit ändert
Die Zahlen in diesem Artikel werden sich ändern. Caching ist zu einem wichtigen Faktor im Preiswettbewerb geworden, und die Anbieter aktualisieren ihre Angebote alle paar Monate. Zwei Entwicklungen sollten Sie beobachten:
- Längere TTLs. Anthropics Option mit 1 Stunde ist allgemein verfügbar. Gemini könnte auf mehrere Tage erweitern. Die TTL wird dadurch voraussichtlich seltener zum Problem.
- Feinere Granularität. OpenAI und Anthropic dürften ihre Mindestgröße von 1,024 Tokens irgendwann senken. DeepSeek hat mit 64 Tokens einen neuen Maßstab gesetzt.
Wenn sich die Rabatte angleichen, entscheiden API-Ergonomie und Latenz statt der maximalen Ersparnis.
Als Nächstes: Teil 3 — Tutorial zum Prompt-Caching mit lauffähigem Python-Code setzt die oben beschriebene Architektur in ausführbaren Code um. Die Latenztabelle aus §3.3 lässt sich dort als Benchmark selbst reproduzieren.
FAQ
Welcher LLM-Anbieter bietet unter dem Strich das günstigste Prompt-Caching?
Bei gleicher Hit-Rate von etwa 75% waren in unseren Messungen von 2026-05 deepseek-v4-flash für chinesische Workloads und der implizite Cache von gemini-2.5-flash für englische Workloads pro effektiver Million Tokens am günstigsten. claude-sonnet-4-5 bietet mit etwa 90% den höchsten Rabatt pro Aufruf, hat aber einen höheren Basispreis. Ab einer Hit-Rate von mehr als 85% liegt Claude vorn. Setzen Sie Ihre eigene Hit-Rate in die Formel aus §4.1 ein.
Warum kostet Gemini bei Workloads mit geringem Volumen mehr? Die stündliche Speichergebühr für explizite Caches hebt den Rabatt auf, wenn der Cache nicht häufig genug abgefragt wird. Verwenden Sie bei geringem Volumen den impliziten Cache von Gemini. Dafür fällt keine Speichergebühr an, der Rabatt beträgt etwa 25%.
Kann ich Claudes cache_control mit OpenAI verwenden?
Nicht direkt. Es handelt sich um getrennte Cache-Implementierungen. Beim OpenAI-kompatiblen Endpunkt /chat/completions hat das Feld für Modelle außerhalb von Anthropic normalerweise keine Wirkung. Diese Modelle cachen ohnehin automatisch. Verwenden Sie für Claude den nativen Anthropic-Endpunkt /v1/messages mit den entsprechenden Markern.
Ist DeepSeeks MLA-Architektur proprietär? Das Paper von DeepSeek-AI aus dem Jahr 2024 ist öffentlich. Andere Anbieter könnten eine KV-Kompression nach dem MLA-Prinzip übernehmen, müssten dafür aber das Basismodell neu trainieren. Die Funktion lässt sich nicht zur Laufzeit zuschalten. Stand 2026-05 ist DeepSeek der einzige große Anbieter, der diese Architektur produktiv einsetzt.
Wie sieht es mit selbst gehosteten Open-Source-Modellen aus? vLLM, SGLang und andere Inference-Engines unterstützen Prefix-Caching nativ. Grundlage ist das PagedAttention-Paper. Beim Self-Hosting auf H100s/H200s können Sie mit LMCache oder vergleichbaren Lösungen ein Disk-Backend für den Cache umsetzen. Die Kostenanalyse in diesem Artikel gilt nur für Managed Services. Beim Self-Hosting sieht die Wirtschaftlichkeit völlig anders aus. Wenn Sie Routing über mehrere Anbieter benötigen, den Router aber nicht selbst betreiben möchten, bietet eine gemanagte LiteLLM-Alternative eine einheitliche API für dieselben Anbieter und erhält deren Caching-Funktionen. Welche Open-Weight-Modelle wo cachen und welche Hosts daraus ein fertiges Produkt machen, zeigt der Artikel Prompt-Caching für Open-Weight-LLMs.
Warum fehlen Mistral, Cohere und Anbieter von Llama-APIs in diesem Vergleich? Ihre Cache-Angebote waren Stand 2026-05 noch weniger ausgereift. Mistrals Caching befindet sich im Early Access, Cohere bietet kein explizites Caching an, und die Unterstützung bei Llama-API-Anbietern wie Groq, Together und Replicate unterscheidet sich stark. Der Vergleich sollte aktualisiert werden, sobald sich deren Funktionsumfang stabilisiert hat.
Quellen: Prompt-Caching bei Anthropic · Prompt-Caching bei OpenAI · Context-Caching bei Google Gemini · KV-Cache bei DeepSeek · Context-Cache bei Alibaba Bailian · DeepSeek-V2- / MLA-Paper · PagedAttention / vLLM (Kwon et al. 2023). Die Messwerte stammen vom 2026-05-25 und wurden über https://synthorai.io/v1 erhoben.