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

TL;DR — LLM-Prompt-Caching ist keine nachträglich angebaute Optimierung, sondern ergibt sich direkt aus der Berechnung von Attention in der Transformer-Architektur. Sobald klar ist, warum sich die Key/Value-Vektoren eines stabilen Präfixes mathematisch wiederverwenden lassen, zeigt sich der eigentliche Vorteil: Die Kosten sinken drastisch um 50–90%, während zugleich die Time to First Token um den Faktor 5–20 kürzer wird. Dieser Artikel ist Teil 1 einer fünfteiligen Serie. Er erklärt, warum Caching architektonisch möglich ist, wann sich ein Cache angesichts des Kompromisses zwischen Speicherbedarf und Rechenaufwand lohnt und welches TTL-Verhalten jeder Entwickler kennen sollte. Teil 2 geht auf die Implementierungen der einzelnen Provider ein.

Serie: Teil 1 von 5 — Caching-Grundlagen · Weiter: Teil 2 — Provider-Vergleich und Bewertung · Teil 3 — Praxistutorial mit Code · Teil 4 — Das beste LLM nach Anwendungsfall · Teil 5 — LangChain-Integration · Alles auf einer Seite: der vollständige Leitfaden zu Prompt-Caching

Warum die Token-Kosten deiner AI-App schneller steigen als die Nutzerzahlen

Wer einen Chatbot, eine RAG-App oder einen AI-Agent produktiv betreibt, kennt das Problem: Die Rechnung verdoppelt sich, obwohl die Nutzung nicht entsprechend zunimmt. Im Request-Log findet man dann bei jedem Aufruf denselben mehrere Tausend Token langen System-Prompt, dieselben Tool-Beschreibungen und dieselben Abschnitte aus der Wissensdatenbank.

Das ist das zentrale wirtschaftliche Problem der LLM-Inferenz: Das Modell ist zustandslos. Bei jedem Request wird der gesamte Kontext von Grund auf neu verarbeitet. Wird ein System-Prompt mit 8K Token 1.000-mal aufgerufen, fallen 8 Millionen Token für identische Arbeit an. Du bezahlst jeden einzelnen davon, und deine Nutzer warten jedes Mal darauf.

Prompt-Caching löst dieses Problem. Anders als viele Performance-Tricks wird es nicht nachträglich in die Architektur eingebaut, sondern folgt unmittelbar aus der Definition von Transformer-Attention. Sobald das klar ist, lassen sich auch Preise, TTLs und die Unterschiede zwischen Providern schlüssig einordnen.

1. Warum LLMs überhaupt einen Cache haben: Transformer-Inferenz Schritt für Schritt

Fast jedes Tutorial zu Prompt-Caching überspringt diesen Teil. Dabei erklärt gerade er, warum es den Cache überhaupt gibt und weshalb die Rabatte der Provider keine willkürlichen Marketingwerte sind, sondern reale GPU-Kosten widerspiegeln.

1.1 Self-Attention in einer Gleichung

Ein Decoder-only Transformer, zu dessen Modellfamilie GPT-4, Claude, Gemini, DeepSeek und Qwen gehören, verarbeitet Token durch wiederholte Self-Attention. Für eine Sequenz aus N Token lautet die Attention-Ausgabe für jedes Token i:

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

Q, K und V sind Matrizen der Form [N × d]. Sie werden durch drei gelernte lineare Projektionen aus den Input-Embeddings erzeugt, jeweils eine pro Layer und Head. Die ursprüngliche Definition stammt aus Attention Is All You Need (Vaswani et al., 2017).

Für das Caching sind zwei Eigenschaften dieser Gleichung entscheidend:

Eigenschaft 1 — Causal Masking. Während der Generierung kann Token i nur Token an Positionen ≤ i berücksichtigen. Die Attention-Matrix ist untere Dreiecksmatrix: Die K- und V-Vektoren früher Token werden von jedem späteren Token verwendet, spätere Token verändern sie jedoch nicht.

Eigenschaft 2 — K und V hängen nur vom Präfix ab. Sie werden aus den Input-Embeddings der Positionen 1…i über feste Gewichtsmatrizen berechnet. Daher sind die K- und V-Vektoren an Position i eine deterministische Funktion der Token an den Positionen 1…i und ausschließlich dieser Token. Nichts an Position i+1 kann K_i oder V_i verändern.

Daraus folgt unmittelbar: Haben zwei Requests ein identisches Präfix der Länge P, sind die ersten P Zeilen von K und V Bit für Bit identisch.

Das ist die gesamte theoretische Grundlage von Prompt-Caching. Alles Weitere ist Engineering.

1.2 Die zwei Phasen der Inferenz

Moderne LLM-Inferenz besteht aus zwei getrennten Phasen, die GPU-Zeit auf sehr unterschiedliche Weise beanspruchen. Diese Aufteilung wird in Efficiently Scaling Transformer Inference (Pope et al., 2022) ausführlich beschrieben.

Prefill-Phase. Das Modell nimmt den vollständigen Prompt auf einmal auf. In jedem Layer berechnet es Q, K und V für sämtliche Input-Token und führt die Self-Attention aus. Prefill ist compute-bound: Die Matrixmultiplikationseinheiten der GPU werden ausgelastet. Wegen der Attention-Matrix wächst der Aufwand mit der Prompt-Länge quadratisch, also O(N²).

Decode-Phase. Das Modell erzeugt autoregressiv jeweils ein Output-Token. In Schritt t wird nur Q für das neue Token berechnet. Dieses greift auf K/V für alle vorherigen Token zu. Decode ist memory-bandwidth-bound: Der Großteil der Zeit entfällt auf das Lesen von K/V aus dem GPU-Speicher, nicht auf Multiplikationen. Der Aufwand pro Token beträgt O(N) und wächst damit linear zur aktuellen Kontextlänge.

Bei einem typischen Chatbot-Workload mit einem System-Prompt von 8K Token, einer Nutzeranfrage von 100 Token und einer Antwort von 300 Token dominiert Prefill sowohl Laufzeit als auch Kosten ungefähr im Verhältnis 4:1. Genau diesen Anteil spart Caching ein.

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 Der KV-Cache: Prefill-Ergebnisse für Decode speichern

Ursprünglich bezeichnete „KV-Cache“ eine Optimierung innerhalb eines einzelnen Requests. Während des Decodings muss jedes neu generierte Token auf K und V aller vorherigen Token zugreifen. Würden diese in jedem Schritt neu berechnet, würde aus einem Decode mit O(N) ein Decode mit O(N²). Daher speichert jede Inference Engine die während des Prefills erzeugten K- und V-Werte im GPU-Speicher und verwendet sie während der gesamten Decode-Phase erneut. Das ist universell und wird von jedem kommerziellen LLM so umgesetzt. Erst dadurch wird die Generierung überhaupt praktikabel.

Was Provider als „Prompt-Caching“ anbieten, ist die nächste Verallgemeinerung: Der KV-Cache bleibt nach Ende des Requests erhalten und wird für den nächsten Request mit demselben Präfix wiederverwendet.

1.4 Der Kompromiss zwischen Speicher und Rechenleistung: Warum es TTLs gibt

Warum speichern Provider dann nicht einfach alles dauerhaft? Weil der KV-Cache enorm groß ist.

Bei einem Modell mit L Transformer-Layern, H Attention-Heads, der Head-Dimension D und B Byte pro Wert, üblicherweise 2 bei fp16, beträgt die Größe des KV-Caches für N Token:

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

Bei einem Modell der 70B-Klasse mit 80 Layern, 8 KV-Heads nach Grouped-Query Attention, einer Head-Dimension von 128 und fp16-Gewichten sind das ungefähr 320 KB pro Token. Ein Kontext mit 32K Token benötigt ~10 GB KV-Cache, und zwar nur für einen einzigen Request. Eine moderne H100-GPU bietet 80 GB. Mehr als eine Handvoll solcher Kontexte passen nicht gleichzeitig in den Speicher.

Genau dieses Problem sollte PagedAttention (Kwon et al., 2023, das Paper hinter vLLM) auf Batch-Ebene lösen. Dieselbe Einschränkung begrenzt Prompt-Caching über mehrere Requests hinweg:

Die Cache-TTL eines Providers ist daher im Wesentlichen eine Eviction-Policy für Speicher: Irgendwann benötigt die GPU den Speicher für aktive Workloads anderer Nutzer und entfernt das gecachte Präfix. 5 Minuten für Caches im HBM, bis zu 1 Stunde für in DRAM ausgelagerte Caches und mehrere Stunden für festplattenbasierte Caches.

Der Ansatz von DeepSeek. DeepSeek-V2 führte Multi-head Latent Attention (MLA) ein. Gegenüber der üblichen Grouped-Query Attention wird der KV-Cache damit um ungefähr den Faktor 4 komprimiert (DeepSeek-AI, 2024). Erst diese Komprimierung macht es möglich, den KV-Cache statt im HBM auf Festplatte zu speichern. Dadurch kann DeepSeek wiederum wesentlich kleinere minimale Cache-Einheiten verwenden, nämlich 64 statt 1.024 Token bei HBM-basierten Caches, und deutlich längere effektive TTLs anbieten.

Deshalb setzt Caching über mehrere Requests hinweg auch Token für Token identische Präfixe voraus. Der Cache wird über einen Hash der Token-IDs adressiert. Jede Abweichung, selbst ein einzelnes Zeichen, das zu einer anderen Tokenisierung führt, erzeugt ab dieser Stelle andere K- und V-Werte. Auf dieser Ebene gibt es keinen „unscharfen Abgleich“. Dafür ist semantisches Caching zuständig, das im Gateway allerdings über einen anderen Mechanismus läuft.

1.5 Zwei Cache-Ebenen

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

Der Rest der Serie und fast alle Einstellungen, die du als Entwickler optimieren wirst, betreffen Ebene 2.

2. Zwei Vorteile: Kosten UND Latenz

Die meisten Artikel stellen Caching als Kostenoptimierung dar. Das greift zu kurz. Gerade bei nutzerseitigen Chats ist die geringere Latenz für Produktionsteams häufig der wichtigere Grund, Caching einzusetzen.

2.1 Die Kostenrechnung

Preisseiten nennen zwar die Eckdaten, rechnen sie aber selten für einen realistischen Workload durch. Nehmen wir einen Support-Bot mit einem System-Prompt von 8.000 Token, 100K Anfragen pro Tag und Nutzernachrichten von 200 Token. Grundlage ist claude-sonnet-4-5 mit den von Anthropic veröffentlichten Preisen für 2026: 10% des regulären Preises für gecachten Input und 125% für einen Cache-Write.

Ohne Caching

• Input pro Aufruf: 8.200 Token × regulärer Input-Preis
• Kosten pro Aufruf, gemessen an einem einzelnen Aufruf: ~$0.022
• Monatliche Kosten: 100K × 30 × $0.022 = ~$66,000

Mit Prompt-Caching

• Einmaliger Cache-Write: 8.000 Token × 125% Aufschlag, bei diesem monatlichen Volumen vernachlässigbar
• Danach pro Aufruf: 8.000 Token × 10% des regulären Preises + 200 Token × regulärer Preis + Output
• Effektive Kosten pro Aufruf: ~$0.003
• Monatliche Kosten: ~$9,000

~86% Ersparnis. Das ist der von Anthropic veröffentlichte Rabatt, angewendet auf eine realistische Input-Struktur. Der nachfolgende Artikel, Teil 3 — Tutorial, zeigt echte Messwerte für die übrigen Provider.

2.2 Der Latenzvorteil, der oft wichtiger ist

Prefill ist nicht nur teuer. Bei Prompts mit mehr als einigen Hundert Token verursacht es den größten Anteil der Time to First Token. Bei einem Cache-Hit lässt sich diese Arbeit fast vollständig überspringen.

Gemessene Streaming-TTFT über das öffentliche Synthorai-Gateway am 2026-05-25 mit einem stabilen System-Prompt von ~7.300 Token:

Einzelmessung mit einem einzelnen Tenant. Bei langen Prompts über 5K Token ist der TTFT-Vorteil am deutlichsten. Bei kurzen Prompts ist der Prefill-Anteil zu klein, um die Latenz zu dominieren. Der größte gemessene Vorteil von Claude liegt bei den Kosten: Ein Cache-Read reduziert den Input-Preis um ~88–89%. Laut den veröffentlichten Zahlen von Anthropic steigt der TTFT-Vorteil bei Prompts mit 100K+ Token deutlich an.

Bei Chat-UIs nehmen Nutzer Verzögerungen ab ungefähr 1 s TTFT und ~2 s bis zum ersten nützlichen Text bewusst wahr. Ein RAG-Prompt mit 10K Token liegt ohne Caching klar über dieser Grenze. Mit Caching fühlt sich derselbe Workload unmittelbar an.

Auch bei Agent-Loops mit 15 oder mehr Schritten ist die Kostenersparnis von 50% attraktiv. Produktiv einsetzbar wird das System aber erst durch die niedrigere Latenz: 15 Schritte × 5s Prefill ergeben 75 s Leerlauf pro Aufgabe. Mit Caching werden daraus 15 × 0.5s = 7.5 s.

2.3 Warum das für die Produktstrategie relevant ist

Caching wird häufig als Kostenoptimierung des Ops-Teams betrachtet, die man nach dem Launch ergänzt. Wegen der geringeren Latenz gehört Caching jedoch auch zur UX:

• Ein Chatbot mit weniger als 1 s TTFT wirkt reaktionsschnell. Derselbe Bot wirkt bei 3 s defekt.
• Ein RAG-Produkt, bei dem Retrieval und Prefill 4 s dauern, verliert gegen dasselbe Produkt mit 1 s.
• Ein Agent, der eine Aufgabe in 20 s erledigt, setzt sich gegen einen Agent mit 90 s durch.

Die Cache-Strategie sollte gemeinsam mit Modell und Prompt-Struktur festgelegt werden, nicht erst drei Sprints nach dem Launch.

3. Cache-Aktualität, TTL und Betriebsmodell

Die TTL gehört zu den meistgefragten und am seltensten erklärten Aspekten von Prompt-Caching. Entscheidend sind zwei Punkte:

3.1 Aktualität hat zwei Bedeutungen, die nicht verwechselt werden dürfen

Cache-Aktualität ≠ Aktualität der Antwort. Häufig werden zwei unterschiedliche Konzepte vermischt:

Gecachte Antworten sind aus Sicht der Modellqualität also nicht „veraltet“. Sie sind mathematisch identisch mit Antworten ohne Cache. Schreibst du allerdings „Die aktuelle Uhrzeit ist 14:32:05“ in den System-Prompt und setzt auf Cache-Hits, bleibt diese „aktuelle Uhrzeit“ bis zum Ablauf der TTL bei 14:32:05. Das Modell wird Nutzern dann überzeugend eine falsche Uhrzeit nennen.

3.2 TTL-Verhalten der Provider

Der Standardwert von 5 Minuten ist nicht willkürlich. Er entspricht ungefähr dem Zeitraum, über den der GPU-Speicherdruck bei stark ausgelasteten Modellen relevant wird. Wie in §1.4 berechnet, kann der KV-Cache eines einzigen großen Kontexts mehrere Dutzend GB belegen. Provider können solche Caches nicht unbegrenzt vorhalten.

3.3 TTL-gerechtes Design

Drei Muster haben sich im Produktivbetrieb bewährt:

Muster A — Sessions warm halten. Bei Chats hält die natürliche Aufruffrequenz mit Sekunden bis Minuten zwischen einzelnen Nachrichten den Cache von selbst aktiv. Die TTL ist hier kein Problem. Dynamische Daten sollten allerdings nicht im Präfix stehen.

Muster B — Heartbeat für Batch-Jobs. Sende bei Batch-Jobs, die mehrere Stunden laufen, alle TTL/2 einen minimalen Request, um den Cache warm zu halten. Die Kosten sind mit wenigen Input-Token praktisch null, während du Eviction-Spitzen vermeidest.

Muster C — Provider mit langer TTL für seltene Zugriffe nutzen. Wird ein Dokument mit 50K Token nur sporadisch abgefragt, etwa einmal pro Stunde über eine Woche, sind explizite Gemini-Caches mit 24 Stunden TTL oder die festplattenbasierten Caches von DeepSeek trotz Speichergebühr den Alternativen mit kurzer TTL überlegen.

4. Grundlagen, die jeder Entwickler kennen sollte

Provider bieten Caching in fünf sehr unterschiedlichen Varianten an: explizite Marker, vollautomatisch, hybrid, architektonisch über Festplattenzugriff oder gar nicht. Der nächste Artikel widmet sich diesem Vergleich: Teil 2 — Provider-Vergleich und Bewertung. Vier Prinzipien gelten jedoch unabhängig vom Provider und ergeben sich direkt aus der beschriebenen Architektur:

4.1 Caching arbeitet mit Präfixen, daher zählt die Reihenfolge

Da K/V an Position i von den Token an den Positionen 1…i abhängt, können Provider nur ein zusammenhängendes Präfix ab Token 0 abgleichen. Wird ein einziges Zeichen an Position 0 geändert, ist das gesamte Präfix ungültig. Stabile Inhalte gehören nach vorn, veränderliche Inhalte nach hinten. Das ist keine Faustregel, sondern folgt direkt aus der kausalen Struktur von Self-Attention (§1.1).

4.2 Der Cache speichert K/V, nicht Antworten

Ein Cache-Hit liefert keine zuvor generierte Antwort zurück. Er stellt bereits berechnete K- und V-Vektoren bereit, mit denen das Modell eine neue Antwort auf die aktuelle Frage generiert. Daraus folgt:

• Die Output-Qualität ist identisch mit der eines Aufrufs ohne Cache (§1.1).
• Der Output bleibt auf die übliche Weise nicht deterministisch. Temperature, Top-p und weitere Parameter gelten weiterhin.
• Gecachte Antworten sind aus Sicht der Modellqualität nie „veraltet“. Nur der Inhalt deines Prompts, etwa Zeitstempel oder Preise, kann veraltet sein. Siehe nochmals §3.1.

4.3 Cache-Writes sind eine Investition und nicht kostenlos

Bei Providern mit Aufschlag für Cache-Writes, Anthropic mit 125% und Gemini Explicit Caching mit 125%, kostet der erste Aufruf mit einem neuen Präfix mehr als ein Aufruf ohne Caching. Der Break-even ist schnell erreicht, meistens bereits nach einem Hit. Ändert sich dein vermeintlich „stabiles“ Präfix aber bei jedem Request, zahlst du wiederholt für Writes, ohne davon zu profitieren. Das passiert häufig, wenn abgerufene Dokumente nach Relevanz sortiert werden. Es ist das klassische Anti-Pattern.

4.4 Caching-APIs sind nicht zwischen Providern portierbar

cache_control (Anthropic) ≠ cached_content (Gemini) ≠ cache_id (Qwen). Soll deine Anwendung mit mehreren Providern laufen, musst du entweder drei Integrationen pflegen oder einen Token-Gateway davorschalten, der sie vereinheitlicht. Teil 2 behandelt das ausführlich.

5. Ist Prompt-Caching geschenktes Geld?

Fast. Es lohnt sich, wenn:

• deine Prompts ein stabiles Präfix besitzen, etwa System-Prompt, Wissensdatenbank oder Tool-Schemas
• deine Aufrufe häufig erfolgen oder zusammenhängen, etwa in derselben Session, bei Batch-Workloads oder während laufender Agent-Ausführungen
• du die Prompts so strukturieren kannst, dass stabile Inhalte am Anfang stehen

Sind alle drei Bedingungen erfüllt, sinken die Kosten üblicherweise um 50–90%, während die TTFT um den Faktor 3–20× kürzer wird, ohne dass du das Modell wechseln musst.

Als Nächstes: Teil 2 — Vergleich der Provider-Caches und Bewertungsrahmen überführt die oben beschriebene Architektur in einen Funktionsvergleich von Claude, OpenAI, Gemini, DeepSeek und Qwen. Außerdem enthält er ein Bewertungsschema, mit dem du den passenden Provider für deinen Workload auswählen kannst.

Quickstart: Alle Provider mit dem OpenAI SDK nutzen

Synthorai bietet einen OpenAI-kompatiblen Endpoint. Richte das offizielle openai SDK darauf aus, und für den Wechsel zwischen Claude, GPT, Gemini, DeepSeek und Qwen genügt eine einzige Zeile. Das Gateway übersetzt cache_control in die native Caching-Syntax des jeweiligen Providers.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

Derselbe Aufruf funktioniert mit gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash und qwen3-max. Nur das Feld model ändert sich. Das Gateway liefert die Metadaten zu Prompt-Cache-Hits im standardisierten OpenAI-Feld prompt_tokens_details.cached_tokens zurück. Zusätzlich enthält die Antwort ein Feld cost mit den Kosten in USD, sodass du lokal keine Preismatrix für jeden Anbieter pflegen musst.

FAQ

Ist LLM-Prompt-Caching dasselbe wie semantisches Caching? Nein. Prompt-Caching ist präfixbasiert und verwendet K/V-Werte erneut, wenn der Anfang des Prompts auf Token-Ebene exakt übereinstimmt. Semantisches Caching gleicht die Bedeutung ab, etwa über Embeddings, und gibt eine frühere Antwort zurück. Beide Verfahren sind nützlich. Ein guter Token-Gateway kombiniert sie in mehreren Ebenen.

Verändert Prompt-Caching den Output des Modells? Nein. K und V sind deterministische Funktionen der Input-Token (§1.1). Die Logits, die das Modell mit gecachtem K/V erzeugt, sind mathematisch identisch mit denen aus einem frisch berechneten K/V. Caching ist eine reine Effizienzoptimierung ohne Einfluss auf die Qualität.

Warum ist die Cache-TTL so kurz? Kann der Cache nicht einfach dauerhaft gespeichert werden? Der KV-Cache ist enorm groß. Wie §1.4 zeigt, belegt ein 32K-Kontext bei einem 70B-Modell ~10 GB. GPU-Speicher ist der Engpass. Sobald der Server diesen Speicher für aktive Workloads benötigt, werden Caches entfernt. Festplattenbasierte Caches wie bei DeepSeek können mehrere Stunden bestehen, In-Memory-Caches normalerweise nicht.

Worin unterscheiden sich KV-Cache und Prompt-Cache? Der KV-Cache ist die In-Memory-Datenstruktur, die während der Inferenz verwendet wird. „Prompt-Cache“ bezeichnet die Wiederverwendung dieses KV-Caches über mehrere Requests hinweg. Das entspricht Ebene 1 und Ebene 2 aus §1.5.

Können gecachte Prompts so veralten, dass die Qualität sinkt? Aus Sicht des Modells nein. Aus Sicht deiner Inhalte ja, wenn der Prompt zeitabhängige Informationen enthält. Der Cache speichert K/V-Vektoren und keine Fakten über die Welt. Siehe §3.1.

Wie messe ich die Cache-Hit-Rate? Jeder Provider liefert sie im Usage-Objekt der Antwort: cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini) und prompt_cache_hit_tokens (DeepSeek). Erfasse diese Werte in deiner Logging-Pipeline.

Referenzen und Quellen: Vaswani et al., „Attention Is All You Need“ (NeurIPS 2017) · Pope et al., „Efficiently Scaling Transformer Inference“ (2022) · Kwon et al., „Efficient Memory Management for LLM Serving with PagedAttention“ (SOSP 2023, vLLM) · DeepSeek-AI, „DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model“ (2024) — MLA-Architektur · Anthropic-Dokumentation zu Prompt-Caching · OpenAI-Dokumentation zu Prompt-Caching · Google-Gemini-Dokumentation zu Context Caching · DeepSeek-Leitfaden zum KV-Cache · Alibaba Bailian Context Cache

← Zurück zum Blog