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:
**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)
- 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](https://arxiv.org/abs/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
