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

Agentenschleifen mit langem Kontext können KV-Cache-Kapazität und Transferbandbreite stark beanspruchen. Die Rechnungen unten sind illustrative Untergrenzen für unkomprimierte BF16-KV bei Full Attention. Die tatsächliche Serving-Leistung hängt von Attention-Kernels, Batching, Cache-Residenz, Quantisierung und Modellparallelismus ab. Konfiguration und Quellen stehen auch im KV-Cache-Leitfaden.

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

Eine Agentenschleife kann nach einem Tool-Aufruf ein langes Präfix fortsetzen. Betrachten wir 100k Kontext-Tokens, ein Tool-Ergebnis mit 2.048 Tokens und eine Antwort mit 512 Tokens:

• Decode: Bei Full Attention greift jedes neue Token auf das bisherige Präfix zu. Die KV von ungefähr 100k Tokens wird in jedem der 512 Decode-Schritte gelesen; Implementierungsdetails und wachsender Kontext verändern die genaue Bytezahl.
• Inkrement: Nur 2.048 + 512 Tokens neue KV werden berechnet und geschrieben.

Referenzgeometrie: DeepSeek-V3 MLA¹ mit 512 latenten plus 64 RoPE-Elementen pro Token und Schicht, 61 Schichten, BF16 → 70.272 B ≈ 68,6 KiB pro Token, unter Annahme dieses Cache-Layouts. Die Modellkarte bewirbt 128K Kontext. Das 1M-Token-Szenario weiter unten extrapoliert lediglich diese Geometrie und ist keine unterstützte DeepSeek-V3-Konfiguration.²

Das ist die Cache-Kapazität einer Sitzung zu Beginn der Runde, ohne Verwaltungs- und Block-Overhead.

HBM-Bytes pro Runde: Agent vs Chat

Wenn diese KV im HBM bleibt und der Kernel bei jedem Decode-Schritt das gesamte Präfix liest, ergeben sich näherungsweise folgende Lesevolumina:

Dieses Beispiel ergibt 25-mal so viele KV-Lesebytes für die Agentenrunde. Das belegt keine 25-fachen Token-Kosten oder Latenzen: Batching, Kernel-Effizienz, Speicherplatzierung und Modellgewichte wirken ebenfalls mit.

Das inkrementelle Prefill des Tool-Ergebnisses berechnet ebenfalls neue KV. Seine Laufzeit lässt sich nicht zuverlässig aus Peak-FLOP/s allein ableiten, insbesondere bei einem verteilten MoE-Modell.

Eine hypothetische Flotte mit 50 Workern und 1M Kontext

Für eine Kapazitätsrechnung extrapolieren wir dasselbe BF16-MLA-Layout auf 50 gleichzeitige Worker mit je 1M Tokens. Dies überschreitet DeepSeek-V3s beworbene Kontextlänge und ist ein hypothetisches Cache-Sizing-Beispiel.

Falls die gesamte KV im HBM liegt und Full Attention sie bei jedem Schritt liest, ergeben diese Decode-Raten pro Worker folgende aggregierte HBM-KV-Leseanforderung:

Eine H200 besitzt laut NVIDIA 141 GB HBM und 4,8 TB/s nominelle HBM-Bandbreite.³ 3,514 TB geteilt durch 141 GB ergeben etwa 25 H200-Karten als strikte Kapazitätsuntergrenze nur für KV, ohne Platz für Gewichte, Fragmentierung oder Runtime-Zustand. Bei 20 Token/s pro Worker entfallen rechnerisch 70,3 TB/s geteilt durch 25, also 2,8 TB/s pro Karte: rund 59 % des theoretischen H200-HBM-Maximums. Das ist ein Bandbreitenbudget, keine gemessene Auslastung oder Durchsatzprognose.

HotInfra'26⁴ schlägt speicherzentrierte KV-Cache-Server vor, unter anderem mit CXL-Expandern und Near-Memory Processing. Dieser Entwurf unterstreicht die Bedeutung der KV-Platzierung; er misst keine GPU-Auslastung von 3,4 % für unser Szenario. Siehe auch die Scale-up-Netzwerk-Analyse.

Das Tiering-Muster

DualPath⁵ behandelt das Laden von KV aus externem Storage an einer Rundengrenze in disaggregierten Prefill/Decode-Systemen. Es ergänzt einen Storage-zu-Decode-Pfad mit anschließendem RDMA-Transfer zu Prefill-Engines. Das Paper berichtet bis zu 1,87-fachen Offline-Durchsatz und 1,96-fachen durchschnittlichen Online-Durchsatz gegenüber der eigenen Baseline. Das sind Ergebnisse für dieses System und diese Workloads, kein genereller Speedup für alle Agentenflotten. Der einmalige KV-Transfer an der Rundengrenze ist von den wiederholten HBM-Zugriffen während des Decodes zu unterscheiden.

TensorRT-LLMs KV Cache Manager V2⁶ unterstützt Hot-Pools im HBM und Cold-Page-Verwaltung. Die Einstellung use_kv_cache_manager_v2 steht standardmäßig auf auto: Dokumentierte modellspezifische Präferenzen wählen V2; ohne Präferenz fällt das System auf V1 zurück. V2 ist also nicht für alle Modelle standardmäßig aktiv. Cold-Pool-Funktionen betreffen Cache-Platzierung und Transfers; sie ermöglichen nicht, bei jedem Attention-Schritt Cold Storage mit HBM-Geschwindigkeit zu lesen.

Die mechanische Lücke: PCIe vs HBM

Für einen möglichen Auslagerungspfad bietet PCIe 5.0 x16 ungefähr 63 GB/s je Richtung nach 128b/130b-Kodierung, noch vor Paket- und Software-Overhead.⁷ Der publizierte H200-HBM-Peak liegt bei 4,8 TB/s. Der Vergleich dieser nominellen Werte ergibt:

Das ungefähr 76-fache Verhältnis vergleicht Interface-Peaks, keine gemessenen End-to-End-Raten. Ideale Untergrenzen der Transferdauer:

Diese PCIe-Zeiten gelten nur, wenn der gesamte Cache nachgeladen werden muss. Ein Cache-Treffer braucht keinen solchen Transfer; Transfers können außerdem Rechenarbeit überlappen. NVIDIA nennt 900 GB/s bidirektionales NVLink-C2C für Grace Blackwell und bis zu 1,8 TB/s für Vera Rubin, nicht 2,25 TB/s.⁸ Die Linkrate allein bestimmt keine anwendungsseitige KV-Nachladezeit. Siehe die NVLink-Zahlen.

Energie und Kosten: Grenzen der Bandbreitenrechnung

Die Bytezahlen helfen bei Kapazitäts- und Bandbreitenbudgets. Sie bestimmen weder GPU-Auslastung noch Joule oder Preis pro Token. Dafür braucht man Modellplatzierung, Batchgröße, gemessene Leistung, Kernel-Durchsatz und tatsächliche Cache-Trefferquote. Eine frühere Einzelkarten-Tabelle kombinierte einen 65-GB-Gewichts-Read mit DeepSeek-V3s 37B aktiven Parametern und ließ die verteilten 671B Gesamtgewichte außer Acht; sie beschreibt kein reales DeepSeek-V3-Deployment.²

Was Prefix-Caching einspart

RadixAttention in SGLang⁹ verwendet KV-Blöcke geteilter Präfixe erneut. Bleibt ein Präfix resident, muss die nächste Runde dessen KV beim Prefill nicht neu berechnen. Die Decode-Attention liest die residente Präfix-KV weiterhin; Caching beseitigt diese HBM-Zugriffe nicht.

Wann es nicht geht: Eviction unter Gleichzeitigkeit

Prefix-Caching bleibt durch die Speicherkapazität begrenzt. Für eine idealisierte 141-GB-Karte, die vollständig KV vorbehalten ist:

50 Worker × 1M Tokens benötigen 3,514 TB KV, entsprechend ungefähr 25 × 141-GB- oder 20 × 180-GB-Karten als Kapazitätsuntergrenze. Reale Systeme brauchen darüber hinaus Platz für Gewichte, Fragmentierung und Runtime-Puffer. Ob ein weiterer Worker eine Verdrängung auslöst, hängt von Platzierung und Policy ab; die reine Flottengröße entscheidet das nicht.

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. Zwei Pfade getrennt planen: Residente KV wird beim Decode aus dem HBM gelesen; fehlende oder verdrängte Präfixe werden an Rundengrenzen über Storage-/Host-Verbindungen geladen. Miss-Rate und Transferbytes getrennt schätzen.
4. Das Deployment messen: Durchsatz, Auslastung und Energie mit tatsächlichem Modell, Kontextmix, Cache-Policy und Hardware prüfen.

DualPath, TensorRT-LLM V2 und der HotInfra-Entwurf behandeln verschiedene Teile dieses Platzierungsproblems. Der Break-even für Offloading oder zusätzlichen GPU-Speicher hängt vom Workload ab. Die Gleichungen liefern ein Ausgangsbudget, keine universelle Serving-Empfehlung.

Referenzen