Nachfragetreiber — KI-Use-Cases

Analyse-Dossier · Thema KI

KI-Use-Cases als Nachfragetreiber für Speicher & Storage

Dieses Dossier ordnet die KI-Anwendungen nicht nach Modalität, sondern danach, welchen Bedarf an Arbeitsspeicher (HBM, DRAM) und Storage (NAND) sie erzeugen — wie stark und welcher Art. Es ist die Nachfrage-Brücke zur Hardware-These: Von hier aus klickt man in jeden Use Case und sieht, wo die Sache 2026 steht und was das für den Speicher-/Storage-Bedarf bedeutet.

Thema: KI Typ: Analyse-Dossier (keine Investments darunter) Status: Use-Cases mit Quellen & Diagrammen (laufend) Speist: Arbeitsspeicher-These

Leitfrage

Welche KI-Use-Cases treiben den Bedarf an Arbeitsspeicher (HBM, DRAM) und Storage (NAND) — wie stark, welcher Art (Kapazität vs. Bandbreite), und landet die Last im Datacenter oder am Edge? Ziel ist nicht die App-Bewertung, sondern das Verständnis, welche Nachfrage die Memory-/Storage-These (z. B. Micron) trägt.

So ist die Matrix zu lesen

Jeder Use Case wird auf vier Bedarfsdimensionen bewertet. Speicher und Storage sind gleichgewichtig; Compute steht nur als Kontext dabei, weil er erklärt, warum Speicher-/Storage-Bedarf entsteht.

Die vier Dimensionen

  • HBM — Hochbandbreiten-Speicher am Beschleuniger (Modellgewichte, KV-Cache). Treiber: Training & LLM-Inferenz.
  • DRAM — Arbeitsspeicher im Server (Embedding-Tabellen, Vektor-Indizes, KV-Offload).
  • NAND / Storage — Trainings-Datenseen, generierter Output, Embeddings, Logs.
  • Compute (Kontext) — Trainings- und Inferenz-Last als Ursache, nicht als Bewertungsachse.

Skala & Querschnitt

Bedarfsintensität je Zelle:

H hoch   M mittel   N niedrig

Zusätzlich markiert: Edge vs. Datacenter. „N" bei HBM/DRAM heißt meist: Last liegt am Edge (Kameras, Autos, Geräte) und zählt nicht für Datacenter-Speicher.

Die Buchstaben sind ein qualitatives Analyse-Raster (Einschätzung). Quantitative Belege (GB je Modell, PB Trainingsdaten, $/Token-Trend) stehen mit klickbaren Quellen auf den einzelnen Use-Case-Seiten; einzelne noch nicht belegbare Werte bleiben dort als „Recherche ausstehend" markiert.

Nachfrage-Matrix

Sortiert nach Relevanz für die Speicher-/Storage-These. Use-Case-Namen sind in die jeweilige „Stand-der-Dinge"-Seite verlinkt.

Use Case HBM DRAM NAND / Storage Compute Profil
Empfehlung & Ranking MHHH Dual-Gigant (DRAM + Storage)
RAG & Dokumentenverarbeitung MHHM Dual (DRAM + Storage)
Text, Chat & Reasoning HHMH HBM-geführt
Code & Coding-Assistenten HHMH HBM-/speichergeführt
Agents & Automatisierung HHMH Speicher-Multiplikator
Video-Generierung MMHH Storage-geführt
Bild-Generierung MMMH ausgeglichen
Vision & Perzeption NNHH Storage-geführt · Edge-Inferenz
Robotik & physische KI NNHH Storage-geführt · Edge
Audio & Sprache NMMM leicht · hochfrequent
Wissenschaft & Bio MMHH Storage-geführt · schubweise

Datenquelle: assets/data/matrix.csv — bei Änderung Tabelle und CSV synchron halten. Die H/M/N-Einstufung ist eine Einschätzung; die zugrunde liegenden Fakten sind je Use-Case-Seite mit klickbaren Quellen hinterlegt.

Synthese — wer treibt was

Top-Treiber Arbeitsspeicher

  • HBM: Text/Reasoning, Code, Agents — KV-Cache und Modellgewichte am Beschleuniger. Reasoning und lange Kontexte sind der strukturelle Hebel.
  • DRAM: Empfehlung/Ranking (Embedding-Tabellen) und RAG (Vektor-Indizes) — der stetige, planbare Kapazitätstreiber.
  • Multiplikator: Agents ziehen auf bestehenden Modellen ein Vielfaches an Tokens/Kontext und damit Speicher.

Top-Treiber Storage (NAND)

  • Trainings-Datenseen: Vision/Perzeption (z. B. Fahrzeug-Logs), Video, Wissenschaft — Petabyte-Größenordnung.
  • Generierter Output: Video- und Bild-Generierung produzieren laufend große Dateien.
  • Vektoren & Logs: RAG/Dokumente und Empfehlung/Ranking erzeugen wachsende Embedding- und Event-Bestände.
Kernbefund: Die Speicher-These (HBM/DRAM) hängt v. a. an Reasoning/Agents und an Empfehlung/RAG; die Storage-These (NAND) an Trainings-Datenseen und generiertem Medien-Output. Vision & Robotik treiben viel Compute und Storage, aber wenig Datacenter-Speicher (Edge). Die Belege je Aussage stehen auf den verlinkten Use-Case-Seiten. Rückbezug: Themendossier Arbeitsspeicher (HBM-Lieferseite: SK Hynix, Micron).

Querschnitt: Edge vs. Datacenter

Für die Speicher-/Storage-These zählt v. a., wo die Last anfällt. Faustregel des Dossiers:

Datacenter (zählt für die These)

LLM-Inferenz & -Training, Empfehlungs-/Ranking-Systeme der Plattformen, Enterprise-RAG, Video-/Bild-Generierung, wissenschaftliches Training. Hier sitzen HBM, Server-DRAM und Datacenter-NAND.

Edge (zählt kaum für DC-Speicher)

Perzeptions-Inferenz in Kameras/Fahrzeugen, On-Device-Robotik, viel On-Device-Audio. Treibt Edge-Silizium; das zugehörige Training erzeugt aber Datacenter-Storage-Bedarf (Datenseen).

Use-Case-Seiten

Jede Seite zeigt den Stand der Dinge 2026 und übersetzt ihn in HBM-/DRAM-/NAND-Bedarf.

Dual-GigantEmpfehlung & RankingEmbedding-Tabellen (DRAM) + Clickstream-Datenseen (Storage). Wirtschaftlich heute die größte „KI". DualRAG & DokumentenverarbeitungVektor-Indizes (DRAM) + Korpora/Embeddings (Storage). Inkl. KI-Suche. HBM-geführtText, Chat & ReasoningKV-Cache und Kontextlänge treiben HBM. Reasoning vervielfacht die Tokens. HBM-/speichergeführtCode & Coding-AssistentenRiesige Repo-Kontexte und agentische Schleifen. MultiplikatorAgents & AutomatisierungViele Aufrufe, langer Kontext, parallele Instanzen — Hebel auf Speicher. Storage-geführtVideo-GenerierungCompute- und Storage-Monster: große Dateien, riesige Trainingsvideos. ausgeglichenBild-GenerierungDiffusion, moderater Speicher, hohe Stückzahl an Output. Storage · EdgeVision & PerzeptionErkennen statt erzeugen. Training = Datenseen, Inferenz am Edge. Storage · EdgeRobotik & physische KIWeltmodelle/Sim im DC, Inferenz on-device. leichtAudio & SpracheSTT/TTS/Voice-Agents: günstig je Einheit, aber hochfrequent und latenz-sensibel. burstyWissenschaft & BioDrug Discovery, Protein/Materialien, Wetter — schubweises Training, große Datasets.

Offene Punkte / Recherche-Checkliste

  • Je Use Case die Bedarfssignatur mit harten Zahlen unterlegen (GB HBM je Modellklasse, PB Trainingsdaten, Embedding-Tabellengrößen).
  • $/Token- und $/GB-Trends als Treiber/Bremse der Nachfrage erfassen.
  • Datacenter- vs. Edge-Anteil je Use Case quantifizieren.
  • Marktgrößen/Wachstum je Segment belegen (Primär- vor Sekundärquellen).
  • Synthese-Kernbefund mit Quellen härten und mit der Arbeitsspeicher-These verknüpfen.
  • Reifegrad-Ampeln je Use Case beim nächsten Review aktualisieren (Stand-Datum führen).