Ihre Agenten-Flotte ist ein Storage-Array: Die KV-Cache-Tiering-Mathematik hinter agentischer Inferenz

Agentische Inferenz wird verkauft als „dieselben GPUs, längere Prompts". Die Arithmetik sagt etwas anderes. Eine Multi-Turn-Agentenschleife sieht-chat-Workload gar nicht ähnlich: Sie sieht aus wie ein Storage-Array mit angehängten GPUs — eine Flotte von Prozessen, deren dominierende Kosten nicht Tokens-pro-Sekunde sind, sondern Bytes an KV-Cache, die pro Runde bewegt werden, und deren Kapazitätsplanung in Gigabyte Working Set erfolgen sollte, nicht in Requests oder FLOPs. Dieser Leitfaden rechnet die Zahlen pro Runde und pro Flotte durch — jede Figur berechnet aus der site-verifizierten KV-Cache-Formel und Primärquellen.

Die Form des Workloads: Lange-Präfix-Re-Reads plus kleine Incremente

Chat besteht aus kurzen Prompts, wenigen Runden, kleinem Zustand. Eine agentische Schleife — planen, ein Tool aufrufen, das Ergebnis lesen, wieder planen — macht das Gegenteil. Der Sitzungskontext wächst monoton: Jede Runde liest das gesamte Präfix erneut und hängt ein kleines Inkrement an. Pro Runde macht ein Agent mit 100k Kontext, einem 2.048-Token-Tool-Ergebnis und 512 generierten Tokens:

• Präfix-Re-Read: Die vollständige KV von ~100k bisherigen Tokens muss bei jedem Decode-Schritt der Attention zur Verfügung stehen — 512-mal neu gelesen während der Antwort.
• Inkrement: Nur 2.048 + 512 Tokens neue KV werden berechnet und geschrieben.

Referenzmodell: DeepSeek-V3 MLA¹ — die site-verifizierte Konfiguration (KV-Cache-Leitfaden): 576 Latent-Elemente pro Token pro Schicht, 61 Schichten, bf16 → 70.272 B ≈ 68,6 KiB pro Token. Selbst nach MLAs 93,3-%-Kompression gegenüber MHA ist der Multiplikator die Kontextlänge:

Das ist ein Agent, der auf der GPU residiert. Jetzt zählen wir die Bytes, die tatsächlich bewegt werden müssen.

HBM-Bytes pro Runde: Agent vs Chat

Beim Decode liest jeder Schritt die vollständige KV dieses Workers aus dem HBM (das Gewichts-Lesen teilt sich über den Batch; das KV-Lesen nicht — es ist pro Sequenz, bei jedem Schritt, immer). Direkt berechnet:

Eine Agentenrunde bewegt 25× die HBM-Bytes einer Chat-Runde auf demselben Modell — und der Faktor skaliert linear mit dem Kontext, weil der Read-pro-Schritt die ganze Sitzung ist, nicht das Inkrement. Der KV-Write ist Rauschen; das Re-Read ist der Workload. Dieses eine Verhältnis erklärt, warum Agenten-Token-Kosten nicht wie Chat-Token-Kosten aussehen: Chat amortisiert, Agents scannen erneut.

Prefill-vs-Decode-Rahmen: Das inkrementelle Prefill einer Runde (~2k Tokens) ist FLOP-lastig — rund 2 × 2 × 37B aktive Parameter × 2.048 ≈ 303 TFLOP, weniger als eine halbe Sekunde auf einer H100. Der Decode ist bytes-lastig: 3.598 GB reine Re-Reads pro Runde. Keine der beiden Formen ist die Engpass-Form von Chat.

Die Bandbreiten-Wand: 50 gleichzeitige 1M-Kontext-Worker

Skaliere zu einer bescheidenen Agentenflotte: 50 Worker, jeweils bei 1M Kontext geparkt.

Damit überhaupt dekodiert werden kann, liest jeder Worker bei jedem Schritt seine eigene vollständige Cache erneut (teils aus HBM, teils von überall, wohin das Tiering den Rest gelegt hat). Aggregierte Read-Bandbreite, nur um die Flotte dekodieren zu lassen, bei drei Raten pro Worker:

Eine einzelne H100 liest 3,35 TB/s. Auf ~25 Karten (die reine KV-Kapazität einer 141-GB-Karten-Flotte — eine Karte der H200-Klasse, HBM3e mit 4,8 TB/s — unten berechnet) bedeuten 70,3 TB/s ~2,8 TB/s reinen KV-Traffic pro Karte — 84 % der 3,35 TB/s einer H100 bzw. 59 % der 4,8 TB/s dieser H200, für die Bewegung der eigenen Historie eines einzigen Workers zurück zu sich selbst, ohne ein einziges Attention-Rechenwerk.

Die GPU wartet meist im Leerlauf: Für ein 37B-aktiv-MoE-Token bei 100k Kontext braucht die Arithmetik ~75 µs SM-Zeit, während der KV-Read ~2,1 ms dauert — eine Rechen-Auslastung von 3,4 %. Die Karte ist nicht FLOP-begrenzt; sie ist Storage-I/O-begrenzt, ganz im Sinne eines Datenbankservers. Genau diese Beobachtung stellt HotInfra'26² ins Zentrum: Reimagining LLM Inference Infrastructure with Memory-Centric KV Cache Servers (Kiyawat & Skadron, HotInfra '26, ko-lokiert mit ISCA '26) schlägt vor, KV in speicherzentrische Server zu disaggregieren — auf einem CXL/PNM/PIM-Gerätespektrum von CPU-angehängten CXL-DDRx-Expandern bis zu Near-Memory-Compute-Knoten. Ihre Beispiel-Workload ist ein 32K-Token-Generation-Lauf. Das Muster hat in ihrem Vokabular einen Namen: ein KV-Cache-Server — Storage-Array-Denken, formal vorgeschlagen. Die Mechanik spiegelt, was die NVLink-Bandbreiten-Grundwahrheit und unsere Scale-up-Netzwerk-Analyse andernorts zeigen: Das Fabric, das der Workload wirklich braucht, ist das Speicher-Fabric — und die GPUs hängen daran wie Beschleuniger.

Das Tiering-Muster

DualPath (arXiv:2602.21548) formuliert das Problem im eigenen ersten Satz: „The performance of multi-turn, agentic LLM inference is increasingly dominated by KV-Cache storage I/O rather than computation." In disaggregierten Prefill/Decode-Clustern sättigt das Laden der Runden-KV aus externem Storage die Storage-NICs der Prefill-Seite, während die der Decode-Seite brachliegen; DualPath ergänzt einen Storage-zu-Decode-Pfad (via RDMA über das Compute-Netzwerk) und berichtet bis zu 1,87× Offline- und im Mittel 1,96× Online-Serving-Durchsatz gegenüber der hauseigenen Baseline. Die Bedeutung für die Kapazitätsplanung: Das Paper behandelt KV als einen platzierten, bewegten und lastausbalancierten Bytestrom — ein Storage-Scheduling-Problem, kein Model-Serving-Problem. Es belegt zahlenmäßig, was die Runden-Mathematik oben vorhersagt: Der Präfix-Re-Read ist eine zwingende Datenbewegung, und wohin diese Bytes geroutet werden, entscheidet den Durchsatz, bevor FLOPs überhaupt ins Bild kommen.

TensorRT-LLMs KV Cache Manager V2³ ist dasselbe Muster in Produktform: ein Hot Tier im HBM und ein Cold Pool für ausgelagerte KV, Cold-Page-Codecs für komprimierte Kaltseiten, pool_ratio-Quoten pro Schichtgruppe und Cold-Tier-Statistiken in kvCacheIterationStatsByColdPoolGroup (die 1.2-Release-Notes führen die Pool-Ratio- und Cold-Tier-Statistik-Breaking-Changes; die Cold-Page-Codecs und die V1-Deprekations-Ankündigung kamen mit der v1.3.0-RC-Reihe, August 2026). V2 ist die empfohlene Architektur, und NVIDIA hat angekündigt, dass V1 depreziert wird; Hot/Cold-Tiering ist längst keine Exotik mehr — es ist das default-geschaltete Control Plane für exakt den Re-Read-Traffic, den dieser Leitfaden berechnet.

Die mechanische Lücke: PCIe vs HBM

Ob das „Cold Tier" Host-DRAM über die PCIe-Leitung⁴, ein CXL-Expander oder ein entfernter KV-Server ist — die Bytes kreuzen ein Fabric, das langsamer ist als HBM, meist PCIe. PCIe 5.0 x16 ≈ 64 GB/s roh, ~63 GB/s effektiv (32 GT/s × 16 Lanes bei 128b/130b-Encoding, gemäß PCI-SIG-Gen5-Spezifikation). Gegen HBM3e mit 4,8 TB/s:

Die ~75-fache Lücke ist kein Detail — sie fixiert das Fundament jeder Runde. Re-Read-Zeiten, berechnet:

Ein Page-in aus dem Cold Tier addiert eine Zehntelsekunde bis zu einer Sekunde pro Runde — unsichtbar in Chat-Maßstäben, katastrophal bei Agenten-Kadenz (eine Tool-Schleife kann in unter einer Sekunde rondieren). Deshalb ist die Placement-Politik des Tierings (welche Seiten heiß bleiben) wichtiger als die Kapazität: Bytes, die im HBM bleiben, kosten 76× weniger Latenz bei jeder Berührung. NVLink-C2C-Klasse-Links (2,25 TB/s+ laut den NVLink-Zahlen) liegen zwischen den Extremen und sind der Grund, warum integrierte GB200-Klasse-Designs besser standhalten als PCIe-angehängtes Host-Offloading.

Die Ökonomie: Tokens/Joule mit dem I/O-Term

Chat-Decode-Ökonomie: Batch 1, ein Schritt liest Gewichte + KV. Agenten-Decode-Ökonomie auf derselben 700-W-Karte, pro Token berechnet:

Die interessante Zeile ist nicht J/Token — sondern dass bei 1M ~52 % der Schrittdauer eines Agenten reiner KV-Re-Read sind (70,27 GB ÷ 3,35 TB/s = 21,0 ms des 40,4-ms-Schritts; die restlichen ~48 % sind der Gewichts-Read — jede Mikrosekunde des Schritts ist Speicher-Traffic, nichts davon Rechenwerk). Die GPU verbrennt ihre volle 700 W, während sie 3,4 % nützliche Mathematik macht. Energie pro geliefertem Agenten-Token wird von einem I/O-Term dominiert, nicht von einem Rechenterm — das Gegenteil von Chat, wo der Gewichts-Read dominiert und Batching ihn amortisiert. Sobald KV hinter einem langsameren Tier liegt, kommt die PCIe-Energie dazu: Sekundenbruchteile pro Restore sind reale Joule für null FLOPs.

Wann Prefix-Caching das Re-Read tötet

RadixAttention (SGLang)⁵, arXiv:2312.07104) macht die Recompute-Hälfte des Re-Reads fast gratis: Geteilte Präfixe liegen in einem Radix-Baum, und das Paper berichtet bis zu 6,4× Durchsatz auf präfix-lastigen Workloads — Multi-Turn-agentische Schleifen sind sein Best-Case-Muster (Runde n teilt die Runden 1…n−1). Prefix-Caching vernichtet Prefill-Rechenleistung und hält die heiße KV auf einer GPU resident, sodass HBM-Re-Reads mit vollem Tempo fließen.

Wann es nicht geht: Eviction unter Gleichzeitigkeit

Prefix-Caching kann Kapazität nicht heilen. LRU-Eviction schlägt in dem Moment zu, in dem das Working Set das Hot Tier übersteigt — und das Working Set ist exakt das, was dieser Leitfaden berechnet. Auf einer 141-GB-Karte (Gewichte auf anderen Karten des Knotens):

50 Worker × 1M Kontext = 3.514 GB KV = ~25 × 141-GB-Karten oder ~20 × 180-GB-Karten — nur um den Zustand der Flotte zu halten, bevor ein einziges FLOP Gewichte platziert ist. Bei 100k im Schnitt ist das Set 351 GB — immer noch 2,5 Karten voller reinem Cache. Unter einem Radix-Baum ist das brutal: Sobald Worker 51 ankommt, verdrängt die LRU genau die langen Präfixe, die agentische Runden billig machten — und die nächste Runde zahlt 0,11–1,1 s (siehe PCIe-Tabelle), um Bytes wiederherzustellen, die die Flotte gerade erst berechnet hat. Eviction-Druck bei Agenten-Kadenz ist eine Thrash-Schleife, und Gleichzeitigkeit ist der Auslöser.

Wie Kapazitätsplanung wirklich aussieht (die kritische Sicht)

„Agenten laufen auf derselben Infrastruktur wie Chat" ist die Marketing-Zeile — meist gefolgt von einer Tokens/s-Zahl. Die Arithmetik sagt etwas anderes, und die ehrliche Faustregel fällt direkt aus den Zahlen oben:

1. Working Set pro Agenten berechnen: Bytes/Token (hier 70,27 KB, gemäß den MLA-Zahlen) × Kontext. Aufschreiben; das ist die eine Zahl, die alles dimensioniert.
2. Mit der Flottengröße multiplizieren: Das ist die Kapazität des Storage-Arrays. 50 × 1M = 3,5 TB verwalteter Zustand — planen wie Array-Kapazität: Hot-HBM-Tier, Cold-DRAM/CXL/Remote-Tier, Eviction-Politik als Placement-Engine.
3. Bewegung provisionieren, nicht FLOPs: Flotten-Decode-Rate × Working Set = benötigte Read-Bandbreite (oben 70,3 TB/s bei 20 Tok/s). Prüfen gegen das aggregierte HBM des Hot Tiers und gegen das Cold-Tier-Fabric (63 GB/s pro PCIe x16; ~50 GB/s pro 400-Gb-NIC) — genau DualPaths Storage-NIC-Beobachtung.
4. Die Idle-Mathematik prüfen, bevor man irgendeiner Tokens/s-Zahl glaubt: Bei 3,4 % GPU-Auslastung ist die Flotte ein Platten-Array mit teuer angehängten SIMD-Einheiten.

Das Muster formiert sich bereits: DualPath routet den Bytestrom, TensorRT-LLM V2 liefert Hot/Cold-Pools mit Codecs und Quoten, HotInfra'26 speichert KV in speicherzentrischen Cache-Servern auf CXL/PIM-Fabrics. Die Infrastruktur-Implikation — Agentenflotten wie Storage-Arrays planen, in Working-Set-Bytes — ist keine spekulative Prognose; sie ist die Design-Annahme, auf der diese Systeme 2026 gebaut wurden. Kapazität ist im Chat-Zeitalter still gescheitert, weil der Zustand eines Gesprächs trivial klein ist. Der Zustand einer gleichzeitigen Agentenflotte sind Terabytes, laufend neu gelesen. So dimensionieren.

Referenzen