KV-Cache
Stand
Was ist KV-Cache?
Der KV-Cache, nicht die Modellgewichte, ist die bindende VRAM-Beschränkung bei der LLM-Inferenz — ein Kontext von 8.000 Token bei einem 70B-Modell verbraucht bereits rund 42 GB, sodass eine Verdopplung der Kontextlänge die Hardwarekosten annähernd verdoppelt.
Der KV-Cache — Key-Value-Cache — ist die Speicherstruktur, die schnelle, erschwingliche Inferenz großer Sprachmodelle überhaupt erst möglich macht, und er steht direkt hinter Kosten- und Latenzentscheidungen für jedes SAP-Joule- oder AI-Foundation-Deployment, das bei echtem Nutzervolumen läuft. Ihn zu verstehen unterscheidet einen Architekten, der erklären kann, warum ein längeres Kontextfenster teuer ist, von einem, der nur auf eine Rechnung zeigen kann.
Was es ist und warum es wichtig ist
Wenn ein Transformer-Modell eine Antwort Token für Token generiert, muss jedes neue Token allen vorangegangenen Token „Aufmerksamkeit schenken“ — der gesamten bisherigen Konversation, einschließlich des System-Prompts und jedes abgerufenen Grounding-Inhalts. Die Key- und Value-Projektionen für diese gesamte Historie bei jedem einzelnen Schritt neu zu berechnen, würde die Generierung mit jedem Token langsamer machen — ein Effekt, der sich bei langen, mit SAP-Kontext vollgestopften Enterprise-Prompts stark aufsummiert. Der KV-Cache vermeidet das: Er speichert die Key- und Value-Projektionen für jedes Token in dem Moment, in dem sie erstmals berechnet werden, sodass die Generierung von Token Nummer eintausend nur die Verarbeitung dieses einen neuen Tokens erfordert, nicht die Neuberechnung der vorangegangenen neunhundertneunundneunzig. Das ist der einzige Mechanismus, der chat-artige, mehrstufige Generierung überhaupt praktikabel macht.
Warum es zählt
- Ohne Caching würde die Generierung von Token N eine O(N²)-Neuberechnungsexplosion erfordern — der Cache ist das, was autoregressive Generierung im Enterprise-Maßstab überhaupt erst machbar macht.
- Prefix-/Prompt-Caching ist direkt relevant für Joule: Sitzungen, denen derselbe Enterprise-Kontextblock vorangestellt ist, können zwischengespeicherte KV-Projektionen wiederverwenden, statt sie bei jedem Aufruf neu zu berechnen.
- Die konkrete Speicherformel (2 × L × H × d × Bytes) erlaubt es einem Architekten, Hardware zu dimensionieren (einzelnes A100-80GB vs. Multi-GPU-Pod), bevor er sich auf eine Kontextlängen-Anforderung festlegt.
Kernpunkte
- KV-Cache-Speicher = 2 × n_layers × n_kv_heads × d_head × seq_len × batch × dtype_bytes.
- PagedAttention (vLLM) hebt die GPU-Auslastung von ~40 % auf ~90 %, indem es den KV-Cache virtualisiert.
- Prefix-Caching (RadixAttention) verwendet KV-Repräsentationen gemeinsamer Prompt-Präfixe über Aufrufe hinweg wieder — entscheidend für SAP-Joule-System-Prompts.
- INT8-KV-Quantisierung halbiert den Cache-Speicher bei ~1 % Qualitätsverlust, wenn tokenweise dynamische Quantisierung angewendet wird.
- H2O-Eviction reduziert den Cache bei langen Generierungsaufgaben um das 20-Fache, bei <5 % Qualitätsverlust, indem nur Token mit hoher Attention behalten werden.
- Auf einem verwalteten Generative-AI-Hub-Endpunkt ist der KV-Cache selbst für den Kunden unsichtbar — der einzige offengelegte Hebel ist Prompt-/Prefix-Caching (implizit für OpenAI und Gemini, explizite cache_control-Breakpoints für Anthropic Claude und Amazon Nova via Orchestrierung v2); ein selbstgehostetes BYOM-Deployment auf SAP AI Core (SAPs eigenes Beispiel-Repo dokumentiert vLLM, llama.cpp, Ollama und LocalAI) legt dagegen die volle PagedAttention- und Quantisierungs-Palette offen.
- Die Cache-Größe ist zuerst eine harte Kapazitätsgrenze, dann erst eine Kostenkurve: Die Parallelität ist gedeckelt, sobald die Summe der aktiven KV-Caches den GPU-Speicher übersteigt, unabhängig davon, wie viel Rechenleistung noch frei ist — deshalb kann ein Joule-artiges Deployment „langsam“ wirken, während Auslastungsgrafiken noch Spielraum zeigen.
- GQA-basierte Modelle (Llama 3, Mistral) verkleinern den KV-Cache um das 4- bis 8-Fache gegenüber klassischer Multi-Head-Attention bei nahezu keinem Qualitätsverlust — eine Architekturentscheidung im Modell selbst, keine Laufzeitoptimierung, weshalb zwei ähnlich große Modelle nicht automatisch gleich teuer im Betrieb bei langem Kontext sind.
Begriffe auf dieser Seite
- KV-Cache
- Speicherpuffer, der Key- und Value-Matrizen für alle vergangenen Token speichert; ermöglicht Generierungskosten von O(seq_len) pro Schritt statt vollständiger O(seq_len²)-Neuberechnung.
- PagedAttention
- Von virtuellem Speicher inspirierte KV-Cache-Allokation (Kwon 2023, vLLM), die den Cache in nicht-zusammenhängenden Seiten speichert, Fragmentierung eliminiert und die GPU-Auslastung erhöht.
- Prefix-Caching
- Mechanismus (RadixAttention, Zheng 2023), der KV-Repräsentationen gemeinsamer Prompt-Präfixe indiziert, sodass wiederholte Aufrufe die zwischengespeicherte Berechnung wiederverwenden.
- H2O
- Heavy Hitter Oracle (Zhang 2023): KV-Cache-Eviction-Policy, die die Token mit der höchsten kumulierten Attention-Masse behält und die Cache-Größe um das 20-Fache reduziert, bei <5 % Qualitätsverlust.
- INT8-KV-Quantisierung
- Komprimierung von KV-Cache-Einträgen von BF16 (2 Byte) auf INT8 (1 Byte), was den Speicher halbiert, bei ~1 % Qualitätsverlust, sofern tokenweise dynamische Skalen beibehalten werden.
- Entscheidungs-Owner
- Die verantwortliche Person, die den Kompromiss akzeptiert und die nächste Aktion finanziert.
Quellen
- Kwon et al. 2023 — Efficient Memory Management for LLM Serving with PagedAttention (vLLM)
- Zheng et al. 2023 — Efficiently Programming Large Language Models using SGLang (RadixAttention)
- Zhang et al. 2023 — H2O: Heavy-Hitter Oracle for Efficient Generative Inference
- Shazeer 2019 — Fast Transformer Decoding: One Write-Head is All You Need
- NVIDIA H100 SXM Datasheet
- OpenAI prompt caching documentation
- Anthropic prompt caching documentation
- vLLM documentation — PagedAttention and prefix caching
- GitHub SAP-samples — btp-generative-ai-hub-use-cases: bring-your-own OSS LLM on SAP AI Core (Ollama, LocalAI, llama.cpp, vLLM, custom HF Transformers server)
- SAP News Center — How SAP and NVIDIA Advance Enterprise AI Transformation (NIM inference optimisation, SAP-ABAP-1, 2026-03-17)
- PyTorch — torch.nn.functional.scaled_dot_product_attention documentation
- SAP Help Portal — Orchestration service in SAP AI Core generative AI hub (prompt/document grounding pipeline where prefix caching sits)
Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.
Offene SAP-Projekte
Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.