KV-Cache-Glossar: jeder Begriff des Serving-Stacks

Der KV-Cache ist ein wichtiger Faktor für Kapazität und Latenz beim LLM-Serving. Dieses Glossar erklärt gebräuchliche Cache- und Scheduling-Begriffe mit Rechenbeispielen. Die Zahlen beruhen auf den genannten Modellkonfigurationen und Annahmen aus dem KV-Cache-Deep-Dive, dem Agenten-KV-Tiering-Guide, der HBM4-Ökonomie-Analyse und der UNISON-Scheduler-Analyse.

Die Begriffe

KV-Cache

Gespeicherte Attention-Key- (K) und Value- (V) Zustände, mit denen ein Decode-Schritt Projektionen früherer Tokens wiederverwendet. Der Schritt führt weiterhin Attention über relevante frühere Positionen aus. Bei konventioneller voller Attention wächst der gespeicherte Speicher näherungsweise linear mit Kontextlänge und aktiven Sequenzen. Die KV-Kapazität kann neben Gewichten, Aktivierungen, Rechenleistung und Runtime-Belegungen die Nebenläufigkeit begrenzen; hybride Architekturen speichern gegebenenfalls weitere Zustände.

Siehe: Der KV-Cache im Detail

Token

Eine Einheit der Ein- und Ausgabe-Tokenisierung des Modells. Textteile und multimodale Eingaben werden je nach Modell unterschiedlich kodiert; ein Bild-Patch muss nicht genau einem Decoder-Token entsprechen. Jede Größe dieses Glossars ist in Token denominiert — Cache-Bytes, Kontextlänge, Durchsatz —, weshalb Verwechslung von Token- und Zeichenzahlen die Kapazitätsmathematik lautlos bricht. Die Referenzzahlen hier setzen die site-üblichen KV-Byte-Kosten pro Token an (GQA-8 fp16: 262.144 B; MLA bf16: 70.272 B).

Bytes-pro-Token-Formel

Für konventionelle MHA-/MQA-/GQA-Caches mit getrennten K- und V-Tensoren: Attention-Schichten × KV-Köpfe × Kopf-Dimension × Bytes pro Wert × 2. Bei einem 32B-Klasse-GQA-Modell (64 Layer, 8 KV-Heads, 128 Head-Dim, fp16) liefert sie 256 KiB pro Token; bei 32k Kontext hält ein Nutzer damit 8,59 GB Cache. MLA und hybride Architekturen benötigen andere Formeln.

Siehe: Der KV-Cache im Detail

KV-Bytes = 2 × L × H_KV × d_head × b_dtype × s (s = Token; dieselbe Per-Token-Rechnung wie in Abschnitt 3 des PagedAttention-Papers)

Prefill

Die Phase, in der die Engine den Prompt aufnimmt: Sie verarbeitet Eingabe-Token parallel und schreibt K/V-Zustände für Attention-Schichten. Prefill trägt zur Time-to-First-Token bei; Prefix-Caching kann wiederholte Arbeit vermeiden. Die Näherung 2 × aktive Parameter × Tokens ergibt für 2.000 Tokens auf einem 37B-aktiven MoE etwa 148 TFLOP, nicht 303 TFLOP. Attention und Routing erhöhen die Arbeit; die reale Latenz hängt auch von Batch, Kernels und Speicherverkehr ab.

Siehe: Agentisches KV-Tiering

Decode

Die Phase, in der das Modell Ausgabe-Token nacheinander erzeugt. Bei einem dichten Modell und kleinem Batch können Gewichts- und KV-Lesevorgänge den Decode begrenzen. Bei 8k Kontext beträgt die ideale Bandbreiten-Untergrenze des Referenzmodells Qwen3-VL-32B auf einer H200 SXM rund 14,35 ms pro Schritt für einen Nutzer (~69,7 Tok/s Obergrenze). Sechzehn Nutzer passen nach Rohkapazität auf die H200; ein geteilter Gewichts-Lesevorgang hebt die aggregierte Bandbreiten-Obergrenze auf ~760 Tok/s. Das sind Modellgrenzen, keine gemessenen Raten.

Siehe: Der KV-Cache im Detail

MHA (Multi-Head-Attention)

Die ursprüngliche Transformer-Anordnung: Jeder Query-Head besitzt sein eigenes K/V-Paar, also entspricht die Zahl der KV-Paare pro Token der Zahl der Query-Heads. Bei sonst gleicher Kopf-Dimension und Schichtzahl benötigt sie mehr KV-Speicher als MQA oder GQA — in der Referenzkonfiguration (64 Heads, 128 Dim, 64 Layer, fp16) speichert MHA 2.097.152 B = 2 MiB pro Token, also 209,7 GB Cache pro 100k-Kontext-Session.

Siehe: HBM4-Knappheits-Ökonomie

MQA (Multi-Query-Attention)

Der aggressive Extremfall des Teilens: ein einziges K/V-Head-Set, das von allen Query-Heads geteilt wird („the different heads share a single set of keys and values", Shazeer 2019) — das schneidet den Cache in der Referenzkonfiguration um 64× auf 32 KiB (32.768 B) pro Token. Auf manchen Aufgaben leidet die Qualität, weshalb GQA als Interpolation existiert.

Siehe: Der KV-Cache im Detail

GQA (Grouped-Query-Attention)

Der mittlere Entwurf: ein geteiltes K/V-Head-Set pro kleiner Gruppe von Query-Heads. Die illustrierte Form mit 8 KV-Heads für 64 Query-Heads reduziert den Cache pro Token gegenüber einem ansonsten identischen MHA um 8× auf 262.144 B (256 KiB) bei fp16. Das GQA-Paper berichtet Qualität nahe MHA bei Geschwindigkeit nahe MQA und ein Uptraining-Rezept mit etwa 5 % des ursprünglichen Pretraining-Rechenaufwands. Das Verhältnis 3,73× zum DeepSeek-V3-MLA-Beispiel unten vergleicht zwei verschiedene Modellkonfigurationen und ist keine kontrollierte GQA-gegen-MLA-Ersparnis desselben Modells.

Siehe: HBM4-Knappheits-Ökonomie

MLA (Multi-head Latent Attention)

DeepSeeks Mechanismus: Statt K und V pro Head zu speichern, werden ein komprimierter latenter Vektor und ein entkoppelter RoPE-Key abgelegt; K/V werden während der Attention rekonstruiert. Die DeepSeek-V3-Konfiguration speichert 576 Elemente pro Token und Schicht über 61 Schichten, bf16 → 70.272 B ≈ 68,6 KiB pro Token. Das V2-Paper berichtet einen 93,3 % kleineren Cache und 5,76× höheren maximalen Generierungsdurchsatz in seinem eigenen Vergleich mit einer 67B-MHA-Baseline. Der 3,73×-Unterschied zum 256-KiB-GQA-Beispiel oben enthält auch Unterschiede bei Schichtzahl und Dimensionen.

Siehe: Der KV-Cache im Detail

PagedAttention

vLLMs Ausleihe aus dem virtuellen Speicher von Betriebssystemen: den logischen KV-Cache jeder Sequenz in Blöcke fester Größe teilen, über eine Block-Tabelle auf verstreute physische Blöcke abbilden und Block für Block on demand allozieren und freigeben. Die Messung des Papers ist das ganze Argument — Reservierungs-basierte Allokatoren nutzten nur 20,4–38,2 % des KV-Speichers für tatsächliche Token-Zustände (der Rest war Reservierungs-Schlacke und Fragmentierung), während der pagede Allokator 96,3 % erreichte.

Siehe: Der KV-Cache im Detail

Block

Die Allokationseinheit fester Granularität eines paged KV-Cache — vLLMs Default ist 16 Token. Eine 32.768-Token-Sequenz belegt 2.048 Blöcke; in der GQA-8-fp16-Referenzkonfiguration hält jeder Block 16 × 262.144 B = 4 MiB K/V. Der Sinn der Block-Granularität: Ein Request, der bei 1.000 Token endet, zahlt 63 Blöcke, nicht die 8,59 GB, die eine vollständige 32k-Reservierung festschreiben würde; der Verschnitt schrumpft auf höchstens einen teilweise gefüllten Block pro Request.

Siehe: Der KV-Cache im Detail

Block-Tabelle

Die pro Sequenz führende Abbildung von logischen Token-Positionen auf physische Block-Orte — die Page-Tabelle des KV-Cache. Sie macht den Cache nicht-kontinuierlich: Die Attention sammelt K/V-Zeilen über die Tabelle, physische Blöcke werden zwischen Sequenzen geteilt, wo sich Präfixe gleichen, und Referenzzähler entscheiden, wann ein Block tatsächlich freigegeben werden kann. Die Freigabe-Buchhaltung auf Block-Granularität ist zugleich der Haken, an dem jede Eviction-Politik (LRU, TTL, Survival-Penalty) hängt.

Radix-Baum / Präfix-Caching

Die Organisation des gesamten gecachten KV in einem Baum, keyed nach Token-Sequenz, sodass jeder neue Request automatisch das längste passende gecachte Präfix wiederverwendet — abhängig vom Präfixabgleich und der Cache-Regel der Runtime. SGLangs RadixAttention hält fertigen und laufenden KV in einem LRU-verwalteten Radix-Baum; das Papier berichtet bis zu 6,4× höheren Durchsatz auf präfix-lastigen Workloads. Beispiel: Ein geteilter Systemprompt mit 2.000 Tokens belegt ohne Wiederverwendung etwa 524 MB GQA-FP16-KV; ein passender Präfix-Cache kann gespeicherte Blöcke zwischen Anfragen teilen.

Siehe: vLLM vs. SGLang

Präfix-Cache-Hit-Rate

Der Anteil der angefragten Präfix-Token, die aus dem Cache statt aus Prefill-Rechenzeit und KV-Schreibvorgängen bedient werden. Sie ist die Metrik, die begrenzt, was Caching einbringen kann: UNISONs Scheduler-Traces umfassen Hit-Rate-Zugewinne von nur +0,3 % (keine Konkurrenz um den Pool — nichts zu holen) bis +23,1 % (die Baseline verlor ein Viertel des Pools), und SGLangs Cache-Aware-Router hob die Hit-Rate auf einem Shared-Prefix-Workload durch entsprechendes Routing von 20 % auf 75 %. Bei 0 % Hits kostet vLLMs V1-Präfix-Cache trotzdem unter 1 % Durchsatz — weshalb er standardmäßig aktiviert ausgeliefert wird.

Siehe: UNISON-Scheduler-Analyse

Batch

Die Menge der Sequenzen, deren Decode-Schritte gemeinsam in einem Forward-Pass laufen. Der Gewichtssatz eines dichten Modells wird über den Batch geteilt, während jede Sequenz ihren KV-Lesevorgang ergänzt. Für das Referenzmodell bei 8k Kontext auf H200 steigt die ideale aggregierte Bandbreiten-Obergrenze von ~69,7 Tok/s bei Batch 1 auf ~760 Tok/s bei Batch 16; die Latenz-Untergrenze pro Nutzer steigt von 14,35 auf 21,06 ms. Compute, KV-Kapazität, Laufzeitspeicher und Latenzziele begrenzen gemeinsam die sinnvolle Batchgröße.

Siehe: Der KV-Cache im Detail

Kontinuierliches Batching

Das Scheduler-Design (Orca-Linie, Standard in vLLM/SGLang/TensorRT-LLM), das neue Requests in jedem Decode-Schritt aufnimmt und beendete sofort entlässt, statt auf das Ablaufen eines ganzen statischen Batches zu warten. Bei unterschiedlich langen Anfragen kann es die Auslastung verbessern und neue Anfragen zwischen Decode-Schritten aufnehmen. Kapazitäts- und Latenzregeln steuern weiterhin die Aufnahme.

Siehe: vLLM vs. SGLang

TTFT (Time to First Token)

Die Latenz von der Ankunft der Anfrage bis zum ersten generierten Token, einschließlich Warteschlange, Prefill der nicht gecachten Tokens und erstem Decode-Schritt. Welcher Teil dominiert, hängt vom Workload ab. TTFT ist eine Metrik, die Präfix-Caching verbessern kann: Ein Hit vermeidet das Neu-Prefillen einer ganzen Historie — eine gesparte Read-and-Recompute-Operation eines ~7-GB-Präfixes (100k Token, MLA) —; UNISON berichtet TTFT-Reduktionen von 58 % bis 89 % auf Lang-Horizont-Traces, und der Grund, warum diese Ersparnisse enorm sind, ist exakt, dass der Konterfakt das Re-Prefill ist.

Siehe: UNISON-Scheduler-Analyse

TPOT (Time per Output Token)

Die Zeit zwischen generierten Tokens nach dem ersten. In einer bandbreitenbegrenzten Näherung wächst die KV-Lesezeit mit dem Kontext: Auf einer H200 SXM dauert allein das Lesen des 32k-Caches des Referenzmodells mindestens 1,79 ms pro Schritt. TPOT hängt außerdem von Attention-Compute, Batching, Cache-Wiederverwendung, Kernels und Scheduling ab und wächst nicht in jeder Architektur oder Last linear.

Siehe: Der KV-Cache im Detail

AMAT (Average Memory Access Time)

Der Speicher-Hierarchie-Mittelwert aus Hit- und Miss-Latenz, gewichtet mit der Hit-Rate — die Metrik, die Tier-Platzierung beziffert. Formal AMAT = t_hot + (1 − Hit-Rate) × t_cold_penalty: Jedes aus der Cold-Tier bediente Byte zieht den Mittelwert um die volle Tier-Lücke, die bei einem PCIe-angehängten Host-Tier gegenüber HBM3e ~76× an Bandbreite beträgt (63 GB/s vs. 4.800 GB/s) und 0,11–1,1 s an Restore-Latenz pro Runde. UNISON berichtet AMAT-Reduktionen von 22 % bis 51 % allein durch bessere Platzierung.

Siehe: Agentisches KV-Tiering

LRU-Eviction

„Least recently used": den Block zu räumen, dessen KV am längsten nicht mehr berührt wurde. Zugriffshistorie ist leicht zu erfassen; deshalb ist LRU eine häufige Baseline. Eine auf ein Tool-Ergebnis wartende Session kann alt erscheinen und wiederverwendbaren KV verlieren, obwohl sie bald fortgesetzt wird. Ob eine andere Strategie LRU übertrifft, hängt von Workload, Cache-Größe und Bewertungsmetrik ab.

Siehe: UNISON-Scheduler-Analyse

TTL-Eviction

„Time to live": KV nach einem festen Idle-Fenster ablaufen lassen. Eine kurze TTL gibt Speicher früher frei, kann aber eine Session räumen, die noch auf ein langsames Tool-Ergebnis wartet. Der Kompromiss bei Trefferrate und Latenz muss anhand der tatsächlichen Tool-Rückkehrzeiten gemessen werden.

Siehe: UNISON-Scheduler-Analyse

Bélády MIN

Die theoretisch optimale Eviction-Politik für eine bekannte künftige Zugriffsfolge: den Block räumen, dessen nächste Nutzung am weitesten in der Zukunft liegt. Sie ist eine Offline-Benchmark, keine umsetzbare Politik für unbekannte Anfragen. Der Abstand eines Schedulers zu ihr zeigt die verbleibende Lücke auf der gemessenen Zugriffsfolge; daraus allein folgt nicht, welche künftigen Ereignisse vorhersagbar wären. Gelernte „relaxed-Belady"-Strategien schätzen die künftige Wiederverwendung.

Siehe: UNISON-Scheduler-Analyse

Survival-Penalty-Eviction

UNISONs SPEAR-Vorschlag passt eine Survival-Funktion an frühere Tool-Rückkehrzeiten an und benachteiligt die Räumung von Sessions, deren baldige Rückkehr wahrscheinlich erscheint. Frühere Rückkehrzeiten liefern eine Schätzung, keine Garantie. Die Regel ist als Software umsetzbar; ihre Integration in eine konkrete Serving-Engine müsste dennoch implementiert und geprüft werden.

Siehe: UNISON-Scheduler-Analyse

KV-Tiering

Den Cache über eine Hierarchie zu verteilen — HBM-Hot-Tier, Host-DRAM/CXL/Remote-Cold-Pool —, sodass Sessions, die nicht ins VRAM passen, irgendwo günstiger resident bleiben, statt verworfen zu werden. Es wandelt Kapazität in ein Latenzproblem: Re-Reads aus einem PCIe-5.0-x16-Host-Tier mit ~63 GB/s kosten 0,112 s pro 100k-Token-MLA-Runde und 1,12 s pro 1M-Restore, gegenüber 1,46 ms bei HBM3e-Tempo. TensorRT-LLMs „KV Cache Manager V2" (HBM-Hot-Pool plus Cold-Pool mit Quotas pro Layer-Gruppe und Cold-Page-Codecs) ist die Produktform; entscheidend ist die Platzierungspolitik, nicht die Tier-Kapazität.

Siehe: Agentisches KV-Tiering

Swap vs. Recompute

Die beiden Möglichkeiten, einen Cache-Miss in einem tiered System zu bedienen: Swap stellt die geräumten KV-Bytes über das Fabric wieder her (man zahlt Bandbreite und die Latenz des Tiers), Recompute führt den Prefill über die betroffenen Token erneut aus (man zahlt FLOPs und das erneute Lesen der Quell-Tokens). Bei langen Präfixen kann Swap günstiger sein als erneute Berechnung, bei kurzen Präfixen auch umgekehrt. Entscheidend sind Bandbreite und Latenz der Übertragung, verfügbare Rechenleistung, Cache-Format und Präfixlänge. Diese Wahl setzt den AMAT-Preis jeder Räumung fest.

Siehe: UNISON-Scheduler-Analyse

Burst-Buffer

Das Muster aus dem HPC, das inzwischen im LLM-Serving auftaucht: eine schnelle Zwischen-Puffer-Schicht, die Lastspitzen zwischen Quellen und Abnehmern auffängt — im Agenten-Serving ein Storage-/Decode-DMA-Pfad, der geräumten KV ohne Umweg über die Prefill-Seite mit den Decode-GPUs wieder vereint. DualPath (arXiv:2602.21548) ist die KV-Ausprägung dieses Musters: Es fügt einen Storage-to-Decode-Pfad per RDMA über das Compute-Netzwerk hinzu und berichtet bis zu 1,87× offline und 1,96× online Durchsatz gegenüber der hauseigenen Baseline — durch genau diese Entkopplung.

Siehe: Agentisches KV-Tiering

Idle-Window-Migration

Die eigene Wartezeit einer Session als DMA-Budget nutzen: Während ein Agent auf einen Tool-Aufruf pausiert, kann ein Scheduler KV vor der Fortsetzung zwischen Tiers verschieben. Die Übertragung benötigt weiterhin Bandbreite und Energie, kann aber zusätzliche Latenz beim Fortsetzen vermeiden. Das ist UNISONs TIDE-Mechanismus, und das Timing ist die ganze Idee: Eine 7-GB-Übertragung kann während einer 10-s-Tool-Lücke abgeschlossen werden; bei der Fortsetzung könnte sie dagegen zusätzliche Latenz verursachen. Der Zeitpunkt beeinflusst die Reaktionszeit.

Siehe: UNISON-Scheduler-Analyse

Spekulative Dekodierung

Token-Kandidaten günstig erzeugen (mit kleinem Draft-Modell, EAGLE-Head, MTP oder N-Gramm-Lookup) und anschließend durch einen Forward-Pass des Zielmodells verifizieren. Mit korrektem Rejection Sampling bleibt die Sampling-Verteilung des Zielmodells erhalten; andere Verifikationsverfahren brauchen eigene Garantien. Bei genügend akzeptierten Draft-Tokens tauscht das Verfahren Draft- und Verifikationsarbeit gegen weniger serielle Decode-Schritte des Zielmodells. SGLang berichtet für EAGLE-3 2,36× Durchsatz auf Llama 3.1 8B (158,34 → 373,25 tok/s auf einer H100; Benchmark-Bedingungen in vLLM gegen SGLang).

Siehe: vLLM vs. SGLang

Draft-Akzeptanzrate

Der Anteil der vorgeschlagenen Draft-Token, die das Zielmodell tatsächlich behält — der Zähler, der entscheidet, ob sich Spekulation lohnt. Jedes zusätzliche akzeptierte Token pro Verify-Pass ist ein voller speicher-gebundener Decode-Schritt weniger, der Durchsatz hängt aber auch von Draft- und Verifikationskosten ab; eine schlechte Akzeptanzrate zahlt stattdessen Draft-Rechenzeit plus Rollback-Overhead für Verworfenes. Draft-Qualität und Draft-Kosten beeinflussen beide das Ergebnis.

Siehe: Groq LPX: Decode aus SRAM

KV-Quantisierung (FP8/FP4)

Ein schmalerer Cache-Datentyp halbiert (FP8) oder viertelt (FP4-Payload) die Bytes pro Wert vor Skalen-Metadaten. vLLM bietet kv_cache_dtype="fp8"; FP8-KV verdoppelt ungefähr die Tokens pro festem KV-Budget. Beim 256-KiB/Token-GQA-Beispiel belegen 100k Tokens 26,2 GB in bf16 oder 13,1 GB in fp8. Falls 153,6 GB einer 192-GB-Karte nach Gewichten und Laufzeit für KV verfügbar wären, ergäbe die Rohkapazität 5,8 bzw. 11,7 solcher Sessions. Das ist ein hypothetisches Budget, kein allgemeines Ergebnis für eine 192-GB-Karte. FP4-Cache-Support und Qualität hängen von Serving-Engine und Checkpoint ab.

Siehe: HBM4-Knappheits-Ökonomie

Per-Head- / Per-Tensor-Skalen

Die Granularität, in der KV-Quantisierungs-Skalen gewählt werden: per Tensor (ein Skalenfaktor für den ganzen Cache — die einfachste, gröbste Wahl) oder per Attention-Head (q_scale = [num_heads], k/v_scale = [num_kv_heads] in vLLM), was Ausreißer auf Head-Granularität begrenzt und schmale Datentypen überleben lässt. Per-Channel-/Per-Block-Verfeinerungen (KIVI-Stil) können die Qualität bei INT4-KV verbessern; Kalibrierung reicht von Skalen = 1,0 bis Datensatz-Kalibrierung über llm-compressor.

Siehe: Der KV-Cache im Detail

Working Set (Flotte)

Diejenigen KV-Bytes, die die laufende Flotte resident halten muss, um Fortschritt zu machen: Bytes pro Token × Kontext × Flottengröße, pro Agent gerechnet. Es ist die Zahl, die alles andere dimensioniert — 50 bei 1M Kontext geparkte MLA-Agenten sind 50 × 70,27 GB = 3.514 GB verwalteter Zustand, ~25 × 141-GB-Karten, bevor ein einziges Gewicht platziert ist; 100 pausierte 100k-Agenten sind 702,72 GB reiner Cache, die nichts tun. Sobald der Working Set die Hot-Tier übersteigt, beginnen Räumung (und ihre Kosten); jede Politik dieses Glossars ist eine Antwort auf dieses eine Überlauf.

Siehe: Agentisches KV-Tiering

Prefill/Decode-Disaggregation

Prefill und Decode auf verschiedene Beschleuniger oder Knoten-Rollen zu verteilen, damit der rechen-lastige Prefill den speicher-gebundenen Decode in einem gemeinsamen Batch nicht ausbremst. Die 2026-Wendung von der KV-Seite: Disaggregation externalisiert die Cache-Platzierung — der KV einer Runde muss von dort, wo der Prefill ihn schrieb, zur Decode-Replika wandern, ein Fabric-und-Burst-Buffer-Problem (DualPaths Storage-to-Decode-Pfad ist die Antwort), und das TensorRT-LLM-Management aus Hot-/Cold-Pools ist die Kontrollebene, die die Platzierungspolitik der Hot-Tier explizit macht.

Siehe: Agentisches KV-Tiering

Primärquellen

• vLLM-/PagedAttention-Paper
• Grouped-Query-Attention-Paper
• DeepSeek-V2-Paper zu MLA
• SGLang-/RadixAttention-Paper
• UNISON-Preprint
• DualPath-Preprint
• Paper zu spekulativem Decoding

Wie man dieses Glossar benutzt

Jeder Eintrag ist bewusst ein Absatz: die Definition plus die Zahl, die ihn real macht. Braucht ein Begriff die volle Herleitung, trägt sie der verlinkte Artikel — der Deep Dive für Architektur- und Allokator-Mathematik, der Tiering-Guide für die Bytes-bewegt-Sicht auf Agenten-Flotten, die HBM4-Analyse dafür, warum all das Beschaffung ist, und die UNISON-Analyse dafür, wohin Eviction-Politik sich entwickelt. Der rote Faden: Jeder Begriff oben ist ein Hebel an denselben zwei knappen Größen — KV-Bytes und die Bandbreite, sie zu bewegen.