114 lines
6.5 KiB
Markdown
114 lines
6.5 KiB
Markdown
---
|
||
created: 2026-07-07
|
||
updated: 2026-09-23
|
||
sources:
|
||
- blog/2026-07-07_heise-prompt-caching.md
|
||
- other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md
|
||
tags: [concept, prompt-caching, kv-cache, transformer-architecture, token-optimization, cost-reduction, llm-inference, prompt-engineering, cache, security, side-channel, privacy]
|
||
---
|
||
|
||
# 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](https://docs.anthropic.com/en/docs/build-with-claude/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](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
|