Aus einer Speichergrenze wird ein Sitzungsbudget
Nach Gewichten und Laufzeitreserven begrenzt der übrige schnelle Speicher den gleichzeitig gehaltenen Kontext.
KI-gestützte Lernvisualisierung · schematische Erklärung zum Artikel
Gewichte, Aktivierungen und Laufzeit-Arbeitsbereiche belegen HBM, bevor KV zugeteilt wird. Weniger Kapazität trifft deshalb den verbleibenden KV-Pool und kein völlig leeres Gerät.
Die Kapazität von High-Bandwidth Memory (HBM) beeinflusst, wie viele Anfragen mit langem Kontext ein Inferenzserver im Speicher halten kann. Lieferengpässe und Zuteilung spielen ebenfalls eine Rolle. Dieser Beitrag trennt KV-Cache-Rechnung pro Anfrage, veröffentlichte GPU-Spezifikationen und Prognosen über künftige Speicherausstattungen. Weder Rechenleistung noch Speicher allein sagen den tatsächlich erzielten Durchsatz voraus.
Zuerst das KV-Budget berechnen
Bei konventioneller Multi-Head-, Grouped-Query- oder Multi-Query-Attention benötigt ein unkomprimierter KV-Cache näherungsweise
2 × Schichten × KV-Heads × Head-Dimension × Bytes pro Element × gespeicherte Token
Bytes pro Sequenz. Der Faktor zwei steht für Keys und Values. Speicherblöcke, Sliding Windows, Prefix-Sharing, Quantisierung, weiterer Modellzustand und Laufzeit-Overhead können den tatsächlichen Bedarf verändern. Architekturen wie DeepSeeks Multi-Head Latent Attention verlangen eine eigene Rechnung für das Cache-Layout. Sie lassen sich nicht blind mit dieser Formel berechnen. Mehr dazu im KV-Cache-Leitfaden.
Ein hypothetischer Vergleich mit 64 Schichten, Head-Dimension 128 und zwei Bytes pro Element bei 100.000 gespeicherten Token:
| Attention-Layout | KV-Heads | Bytes pro Token | KV pro 100.000-Token-Sequenz |
|---|---|---|---|
| Multi-Head Attention | 64 | 2.097.152 | 209,7 GB |
| Grouped-Query Attention | 8 | 262.144 | 26,2 GB |
| Multi-Query Attention | 1 | 32.768 | 3,28 GB |
Dies sind dezimale GB und rechnerische Speicherwerte, keine gemessene GPU-Auslastung oder gleichzeitiger Durchsatz. Ein wartender Agent, dessen KV-Zustand ausgelagert wurde, belegt nicht denselben HBM wie einer mit vollständig residentem Cache. Prefix-Wiederverwendung und Paging machen die pauschale Gleichung „ein Agent gleich ein vollständiger Cache“ zusätzlich unzuverlässig.
Angebotsseite: Was die Quellen tatsächlich belegen
Micron beschrieb für dieselbe Bitmenge ein ungefähres Wafer-Kapazitätsverhältnis von 3:1 zwischen HBM und DDR5; bei späteren HBM-Generationen könne dieses Verhältnis steigen.1 Das ist eine Branchenabschätzung und keine universelle Umrechnung für jeden Prozess und jedes Produkt. TrendForce prognostizierte für die drei größten Anbieter, dass HBM bis Ende 2027 ungefähr 30 % des DRAM-Wafer-Einsatzes, aber 13 % der DRAM-Bitmenge ausmachen werde.2 Diese Zahlen sind eine Prognose und stützen die Richtung des Wafer-Effekts. Sie sind kein physikalisches Gesetz und keine Zusage für den Ausstoß 2027.
NVIDIA nennt in vorläufigen Spezifikationen bis zu 288 GB HBM4 pro Rubin-GPU.3 Die offiziell angegebene HGX B300 hat 270 GB HBM3E pro GPU; für GB300 NVL72 sind es 279 GB.4 Diese Produkte dürfen nicht unter einer einheitlichen „288 GB B300“-Angabe zusammengefasst werden.
TrendForce berichtete im August 2026, dass NVIDIA mehrere HBM-Stack-Varianten für Rubin Ultra prüfe, und stellte ausdrücklich fest, dass die endgültige Spezifikation noch nicht feststeht.5 Eine mögliche Variante mit weniger Kapazität ist ein Szenario, kein angekündigtes Rubin-Ultra-Produkt mit 192 GB und keine bestätigte Kürzung gegenüber Rubin mit 288 GB. Die frühere Fassung dieses Beitrags stellte den Vergleich fälschlich als Produktschritt dar.
Ein ausdrücklich hypothetisches Kapazitätsszenario
Angenommen, eine GPU hat 288 GB nutzbaren angegebenen Speicher und 40 GB werden für Gewichte, Aktivierungen und Laufzeit reserviert. Die verbleibenden 248 GB könnten höchstens 248 / 7,0272 ≈ 35,3 vollständige Sitzungen mit je 100.000 Token halten, wenn ein bestimmtes Modell 70.272 KV-Bytes pro Token benötigt. Bei einer sonst identischen hypothetischen 192-GB-GPU blieben 152 GB und damit 152 / 7,0272 ≈ 21,6 solcher Sitzungen. Das ist eine 39-prozentige Verringerung des KV-Budgets in diesem Szenario (152 / 248), kein Beleg für spätere Rubin-Ultra-Spezifikationen oder eine gemessene Grenze für Anfragen. Andere Gewichte, Fragmentierung, Quantisierung und Auslagerung ändern beide Zahlen.
Für die Einsatzplanung zählen die tatsächlichen KV-Bytes pro Token des Modells und der für den Server reservierte Speicher. Danach sollte mit realistischen Kontextlängen, Cache-Sharing und Parallelität gemessen werden. Kapazität bestimmt, wie viele vollständige Kontexte resident sein können; Bandbreite, Rechenleistung, Scheduler und Verbindung beeinflussen die Geschwindigkeit. FP8-KV kann den Speicher für Werte mit zwei Bytes ungefähr halbieren, wenn die Implementierung dies unterstützt; Genauigkeit und Umsetzung müssen geprüft werden. Das Auslagern kalter KV-Daten in den Hostspeicher tauscht HBM-Kapazität gegen Übertragungsverkehr und Latenz.
Quellen und Produktstand geprüft am 29. September 2026. Prognosen und Szenarien sind entsprechend gekennzeichnet.
Footnotes
-
Micron-Investorenpräsentation zum Wafer-Verhältnis von HBM und DDR5. ↩
-
TrendForce, Prognose zu HBM-Wafer-Einsatz und Bitmenge, 2. Juni 2026. ↩
-
NVIDIA, Rubin-GPU-Architektur, vorläufige Kapazitätsangabe. ↩
-
NVIDIA-Blackwell-Ultra-Datenblatt, Speicherangaben für HGX B300 und GB300 NVL72. ↩
-
TrendForce, Prüfung der Rubin-Ultra-Konfiguration, 4. August 2026. ↩