Zum Inhalt springen
Kurzer Hinweis: flozi00 TechHub ist ein Solo-Nebenprojekt neben einem Vollzeitjob — persönliche Lernnotizen, keine offiziellen Aussagen. Kritische Schritte selbst prüfen.

HBM-Kapazität und die Kosten des KV-Caches

Wie Kontextlänge GPU-Speicher belegt, warum HBM pro Bit mehr Waferkapazität als DDR5 benötigt und was NVIDIA und TrendForce tatsächlich zur Kapazität von Rubin und Rubin Ultra sagen.

3 Min. Lesezeitflozi00
aimachine-learninggpuhbmgpu-memoryinferencehardware
Direkt zum Fachartikel
Sehen · ausprobieren · verstehen

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

Schritt 1 / 3Bereits belegten Speicher abziehen

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.

Kosten & RessourcenAktueller SchrittBaustein anklicken, um ihn zu erklären
Verfügbare HBM-Kapazität
Die Kapazität des konkreten Systems statt einer spekulativen SKU verwenden.
Gewichte + Laufzeitreserven
Diese Bytes stehen dem KV-Pool nicht zur Verfügung.
Verbleibender KV-Pool
Verfügbarer HBM abzüglich anderer gleichzeitig gehaltener Zustände.
  1. Verfügbare HBM-Kapazität Verbleibender KV-Pool
    Gesamtkapazität
  2. Gewichte + Laufzeitreserven Verbleibender KV-Pool
    abziehen
Das solltest du mitnehmen

Knappes HBM begrenzt das Speicherbudget und die Platzierung; gehaltene Kapazität allein ist kein Serving-Durchsatz.

Lieferprognosen und hypothetische SKU-Vergleiche sind datierte Szenarien. Präfixteilung, Paging und Offload können das einfache Sitzungsbudget verändern.

Begriffe und vollständiger Ablauf
Im schnellen Speicher gehalten
Zustand, der die betrachtete Speicherebene gerade belegt.
KV-Pool
Der für Attention-Keys und -Values verfügbare Teil des GPU-Speichers.
  1. Bereits belegten Speicher abziehen

    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.

  2. Eine Sitzung korrekt dimensionieren

    Bei klassischer Attention wächst gehaltener KV-Speicher mit Schichten, KV-Köpfen, Kopfdimension, Elementgröße und Tokens. Latente oder hybride Architekturen brauchen ihre eigene Zustandsdefinition.

  3. Den Quotienten als Kapazität verstehen

    Pool geteilt durch Bytes je Sitzung schätzt, wie viele Kontexte im Speicher bleiben können. Das misst keine Anfragen pro Sekunde: Aktives Decode benötigt Bandbreite und Rechenleistung; pausierte Sitzungen können anderswo liegen.

Alle Verbindungen

  • Verfügbare HBM-Kapazität → Verbleibender KV-Pool: Gesamtkapazität
  • Gewichte + Laufzeitreserven → Verbleibender KV-Pool: abziehen
  • Modell- und Kontextgeometrie → KV-Bytes je gehaltener Sitzung: Cache dimensionieren
  • Verbleibender KV-Pool → Kapazität gehaltener Sitzungen: verfügbares Budget
  • KV-Bytes je gehaltener Sitzung → Kapazität gehaltener Sitzungen: Bedarf je Sitzung
Du bestimmst das Tempo. Pausiere jederzeit oder wähle einen Schritt aus.

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-LayoutKV-HeadsBytes pro TokenKV pro 100.000-Token-Sequenz
Multi-Head Attention642.097.152209,7 GB
Grouped-Query Attention8262.14426,2 GB
Multi-Query Attention132.7683,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

  1. Micron-Investorenpräsentation zum Wafer-Verhältnis von HBM und DDR5. ↩

  2. TrendForce, Prognose zu HBM-Wafer-Einsatz und Bitmenge, 2. Juni 2026. ↩

  3. NVIDIA, Rubin-GPU-Architektur, vorläufige Kapazitätsangabe. ↩

  4. NVIDIA-Blackwell-Ultra-Datenblatt, Speicherangaben für HGX B300 und GB300 NVL72. ↩

  5. TrendForce, Prüfung der Rubin-Ultra-Konfiguration, 4. August 2026. ↩