Jede Serving-Frage an ein LLM lässt sich auf Arithmetik über einen einzigen Tensor reduzieren: den Key-Value-Cache. Dieses Glossar definiert jeden Begriff des Serving-Stacks so, wie ihn ein Ingenieur braucht — eine rigorose Definition pro Begriff, plus der Formel oder des architektonischen Grundes, wo es darauf ankommt. Die Zahlen sind die site-verifizierten aus dem KV-Cache-Deep-Dive, dem Agenten-KV-Tiering-Guide, der HBM4-Ökonomie-Analyse und der UNISON-Scheduler-Analyse.
Die Begriffe
KV-Cache
Der Speicher der Attention-Key- (K) und Value- (V) Tensoren, den eine Serving-Engine für jedes Token jeder aktiven Sequenz vorhält, damit kein Decode-Schritt die Attention über die gesamte Historie neu berechnen muss. Es ist Memoisierung mit linearem Speicherpreis: Die Bytes wachsen mit jedem gesehenen Token, pro Sequenz, über die Lebensdauer des Requests. Die Kosten pro Token legt die Attention-Architektur nebst Datentyp fest, die Gesamtmenge der parallele Kontext — weshalb die KV-Kapazität, nicht die FLOPs, begrenzt, wie viele Nutzer eine GPU bedient.
Siehe: Der KV-Cache im Detail
Token
Die atomare Einheit, die ein LLM verarbeitet und abrechnet: ein Textstück (oder Bild-Patch), das zu einer Zeile im KV-Cache und einer Attention-Spalte wird. 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
Die eine Formel, aus der jede Kapazitätsmathematik folgt: Layer × KV-Heads × Head-Dimension × Bytes pro Wert × 2 (K und V werden getrennt gespeichert). 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.
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 alle Eingabe-Token parallel (große Matrixmultiplikationen, compute-gebunden) und schreibt dabei pro Token und Layer eine K/V-Zeile. Der Prefill bestimmt die Time-to-First-Token und initialisiert den Cache; Prefix-Caching existiert, um wiederholten Prefill überflüssig zu machen. Der inkrementelle Prefill von ~2k Token pro Runde kostet auf einem 37B-aktiven MoE rund 303 TFLOP — weniger als eine halbe Sekunde H100-Rechenzeit, weshalb Agenten selten FLOP-limitiert sind.
Siehe: Agentisches KV-Tiering
Decode
Die Phase, in der das Modell die Ausgabe Token für Token erzeugt, wobei jeder Schritt über die gesamte gecachte Historie attendiert. Der Decode ist speicher-gebunden: Jeder Schritt muss die Gewichte plus den ganzen KV-Cache dieser Sequenz aus dem HBM lesen und jedes Byte im Wesentlichen einmal verwenden. Bei 8k Kontext auf einem H100 SXM liegt das Rechen-Intensitäts-Floor bei ~20,0 ms pro Schritt — rund 50 tok/s für einen Nutzer —, während Batching 16 Nutzer den Gewichte-Lesevorgang in 10,8× aggregierten Durchsatz verwandelt.
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. Sie erreicht die Qualität des vortrainierten Checkpoints, ist aber der Speicher-Schlimmfall — 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 verbreitete g=8-Konfiguration — 8 KV-Heads für 64 Query-Heads — schneidet den Cache pro Token um 8× gegenüber MHA auf 262.144 B (256 KiB) bei fp16; das Kernresultat des GQA-Papers ist Qualität nahe MHA bei Geschwindigkeit nahe MQA, dazu ein „Uptraining"-Rezept, das bestehende MHA-Checkpoints mit etwa 5 % des ursprünglichen Pretraining-Rechenaufwands umwandelt. GQA statt MLA zu wählen kostet in einem rationierten Speichermarkt 3,73× Kapazität.
Siehe: HBM4-Knappheits-Ökonomie
MLA (Multi-head Latent Attention)
DeepSeeks Mechanismus: statt K und V pro Head zu speichern, wird ein ranger Kompressions-„Latent"-Vektor plus ein kleiner entkoppelter RoPE-Key abgelegt und das volle K/V während der Attention on the fly rekonstruiert. Die Konfiguration von DeepSeek-V3 hält 576 Latent-Elemente pro Token und Layer über 61 Layer, bf16 → 70.272 B ≈ 68,6 KiB pro Token; das V2-Paper berichtet 93,3 % kleineren Cache und 5,76× höheren maximalen Generierungs-Durchsatz gegenüber seiner 67B-MHA-Baseline. Gegenüber GQA-8 ist das eine weitere Kompression um 3,73×.
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 — ohne Konfiguration, ohne kollisionsanfälliges Hashing. 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. Das Freigeld-Beispiel: Ein 2.000-Token-Systemprompt kostet ~524 MB GQA-fp16-KV pro paralleler Konversation — mit Baum-Teilung einmal berechnet und einmal gespeichert.
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. Batching ist die Ökonomie des Serving: Der Gewichte-Lesevorgang wird über den Batch geteilt, während jede Sequenz ihren KV-Lesevorgang privat zahlt; Batches von 16 bei 8k Kontext auf einem H100 verwandeln so einen Gewichte-Durchlauf in 539 tok/s aggregiert — das 10,8× des 49,9 tok/s eines einzelnen Nutzers —, während jeder Nutzer ~48 % länger pro Token wartet. Kapazitiv wird die Batchgröße nicht von FLOPs, sondern von den KV-Bytes pro Nutzer begrenzt.
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. Ohne es bricht der Durchsatz auf burstige Batch-Durchschnitte zusammen und Präfix-Cache-Hits veralten zwischen Batches; mit ihm wird der laufende Batch jeden Schritt neu aus allen gebildet, deren KV noch hineinpasst — was das KV-Budget, wieder, zum Admission-Controller macht.
Siehe: vLLM vs. SGLang
TTFT (Time to First Token)
Die Latenz von der Ankunft des Requests bis zum ersten generierten Token — dominiert von der Prefill-Rechenzeit für den ungecachten Teil des Prompts. TTFT ist die Metrik, in der sich Präfix-Caching auszahlt: 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 Latenz jedes Decode-Schritts nach dem ersten Token — gesetzt durch die Dauer eines speicher-gebundenen Schritts: Gewichte plus die gesamte HBM-gelesene KV dieser Sequenz lesen, ein Token ausgeben. TPOT wächst linear mit dem Kontext (bei 32k, Batch 1, kostet allein das Cache-Lesen in der Referenzkonfiguration jeden Schritt 2,6 ms) und verschlechtert sich mit Batching (~48 % länger pro Token bei Batch 16). Wahrgenommene Geschwindigkeit ist TTFT einmal, TPOT bei jedem Token.
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. LRU ist der Standard-Proxy, weil Zugriffshistorie billig zu führen ist — und es versagt an Agenten genau deshalb, weil eine tool-wartende Session ihren KV seit der letzten Runde nicht berührt hat: Sie wirkt älter als ein plappernder Nutzer und wird zuerst geräumt, ausgerechnet die Sessions mit dem meisten gebankten Kontext zerstörend. LRU ist die Baseline, die jedes Paper von 2026 schlägt, und die Null-Hypothese, gegen die jeder Politikanspruch gemessen werden muss.
Siehe: UNISON-Scheduler-Analyse
TTL-Eviction
„Time to live": KV nach einem festen Idle-Fenster ablaufen lassen, unabhängig von der Zugriffshistorie. Die Agenten-Falle ist Heavy-Tail-Tool-Latenz — jede TTL, die kurz genug ist, um Speicher zurückzugewinnen, tötet auch die Sessions, deren Tool-Aufrufe zufällig lang dauern (ein Browser- oder Sandbox-Schritt kann Dutzende Sekunden brauchen). LRU scheitert durch Missranking; TTL scheitert planmäßig: Beide stellen dem Zugriffsprotokoll eine Frage, die nur die Job-Struktur (ein Tool-Aufruf impliziert eine Rückkehr) beantworten kann.
Siehe: UNISON-Scheduler-Analyse
Bélády MIN
Die theoretisch optimale Eviction-Politik: den Block räumen, dessen nächste Nutzung am weitesten in der Zukunft liegt — berechenbar nur mit einem Orakel. Sie ist die Obergrenze, an der jede reale Politik gemessen wird; die nützliche Rahmung aus UNISONs Evaluation: Ein guter Scheduler überbrückt den Großteil der Strecke von LRU Richtung Bélády-Klasse-Voraussicht, und der Rest-Orakelabstand zeigt, wie viel Voraussicht der Workload tatsächlich verbietet (manche Tool-Ausgänge sind unvorhersagbar, und das holt kein Hazard-Modell zurück). Gelernte, „relaxed-Belady"-Politiken sind dieselbe Idee mit vorhergesagten Zukünften.
Siehe: UNISON-Scheduler-Analyse
Survival-Penalty-Eviction
Die Verfeinerung von 2026: eine Survival-Funktion über die Tool-Rückfall-Lücke jeder Session fitten (Lücken-Durchschnitt plus ein Turn-Index-Hazard — eine Session, die aus 40 Tool-Aufrufen zurückgekehrt ist, kehrt fast sicher aus ihrem 41. zurück) und die Räumung voraussichtlich rückkehrender Sessions benachteiligen. Das ist UNISONs SPEAR-Politik, derselbe statistische Wechsel, der CDN-Caching von LRU zu gelernten Politiken brachte — und, die ehrliche Einschränkung aus dem Paper, deren Ranking-Hälfte heute softwareseitig replizierbar ist; eine Runtime könnte sie als Patch in ihren Block-Manager implementieren, ohne neues Silizium.
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). Für lange Agenten-Präfixe gewinnt Swap fast immer — das Neu-Prefillen eines ~7-GB-, 100k-Token-Präfixes kostet das komplette Read-and-Recompute, der schlechteste Fall der UNISON-Tiering-Analyse —, während bei kurzen Blöcken Recompute günstiger sein kann als Fabric-Roundtrips. 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, liegt Speicherbandbreite brach, und die KV-Bewegung zwischen Tiers kostet dann nichts — anders als eine Bewegung, die mit dem Resume-Prefill konkurriert. Das ist UNISONs TIDE-Mechanismus, und das Timing ist die ganze Idee: Eine 7-GB-Migration im Inneren einer 10-s-Tool-Lücke ist gratis; dieselbe Migration, gestartet während das Tool zurückkehrt, konkurriert mit dem Resume und ist ein reiner Verlust. Idle-Window-Scheduling ist der Unterschied zwischen lebensfähigem Tiering und einem Latenz-Bug.
Siehe: UNISON-Scheduler-Analyse
Spekulative Dekodierung
Token-Kandidaten billig erzeugen (mit kleinem Draft-Modell, EAGLE-Head, MTP oder N-Gramm-Lookup) und dann den ganzen Entwurf in einem parallelen Forward-Pass des Zielmodells verifizieren. Das Verfahren ist algorithmisch verlustfrei — die Verteilung des Verifizierers bleibt erhalten — und attackiert den seriellen, speicher-gebundenen Decode-Flaschenhals, indem es Verify-Pass-FLOPs gegen akzeptierte Drafts pro Schritt tauscht. SGLangs EAGLE-3 zeigt 2,36× Durchsatz auf Llama 3.1 8B (158,34 → 373,25 tok/s auf einer H100; Zahlen wie in vLLM gegen SGLang benchmarked); eine scharfe Kante: In vLLM sind Pipeline-Parallelität und spekulative Dekodierung Stand ≤ 0.15.0 inkompatibel.
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 skaliert also damit; eine schlechte Akzeptanzrate zahlt stattdessen Draft-Rechenzeit plus Rollback-Overhead für Verworfenes. Deshalb dominiert die Draft-Qualität: Ein LPU/Groq-Klasse-Drafter mit Gewichten im SRAM ist attraktiv, weil er Kandidaten billig nachschieben kann, während die große Karte parallel verifiziert.
Siehe: Groq LPX: Decode aus SRAM
KV-Quantisierung (FP8/FP4)
Den Cache in einem schmaleren Datentyp speichern — halbiert (FP8) oder viertelt (FP4) die Bytes pro Wert, bei unveränderter Architektur und Allokator. vLLM bietet kv_cache_dtype="fp8" (e4m3/e5m2, CUDA 11.8+) mit der Kapazitäts-zuerst-Rahmung der Dokumente: FP8-KV verdoppelt ungefähr die Token, die ins selbe Budget passen — GQA-8 bei 100k Kontext fällt von 26,2 GB auf 13,1 GB pro Session, eine 192-GB-Karte kommt von 5,8 auf 11,6 parallele Agenten. FP4-Klasse-Cache geht auf Kosten der Genauigkeit weiter.
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, laut der HBM4-Analyse) machen INT4-Klasse-KV überhaupt erst praktikabel; 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
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.