Upgrade to Pro — share decks privately, control downloads, hide ads and more …

KI im Rechenzentrum: Storage anders denken?

KI im Rechenzentrum: Storage anders denken?

Künstliche Intelligenz (KI) revolutioniert Geschäftsmodelle und -prozesse, erfordert aber gleichzeitig neue Paradigmen in der zugrundeliegenden IT-Infrastruktur.

Im Vortrag beleuchten Wolfgang und Kerstin unter anderem spezifische Anforderungen in den Phasen Training und Inferenz, erklären, warum herkömmliche Storage-Lösungen scheitern (müssen), und zeigen sinnvolle Ansätze für den Betrieb einer optimalen Infrastruktur für KI-Workloads auf.

Dabei konzentrieren sie sich auf die Bereiche Storage, Memory und Speichernetzwerk. Es werden technologische Optionen und Architekturbeispiele vorgestellt. Führungskräfte und technische Verantwortliche erhalten Hinweise für die Auswahl und Beschaffung geeigneter Produkte.

Avatar for Wolfgang Stief

Wolfgang Stief

October 23, 2025
Tweet

More Decks by Wolfgang Stief

Other Decks in Technology

Transcript

  1. # whoami Kerstin Mende-Stief ‣ zertifizierter grundschützer & geschä ft

    sfortführer ‣ prompt engineer, natürlich auch zertifiziert ‣ experte für so einiges ‣ seit 1.9. vollzeit-journalist ‣ raubtierversorger, nicht zertifiziert Wolfgang Stief ‣ Dipl.-Ing. Elektrotechnik ‣ »irgendwas mit Computern« seit 1998 ‣ Solaris, Linux, Storage, verteilte Dateisysteme, Dokumentation ‣ Alteisen, Haus & Hof, Garagenschreinerei (»was mit Holz machen«)
  2. # cat /etc/motd ‣ KI Basics und ein paar Begri

    ff e, die wir weiter hinten brauchen ‣ Storage-Anforderungen in den verschiedenen Phasen eines LLM ‣ (moderne) Technologien für diese Anforderungen Hardware, So ft ware, Protokolle, Infrastruktur ‣ Fein. Und was soll ich jetzt einkaufen? ‣ Q & A ‣ nur Storage, keine generelle KI-Infrastruktur ‣ nur Storage, kein KI HowTo ‣ wir sind Techniker, keine Juristen ‣ Einführung/Überblick, es gibt keine Konfigurationsdetails ‣ on-prem only, wir reden nicht über KI-Cloud-Features
  3. KI ist nicht gleich KI 95% der KI-Projekte scheitern. Warum?

    ‣ kein Plan ‣ keine Sicherheitsstrategie ‣ kulturelle und organisatorische Versäumnisse ‣ keine Ahnung Oder wissen Sie was LSTM, VLM oder MLM sind? Und was der Unterschied zwischen Training und Inference ist? Oder warum Sie jetzt auch noch RAG brauchen? Wozu Tokens und Parameter gut sind?
  4. Und dann auch noch extra Storage für KI?! Daten nur

    sammeln reicht nicht. Daten müssen (u. a.): ‣ kuratiert ‣ klassifiziert ‣ sortiert ‣ indiziert und angereichert ‣ vektorisiert sowie ‣ demokratisiert werden. Und das nicht nur schnell, sondern auch noch compliant und sicher – außer es macht Ihnen nichts aus, dass Ihre Röntgenbilder und Kreditanträge im Darknet ausgewertet werden.
  5. ‣ 100% write ‣ sequential ‣ + Netzwerk ‣ NVMe

    SSDs Welchen Storage will KI? Daten sammeln Daten aufbereiten Training Checkpointing Inference + RAG https://commoncrawl.org/blog/september-2025-crawl-archive-now-available https://www.together.ai/blog/redpajama-v2-faq
  6. ‣ Größenordnung ~1%+ des Datasets (raw) ‣ ~90:10 read:write ‣

    sequential ‣ + CPU ‣ NVMe SSDs Welchen Storage will KI? Daten sammeln Daten aufbereiten Training Checkpointing Inference + RAG
  7. ‣ Größenordnung ~1%+ des Datasets (raw) ‣ ~95:5 read:write ‣

    random access ‣ + GPU ‣ je 1B Parameter ca. 24GB GPU-Memory Minimum (viel) mehr ist besser (=schneller) GPT-3: 175B, Llama 7B…70B ‣ NVMe SSDs + HBM + schnellen Transfer SSD ➛ HBM Welchen Storage will KI? Daten sammeln Daten aufbereiten Training Checkpointing Inference + RAG
  8. ‣ Größenordnung ~5%+ des Datasets (raw) ‣ 100% sequential write

    (Normalbetrieb) ‣ + GPU ‣ während Training: Checkpoints in regelmäßigen Abständen ‣ während Checkpoint schreiben »steht« ein Teil der GPUs ➛ teuer je schneller Checkpoints weg geschrieben werden können, umso besser ‣ ~100% sequential read (Restore nach Abbruch) ‣ während Restore »stehen« alle GPUs ➛ teuer ‣ NVMe + HBM + schneller Transfer HBM ↔︎ SSD Welchen Storage will KI? Daten sammeln Daten aufbereiten Training Checkpointing Inference + RAG
  9. ‣ Größenordnung ~1%+ des Datasets (raw) ‣ ~100% random read

    (mehr write bei Multimedia ≠ Text) ‣ + GPU (insbes. Multimedia Modelle) ‣ RAG erzeugt write, häufig vernachlässigbar und nicht kritisch ‣ NVMe SSDs ‣ Storage ist typ. Bottleneck @ LLM Inference Welchen Storage will KI? Daten sammeln Daten aufbereiten Training Checkpointing Inference + RAG
  10. Speicher-Hierarchie (noch ganz ohne KI) ‣ SSD vs. DIMM/HBM: x100

    ‣ DIMM/HBM vs. CPU-$$: x10 Memory Wall CPUs werden schneller schneller, als DRAM hinterherkommt. ‣ formuliert 1994 ‣ Moores Law ca. Verdoppelung / 18 Monate. ‣ DRAM ca. 7%-10% Verbesserung / Jahr. ➛ riesige L2/L3-Caches und HBM CPU Register L1/L2/L3 Cache DIMM / HBM Storage Class Memory (PCM/Optane, NVDIMM) Flash Memory, SSD (NVMe) HDD (SATA, SAS) »Rotating Rust« Archive und Backup (typ. Tape) 1 ns 10 ns … 20 ns 120 ns (HBM3) 160 ns (DDR5) 300 ns 20 µs 10 ms 20 s Adressierung Byte Adressierung Block
  11. Hauptspeicher – DDR/GDDR und HBM (Graphics) Dual Data Rate Memory

    ‣ DDR5 (2020): max. 70,4 GB/s DDR6 (geplant 2027): max. 134,4 GB/s ‣ GDDR7 (2024): max. 1500 GB/s ‣ PCIe 6.0 (2022): 7,56 GB/s x1 (max x16) hierarchisch High Bandwidth Memory ‣ HBM4 (April 2025): 2048 GB/s stacking, 3D stacking TSV – Through-Silicon Via ‣ NVLink 5.0 (2023): 1800 GB/s Mesh GPU HBM HBM GPU HBM HBM NVLink CPU DDR5 MMU CPU DDR5 MMU PCIe
  12. (R)DMA und GPUdirect herkömmliches I/O ‣ vom Device über CPU

    ins RAM ‣ vom RAM über CPU in GPU (R)DMA ‣ vom (remote) Device ins RAM ‣ vom RAM über CPU in GPU GPUdirect ‣ vom (remote) Device in die GPU I/O Ethernet, Infiniband FC, SAS/SATA, NVMe PCIe Hub CPU RAM GPU HBM I/O Ethernet, Infiniband FC, SAS/SATA, NVMe PCIe Hub CPU RAM GPU HBM I/O Ethernet, Infiniband FC, SAS/SATA, NVMe PCIe Hub CPU RAM GPU HBM
  13. ‣ Peripheral Component Interconnect ‣ parallel (PCI) ➛ seriell (PCIe)

    ➾ einfacher und schneller als parallel PCIe 1.0 in 2003, 250 MB/s je Lane ‣ immer einzelne Lanes, können parallel geschaltet werden (x2, x4, x8, x16) ‣ Point-to-Point, switched, vollpuplex ‣ aktuell: PCI 6.2 (2022), x1 = 7,563 GB/s (x16 = 121 GB/s) – Devices verfügbar PCIe 7.0 (2025), x1 = 15,125 GB/s (x16=242 GB/s) – Devices ca. ab Ende 2026 PCIe 8.0 (geplant 2028), x1 = 30,25 GB/s (x16 = 484 GB/s) – Devices ab ca. 2030 ‣ www.pcisig.com PCI express – NVM express – CXL
  14. ‣ Non-volatile Memory express ‣ NVMe 1.0 in 2011, aktuell

    NVMe 2.3 (August 2025) ‣ Protokoll für Flash-Storage Block Management, Zoned Name Spaces (ZNS, write amplification), Live Migration, Out-of-Band Management, Network Boot/UEFI, Encryption per I/O, u. a. ‣ 64k Command Queues mit 64k Commands je Queue SATA/SAS: 1 Queue mit 32/254 Commands (ausreichend für HDD) ‣ Übertragung per PCIe NVMe-oF, NVMe over TCP, NVMe over RDMA ‣ Verschiedene Stecker/Anschlüsse! ‣ www.nvmexpress.org PCI express – NVM express – CXL
  15. ‣ Compute Express Link »Remote PCIe« ➛ disaggregated infrastructure, composable

    infrastructure ‣ CXL 1.0 in 2019, basiert auf PCIe 5.0 – aktuell CXL 3.2 (12/2024) auf Basis PCIe 6.0 ‣ CXL 1.0: single machine CXL 2.0: 2-16 Systeme, single switch CXL 3.0: Fabric Topology, 4096 end devices ‣ CXL.memory, CXL.cache, CXL.io ‣ Resource Pooling, Device Hotplug, Device Pooling, Memory Pooling ‣ Auf Version/Kompatibilität achten, in Standardisierung ist noch viel Bewegung! ‣ www.computeexpresslink.org PCI express – NVM express – CXL
  16. ‣ skaliert über Parallelität Disks, Storage Nodes, Netzwerkverbindungen ‣ kommerziell

    und Open Source Ceph, IBM Spectrum Scale (aka GPFS) Quantum StorNext, Quobyte, BeeGFS Hammerspace Data Platform, MooseFS, DDN EXAscale, DAOS, WekaIO, Lustre u. a. ‣ Global Name Space / Single Name Space ‣ Redundante Datenhaltung mehrfache Kopien, Erasure Coding ‣ Erasure Coding: Funktionsweise, Vor-/Nachteile (storage2day 2019) https://speakerdeck.com/stiefkind/erasure-coding-in-theorie-und-praxis https://www.youtube.com/watch?v=spEccKD6mj8 Verteilte Dateisysteme Metadataserver Storage Client Storage Client Storage Client Storage Node Storage Node … … Storage Node
  17. ‣ pNFS als optionales Feature seit NFSv4.1 ‣ NFSv4: stateless

    ➛ stateful ‣ unterstützt RDMA ‣ Flexible Files layout type (RFC8435) NFSv3 als Storage Protocol NFSv3 als Storage Management Protocol ‣ NFS v4.2 (RFC7862) Server-Side Clone and Copy, Application I/O Advise, Sparse Files and Space Reservation, Application Data Block Support, Labeled NFS, Layout Enhancements ‣ Bestandteil des Linux-Kernels, keine proprietäre So ft ware notwendig ‣ Performance kommt vom darunter liegenden Block-Layer (XFS, ext4, ZFS u. a.) Verteilte Dateisysteme – pNFS und NFSv4.2 Metadataserver Storage Client Storage Client Storage Client Storage Node Storage Node … … Storage Node
  18. ‣ Requirement: schnelle Kommunikation, geringe Latenz, hohe Bandbreite, RDMA/ GPUDirect

    ‣ Infiniband: XDR bis 2400 Gbit/s (x12, 2024) ‣ Fibre Channel: 128GFC aka Gen8 @ 99,4 Gbit/s (2022) ‣ Ethernet: bis 800 Gbit/s (2024) Spine-Leaf-Architektur ‣ Next: UltraEthernet ‣ UEC gegründet Juli 2023 ‣ »overcome shortcomings of RDMA protocol« Multipathing, Congestion Management, Scaling Limitations, Recovery Mechanisms ‣ getrieben von KI/HPC Infrastruktur ‣ »one ring to rule them all« Communicate!
  19. Bescha ff ung und Benchmarks? ‣ MLPerf Storage https://github.com/mlcommons Doku

    und Ergebnisse nur innerhalb Version vergleichbar ‣ Storage Perfomance Council SPC-2 (large scale data movement) nicht so richtig KI/ML ‣ IO500 https://io500.org/ »ganz große Hobel« (HPC) ‣ Einheitsgrößen sind aus. ‣ Storage Benchmarks – The Good, the Bad and the Ugly https://speakerdeck.com/stiefkind/storage-benchmarks-the-good-the-bad-and-the-ugly https://www.youtube.com/watch?v=slpJ3ZBbuww ≈100% of all benchmarks are wrong –Brendan Gregg (Intel)
  20. Und was ist mit Backup? Oder Langzeitarchiv? ‣ Modell oder

    Trainingsdaten i. d. R. wieder bescha ff bar ‣ RAG-Daten sollten »in anderem Backup« sein ‣ EU AI Act Dokumentationspflicht zu Datenherkun ft , Aufbereitung, Modellierung fordert nicht explizit ein Archiv ‣ Branchenvorgaben können davon abweichen! z. B. Pharma/Medical
  21. Kerstin Mende-Stief Wolfgang Stief [email protected] https://www.linkedin.com/in/wstief @stiefkind.bsky.social @[email protected] https://speakerdeck.com/stiefkind https://datadisrupted.tech/

    https://mende.media/ Du willst auf dem Laufenden bleiben? Werde Teil der https://www.computingdeutschland.de/-Community oder folge Kerstin auf LinkedIn: https://www.linkedin.com/in/mende/ Danke!