LLM-Prompt-Caching #1: Wie KV-Cache & TTL funktionieren

Kurzfassung — LLM-Prompt-Caching ist keine aufgesetzte Optimierung; es ergibt sich daraus, wie die Transformer-Architektur Attention tatsächlich berechnet. Sobald man versteht, warum die Schlüssel/Wert-Vektoren eines stabilen Präfixes mathematisch wiederverwendbar sind, wird die eigentliche Überraschung der zweifache Nutzen: dramatische Kostenreduktion (50–90 %) und dramatische Reduktion der Zeit bis zum ersten Token (5–20×). Dieser Artikel — Teil 1 einer vierteiligen Serie — behandelt den architektonischen Grund für die Existenz des Cachings, den Speicher-versus-Rechen-Kompromiss, der bestimmt, ob sich ein Cache lohnt, und das TTL-Verhalten, das jeder Entwickler verstehen muss. Teil 2 geht in die anbieterspezifischen Implementierungen.

Serie: Teil 1 von 4 — Caching-Prinzipien · Weiter: Teil 2 — Anbietervergleich & Bewertung · Teil 3 — Tutorial mit funktionierendem Code · Teil 4 — Das beste LLM je nach Anwendungsfall

Warum die Token-Rechnung Ihrer KI-App schneller wächst als Ihre Nutzer

Wenn Sie einen Chatbot, eine RAG-Anwendung oder einen KI-Agenten ausliefern, sind Sie wahrscheinlich gegen dieselbe Wand gelaufen: Ihre Rechnung verdoppelt sich, während Ihre Nutzung es nicht tut. Öffnen Sie das Anfrageprotokoll, und Sie finden denselben mehrere Tausend Token langen System-Prompt, dieselben Werkzeugbeschreibungen, dieselben Wissensdatenbank-Abschnitte — bei jedem Aufruf erneut gesendet.

Das ist das zentrale wirtschaftliche Problem der LLM-Inferenz: das Modell ist zustandslos. Jede Anfrage verarbeitet den gesamten Kontext von Grund auf neu. Ein 8K-Token-System-Prompt, der 1.000 Mal aufgerufen wird, entspricht 8 Millionen Token wiederholter Arbeit. Sie zahlen für jeden einzelnen davon — und Ihre Nutzer warten auf jeden einzelnen davon.

Prompt-Caching behebt das. Doch anders als die meisten Performance-Tricks wird es nicht zur Architektur hinzugefügt — es ist eine natürliche Folge der Definition von Transformer-Attention. Sobald man das erkennt, ordnet sich der Rest des Artikels (Preisgestaltung, TTL, Anbieterunterschiede) sauber ein.

1. Warum LLMs überhaupt einen Cache haben: ein Rundgang durch die Transformer-Inferenz

Dieser Abschnitt ist der Teil, den fast jedes „Prompt-Caching”-Tutorial überspringt. Es ist der Teil, der erklärt, warum der Cache überhaupt existiert — und warum die von Anbietern angebotenen Rabatte keine willkürlichen Marketingzahlen sind, sondern echte GPU-Ökonomie widerspiegeln.

1.1 Self-Attention in einer Gleichung

Ein Decoder-only-Transformer (die Familie, zu der GPT-4, Claude, Gemini, DeepSeek, Qwen alle gehören) verarbeitet Token, indem er Self-Attention wiederholt anwendet. Für eine Sequenz von N Token ist die Attention-Ausgabe für jedes Token i:

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

wobei Q, K, V Matrizen der Form [N × d] sind, die aus den Eingabe-Embeddings durch drei gelernte lineare Projektionen abgeleitet werden (eine pro Schicht pro Kopf). Die ursprüngliche Definition stammt aus Attention Is All You Need (Vaswani et al., 2017).

Zwei Eigenschaften dieser Gleichung sind für das Caching enorm wichtig:

Eigenschaft 1 — Kausale Maskierung. Während der Generierung kann Token i nur Token an Positionen ≤ i beachten. Die Attention-Matrix ist untere Dreiecksmatrix: die K- und V-Vektoren früher Token werden von jedem späteren Token verwendet, aber spätere Token verändern sie nie.

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

Die Implikation ist unmittelbar: wenn zwei Anfragen ein identisches Präfix der Länge P teilen, sind die ersten P Zeilen von K und V Bit für Bit identisch.

Das ist die gesamte theoretische Grundlage für Prompt-Caching. Alles andere ist Ingenieurarbeit.

1.2 Die zwei Phasen der Inferenz

Moderne LLM-Inferenz läuft in zwei verschiedenen Phasen ab, die GPU-Zeit sehr unterschiedlich verbrauchen. Diese Aufteilung ist ausführlich in Efficiently Scaling Transformer Inference (Pope et al., 2022) dokumentiert.

Prefill-Phase. Das Modell nimmt den gesamten Prompt auf einmal auf. Für jede Schicht berechnet es Q, K, V für jedes Eingabe-Token und führt die Self-Attention aus. Prefill ist rechengebunden: es lastet die Matrixmultiplikationseinheiten der GPU voll aus. Die Kosten skalieren wegen der Attention-Matrix mit O(N²) in der Prompt-Länge.

Decode-Phase. Das Modell erzeugt autoregressiv jeweils ein Ausgabe-Token. In Schritt t wird nur das Q des neuen Tokens berechnet; es beachtet die K/V aller vorherigen Token. Decode ist speicherbandbreitengebunden — die meiste Zeit wird mit dem Lesen von K/V aus dem GPU-Speicher verbracht, nicht mit Multiplizieren. Die Kosten skalieren mit O(N) pro Token (linear in der aktuellen Kontextlänge).

Bei einer typischen Chatbot-Last (8K-Token-System-Prompt + 100-Token-Nutzeranfrage + 300-Token-Antwort) dominiert Prefill die Wanduhrzeit und die Dollarkosten im Verhältnis von etwa 4:1. Genau das spart das Caching ein.

Aufschlüsselung pro Aufruf (8K-Prompt, 300 Ausgabe-Token, Modell der Claude-Klasse):

  ████████████████████████████████░░░░░░░░  Prefill: ~80 % der Rechenleistung
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20 % der Rechenleistung

1.3 Der KV-Cache: Prefill-Arbeit für das Decode aufbewahren

Der „KV-Cache” bezeichnete ursprünglich eine Optimierung innerhalb einer Anfrage. Während des Decodings muss jedes neu erzeugte Token die K und V jedes vorherigen Tokens beachten. Diese bei jedem Schritt neu zu berechnen würde ein O(N)-Decode in ein O(N²)-Decode verwandeln. Daher speichert jede Inferenz-Engine die K und V aus dem Prefill im GPU-Speicher und verwendet sie für die gesamte Decode-Phase wieder. Das ist universell — jedes kommerzielle LLM tut es. Es ist das, was die Generierung überhaupt erst handhabbar macht.

Was Anbieter als „Prompt-Caching” anbieten, ist die nächste Verallgemeinerung: den KV-Cache nach dem Ende der Anfrage behalten und für die nächste Anfrage wiederverwenden, die dasselbe Präfix teilt.

1.4 Der Speicher-Rechen-Kompromiss (warum TTLs existieren)

Warum also speichert nicht jeder Anbieter einfach alles für immer zwischen? Weil der KV-Cache enorm ist.

Für ein Modell mit L Transformer-Schichten, H Attention-Köpfen, D Kopf-Dimension und B Bytes pro Wert (typischerweise 2 bei fp16) ist die KV-Cache-Größe für N Token:

KV-Cache-Größe  =  2 × L × H × D × B × N
                   ↑   ↑   ↑   ↑   ↑   ↑
                  K&V Schichten Köpfe Kopf Bytes Token

Für ein Modell der 70B-Klasse mit 80 Schichten, 8 KV-Köpfen (nach Grouped-Query-Attention), 128 Kopf-Dimension und fp16-Gewichten sind das rund 320 KB pro Token. Ein 32K-Token-Kontext = ~10 GB KV-Cache, nur für eine einzige Anfrage. Eine moderne H100-GPU hat 80 GB; davon passen höchstens eine Handvoll gleichzeitig hinein.

Das ist die zentrale Einschränkung, die PagedAttention (Kwon et al., 2023, das Paper hinter vLLM) auf Batch-Ebene zu lösen entworfen wurde — und dieselbe Einschränkung begrenzt das Prompt-Caching auf der anfrageübergreifenden Ebene:

Die Cache-TTL eines Anbieters ist also im Wesentlichen eine Speicher-Verdrängungsrichtlinie: irgendwann benötigt die GPU diesen Speicher für die aktiven Lasten anderer Nutzer, und das zwischengespeicherte Präfix wird verdrängt. 5 Minuten für HBM-resistente Caches; bis zu 1 Stunde für in den DRAM ausgelagerte Caches; Stunden für plattengestützte Caches.

DeepSeeks Trick. DeepSeek-V2 führte Multi-head Latent Attention (MLA) ein, die den KV-Cache im Vergleich zur Standard-Grouped-Query-Attention um rund 4× komprimiert (DeepSeek-AI, 2024). Genau diese Kompression erlaubt es ihnen, den KV-Cache auf Festplatte statt im HBM zu persistieren — was wiederum eine viel kleinere minimale Cache-Einheit ermöglicht (64 Token gegenüber 1.024 bei HBM-resistenten Caches) und viel längere effektive TTLs.

Das ist auch der Grund, warum anfrageübergreifendes Caching Token für Token identische Präfixe erfordert. Der Cache wird über einen Hash der Token-IDs indiziert, und jede Abweichung — und sei es nur ein Zeichen, das anders tokenisiert wird — erzeugt von diesem Punkt an ein anderes K und V. Auf dieser Schicht gibt es kein „unscharfes Matching” (das macht das semantische Caching, aber das ist ein anderer Mechanismus im Gateway).

1.5 Zwei Schichten des Cachings

┌──────────────────────────────────────────────────────────────┐
│  Schicht 1: KV-Cache pro Anfrage (immer aktiv, jeder Anbieter)│
│  → hält das Decode bei O(N) statt O(N²)                     │
│  → Sie kümmern sich nicht darum; der Anbieter tut es einfach │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Schicht 2: anfrageübergreifender Prompt-Cache (der Geld-    │
│           und Zeitsparer, um den es in dieser Serie geht)     │
│  → verwendet Prefill-K/V über Anfragen mit passenden Präfixen wieder │
│  → angeboten als: explizit / vollautomatisch / hybrid        │
│  → begrenzt durch TTL (durch Speicher-Verdrängung getrieben) │
└──────────────────────────────────────────────────────────────┘

Der Rest der Serie — und das meiste, was Sie als Entwickler einstellen werden — lebt in Schicht 2.

2. Die zwei Gewinne: Kosten UND Latenz

Die meisten Artikel rahmen das Caching als Kostenoptimierung. Das verkauft es unter Wert. Der Latenzgewinn ist oft der größere Grund, warum Produktionsteams das Caching einführen, insbesondere für nutzerseitigen Chat.

2.1 Die Kostenrechnung

Preisseiten geben die Schlagzeilenzahlen an, zeigen sie aber selten auf eine realistische Last angewendet. Nehmen Sie einen Kundensupport-Bot mit einem 8.000-Token-System-Prompt, 100K Anfragen/Tag, 200-Token-Nutzernachrichten. Auf claude-sonnet-4-5 mit Anthropics veröffentlichten 2026er-Tarifen bepreist (10 % zwischengespeicherte Eingabe, 125 % Cache-Schreibaufschlag):

Ohne Caching

• Eingabe pro Aufruf: 8.200 Token × Basis-Eingabetarif
• Kosten pro Aufruf (gemessen, Einzelaufruf): ~0,022 $
• Monatskosten: 100K × 30 × 0,022 $ = ~66.000 $

Mit Prompt-Caching

• Einmaliges Cache-Schreiben: 8.000 Token × 125 % Aufschlag (vernachlässigbar gegenüber dem Monatsvolumen)
• Danach pro Aufruf: 8.000 Token × 10 % Basis + 200 Token × Basis + Ausgabe
• Effektive Kosten pro Aufruf: ~0,003 $
• Monatskosten: ~9.000 $

~86 % gespart. Diese Zahl ist Anthropics veröffentlichter Rabatt, angewendet auf eine realistische Eingabeform. Der folgende Artikel (Teil 3 — Tutorial) zeigt echte gemessene Zahlen für die übrigen Anbieter.

2.2 Der Latenzgewinn (oft die wichtigere Geschichte)

Prefill ist nicht nur teuer — es ist der größte einzelne Beitrag zur Zeit bis zum ersten Token für jeden Prompt, der länger als ein paar Hundert Token ist. Cache-Treffer lassen Sie fast den gesamten Prefill überspringen.

Gemessenes Streaming-TTFT am öffentlichen Synthorai-Gateway, 2026-05-25, ~7.300-Token stabiler System-Prompt:

Einzellauf, Einzelmandant. Der TTFT-Gewinn ist bei langen Prompts (>5K Token) am sichtbarsten; bei kurzen Prompts ist der Prefill-Anteil zu klein, um die Latenz zu dominieren. Claudes größter gemessener Gewinn sind die Kosten (~88–89 % Reduktion bei der Eingabe im Cache-Lesevorgang) — bei Prompt-Größen im Bereich von 100K+ summiert sich der TTFT-Gewinn gemäß Anthropics veröffentlichten Zahlen erheblich.

Für Chat-Oberflächen liegt die Schwelle, ab der Nutzer eine Verzögerung bewusst wahrnehmen, bei etwa 1 s für das TTFT und ~2 s für den ersten brauchbaren Text. Ein 10K-Token-RAG-Prompt ohne Caching liegt deutlich über dieser Linie. Mit Caching fühlt sich dieselbe Last sofort an.

Bei Agenten-Schleifen mit 15+ Schritten ist die Kostengeschichte gut (50 % gespart), aber die Latenzgeschichte macht das Produkt überhaupt erst auslieferbar: 15 Schritte × 5 s Prefill = 75 s Totzeit pro Aufgabe → mit Caching 15 × 0,5 s = 7,5 s.

2.3 Warum das für die Produktstrategie wichtig ist

Ein häufiger Fehler ist, das Caching als „Ops betreibt Kostenoptimierung” zu behandeln — etwas, das man nach dem Start aufschraubt. Doch der Latenzgewinn bedeutet, dass das Caching auch Teil der UX-Oberfläche ist:

• Ein Chatbot mit einem TTFT unter 1 s fühlt sich lebendig an; derselbe Bot bei 3 s fühlt sich kaputt an.
• Ein RAG-Produkt, bei dem Retrieval+Prefill 4 s dauert, verliert gegen dasselbe Produkt, bei dem es 1 s dauert.
• Ein Agent, der eine Aufgabe in 20 s erledigt, gewinnt gegen einen, der 90 s braucht.

Sie sollten Ihre Cache-Strategie zur gleichen Zeit festlegen, in der Sie Ihr Modell und Ihre Prompt-Struktur festlegen — nicht drei Sprints nach dem Start.

3. Cache-Aktualität, TTL und das Betriebsmodell

Die TTL-Frage ist einer der am häufigsten gestellten und am wenigsten erklärten Teile des Prompt-Cachings. Zwei Dinge sind zu verstehen:

3.1 Aktualität hat zwei Bedeutungen — verwechseln Sie sie nicht

Cache-Aktualität ≠ Antwort-Aktualität. Zwei verschiedene Konzepte werden oft vermengt:

Mit anderen Worten: zwischengespeicherte Antworten sind in keinem modellqualitätsbezogenen Sinne „veraltet”. Sie sind mathematisch identisch mit nicht zwischengespeicherten. Aber wenn Sie „die aktuelle Zeit ist 14:32:05” in Ihren System-Prompt schreiben und sich auf Cache-Treffer verlassen, bleibt Ihre „aktuelle Zeit” bis zum TTL-Ablauf bei 14:32:05 und Ihr Modell wird Ihre Nutzer selbstbewusst darüber belügen.

3.2 TTL-Verhalten über Anbieter hinweg

Der 5-Minuten-Standard ist nicht willkürlich — er entspricht ungefähr dem GPU-Speicherdruck-Horizont beliebter Modelle bei Spitzenlast. Wie in §1.4 berechnet, kann der KV-Cache eines großen Kontexts zig GB betragen; Anbieter können es sich nicht leisten, sie unbegrenzt zu halten.

3.3 Entwurf im Hinblick auf die TTL

Drei Muster, die in der Produktion funktionieren:

Muster A — Sitzungen warm halten. Beim Chat hält die natürliche Anfragekadenz (Sekunden bis Minuten zwischen den Zügen) den Cache von selbst am Leben. Machen Sie sich keine Sorgen um die TTL; bringen Sie nur keine dynamischen Daten in das Präfix.

Muster B — Heartbeat für Batch. Bei Batch-Jobs, die sich über Stunden erstrecken, senden Sie alle TTL/2 eine minimale Anfrage, um den Cache warm zu halten. Die Kosten sind praktisch null (ein paar Eingabe-Token) und verhindern Cache-Verdrängungsstürme.

Muster C — Anbieter mit langer TTL für Kaltspeicherung nutzen. Wenn Sie ein 50K-Token-Dokument haben, das sporadisch abgefragt wird (z. B. einmal pro Stunde über eine Woche), übertreffen explizite Gemini-Caches (24-Stunden-TTL) oder DeepSeek-Plattencaches die Alternativen mit kurzer TTL trotz der Speichergebühr.

4. Universelle Prinzipien, die jeder Entwickler kennen sollte

Anbieter bieten Caching in fünf sehr unterschiedlichen Formen an — explizite Marker, vollautomatisch, hybrid, architektonische Plattenspeicherung oder gar keine. Wir widmen den nächsten Artikel diesem Vergleich (Teil 2 — Anbietervergleich & Bewertung). Doch vier Prinzipien gelten unabhängig vom Anbieter und folgen direkt aus der Architektur, die wir gerade durchgegangen sind:

4.1 Caching ist präfixbasiert — die Reihenfolge zählt

Da K/V an Position i von den Token an den Positionen 1…i abhängen, können Anbieter nur ein zusammenhängendes Präfix ab Token 0 abgleichen. Ändern Sie ein einziges Zeichen an Position 0, und das gesamte Präfix wird ungültig. Stabiler Inhalt zuerst, flüchtiger Inhalt zuletzt. Das ist keine Heuristik — es ist eine direkte Folge der kausalen Struktur der Self-Attention (§1.1).

4.2 Der Cache speichert K/V, keine Antworten

Ein Cache-Treffer liefert keine zuvor generierte Antwort zurück — er liefert zuvor berechnete K- und V-Vektoren zurück, die das Modell dann verwendet, um eine frische Antwort auf die aktuelle Frage zu generieren. Das bedeutet:

• Die Ausgabequalität ist identisch mit einem nicht zwischengespeicherten Aufruf (§1.1).
• Die Ausgabe ist auf die üblichen Weisen nicht deterministisch — Temperatur, Top-p usw. gelten weiterhin.
• Zwischengespeicherte Antworten sind im modellqualitätsbezogenen Sinne nie „veraltet” — nur der Inhalt Ihres Prompts (Zeitstempel, Preise) kann veraltet sein. Siehe erneut §3.1.

4.3 Cache-Schreibvorgänge sind Investitionen, nicht kostenlos

Bei Anbietern, die einen Schreibaufschlag berechnen (Anthropic 125 %, Gemini explizit 125 %), kostet der erste Aufruf mit einem neuen Präfix mehr als gar kein Caching. Der Break-even ist schnell erreicht (meist ein Treffer), aber wenn sich Ihr „stabiles” Präfix bei jeder Anfrage ändert, zahlen Sie immer wieder Schreibkosten ohne Gegenwert. Achten Sie darauf, wenn Sie abgerufene Dokumente nach Relevanz sortieren — das ist das klassische Anti-Muster.

4.4 Caching-APIs lassen sich nicht zwischen Anbietern übertragen

cache_control (Anthropic) ≠ cached_content (Gemini) ≠ cache_id (Qwen). Wenn Ihre Anwendung mit mehreren Anbietern laufen muss, pflegen Sie entweder drei Integrationen oder Sie setzen ein Token Gateway davor, um sie zu vereinheitlichen. Teil 2 behandelt dies im Detail.

5. Ist Prompt-Caching geschenktes Geld?

Fast. Es zahlt sich aus, wenn:

• Ihre Prompts ein stabiles Präfix haben — System-Prompt, Wissensdatenbank, Werkzeugschemata
• Ihre Aufrufe häufig oder verbunden sind — dieselbe Sitzung, Batch-Lasten, laufende Agenten-Durchläufe
• Sie Prompts so strukturieren können, dass der stabile Inhalt am Anfang sitzt

Treffen Sie diese drei Punkte, werden Sie typischerweise 50–90 % geringere Ausgaben und ein 3–20× schnelleres TTFT sehen, ohne das Modell zu wechseln.

Als Nächstes: Teil 2 — Anbieter-Caching-Vergleich & Bewertungsrahmen nimmt das obige architektonische Bild und verwandelt es in einen funktionsweisen Vergleich von Claude, OpenAI, Gemini, DeepSeek und Qwen, mit einem Bewertungsraster für die Auswahl des richtigen Anbieters für Ihre Last.

Schnellstart: das OpenAI-SDK mit jedem Anbieter nutzen

Synthorai bietet einen OpenAI-kompatiblen Endpunkt — richten Sie das offizielle openai-SDK darauf aus, und jedes Modell (Claude, GPT, Gemini, DeepSeek, Qwen) wird zu einem einzeiligen Modellwechsel. Das Gateway übersetzt cache_control in die native Caching-Syntax jedes Anbieters.

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 für gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash, qwen3-max — nur das Feld model ändert sich. Das Gateway gibt die Prompt-Cache-Treffer-Metadaten im standardmäßigen OpenAI-Feld prompt_tokens_details.cached_tokens zurück, plus ein cost-Feld in USD, sodass Sie lokal keine anbieterspezifische Preismatrix pflegen müssen.

FAQ

Ist LLM-Prompt-Caching dasselbe wie semantisches Caching? Nein. Prompt-Caching ist präfixbasiert — es verwendet K/V-Werte für eine exakte Übereinstimmung auf Token-Ebene am Anfang des Prompts wieder. Semantisches Caching gleicht auf der Bedeutungs-Ebene ab (über Embeddings) und gibt eine frühere Antwort zurück. Beide sind nützlich, und ein gutes Token Gateway kombiniert sie in Schichten.

Ändert Prompt-Caching die Ausgabe des Modells? Nein. K und V sind deterministische Funktionen der Eingabe-Token (§1.1). Die Logits, die das Modell aus einem zwischengespeicherten K/V erzeugt, sind mathematisch identisch mit denen aus einem frisch neu berechneten K/V. Caching ist eine reine Effizienzoptimierung ohne Qualitätseinfluss.

Warum ist die Cache-TTL so kurz — können sie ihn nicht einfach für immer behalten? Der KV-Cache ist enorm (§1.4: ~10 GB pro 32K-Kontext für ein 70B-Modell). Der GPU-Speicher ist der Engpass; Caches werden verdrängt, sobald der Server diesen Speicher für aktive Lasten benötigt. Plattengestützte Caches (DeepSeek) können Stunden leben, aber In-Memory-Caches können das in der Regel nicht.

Was ist der Unterschied zwischen KV-Cache und Prompt-Cache? Der KV-Cache ist die In-Memory-Datenstruktur, die während der Inferenz verwendet wird. Der „Prompt-Cache” ist die anfrageübergreifende Wiederverwendung dieses KV-Caches. Schicht 1 versus Schicht 2 in §1.5 oben.

Werden zwischengespeicherte Prompts jemals auf qualitätsmindernde Weise veraltet? Nein, aus Sicht des Modells. Ja, aus Sicht Ihres Inhalts, wenn Ihr Prompt zeitkritische Informationen kodiert. Der Cache speichert K/V-Vektoren, keine Fakten über die Welt. Siehe §3.1.

Wie messe ich die Cache-Trefferquote? Jeder Anbieter gibt sie im Usage-Objekt der Antwort zurück — cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini), prompt_cache_hit_tokens (DeepSeek). Verfolgen Sie diese in Ihrer Logging-Pipeline.

Referenzen & 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 architecture · Anthropic Prompt Caching docs · OpenAI Prompt Caching docs · Google Gemini Context Caching docs · DeepSeek KV Cache guide · Alibaba Bailian Context Cache

← Zurück zum Blog