Prompt-Caching bei Open-Weight-LLMs: Warum der Provider über Treffer entscheidet

Bei einem Closed Model ist Prompt-Caching ein klar dokumentierter Vertrag. Claude bietet Breakpoints über cache_control; OpenAI und Gemini cachen ab einer bestimmten Token-Zahl automatisch. Die Rabatte sind veröffentlicht und stabil. Eine Seite Dokumentation genügt.

Open Weights setzen diese Annahme außer Kraft. Derselbe Qwen- oder Llama-Checkpoint läuft bei einem Dutzend Hosts, und Caching ist keine Eigenschaft des Modells, sondern des Ausführungsorts. Wie groß die Unterschiede sind, zeigt eine Messung: Wir haben einen identischen Prompt mit ~4.7K Token sechsmal über einen Multi-Provider-Router an dasselbe Qwen-Modell gesendet, ohne einen Upstream festzulegen.

Dasselbe Modell, derselbe Router, derselbe Prompt: Die Kosten lagen zwischen $0.0141 und $0.000286, eine Spanne von 49×. Entscheidend waren allein der gewählte Upstream und die Frage, ob der Prefix dort bereits warm war.

Zusammenfassung

• Prompt-Caching für Open-Weight-Modelle ist das Ergebnis des Routings, keine Modellfunktion. Implementiert wird es kostenlos und automatisch in der Inference Engine. Jede darüberliegende Schicht kann es erhalten oder zunichtemachen.
• Fünf Schichten: Eine stellt Caching bereit, drei können es verhindern. Das Modell (bestimmt die Cache-Eignung, stellt aber keinen Cache bereit) → die Inference Engine (Caching, kostenlos) → der Compute Host (macht daraus ein Produkt, mit großen Unterschieden) → das Gateway (Routing über mehrere Cluster) → der Router (verteilt auf Anbieter mit getrennten Caches).
• Gemessen. Eine identische, vom Router verteilte Anfrage kostete bei einem Upstream 49× mehr als bei einem anderen. Bei einem Modell gewährte ein Host 59.6% Rabatt, ein anderer 0%. Veröffentlichte Cache-Rabatte reichen je nach Modell von 0% bis ~98%.
• Was zu tun ist. Route festlegen, damit wiederkehrende Prefixes denselben warmen Cache treffen. Nicht anhand von cached_tokens prüfen, sondern anhand der Kostenänderung, denn das Feld zeigt bei echten Treffern oft 0. Latenz separat bewerten: Warme Prefills sind selbst bei ~0% Kostenrabatt 2–10× schneller.

Die Live-Werte wurden am 2026-06-14 mit einem Multi-Provider-Router und unserem eigenen Gateway gemessen. Verwendet wurden ein fester englischer Prompt mit ~4.7K Token, ein kleines max_tokens und sequenzielle Aufrufe. Die dokumentierten Preise wurden am selben Tag anhand der Primärquellen der Provider geprüft und gezielt gegengeprüft. Übertragbar sind vor allem die Verhältnisse wie prozentualer Rabatt und Latenzänderung. Die absoluten Kosten hängen von Plattform, Prompt und Auslastung ab. Vor dem Zitieren selbst reproduzieren.

Welche Cache-Typen in der Praxis vorkommen

Vor dem Stack zunächst die Begriffe. Bei Open-Weight-Hosts begegnen einem vier unterschiedliche Cache-Varianten mit jeweils eigener Abrechnung.

1. Automatisches Prefix-Caching ohne Marker. Das ist die häufigste Variante. Der Server bildet einen Hash über den Prompt-Prefix, verwendet bei Übereinstimmung den KV-Zustand einer früheren Anfrage wieder und wendet den Rabatt selbstständig an. cache_control oder Codeänderungen sind nicht nötig; oft lässt sich das Verhalten nicht einmal deaktivieren. DeepSeek, Zhipu GLM und die meisten Open-Weight-Hosts arbeiten so. Schreibvorgänge sind kostenlos. Der Cache bleibt je nach Implementierung einige Minuten im VRAM oder mehrere Stunden bis Tage auf Disk bestehen. DeepSeek speichert Prefixes nach eigenen Angaben „einige Stunden bis einige Tage“.

2. Explizites Breakpoint-Caching (cache_control). Diese von Anthropic bekannte Variante bieten auch einige Open-Weight-Hosts an. Alibaba Model Studio akzeptiert "cache_control": {"type": "ephemeral"} in einem Qwen-Message-Block; einige Serving-Plattformen bieten einen entsprechenden Marker. Man markiert die Grenze, zahlt einen Aufschlag für das Schreiben und erhält dafür einen höheren Rabatt beim Lesen.

3. Gemietete Cache-Objekte mit Speichergebühr. Hier ist Vorsicht geboten. Bei Moonshots älterer moonshot-v1-Familie wird zunächst mit POST /v1/caching ein Cache angelegt. Danach fallen eine Schreibgebühr, eine Speichergebühr pro Token und Minute sowie eine Treffergebühr pro Aufruf an. Googles explizites Gemini-Caching folgt demselben Prinzip: Eingabekosten plus Speichergebühr von ungefähr $1.00–$4.50 pro 1M-tokens und Stunde. Der Cache ist eine gemietete Ressource, die aktiv gelöscht werden muss.

4. KV-Wiederverwendung beim Self-Hosting, kostenlos. Wer die Weights selbst betreibt, erhält automatisches, kostenloses Caching durch die Inference Engine. Es gibt weder Schreib- oder Lesekosten noch eine Speichermiete. Ein Treffer überspringt einfach den Prefill.

Qwen bietet in Model Studio beide Varianten an, mit einem klaren Trade-off: Im impliziten Modus kostet ein Treffer 20% der Eingabekosten, Schreibvorgänge sind kostenlos. Im expliziten Modus kostet ein Treffer 10% der Eingabekosten, dafür fallen beim Schreiben 125% an und der Eintrag hat eine TTL von 5 Minuten. Der Rabatt ist größer, aber das Befüllen kostet und nach jedem Ablauf erneut.

Wo Caching im Stack stattfindet

Der entscheidende Punkt: Prompt-Caching für Open Weights ist auf genau einer Schicht gelöst und auf jeder darüberliegenden Schicht gefährdet. Geht man den Stack von den Weights nach oben durch, sind bei jeder Schicht zwei Fragen relevant: Stellt sie Caching selbst bereit oder leitet sie es nur weiter? Und kann sie das Ergebnis der darunterliegenden Schicht zunichtemachen?

  request
     |
     v
  +--------------------------------------------------+
  | L5  router             scatters across vendors   |  can break it
  | L4  gateway            multi-cluster routing     |  can break it
  | L3  compute host       uneven delivery           |  can break it
  |==================================================|
  | L2  inference engine   CACHING LIVES HERE, free  |  <-- the cache is born here
  |==================================================|
  | L1  model              cacheability: MLA / GQA   |  sets the ceiling
  +--------------------------------------------------+

  A cache hit is born at L2 and must survive L3-L5 routing to reach you;
  every layer above L2 is a chance to land where your prefix isn't.

Schicht 1 — Das Modell: Cache-Eignung, kein Cache

Viele vermuten Caching genau auf dieser Ebene und sagen etwa: „DeepSeek hat Caching.“ Deshalb ist eine klare Abgrenzung nötig. Ein Checkpoint besteht aus Weights und führt dieselbe Attention aus, unabhängig davon, ob ein KV-Cache existiert. Er bringt weder Cache noch Rabatt, TTL oder cache_control-Marker mit. Das sind Funktionen des Serving-Stacks. Streng genommen stellen die Weights also kein Cache-Produkt bereit.

Neutral sind die Weights trotzdem nicht. DeepSeek zeigt besonders gut, warum: Die Attention-Architektur des Modells bestimmt die Größe des KV-Caches und damit, wie günstig Caching überhaupt werden kann:

• DeepSeeks Multi-head Latent Attention (MLA) komprimiert den KV-Cache in eine latente Darstellung mit niedrigem Rang, auf etwa 4–14% eines üblichen Multi-Head-Caches. Genau diese Kompression ermöglicht es der DeepSeek-API, Prefixes auf Disk zu speichern und Cache-Lesevorgänge mit ~2% der Eingabekosten abzurechnen. Die Architektur schafft die Voraussetzung; der Disk-Cache ist ein darauf aufbauendes Produkt.
• Grouped-Query Attention (GQA) kommt bei Llama, Qwen, Mistral und DeepSeek zum Einsatz. Gemeinsame KV-Heads verkleinern den Cache um den Gruppenfaktor, bei Llama-3 um ≈8×.

Der Beitrag von Schicht 1 ist also Cache-Eignung, nicht der Cache selbst. Die Architektur setzt die Untergrenze dafür, wie günstig die darüberliegenden Schichten Caching anbieten können. Die Weights selbst liefern jedoch nie ein gecachtes Token aus. Die Aussage „DeepSeek hat Caching“ vermischt zwei Dinge mit demselben Namen: die Weights auf dieser Schicht, die MLA mitbringen, und DeepSeeks API samt Serving-Stack auf den Schichten 2–3, die Disk-Cache, Rabatt und Usage-Felder bereitstellen. Wer die offenen Weights herunterlädt und selbst betreibt, behält den durch MLA verkleinerten KV-Cache. Das Disk-Cache-Produkt bleibt jedoch auf DeepSeeks Servern. An seine Stelle tritt die selbst gewählte Schicht 2. Operativ bleibt die Konsequenz dieselbe: Nicht fragen, ob ein Modell cached, sondern wo es bereitgestellt wird. Die Architektur ist trotzdem relevant. Sie setzt die Grenze; der Request-Pfad entscheidet über das tatsächliche Ergebnis.

Schicht 2 — Die Inference Engine: Hier wird Caching implementiert, kostenlos

Eine Schicht darüber ist Caching nicht nur vorhanden, sondern bereits gelöst und kostenlos. Moderne Inference Engines cachen Prefixes automatisch:

• vLLM — Automatic Prefix Caching: Bildet für jeden KV-Block einen Hash, verwendet jeden bereits bekannten Block mit passendem Prefix-Hash wieder und entfernt Einträge per LRU. In V1 standardmäßig aktiviert.
• SGLang — RadixAttention: Speichert den KV-Cache in einem Radix-Tree, sodass jeder gemeinsame Prefix wiederverwendet werden kann, inklusive cachebewusstem Scheduling.
• TensorRT-LLM — Wiederverwendung von Blöcken über enable_block_reuse, standardmäßig aktiviert. KV-Blöcke können optional in den Host-Speicher ausgelagert werden.

Projekte wie LMCache gehen noch weiter. Sie lagern KV-Daten auf CPU oder Disk aus und teilen sie zwischen Instanzen. Das ist ein erster Ansatz zur Lösung des Routing-Problems, das auf den nächsten Schichten entsteht. Beim Self-Hosting ist das Thema damit erledigt: Caching läuft automatisch, verursacht abgesehen von den ohnehin betriebenen GPUs keine Kosten, entfernt Einträge per LRU und gehört vollständig dem Betreiber. Ein Treffer überspringt den Prefill, senkt die TTFT und erhöht den Durchsatz. Ein Abrechnungsfeld für cached_tokens gibt es nicht, weil nichts abgerechnet wird. Der Nutzen zeigt sich in den eigenen Latenzmetriken. Bei einem Closed Model mietet man Caching; bei einem offenen Modell kann man es vollständig selbst betreiben. Dafür ist der Cache flüchtig: Er liegt im VRAM und wird per LRU verdrängt. Er bleibt nur erhalten, solange der Prefix häufig genug verwendet wird. Genau das müssen die darüberliegenden Schichten sicherstellen.

Schicht 3 — Der Compute Host: Uneinheitlich als Produkt verpackt

Kommerzielle Inference Hosts kapseln Schicht 2 und betreiben Flotten aus Replikas. Das kostenlose automatische Caching übernehmen sie von der Engine. Entscheidend ist, wie gut sie es umsetzen. Dabei gibt es in zwei Punkten große Unterschiede.

Erstens unterscheiden sich Sichtbarkeit und Preis erheblich. Bei den großen Open-Weight-Hosts findet man unter anderem folgende Modelle: Ein Anbieter berechnet für gecachte Eingaben pauschal 50% und nimmt gecachte Token von Rate Limits aus. Ein anderer gewährt bei Serverless standardmäßig 50% Rabatt. Ein dritter legt den Preis pro Modell fest, etwa ~80% Rabatt für eine Qwen-Stufe, und bietet einen Cache-Key-Hinweis für bessere Affinity. Ein vierter aktiviert Caching auf dedizierten Endpoints dauerhaft, ohne es offenzulegen. Dieselbe zugrunde liegende Engine, vier unterschiedliche Preisstrategien.

Zweitens tritt hier erstmals ein Problem auf, das Caching tatsächlich verhindert: mehrere Replikas. Der warme Prefix liegt im VRAM genau der Replica, die den kalten Request verarbeitet hat. Der Load Balancer des Hosts kann die nächste Anfrage an eine andere Replica mit leerem Cache senden. Genau das zeigte unser Test. Wir haben dasselbe Qwen-Modell jeweils an einen einzelnen Upstream gebunden und einen Cold→Warm-Ablauf ausgeführt:

Provider A hat sauber gecacht und den Treffer gemeldet. Provider B wirbt für dieses Modell mit einem Cache-Read-Preis, gewährte in unserem Test aber weder beim ersten kalten noch bei zwei warmen Aufrufen einen Rabatt. Ob der Grund in den Voraussetzungen, der Verteilung auf mehrere Replikas oder einer längeren Aufwärmphase als zwei Requests lag, ließ sich nicht feststellen. Auf diesem Request-Pfad betrug der gemessene Rabatt null. Die technische Fähigkeit ist auf Schicht 2 gelöst. Ob sie tatsächlich beim Nutzer ankommt, hängt von der Implementierung auf Schicht 3 ab und unterscheidet sich je nach Host.

Schicht 4 — Das Gateway: Das Multi-Cluster-Problem

Ein Gateway steht vor einem oder mehreren Upstreams und macht aus dem Replica-Problem ein Cluster-Problem. Verteilt es Requests ohne Cache Affinity per Round-Robin auf Cluster oder Provider, ist der warme Cache strukturell nicht mehr erreichbar: Jede Anfrage landet dort, wo der Prefix fehlt. Ein cachebewusstes Gateway muss nach Prefix-Hash routen, damit identische Prefixes demselben Upstream zugeordnet bleiben. Schicht 2 ordnet sie nach demselben Prinzip denselben KV-Blöcken zu. Das gilt sowohl für selbst betriebene Software wie LiteLLM als auch für gehostete Services. Die betrieblichen Abwägungen beschreibt LiteLLM im Vergleich zu einem Managed Gateway.

Wir haben auf einem Drittanbieter-Gateway Cold→Warm-Tests mit mehreren Open-Weight-Modellen durchgeführt und die Kosten direkt aus dem cost-Feld jedes Requests ausgelesen:

DeepSeek-V4 erreichte 97–99%, die Affinity funktionierte also durchgängig. qwen3.5-plus und qwen3-max lieferten beim warmen Aufruf dagegen ~0%, obwohl der Katalog einen Cache-Read-Preis auswies. Die Tabelle zeigt noch zwei weitere wichtige Eigenschaften von Gateways:

• Das Usage-Feld ist unzuverlässig, die Kosten sind es nicht. cached_tokens zeigte hier bei jedem Aufruf 0, auch bei Kostenrückgängen von 99%. Viele OpenAI-kompatible Gateways befüllen das Feld für automatisch cachende Upstreams nicht. Deshalb einen kalten und einen warmen Aufruf über die cost-Differenz vergleichen, nicht anhand des Token-Felds. Dasselbe gilt beim Prüfen der Cache-Versprechen eines Gateways.
• Die Latenz sinkt auch ohne Kostenrabatt. Jeder warme Aufruf war 2–10× schneller. Bei qwen3.5-flash fiel die Latenz von 10.2s auf 1.0s. Das galt auch für Modelle mit ~0% Rabatt. Ein Treffer überspringt den Prefill, unabhängig von der Preisgestaltung des Hosts. Caching kann die TTFT daher selbst dann verbessern, wenn sich die Rechnung nicht ändert.

Ein Gateway ohne Affinity stellt einen Cache bereit, den man nicht zuverlässig erreicht. Meldet es die Cache-Kosten nicht, lässt sich der Treffer nicht verifizieren.

Schicht 5 — Der Router: Zufällige Verteilung über Provider

Ganz oben verteilt ein Multi-Provider-Router eine Modell-ID per Load Balancing auf die Cluster verschiedener Unternehmen. Jeder Anbieter hat einen eigenen Cache. Selbst perfekte Affinity innerhalb eines Providers hilft nicht mehr, wenn Aufruf 1 zu einem Anbieter und Aufruf 2 zu einem anderen geht. Einen gemeinsam nutzbaren Cache gibt es nicht. Genau diese Streuung führte zur Messung am Anfang des Artikels. Sie verschärft das Problem von Schicht 4: Es gibt nicht nur mehrere Cluster, sondern mehrere Anbieter mit getrennten Cache-Zuständen und unterschiedlichen Preisen. Der teuerste gewählte Upstream berechnete das 20-Fache des Basistarifs des günstigsten. Der Cache griff erst, als das Routing zufällig bei einem Provider blieb.

Die Lösung besteht darin, den Zufall aus dem Routing zu entfernen. Wiederkehrende Prefixes müssen deterministisch im selben warmen Cache landen:

# Pin the upstream; otherwise load-balancing scatters you across disjoint caches.
# (field names follow a common multi-provider router's API)
import requests

requests.post(f"{ROUTER_BASE}/chat/completions",
  headers={"Authorization": f"Bearer {API_KEY}"},
  json={
    "model": "qwen/qwen3.5-35b-a3b",
    "messages": messages,
    "usage": {"include": True},              # return cost + cached_tokens
    "provider": {                            # the part that makes caching work
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

Der Router meldete sowohl cached_tokens als auch die Kosten pro Request. Beim Treffer waren es 4,224 Token. Damit ließen sich beide Werte prüfen, was besser ist als beim Gateway auf Schicht 4, das 0 meldete. Das Routing muss jedoch selbst eingeschränkt werden. Caching ist ein Routing-Problem, das wie ein Preisfeature aussieht: Auf Schicht 2 ist der Cache kostenlos. Die Schichten 3, 4 und 5 bieten drei zunehmend problematische Möglichkeiten, Requests am eigenen Cache vorbeizurouten.

Wie hoch ist der Rabatt? Das Spektrum ist enorm

Wenn das Routing stimmt, stellt sich die Frage nach der tatsächlichen Ersparnis. Bei Closed Models liegen die Rabatte für Cache Reads meist um 90%. Bei Open Weights reichen die veröffentlichten Preise von einem kaum messbaren Nachlass bis fast 100%, selbst innerhalb des Portfolios eines einzelnen Anbieters. Veröffentlichte First-Party-Preise:

DeepSeeks automatischer Disk-Cache bietet den größten Rabatt: deepseek-v4-flash berechnet für gecachte Eingaben $0.0028/M statt $0.14/M bei einem Miss, also ein Verhältnis von 1:50. Unser Test auf Schicht 4 bestätigte das mit 97.9%. Drittanbieter-Hosts derselben Open Weights legen ihre Preise für gecachte Eingaben unabhängig fest. Einige gewähren pauschal ~50%, andere je nach Modell zwischen ~50% und ~90%. Der tatsächliche Rabatt hängt daher vom Host ab, nicht nur vom Modell. Derselbe Funktionsname, 48 Prozentpunkte Unterschied.

Da der Rabatt von der Plattform abhängt, hat dasselbe Modell überall andere Cache-Konditionen. Vier Varianten für deepseek-v4-pro:

„DeepSeek-V4-Pro unterstützt Caching“ ist korrekt, operativ aber fast wertlos. Die relevante Frage lautet: „Wo wird Caching unterstützt, zu welchem Preis und wie wird es ausgewiesen?“

Checkliste für die Entscheidung

• ✅ Das Modell setzt die Grenze, stellt aber nicht den Cache bereit (Schicht 1). Seine Attention-Architektur wie MLA oder GQA bestimmt, wie günstig Caching werden kann. Ein gecachtes Token liefert das Modell selbst nicht aus. Deshalb immer prüfen, wo es bereitgestellt wird und wie der Stack des Hosts arbeitet.
• ✅ Beim Self-Hosting ist Caching bereits kostenlos vorhanden (Schicht 2). Prüfen, ob automatisches Prefix-Caching aktiviert ist. Bei vLLM und SGLang ist das standardmäßig der Fall. Außerdem die Prefix-Hit-Rate überwachen.
• ✅ Bei einem Compute Host die tatsächliche Auslieferung prüfen, nicht die Preistabelle (Schicht 3). Ein Cache-Read-Preis ist zunächst nur eine Behauptung. Entscheidend ist der gemessene Kostenunterschied zwischen Cold und Warm. Falls der Host einen Cache-Key-Hinweis für Affinity anbietet, sollte er verwendet werden.
• ✅ Bei einem Gateway Cache-Affinity-Routing und Kostenangaben verlangen (Schicht 4). Bleiben identische Prefixes nicht beim selben Upstream oder sinkt cost beim warmen Aufruf nicht, ist der Cache entweder unerreichbar oder nicht überprüfbar.
• ✅ Bei einem Router den Upstream festlegen (Schicht 5). Das Routing einschränken, etwa über die Provider-Reihenfolge bei deaktivierten Fallbacks. Andernfalls verteilt das Load Balancing Requests auf getrennte Caches und kann sie an einen 20–50× teureren Upstream senden.
• ✅ Latenz und Kosten getrennt bewerten. Warme Prefills sind selbst bei ~0% Kostenrabatt 2–10× schneller.
• ✅ Auf Cache-Typen mit Speichergebühr achten. Gemietete Caches wie Moonshot moonshot-v1 und Gemini explicit berechnen für ungenutzte Caches nach Token und Zeit. Bei automatischen Prefix-Caches fällt keine Speichergebühr an.

Fazit

Bei Closed Models hat die Frage „Unterstützt es Caching?“ genau eine Antwort. Bei Open Weights ist die technische Fähigkeit seit Jahren auf Ebene der Inference Engine gelöst. vLLM und SGLang cachen jeden Prefix automatisch und kostenlos. Alle darüberliegenden Schichten sind Infrastruktur, die einen Treffer entweder erhält oder verhindert: der Replica-Balancer eines Compute Hosts, das Cluster-Routing eines Gateways und die zufällige Verteilung eines Routers auf verschiedene Anbieter. Die Modellarchitektur setzt die Untergrenze für die Cache-Kosten. MLA und GQA bringen echte Vorteile auf Modellebene. Was tatsächlich beim Nutzer ankommt, entscheidet jedoch der Request-Pfad. Cache-Verhalten sollte deshalb als Routing-Eigenschaft behandelt werden: Kosten auf dem konkreten später verwendeten Pfad messen, die Route festlegen, damit Requests den zuvor aufgewärmten Cache wieder treffen, und bedenken, dass selbst der größte Rabatt nutzlos ist, wenn der zweite Request an einem Ort landet, den der erste nie berührt hat.

Die technischen Grundlagen eines KV-Caches und die Funktionsweise von TTLs erklärt So funktionieren KV-Cache und TTL. Wie sich die Cache-Versprechen eines Gateways prüfen lassen, beschreibt Macht Ihr LLM-Gateway falsche Angaben zum Cache?.

FAQ

Unterstützen Open-Weight-Modelle Prompt-Caching? Die Weights bestimmen, wie günstig Caching werden kann. Attention-Architekturen wie MLA und GQA verkleinern den KV-Cache. Der Cache selbst, der Rabatt und die API stammen jedoch aus dem Serving-Stack. Implementiert wird Caching in der Inference Engine, etwa vLLM, SGLang oder TensorRT-LLM. Compute Hosts übernehmen es, Gateways und Router leiten es weiter oder verteilen Requests daran vorbei. Derselbe Checkpoint kann bei drei Hosts kostenloses automatisches Caching, gar kein Caching oder ausschließlich explizites Caching bieten.

Warum hat dasselbe Modell bei einem Aufruf 49× mehr gekostet als bei einem anderen? Ein Multi-Provider-Router verteilt Requests ohne festen Upstream per Load Balancing auf die Cluster verschiedener Anbieter. Diese haben unterschiedliche Basispreise und getrennte Cache-Zustände. Ein Aufruf traf einen teuren Provider mit kaltem Cache, ein anderer einen günstigen Provider mit warmem Cache. Durch das Festlegen des Upstreams, eine eingeschränkte Provider-Reihenfolge und deaktivierte Fallbacks lassen sich beide Faktoren kontrollieren.

Muss ich beim Self-Hosting für Caching bezahlen? Nein. Automatisches Prefix-Caching ist bei vLLM, SGLang und TensorRT-LLM standardmäßig aktiviert und kostenlos. Ein Treffer überspringt lediglich den Prefill. Es fallen nur die Kosten für die ohnehin betriebenen GPUs an. Der Cache wird selbst verwaltet und bei Bedarf an VRAM per LRU geleert.

Die API meldet cached_tokens: 0, aber die Kosten sind gesunken. Hat Caching funktioniert? Wahrscheinlich ja. Viele Gateways befüllen cached_tokens bei automatisch cachenden Upstreams nicht. Maßgeblich ist das cost-Feld: Ein großer Kostenrückgang zwischen einem kalten und einem identischen warmen Aufruf weist auf einen Cache-Treffer hin.

Welches Open-Weight-Modell bietet den größten Cache-Rabatt? DeepSeeks automatischer Disk-Cache: deepseek-v4-flash berechnet für gecachte Eingaben ~$0.0028/M statt $0.14/M ohne Cache, also ~98% weniger. In unseren Cold→Warm-Tests ließ sich über die V4-Reihe ein Rabatt von 97.9–99.2% reproduzieren. Viele Drittanbieter-Hosts gewähren stattdessen pauschal ~50%.

Gibt es einen Haken bei Caches mit Speichergebühr? Ja. Moonshots expliziter moonshot-v1-Cache und Geminis expliziter Cache werden nach Token und Zeit abgerechnet, solange der Cache bestehen bleibt. Bei Gemini sind es ~$1–4.50 / 1M-tokens / hour. Ein ungenutzter Cache verursacht weiter Kosten, wenn er nicht gelöscht wird. Automatische Prefix-Caches haben keine Speichergebühr.

Verifizierung: Die Live-Werte für Kosten und Latenz wurden am 2026-06-14 mit einem Multi-Provider-Router und unserem eigenen Gateway gemessen. Verwendet wurden ein fester Prompt mit ~4.7K Token, ein kleines max_tokens und sequenzielle Cold→Warm-Aufrufe. Die Rabatte wurden anhand des zurückgegebenen cost-Werts pro Request berechnet. Dokumentierte Preise und Cache-Mechanismen wurden am selben Tag anhand der Primärquellen der Provider geprüft und gezielt gegengeprüft. Einige Anbieterpreise, insbesondere Moonshots Gebühren für explizite Caches, ändern sich häufig. Vor dem Zitieren aktuelle Werte prüfen. Die eigenen Ergebnisse variieren je nach Provider, Prompt, Region und Auslastung.

Quellen

• DeepSeek — Preise
• DeepSeek — Leitfaden zu KV-Cache und Context Caching
• Technischer Bericht zu DeepSeek-V3 — MLA und KV-Cache-Kompression
• GQA: Training Generalized Multi-Query Transformer Models (Ainslie et al.)
• Alibaba Cloud Model Studio — Context Cache und Preise
• Moonshot AI — Context Caching
• Zhipu / Z.AI — Preise und Caching
• vLLM — Automatic Prefix Caching
• SGLang — RadixAttention und Cache
• LMCache — Auslagerung und gemeinsame Nutzung des KV-Caches
• Google — Context Caching für Gemini

Alle Quellen wurden am 2026-06-14 geprüft. Keine Finanzberatung; vor einer Entscheidung die aktuellen Preise prüfen.

← Zurück zum Blog