Open-Weight LLM Caching: Warum Ihres Provider-Roulette ist

Bei einem geschlossenen Modell ist Prompt-Caching ein dokumentierter Vertrag. Claude hat cache_control-Breakpoints; OpenAI und Gemini cachen automatisch ab einem Token-Schwellenwert; die Rabatte sind veröffentlicht und stabil. Sie lesen eine Seite und sind fertig.

Open Weights brechen diese Annahme. Denselben Qwen- oder Llama-Checkpoint betreiben ein Dutzend Hosts, und Caching ist keine Eigenschaft des Modells — es ist eine Eigenschaft des Ortes, an dem das Modell läuft. Um zu zeigen, wie weit das geht, hier eine gemessene Anfrage — ein identischer ~4.700-Token-Prompt, der über einen Multi-Provider-Router sechsmal an dasselbe Qwen-Modell gesendet wurde, ohne festgelegten Upstream:

Gleiches Modell, gleicher Router, gleicher Prompt: Die Rechnung reichte von $0,0141 bis $0,000286 — eine 49-fache Spanne — rein davon abhängig, welchen Upstream der Router wählte und ob dieser Upstream das Präfix warm hatte.

Zusammenfassung

• Prompt-Caching für Open-Weight-Modelle ist ein Routing-Ergebnis, kein Modell-Feature. Es wird — kostenlos und automatisch — im Inferenz-Engine implementiert und dann von jeder darüber liegenden Schicht erhalten oder zerstört.
• Fünf Schichten: eine liefert Caching, drei können es zerstören. Das Modell (legt Cachefähigkeit fest, bedient keinen Cache) → der Inferenz-Engine (Caching, kostenlos) → der Compute-Host (macht es zum Produkt, uneinheitlich) → das Gateway (Multi-Cluster-Routing) → der Router (verteilt auf Anbieter mit disjunkten Caches).
• Gemessen. Eine identische Anfrage, durch einen Router verteilt, kostete bei einer Wahl 49-mal mehr als bei einer anderen; bei einem Modell lieferte ein Host 59,6 % Rabatt und ein anderer 0 %; veröffentlichte Cache-Rabatte reichen über Modelle hinweg von 0 % bis ~98 %.
• Was zu tun ist. Pinnen Sie Ihre Route, damit wiederholte Präfixe denselben warmen Cache treffen; prüfen Sie anhand des Kosten-Deltas, nicht des Feldes cached_tokens (das bei einem echten Treffer oft 0 anzeigt); wägen Sie Latenz separat ab — warme Prefills laufen 2–10× schneller, selbst bei ~0 % Kostenrabatt.

Live-Zahlen wurden am 2026-06-14 gegen einen Multi-Provider-Router und unser eigenes Gateway gemessen, mit einem festen ~4.700-Token-englischen Prompt, kleinem max_tokens, sequenziellen Durchläufen. Die dokumentierten Preise wurden am selben Tag gegen primäre Anbieter-Dokumentationen geprüft und adversarial gegengeprüft. Verhältnisse (prozentualer Rabatt, Latenzänderung) sind der übertragbare Teil; absolute Dollar-Beträge hängen vom Ort, Ihrem Prompt und der Last ab. Reproduzieren Sie die Ergebnisse, bevor Sie sie zitieren.

Die Cache-Typen, denen Sie wirklich begegnen werden

Zuerst das Vokabular, dann der Stack. Bei Open-Weight-Hosts gibt es vier verschiedene Cache-Formen, die unterschiedlich abgerechnet werden.

1. Automatisches Prefix-Caching (ohne Marker). Das vorherrschende Muster. Der Server hasht Ihr Prompt-Präfix, verwendet den KV-Zustand wieder, wenn er mit einer früheren Anfrage übereinstimmt, und wendet den Rabatt eigenständig an – kein cache_control, keine Code-Änderung, oft nicht deaktivierbar. DeepSeek, Zhipu GLM und die meisten Open-Weight-Hosts tun dies. Schreibvorgänge sind kostenlos; der Cache lebt irgendwo zwischen VRAM (Minuten) und Festplatte (DeepSeek behält Präfixe „einige Stunden bis einige Tage”).

2. Explizites Breakpoint-Caching (cache_control). Die Anthropic-Form, die auch einige Open-Weight-Hosts anbieten. Alibabas Model Studio akzeptiert "cache_control": {"type": "ephemeral"} in einem Qwen-Nachrichtenblock; einige Serving-Plattformen bieten einen entsprechenden Marker an. Sie markieren die Grenze, zahlen einen Schreib-Aufschlag und erhalten dafür einen tieferen Lese-Rabatt.

3. Gemietete Cache-Objekte (mit Speichergebühr). Der Typ, den man im Auge behalten sollte. Moonshoots Legacy-Familie moonshot-v1 erfordert einen POST /v1/caching-Aufruf zum Erstellen eines Caches und berechnet dann eine Schreibgebühr, eine Speichergebühr pro Token pro Minute sowie eine Treffergebühr pro Aufruf. Googles explizites Gemini-Caching funktioniert nach demselben Prinzip – Eingabekosten plus Speicher zu etwa $1,00–$4,50 pro 1M-Token pro Stunde. Der Cache ist eine Ressource, die Sie mieten und selbst bereinigen müssen.

4. Self-Hosted KV-Wiederverwendung (kostenlos). Betreiben Sie die Gewichte selbst, cached die Inference-Engine kostenlos und automatisch. Keine Schreibgebühr, kein Lesetarif, keine Speichermiete – ein Treffer überspringt einfach das Prefill.

Qwen auf Model Studio bietet beide Modi – automatisch und explizit – mit einem echten Kompromiss: Implizit berechnet einen Treffer mit 20 % der Eingabe bei kostenlosen Schreibvorgängen; explizit berechnet einen Treffer mit 10 % der Eingabe, erhebt jedoch 125 % auf den Schreibvorgang und begrenzt den Eintrag auf einen 5-Minuten-TTL. Tieferer Rabatt, aber Sie zahlen für das Befüllen und erneut bei jedem Ablauf.

Wo Caching im Stack angesiedelt ist

Hier ist der Kerngedanke. Prompt-Caching für Open Weights ist genau auf einer Ebene gelöst und auf jeder darüberliegenden Ebene gefährdet. Gehen Sie den Stack von den Gewichten nach oben durch und fragen Sie auf jeder Ebene: Stellt diese Ebene Caching bereit, oder leitet sie es nur weiter – und kann sie das, was die Ebene darunter bereits getan hat, zerstören?

  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.

Ebene 1 — Das Modell: Cachefähigkeit, kein Cache

Dies ist die Ebene, in der die meisten Menschen glauben, dass Caching stattfindet — „DeepSeek hat Caching” — daher ist es die erste, bei der Präzision gefragt ist. Ein Checkpoint ist ein Satz von Gewichten; er führt dieselbe Attention aus, unabhängig davon, ob ein KV-Cache existiert oder nicht. Er liefert keinen Cache, keinen Rabatt, kein TTL, kein cache_control-Marker — das sind Funktionen der Serving-Ebene. In diesem strengen Sinne bieten die Gewichte kein Caching-Produkt.

Aber die Gewichte sind nicht neutral, und DeepSeek ist das perfekte Beispiel dafür. Die Attention-Architektur des Modells bestimmt, wie groß der KV-Cache ist, und damit, wie günstig Caching überhaupt sein kann:

• DeepSeeks Multi-head Latent Attention (MLA) komprimiert den KV-Cache in ein niedrigrangiges Latent — auf etwa 4–14 % eines Standard-Multi-Head-Caches. Genau diese Komprimierung ermöglicht es DeepSeeks API, Präfixe auf Disk zu persistieren und einen Cache-Read mit ~2 % des Input-Preises zu berechnen. Die Architektur ist der Ermöglicher; der Disk-Cache ist ein darauf aufgebautes Produkt.
• Grouped-Query Attention (GQA) — verwendet von Llama, Qwen, Mistral und DeepSeek — teilt KV-Heads, um den Cache um den Gruppenfaktor zu verkleinern (≈8× bei Llama-3).

Der Beitrag von Ebene 1 ist also Cachefähigkeit, kein Cache: Die Architektur setzt die Obergrenze dafür, wie günstig jede darüberliegende Ebene Caching gestalten kann — aber die Gewichte selbst liefern niemals ein gecachtes Token. Und „DeepSeek hat Caching” vermischt stillschweigend zwei verschiedene Dinge unter demselben Namen — die Gewichte (diese Ebene, die MLA liefern) und DeepSeeks API und Serving-Stack (Ebenen 2–3, die den Disk-Cache, den Rabatt und die Usage-Felder liefern). Laden Sie die offenen Gewichte herunter und betreiben Sie sie selbst, behalten Sie MLAs kleinen KV-Cache — aber das Disk-Cache-Produkt verbleibt auf DeepSeeks Servern. Sie erben stattdessen die Ebene 2, die Sie selbst deployen. Die operative Schlussfolgerung bleibt daher bestehen: Hören Sie auf zu fragen, ob ein Modell cached, und fragen Sie stattdessen, wo es betrieben wird — verwechseln Sie das nur nicht damit, dass die Architektur keine Rolle spielt. Sie setzt die Obergrenze; der Pfad bestimmt, was Sie tatsächlich erhalten.

Ebene 2 — Die Inference-Engine: wo Caching gebaut wird, und kostenlos ist

Eine Ebene höher ist Caching nicht nur vorhanden — es ist gelöst, und kostenlos. Moderne Inference-Engines cachen Präfixe automatisch:

• vLLM — Automatic Prefix Caching: hasht jeden KV-Block, verwendet jeden Block wieder, dessen Präfix-Hash bereits gesehen wurde, räumt per LRU aus. In V1 standardmäßig aktiviert.
• SGLang — RadixAttention: speichert den KV-Cache in einem Radix-Baum, sodass jedes gemeinsame Präfix wiederverwendet wird, mit cache-bewusstem Scheduling.
• TensorRT-LLM — Block-Wiederverwendung (enable_block_reuse, standardmäßig aktiviert), mit optionalem Auslagern von KV-Blöcken in den Host-Speicher.

Projekte wie LMCache erweitern dies weiter — sie lagern KV auf CPU/Disk aus und teilen es instanzübergreifend, was den Keim der Lösung für das Routing-Problem darstellt, auf das wir gleich stoßen werden. Der Punkt: Wenn Sie selbst hosten, sind Sie fertig. Caching ist automatisch, kostet nichts über die bereits betriebenen GPUs hinaus, räumt per LRU aus, und Sie besitzen es — ein Cache-Hit überspringt einfach das Prefill, senkt die TTFT und erhöht den Durchsatz. Es gibt kein cached_tokens-Abrechnungsfeld, weil nichts abgerechnet wird; der Gewinn zeigt sich in Ihren eigenen Latenz-Metriken. Bei einem geschlossenen Modell mieten Sie Caching; bei einem offenen können Sie es vollständig besitzen. Der Haken ist das Gegenteil der gehosteten Welt: Der Cache ist flüchtig (VRAM, LRU) und überlebt daher nur, solange das Präfix heiß bleibt — was genau das ist, was die darüberliegenden Ebenen bewahren müssen.

Ebene 3 — Der Compute-Host: Produktisierung, uneinheitlich

Kommerzielle Inference-Hosts kapseln Ebene 2 und betreiben Flotten von Replikas. Sie erben das kostenlose automatische Caching – die Frage ist, ob sie es gut implementieren, und die Antwort ist auf zwei Achsen gemischt.

Erstens variieren Transparenz und Preisgestaltung erheblich. Unter den wichtigsten Open-Weight-Hosts: Einer wendet pauschal 50 % auf gecachte Eingaben an und lässt gecachte Token die Rate-Limits umgehen; ein anderer bietet standardmäßig 50 % Rabatt auf Serverless; ein dritter berechnet gecachte Eingaben modellabhängig (z. B. ein Qwen-Tier mit ~80 % Rabatt) und stellt einen Cache-Key-Hint zur Verbesserung der Affinität bereit; ein vierter aktiviert Caching dauerhaft und macht es auf dedizierten Endpunkten nicht deaktivierbar. Dieselbe zugrunde liegende Engine, vier Preisphilosophien.

Zweitens – und hier versagt Caching zum ersten Mal – das Multi-Replikas-Problem. Ihr warmes Präfix liegt im VRAM genau der einen Replikas, die die kalte Anfrage bedient hat. Der eigene Load Balancer des Hosts kann Ihre nächste Anfrage an eine andere Replikas mit kaltem Cache weiterleiten. Genau das haben wir beobachtet: Wir haben dasselbe Qwen-Modell jeweils an einen einzelnen Upstream gebunden und Cold→Warm-Messungen durchgeführt:

Provider A hat sauber gecacht und es korrekt ausgewiesen. Provider B – der für dieses Modell einen Cache-Read-Preis bewirbt – hat in unserem Test über einen kalten Aufruf und zwei warme Aufrufe hinweg keinen Rabatt gewährt. Ob das an Eligibility-Kriterien, Replikas-Fan-out oder einer längeren Aufwärmphase als zwei Anfragen liegt, bleibt offen – das gemessene Ergebnis auf diesem Pfad war null. Die Fähigkeit ist auf Ebene 2 gelöst; ob Sie sie tatsächlich erhalten, ist ein Ausführungsdetail von Ebene 3, das je nach Host unterschiedlich ausfällt.

Ebene 4 — Das Gateway: das Multi-Cluster-Problem

Ein Gateway sitzt vor einem oder mehreren Upstreams und multipliziert das Replikat-Problem zu einem Cluster-Problem. Wenn es Anfragen ohne Cache-Affinität im Round-Robin-Verfahren über Cluster oder Provider verteilt, wird der warme Cache strukturell unerreichbar — jede Anfrage landet an einem Ort, an dem das Präfix nicht vorhanden ist. Ein cache-bewusstes Gateway muss nach Präfix-Hash routen, damit identische Präfixe beim selben Upstream verbleiben — genauso wie Ebene 2 sie an denselben KV-Blöcken festhält.

Wir haben eine Cold→Warm-Testreihe über Open-Weight-Modelle auf einem Drittanbieter-Gateway durchgeführt und dabei die cost-Angabe pro Anfrage direkt ausgelesen:

DeepSeek-V4 erreichte 97–99 % (Affinität funktioniert durchgängig); qwen3.5-plus und qwen3-max lieferten beim warmen Aufruf ~0 % zurück, obwohl im Katalog ein Cache-Read-Preis ausgewiesen ist. Zwei weitere Gateway-Lektionen verbergen sich in dieser Tabelle:

• Das Usage-Feld lügt; der Cost-Wert nicht. cached_tokens zeigte bei jedem Aufruf hier 0 an — einschließlich der 99-%-Kostensenkungen. Viele OpenAI-kompatible Gateways befüllen das Cached-Token-Feld nicht für Upstreams, die automatisch cachen. Prüfen Sie anhand des cost-Deltas zwischen einem kalten und einem warmen Aufruf, nicht anhand des Token-Felds — dieselbe Lektion wie beim Prüfen der Cache-Angaben eines Gateways.
• Die Latenz verbessert sich auch dann, wenn die Kosten es nicht tun. Jeder warme Aufruf war 2–10× schneller — qwen3.5-flash ging von 10,2s auf 1,0s — einschließlich der Aufrufe mit ~0 % Rabatt. Ein Cache-Treffer überspringt das Prefill unabhängig davon, wie der Anbieter es berechnet; Caching kann sich also beim TTFT auszahlen, selbst bei einem Gateway, das Ihnen auf der Rechnung nichts spart.

Ein Gateway, das keine Affinität bewahrt, gibt Ihnen einen Cache, den Sie nicht erreichen können; eines, das die Cache-Kosten nicht ausweist, gibt Ihnen einen, den Sie nicht überprüfen können.

Ebene 5 — Der Router: Zufällige Verteilung über Anbieter hinweg

Ganz oben verteilt ein Multi-Provider-Router eine einzelne Modell-ID über Cluster verschiedener Unternehmen — jedes mit einem eigenen Cache. Selbst perfekte Affinität innerhalb eines Anbieters hilft jetzt nicht mehr: Wenn Aufruf 1 zu einem Anbieter und Aufruf 2 zu einem anderen geht, gibt es keinen gemeinsamen Cache, der getroffen werden kann. Das ist die Streuung vom Anfang dieses Beitrags, und sie verstärkt Ebene 4 — nicht nur mehrere Cluster, sondern mehrere Anbieter mit disjunktem Cache-Zustand und disjunkten Preisen (der teuerste Treffer wurde mit dem 20-fachen des günstigsten Upstream-Grundpreises abgerechnet). Der Cache griff nur dann, wenn das Routing zufällig beim selben Anbieter blieb.

Die Lösung besteht darin, die Zufälligkeit zu eliminieren — das Routing deterministisch zu gestalten, sodass wiederholte Präfixe immer beim 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,
    },
  })

Dem Router ist zugutezuhalten, dass er cached_tokens (4.224 beim Treffer) und einen cost-Wert pro Anfrage zurückmeldet, sodass beides überprüft werden kann — besser als das Layer-4-Gateway, das 0 ausgab. Aber das Routing liegt in Ihrer Verantwortung. Caching ist ein Routing-Problem, das als Pricing-Feature verkleidet ist: Der Cache ist auf Ebene 2 kostenlos, und die Ebenen 3, 4 und 5 sind drei eskalierend wirkende Wege, sich durch falsches Routing davon fernzuhalten.

Wie tief ist der Rabatt? Das ist sehr unterschiedlich

Wenn das Routing tatsächlich passt — wie viel spart man dann? Bei geschlossenen Modellen liegt der Cache-Read-Rabatt nahe bei 90 %. Bei Open-Weights-Modellen reicht der veröffentlichte Cache-Read-Preis von einem symbolischen Nachlass bis nahezu vollständig, selbst innerhalb des Angebots eines einzigen Anbieters. Erstanbieter-Listenpreise:

DeepSeeks automatischer Disk-Cache ist der tiefste in der Branche — deepseek-v4-flash liest gecachten Input zu $0,0028/M gegenüber $0,14/M bei einem Miss, ein Verhältnis von 1:50, das unser Layer-4-Test mit 97,9 % reproduziert hat. Drittanbieter-Hosts derselben Open-Weights-Modelle bepreisen gecachten Input unabhängig — manche wenden pauschal ~50 % an, andere variieren je nach Modell zwischen ~50 % und ~90 % — der Rabatt, den Sie erhalten, hängt also davon ab, bei welchem Host Sie landen, nicht nur vom Modell. Gleicher Feature-Name, 48 Prozentpunkte Unterschied.

Da der Rabatt eine Eigenschaft des Anbieters ist, hat ein Modell überall, wo es bereitgestellt wird, unterschiedliche Cache-Ökonomie. deepseek-v4-pro, auf vier Wegen:

„DeepSeek-V4-Pro unterstützt Caching” ist wahr und nahezu nutzlos; die operative Frage lautet: „Unterstützt Caching wo, zu welchem Satz, wie gemeldet.”

Eine Entscheidungs-Checkliste

• ✅ Das Modell setzt die Obergrenze, nicht der Cache (Ebene 1). Seine Attention-Architektur (MLA, GQA) entscheidet, wie günstig Caching sein kann, aber sie liefert niemals ein gecachtes Token — fragen Sie daher weiterhin, wo es bereitgestellt wird und was der Stack des jeweiligen Hosts leistet.
• ✅ Self-Hosting? Sie haben es bereits kostenlos (Ebene 2). Bestätigen Sie, dass automatisches Prefix-Caching aktiviert ist (es ist standardmäßig in vLLM/SGLang aktiv), und beobachten Sie Ihre Prefix-Hit-Rate.
• ✅ Auf einem Compute-Host: Lieferung prüfen, nicht die Preisspalte (Ebene 3). Ein Cache-Read-Preis ist eine Behauptung; messen Sie ein Kalt→Warm-Kostendelta. Verwenden Sie einen Cache-Key-Affinity-Hinweis, wo der Host einen anbietet.
• ✅ Über ein Gateway: Cache-Affinity-Routing und Kostenreporting einfordern (Ebene 4). Wenn identische Prefixe nicht an einem Upstream haften bleiben oder cost bei einem Warm-Call nicht sinkt, ist der Cache unerreichbar oder nicht verifizierbar.
• ✅ Auf einem Router: den Upstream festpinnen (Ebene 5). Schränken Sie das Routing ein (z. B. ein Provider-Order-Feld mit deaktivierten Fallbacks), sonst verlieren Sie Hits durch Load-Balancing über disjunkte Caches — und riskieren einen 20–50× teureren Upstream.
• ✅ Latenz separat von den Kosten bewerten. Warme Prefills sind 2–10× schneller, selbst wenn der Preisnachlass ~0 beträgt.
• ✅ Auf Cache-Typen mit Speichergebühren achten. Gemietete Caches (Moonshot moonshot-v1, Gemini explizit) berechnen pro Token-Zeit für einen inaktiven Cache; automatische Prefix-Caches tun das nicht.

Fazit

Bei geschlossenen Modellen gibt es auf die Frage „Cached es?” eine einzige Antwort. Bei Open-Weights-Modellen wurde die Fähigkeit vor Jahren auf der Inferenz-Engine-Ebene gelöst — vLLM und SGLang cachen jedes Prefix, kostenlos und automatisch. Alles oberhalb dieser Ebene ist Infrastruktur, die den Hit entweder bewahrt oder Sie davon weglenkt: der Replica-Balancer eines Compute-Hosts, das Cluster-Routing eines Gateways, die zufällige Verteilung eines Routers über Anbieter hinweg. Die Architektur des Modells setzt die Obergrenze dafür, wie günstig Caching sein kann — MLA und GQA sind echte Gewinne auf Modellebene — aber der Pfad, den Ihre Anfrage nimmt, entscheidet, was Sie tatsächlich erhalten. Behandeln Sie Cache-Verhalten als eine Routing-Eigenschaft — messen Sie es in Kostenbegriffen auf dem genauen Pfad, den Sie verwenden werden, pinnen Sie die Route fest, damit der Cache, den Sie aufgewärmt haben, auch der ist, den Sie treffen, und denken Sie daran: Der tiefste Rabatt der Welt ist nichts wert, wenn Anfrage zwei an einem Ort landet, den Anfrage eins nie berührt hat.

Für die Mechanik, warum ein KV-Cache existiert und wie TTLs funktionieren, beginnen Sie mit How KV Cache & TTL Work; um die Cache-Behauptungen eines Gateways zu prüfen, lesen Sie Does Your LLM Gateway Lie About Cache?.

FAQ

Unterstützen Open-Weight-Modelle Prompt-Caching? Die Gewichte bestimmen, wie günstig Caching sein kann — Attention-Architekturen wie MLA und GQA verkleinern den KV-Cache — aber der Cache selbst, der Rabatt und die API kommen vom Serving-Stack. Caching wird in der Inference-Engine implementiert (vLLM, SGLang, TensorRT-LLM), von Compute-Hosts übernommen und von Gateways und Routern weitergeleitet (oder verteilt). Denselben Checkpoint auf drei Hosts deployen, und man kann kostenloses automatisches Caching erhalten, gar keines oder nur explizites.

Warum hat dasselbe Modell bei einem Aufruf 49× mehr gekostet als bei einem anderen? Bei einem Multi-Provider-Router wird eine nicht fixierte Anfrage per Load-Balancing auf verschiedene Anbieter-Cluster mit unterschiedlichen Grundpreisen und getrenntem Cache-Zustand verteilt. Ein Aufruf traf einen teuren Anbieter kalt; ein anderer traf einen günstigen warm. Den Upstream fixieren (Anbieterreihenfolge einschränken, Fallbacks deaktivieren), um beides zu kontrollieren.

Muss ich beim Self-Hosting für Caching bezahlen? Nein. Automatisches Prefix-Caching in vLLM, SGLang und TensorRT-LLM ist standardmäßig aktiviert und kostenlos — ein Treffer überspringt einfach das Prefill. Man zahlt nur für die GPUs, die bereits laufen, und der Cache gehört einem selbst, der per LRU verdrängt wird, wenn VRAM benötigt wird.

Die API meldet cached_tokens: 0, aber meine Rechnung ist gesunken — hat Caching funktioniert? Wahrscheinlich ja. Viele Gateways befüllen cached_tokens nicht für Upstreams, die automatisch cachen. Dem cost-Feld vertrauen: Ein großer Rückgang zwischen einem kalten und einem identischen warmen Aufruf bedeutet einen Cache-Treffer.

Welches Open-Weight-Modell hat den tiefsten Cache-Rabatt? DeepSeeks automatischer Disk-Cache: deepseek-v4-flash liest gecachten Input für ~$0,0028/M gegenüber $0,14/M ungecacht (~98% Rabatt), in unseren kalt→warm-Tests über die V4-Linie hinweg mit 97,9–99,2% reproduziert. Viele Drittanbieter-Hosts wenden stattdessen ein pauschales ~50% an.

Gibt es einen Haken bei Caches, die eine Speichergebühr erheben? Ja — Moonshoots expliziter Cache moonshot-v1 und Geminis expliziter Cache berechnen pro-Token-Zeit, um den Cache am Leben zu erhalten (Gemini ~$1–4,50 / 1M-Token / Stunde). Ein vergessener, inaktiver Cache läuft weiter auf Kosten. Automatische Prefix-Caches haben keine Speichergebühr.

Verifizierung: Live-Kosten-/Latenzwerte gemessen am 2026-06-14 gegen einen Multi-Provider-Router und unser eigenes Gateway, mit einem festen ~4,7K-Token-Prompt, kleinem max_tokens, sequenziellen kalt→warm-Durchläufen; Rabatte berechnet aus den zurückgegebenen cost-Werten pro Anfrage. Dokumentierte Preise und Cache-Mechanismen am selben Tag gegen primäre Anbieter-Dokumentationen geprüft und adversarisch gegengeprüft; einige Anbieterangaben (insbesondere Moonshoots explizite Cache-Gebühren) ändern sich häufig — aktuelle Werte vor dem Zitieren bestätigen. Die eigenen Zahlen variieren je nach Anbieter, Prompt, Region und Last.

Quellen

• DeepSeek — Pricing
• DeepSeek — KV cache / Context Caching guide
• DeepSeek-V3 Technical Report — MLA (KV-cache compression)
• GQA: Training Generalized Multi-Query Transformer Models (Ainslie et al.)
• Alibaba Cloud Model Studio — context cache & pricing
• Moonshot AI — Context Caching
• Zhipu / Z.AI — pricing & caching
• vLLM — Automatic Prefix Caching
• SGLang — RadixAttention / cache
• LMCache — KV cache offloading & sharing
• Google — Gemini context caching

Alle geprüft am 2026-06-14. Keine Finanzberatung; aktuelle Preise vor der Verwendung verifizieren.

← Zurück zum Blog