Wenn sich Unternehmen entscheiden, KI-Entwicklung zu betreiben, sollten die verwendeten Speichersysteme den resultierenden Anforderungen gerecht werden können. Moderne KI- und Big Data-optimierte Speicherlösungen kombinieren NAND-Flash mit verteilten software-definierten Speicherarchitekturen inklusive der Möglichkeit zur Cloud-Integration, um eine maximale Performance, Flexibilität und Skalierbarkeit zu erreichen…
Um was geht es in diesem Blogpost? KI-Applikationen und deren Entwicklung stellen verschiedenste Anforderungen an die Speicherinfrastruktur. Generell ergeben sich vor dem Start deshalb eine Reihe von Fragen: Welche Modelle und Workloads stehen im Fokus? GPU-Training, Data Lakes, Inferenz, RAG…? Welche Anforderungen entstehen bei den einzelnen Phasen des KI-Prozesses: geht es um große Sprachmodelle (LLMs) oder kleinere Varianten? Welche Rolle spielt der Einsatz von Vektordatenbanken? Wie schnell sollen Analysedaten für Inferenz und Feinabstimmung bereitstehen? Wie können auch umfangreiche Datensätze kosteneffizient gesichert werden, etc. ?
Hintergrund
GPUs sollen bekanntlich immer genügend Daten zur Verfügung haben, denn unausgelastet verlangsamen Sie den gesamten Prozess und sind teuer. Was bedeuten Latenzen und-/oder der begrenzte Durchsatz meiner vorhandenen Speichersysteme und wie wirkt sich das auf die Leistung eines KI-Gesamtsystems aus. Beispiel: Bei komplexen Deep Learning (DL) Algorithmen bedeutet ein langsamer Speicher immer eine reduzierte maschinelle Lernleistung, denn ML-Implementierungen sind stark auf parallele Berechnungen angewiesen.
Die Sicht der KI-Anwendung
Unter Applikationsgesichtspunkten soll idealerweise eine möglichst hohe "Ingest"-Bandbreite für Zugriffsmuster von kleinen bis großen Files zur Verfügung stehen. Bei kleineren Datensätzen ist das nicht so kritisch, weil neuronale Netzwerke innerhalb jeder Trainingseinheit auf die gleichen Daten zugreifen; und diese können dann lokal auf Flash oder RAM zwischengespeichert werden. Bei sehr vielen großen Datensätzen ergeben sich hingegen eine Reihe von Herausforderungen in Bezug auf Storage, Protokolle, Filesysteme, Server-Technologien und Netzwerkkomponenten.
Zufällige Leseleistung bei geringer Warteschlangen-Tiefe (queue depth, QD) ist für NAND Flashspeicher aus Performance-Sicht für Enterprise-Workloads-Sicht nicht ganz unproblematisch und in der Praxis ein Leistungskriterium für die Subsystem-Performance. Persistent Memory auf Basis Storage Class Memory (SCM) bietet sich als Ergänzung an; die allerdings zu höheren Kosten. Dafür kann SCM eine 5-bis 10-fache Leistung gegenüber SSDs bei einer Random Read Queue Depth Range von 1-4 erzielen.
Wie kann NFS für die KI-Entwicklung genutzt werden?
Für einfache Workloads ist NFS ausreichend, vor allem auf Enterprise-NAS-Systemen mit Caching und Load Balancing. Weniger anspruchsvolle Inferenz-Workloads oder auch modulares KI-Training mit reduzierten parallelen Datenzugriffen fallen in diese Kategorie.
Für Rechen- und datenintensive KI-Training-Workloads, typisch bei Deep Learning, HPC-Simulationen und anderen Big Data Anwendungen, ist je nach Umfang eine Standard NFS-Implementierung der potentielle Engpass. Alternativen sind hier parallele Dateisysteme oder moderne Enterprise-Scale-Out-NAS-Lösungen, falls die Workloads von intelligenten Caching-Mechanismen wie z.B. SSD-basierten Read-Caching-/Tiering profitieren. Dazu gehören scale-out Enterprise NAS-Systeme, die parallele NFS-Cluster-Software nutzen, um (NFS) Performance-Bottlenecks zu minimieren. Wobei NFS nicht immer das alleinige Problem ist, sondern Engpässe natürlich auch an anderen Stellen der Systemumgebung auftauchen können.
Technische Anmerkung zu NFS: Standard NFS ist anfällig für einzelne Fehlerpunkte, wie die Verbindung eines einzelnen Mount-Points. Das bedeutet, ein Link-Failover kann dann nicht durchgeführt werden und die Host-Dienste sind unterbrochen. NFS-Multipathing (s.a. open euler) stellt sicher, dass mehrere Verbindungen zwischen Client und dem Server für jeden einzelnen Mount-Point verbunden sind, um die E/A-Übertragung über diese Verbindungen durchzuführen. Die Leistung wird damit verbessert. Auch wird der Verbindungsstatus regelmäßig überprüft, um eine schnelle E/A-Ausfallsicherung bei einem Verbindungsfehler zu gewährleisten.
Wenn ein Unternehmen leistungsstarke KI-Modelle trainiert, ist eine Scale-Out-Storagelösung sinnvoll. Fragen in dem Zusammenhang sind, ob Objekt Storage, Block- und Filestorage als integrierter Ansatz vorhanden ist und welche Schwerpunkte aus Anwendungssicht gesetzt werden. Kriterien, welches Scale-Out-System zu den jeweiligen KI-Use Cases am besten passen, können sein:
- Maximale I/O Performance und massive Datenmengen wie zum Training von ML-Modellen mit vielen GPUs.
- Wird neben File & Objektspeicher noch Block-Storage benötigt?
- Open-Source-Alternativen mit nativer Integration in Kubernetes, OpenStack & S3
- Reichen mögliche Erweiterungen zu meiner vorhandenen Enterprise Scale-out NAS-Lösung aus?
Bildquelle: SNIA NSF, Networking Storage. Externer Link > https://www.snia.org/
Übersicht zu wichtigen Leistungsanforderungen aus Storagesicht:
1. Skalierbare Speicherkapazitäten
KI-Modelle erfordern je nach Modell sehr große Datenmengen für Training und Inferenz. Dynamisch erweiterbare Lösungen für NAS, SAN sowie Object Storage sind nötig.
Kompression- und Deduplizierungstools um den Speicherbedarf zu reduzieren und Kosten zu senken. High-Density-Architekturen reduzieren den Platzbedarf und reduzieren Komplexität.
2. Hohe IOPS mit geringer Latenz
KI-Workloads benötigen auf Grund des datenintensiven Charakters schnelle Lese- und Schreibzugriffe.
NVMe-SSDs und persistenter Speicher wie Storage-Class Memory (SCM) sind dafür konzipiert, ergänzt um den begrenzten Einsatz von DRAM für Caching.
3. Hohe Bandbreite
Für das Training großer Modelle werden Daten in großem Umfang geladen.
RDMA (Remote Direct Memory Access) und eine schnelle Netzwerkanbindung (z.B. 100 Gbit/s Ethernet oder InfiniBand) sind gefordert.
4. Parallelität
Der Speicher muss sich einfach erweitern lassen. Scale-out-Architekturen zur parallelen Datenverarbeitung bieten sich an.
5. Unterstützung für verteilte Dateisysteme
Distributed Workloads profitieren von parallelen scale-out Filesystemen
S3 Object Storage ist für große KI-Datasets sinnvoll
Große Speichercluster können aus CAPEX-Sicht teuer sein, weshalb auch Tiering-Konzepte wie SSD für Hot Data, HDD/Tape für Cold Data und Active Archiving in Frage kommen können.
6. Datenpersistenz und Verfügbarkeit
Ausfallsicherheit und Redundanz durch verteilte Storage-Cluster.
Snapshots, Replikation und Backup berücksichtigen.
7. Sicherheit und Datenschutz
Verschlüsselung, Zugriffskontrolle und Prozesse wie Auditing sind für sensible Daten wichtig.
Die DSGVO- und Compliance-Konformität muss gewährleistet sein.
8. Kritischer Faktor Metadaten-Management
Metadatenoperationen stehen für rund 50 % aller Filesystem-Operationen. Aber die Skalierung von Metadaten ist im Vergleich zur Skalierung des Speichers - der ja wiederum den I/O Durchsatz linear skalieren soll - komplexer. Dies liegt primär in hierarchisch und voneinander abhängigen Natur der Dateisystem-Metadaten.
Nun steigt die Menge an Metadaten-Operationen bei sehr großen KI- oder auch HPC-Workloads immer weiter an. Kritische Faktoren sind neben der Verarbeitungsleistung deshalb die Verfügbarkeit von Metadaten. Generell ist die möglichst einfache Verwaltbarkeit ohne weitere manuelle Interventionen bzw. zusätzliche Konfigurationsarbeiten anzustreben (automatisiertes storage management).
Beispiel CephFS: hier werden die Metadaten von den eigentlichen Daten entkoppelt, um den RADOS Cluster (Reliable Autonomic Distributed Object Store = Ceph object storage cluster) mit zusätzlichen Workloads nicht zu belasten. Die Metadaten werden von einem Cluster von Metadatenservern (MDS) verarbeitet. CephFS verteilt die Metadaten über sog. Dynamic Subtree Partitioning auf die MDSs.
Beispiel QuobyteFS: das Filesystem speichert die Metadaten in einem verteilten und replizierten Key-Value-Store zur schnellen Metadaten-Speicherung über eine File Query Engine. Es wird weder eine Kopie der Datei-Metadaten benötigt, die synchron gehalten werden muss, noch ist eine weitere Datenbanksystem-Schicht erforderlich. Über die File Query Engine werden Abfragen parallel auf allen Metadatenservern ausgeführt, um schnelle Scans über den gesamten Cluster oder ausgewählte Volumes zu erzielen.
Fazit
Nicht immer muss für KI-Projekte alles gleich komplett neu beschafft werden. Wenn man startet, kann es für viele kleinere- und mittlere Unternehmensgrößen durchaus sinnvoll sein, bewährte vorhandene Enterprise Storage Funktionen mit KI-spezifischen Anforderungen zu kombinieren. Enterprise-Storage bedeutet in dem Zusammenhang hohe Zuverlässigkeit, einfache Integration in bestehende IT-Umgebungen sowie umfassenden Support. Dies kombiniert mit KI-spezifischen Leistungsmerkmalen wie hohe Bandbreiten, niedrige Latenzen, parallele Datenzugriffe und ausreichend hohe Skalierbarkeit ergibt eine Lösung mit Potential, die es ermöglicht bei Bedarf schrittweise auf spezialisierte, leistungsfähigere Systeme umzusteigen, falls die KI-Projekte weiter wachsen.
Allerdings ist es bei KI wichtig, die Speicherarchitektur stets im Auge zu behalten und wo nötig, gezielt zu modernisieren. Organisationen, die mit Hilfe von verteilten und parallelen scale-out File-Systemen - neben Block- und Object Storage - arbeiten, sind dann in der Lage, mit Unterstützung von Software und Technologien wie NVMe-/oF das Potenzial von KI und der damit verbundenen Vorteile für die Anwendungsebene besser auszuschöpfen.
(Stand: Mai 2025).
Querverweis:
> KIOXIA stellt AiSAQ-Software vor: DRAM-Bedarf und damit Kosten in generativen KI-Systemen reduzieren
> Speicherkosten und Energieverbrauch von SSDs mit NVMe FDP Flexible Data Placement senken
> Welche Graphdatenbank für welchen Anwendungsfall?