6.5 KiB
| created | updated | sources | tags | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-07-07 | 2026-09-23 |
|
|
Prompt-Caching — KV-Cache-Wiederverwendung zur Token- und Kostenreduktion
Stand: 2026-07-07. Quelle: heise+ Ratgeber-Artikel. Siehe raw:
[[../../raw/blog/2026-07-07_heise-prompt-caching.md]]
Grundprinzip
Prompt-Caching speichert die internen Berechnungsergebnisse eines gleichbleibenden Prompt-Präfixes zwischen. Bei Folgeanfragen muss das LLM nur noch den abweichenden Suffix verarbeiten. Das senkt sowohl Latenz als auch Token-Kosten.
Technische Grundlage: KV-Cache
Die Basis ist der KV-Cache der Transformer-Architektur:
- Während der Prefill-Phase berechnet der Transformer für jedes Token Key- und Value-Vektoren (Self-Attention)
- Diese Vektoren werden im KV-Cache gespeichert
- Bei der nächsten Anfrage mit identischem Präfix werden die gecachten Vektoren wiederverwendet, statt neu berechnet
- Nur die neuen Tokens des Suffix durchlaufen die volle Prefill-Berechnung
Prompt-Struktur ist entscheidend
Damit Prompt-Caching wirkt, muss der Prompt korrekt strukturiert sein:
| Position | Inhalt | Cache-Verhalten |
|---|---|---|
| Anfang (Präfix) | Systemanweisungen, Dokumente, Tooldefinitionen, Gesprächsverlauf | ✅ Wird gecached |
| Ende (Suffix) | Aktuelle Benutzerfrage, variable Parameter | 🔄 Neu berechnet |
Ein falscher Aufbau (z. B. variable Daten am Anfang) macht das Caching unwirksam.
Performance-Gewinne
| Szenario | Verbesserung |
|---|---|
| Lokal (Ollama, LM Studio) | Bis zu 10× schnellere Inferenz |
| Cloud (Anthropic, OpenAI) | Bis zu 90 % Kostenreduktion |
Was ist kein Prompt-Caching?
Prompt-Caching ist nicht:
- Context-Window-Effizienz (das Reduzieren der Prompt-Länge durch bessere Formulierung)
- Model-Routing (Auswahl des günstigsten Modells für einen Task)
- Semantisches Caching (ähnliche Queries erkennen und gecachte Antworten ausliefern)
- Batch-Processing (mehrere Prompts parallel verarbeiten)
Verbindung zu bestehendem Wiki
Komplementär zu Model-Routing
Prompt-Caching und Model-Routing sind komplementäre Kostenspar-Strategien auf verschiedenen Ebenen:
| Strategie | Wiki-Seite | Ebene | Hebel |
|---|---|---|---|
| Model-Routing | [[../tools/model-routing.md]] |
Modellauswahl | Task → günstigstes passendes Modell |
| Prompt-Caching | (diese Seite) | Token-Berechnung | Stabile Präfixe cachen → weniger Rechenaufwand |
Kombination: Ein über Model-Routing an GLM 5.2 gerouteter Code-Execution-Task profitiert zusätzlich von einem gecachten System-Prompt-Präfix. Besonders wirksam bei:
- Batch-Verarbeitung (gleicher System-Prompt, viele Varianten)
- Agenten-Loops (stabiler Instructions-Präfix, variierende Queries)
- RAG-Pipelines (Kontext-Dokumente am Anfang, Query am Ende)
KV-Cache in der Transformer-Architektur
Siehe auch [[../architecture/transformer-foundation.md]] für die klassische Transformer-Architektur, auf der der KV-Cache basiert.
Kostenspar-Patterns im OpenClaw-Stack
[[../tools/model-routing.md]]— Routing-Patterns für 90% Kosteneinsparung[[../concepts/llm/chinese-model-cost-routing.md]]— DeRonin's 87% Cost-Cut-Playbook[[../concepts/llm/glm-5.2-zai-coding-model.md]]— GLM 5.2 als günstige Execution-Ebene[[../architecture/model-routing.md]]— OpenClaw's Two-Model-Pipeline
Cloud-Anbieter mit Prompt-Caching
- Anthropic Claude — Dokumentiertes Prompt Caching, Cache-Read-Tokens werden günstiger abgerechnet
- OpenAI — Automatisches Caching langer Kontexte
- Google Gemini — Kontext-Caching über API
Lokale Implementierung
Mit Ollama lässt sich Prompt-Caching lokal nachvollziehen:
- Ollama cacht KV-Cache automatisch bei wiederholten Prefixes
- Der Geschwindigkeitsgewinn (bis 10×) ist direkt messbar
- Erkenntnisse sind auf Cloud-Anbieter übertragbar
Sicherheit: Prompt-Caching als Seitenkanal (Update 2026-09-23)
Prompt-Caching ist ein Kostenhebel — und zugleich ein dokumentierter Informationsleck-Vektor. Zwei peer-reviewte Arbeiten (beide 2025) zeigen, dass Cache-Treffer über Timing beobachtbar sind:
| Arbeit | Methode | Kernbefund |
|---|---|---|
| Gu et al., ICML 2025 (arXiv:2502.07776, Stanford) | Statistischer Timing-Audit (Kolmogorov-Smirnov) auf Time-to-First-Token, 17 kommerzielle APIs | Prompt-Caching bei 8 Providern nachgewiesen, globales Cache-Sharing über Nutzergrenzen bei 7 — u.a. OpenAI (text-embedding-3-small), Azure, Deep Infra, Fireworks, Lepton, Perplexity, Replicate. Bei Anthropic (Claude 3 Haiku) und OpenAI (GPT-4o mini) nur per-org. Nach Offenlegung änderten mindestens 5 Provider ihre Implementierung. |
| Wu et al., NDSS 2025 („PROMPTPEEK", SUSTech/ByteDance) | Aktiver Angriff auf KV-Cache-Sharing in Multi-Tenant-Serving (SGLang, vLLM) | Prompt Token für Token rekonstruierbar: 99 % (Input), 98 % (Template), 95 % ohne Vorwissen. PII-Nachweis: alle Platzhalter eines BMI-Prompts (Geschlecht, Alter, Gewicht, Größe) mit 60 Requests. |
Was das praktisch bedeutet:
- Der Risikofaktor ist Cache-Sharing über Nutzergrenzen. Per-User- oder per-Org-Isolation entschärft den Angriff; globales Sharing ist der problematische Fall.
- Betroffen sind Multi-Tenant-Dienste, nicht die lokale Ausführung — wer lokal fährt, teilt keinen Cache (hardware/cloud-exit-and-local-superiority.md).
- Für Cloud-Nutzung gilt: Was nicht im Cache eines Fremden landen soll, gehört nicht in einen geteilten Präfix — oder nicht in einen geteilten Dienst.
- DeepSeek wurde im Stanford-Audit als per-user isoliert bestätigt (allerdings über gemeldete Cache-Hit-Zähler, nicht per Timing).
Details, Zitate und Verifikationsprotokoll: policy/inference-provider-data-retention.md.
Verwandte Seiten
- policy/inference-provider-data-retention.md — Datenhaltung und Cache-Isolation bei Cloud-Anbietern (Ollama-Zusagen, Seitenkanäle, Verifikation)
- ../tools/model-routing.md — Routing als komplementärer Kostenhebel