WISSEN > GLOBAL FILESYSTEM -> AI DATA LAKE
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
AI Data Lake
Die Datenbasis für KI, RAG und Analytics
Das sollten Sie mitnehmen:
- Der Datenpfad entscheidet, nicht die Storage-Klasse.
Maßgeblich ist nicht, wo Daten liegen, sondern wie sie zum Compute gelangen.
- File und Object bleiben beide Datenquellen.
Der Zugriffsweg ist nicht mehr zwingend an die Speicherform gebunden.
- Große Objekte und kleine Dateien sind zwei Regime.
Im einen Fall zählt Bandbreite, im anderen Request Rate, Latenz und Metadatenoperationen.
- Kapazität und Latenz gehören nicht in dieselbe Schicht.
Ein Capacity Tier und ein latenzoptimierter Compute-Zugriff verfolgen unterschiedliche Ziele.
- KI ist kein einheitlicher Workload.
RAG-Ingestion, Retrieval, Training und Checkpointing besitzen jeweils eigene Storage-Profile.
AI Data Lake
Inhaltsverzeichnis
- Der Storage steht am Anfang einer Kette, nicht im Zentrum
- Ein Data Lake muss nicht in einem Object Store beginnen
- Nicht die GPU bestimmt die Verarbeitungsgeschwindigkeit, sondern der Datenpfad
- Kapazität und Latenz gehören nicht zwingend in dieselbe Schicht
- Der Umweg über das Scratch-Dateisystem beginnt zu verschwinden
- Unter dem Begriff KI verbergen sich vier verschiedene Storage-Workloads
- Kapazität allein macht aus einer Datenablage keine Datenbasis
- Entfernung zwischen Storage und Compute ist eine Architekturentscheidung
- Fazit
- Quellen
Unternehmen besitzen meist bereits große Mengen potenziell KI-relevanter Daten. Sie liegen als Dokumente auf File Servern, als Office-Dateien und technische Unterlagen, als Bilder, Videos und Logdaten, als Datenbankexporte oder als Objekte in S3-kompatiblen Speichersystemen. Für KI reicht es jedoch nicht, dass diese Daten irgendwo gespeichert sind: Sie müssen auffindbar und zugänglich sein und in einer Form bereitstehen, die nachgelagerte Systeme verarbeiten können. Genau hier setzt die Idee eines AI Data Lake an.
Ein AI Data Lake ist dabei weder ein bestimmtes Produkt noch eine neue Storage-Klasse. Er beschreibt eine Datenarchitektur, in der große Mengen strukturierter und unstrukturierter Daten als gemeinsame Basis für KI, Retrieval-Augmented Generation, Machine Learning und Analytics zur Verfügung stehen. Die zentrale Architekturfrage lautet deshalb nicht nur, wo die Daten gespeichert werden, sondern wie sie vom primären Speicher bis zur KI-Verarbeitung gelangen.
Der Storage steht am Anfang einer Kette, nicht im Zentrum
Ein vereinfachter Datenpfad für RAG führt von den Originaldaten über Ingestion, Extraction, Chunking, Embeddings und Index bis zu Retrieval und LLM. Der Storage befindet sich damit am Anfang einer längeren Verarbeitungskette, und diese Position hat Konsequenzen für die Bewertung.
[Diagrammkandidat 1: RAG-Datenpfad als lineare Kette]
Ein AI Data Lake sollte deshalb nicht mit einem Vector Store oder einer RAG-Datenbank gleichgesetzt werden. Im Data Lake können Millionen PDF-, Office-, CAD-, Bild- oder Logdateien liegen; für ein RAG-System werden daraus relevante Inhalte extrahiert, segmentiert und anschließend in eine für semantisches Retrieval geeignete Repräsentation überführt. Die Originaldaten bleiben dabei erhalten, sodass mehrere logisch unterschiedliche Datenebenen nebeneinander entstehen.
Ebene
Typische Daten
Primärdaten
Dateien, Objekte, Dokumente, Bilder, Logs
Aufbereitete Daten
extrahierter Text, normalisierte Daten
Chunks
kleinere semantische Einheiten
Embeddings
numerische Vektorrepräsentationen
Index
Such- und Retrieval-Strukturen
KI-Kontext
für eine konkrete Anfrage ausgewählte Informationen
Der AI Data Lake bildet vor allem die persistente Basis, aus der diese weiteren Strukturen erzeugt werden. Wer ihn nach den Anforderungen des Retrievals dimensioniert, dimensioniert die falsche Ebene.
Ein Data Lake muss nicht in einem Object Store beginnen
Object Storage besitzt Eigenschaften, die für große Datenbestände relevant sind. Anders als ein klassisches Dateisystem organisiert er Daten nicht primär über hierarchische Verzeichnisse und Dateisystemoperationen; Anwendungen adressieren Objekte über eine Object API, verbreitet ist insbesondere die S3 API. Ein Objekt besteht vereinfacht aus Object Key, Daten und Metadaten. Das Modell eignet sich damit für Datenbestände, bei denen sehr viele unabhängige Objekte gespeichert und über Schnittstellen verarbeitet werden.
Hinzu kommt die Auslegung auf parallele Zugriffe. AWS beschreibt Amazon S3 ausdrücklich als sehr großes verteiltes System und empfiehlt für hohen Durchsatz mehrere parallele Requests über getrennte Verbindungen. Die dokumentierte Requestrate liegt bei mindestens 3.500 PUT-, COPY-, POST- und DELETE- beziehungsweise 5.500 GET- und HEAD-Operationen pro Sekunde je partitioniertem Präfix, wobei die Anzahl der Präfixe nicht begrenzt ist; große Objekte lassen sich zusätzlich über parallele Byte-Range-Requests lesen. Für KI-Pipelines ist das entscheidend, weil ein Compute-Cluster Objekte nicht sequenziell abarbeiten muss. Viele Worker können gleichzeitig unterschiedliche Objekte oder Objektbereiche lesen, sodass die aggregierte Datenrate mit der Parallelität des Verarbeitungssystems wächst — vorausgesetzt, Storage, Netzwerk und Compute bedienen diese Parallelität ebenfalls.
[Diagrammkandidat 2: Object Storage mit parallelen Worker-Zugriffen]
Daraus folgt jedoch nicht, dass KI gleichbedeutend mit Object Storage wäre. Ein großer Teil der Unternehmensdaten entsteht weiterhin in File-basierten Arbeitsabläufen: Office-Dokumente, Projektverzeichnisse, Engineering- und Forschungsdaten, Medienbestände, Benutzerverzeichnisse und gemeinsam bearbeitete Dokumente. Diese Daten werden über SMB oder NFS genutzt und besitzen eine gewachsene Verzeichnis-, Berechtigungs- und Arbeitsstruktur, die sich nicht folgenlos auflösen lässt.
Ein AI Data Lake bedeutet deshalb nicht zwangsläufig, sämtliche Unternehmensdaten zunächst physisch in einen neuen Object Store zu migrieren. In der Praxis begegnen uns drei Modelle. Im ersten werden die Daten in einen zentralen Object Store übernommen und von dort verarbeitet, was den Zugriff vereinheitlicht, aber einen zusätzlichen Ingestion- beziehungsweise Kopierprozess erzeugt. Im zweiten verbleiben bestehende Daten zunächst auf ihren jeweiligen Plattformen, und die KI-Datenpipeline greift auf mehrere Quellen zu. Im dritten stellt eine Storage-Architektur dieselben oder synchronisierte Datenbestände für unterschiedliche Zugriffsmethoden bereit, sodass klassische File-Workloads und datenorientierte Anwendungen enger zusammenrücken.
Das dritte Modell ist inzwischen keine theoretische Kategorie mehr. Mit S3 Files bietet AWS seit April 2026 Dateisystemzugriff auf S3-Buckets an, ohne dass die Daten S3 verlassen. Damit verliert die vertraute Gegenüberstellung von File und Object einen Teil ihrer Trennschärfe, denn der Zugriffsweg ist nicht mehr zwingend an die Speicherform gebunden. Welches Modell trägt, hängt davon ab, wo die Daten entstehen, wie häufig sie sich ändern und welche Anwendungen weiterhin darauf zugreifen müssen.
Nicht die GPU bestimmt die Verarbeitungsgeschwindigkeit, sondern der Datenpfad
Bei KI-Infrastruktur wird Performance häufig zuerst mit GPUs verbunden, doch das ist nur ein Teil des Systems. Eine GPU kann Daten nur verarbeiten, wenn die vorgelagerten Komponenten sie schnell genug bereitstellen, und der vollständige Pfad führt vom Storage über das Storage-Netzwerk, den Host, CPU und Memory sowie das Framework bis in den GPU-Speicher.
Wie ernst dieser Zusammenhang zu nehmen ist, zeigt die Messmethodik des MLPerf-Storage-Benchmarks von MLCommons. Als Durchsatz gilt dort ausschließlich die Leistung, die ein Storage-System liefern konnte, während sämtliche Beschleuniger bei mindestens 90 Prozent Auslastung blieben — die Beschleuniger also höchstens ein Zehntel der Zeit untätig auf Daten warteten. Aus der allgemeinen Feststellung, Storage könne zum Engpass werden, wird damit eine Kennzahl mit definiertem Schwellwert.
Für die Bewertung eines Systems unterscheiden wir mindestens vier Größen: den Durchsatz als pro Zeiteinheit übertragbare Datenmenge, die Request Rate als Anzahl einzelner Zugriffe pro Sekunde, die Latenz einer einzelnen Operation und die Parallelität als Anzahl gleichzeitig ausführbarer Operationen. Diese Größen sind nicht austauschbar. Ein System kann einen sehr hohen aggregierten Durchsatz erreichen und trotzdem für einen Workload mit vielen kleinen Zugriffen ungeeignet sein.
Besonders folgenreich ist dieser Unterschied für AI Data Lakes. Besteht ein Trainingsdatensatz aus wenigen sehr großen Dateien, lassen sich große Datenmengen über parallele sequenzielle Reads übertragen. Bei hundert Millionen Dateien mit jeweils wenigen Kilobyte entsteht dagegen ein vollkommen anderer Workload, weil für dieselbe Nutzdatenmenge sehr viel mehr einzelne Operationen erforderlich sind. Das Problem verschiebt sich von der Bandbreite hin zu Request Rate, Latenz, Metadatenoperationen und Parallelisierung.
Dass es sich um zwei getrennte Regime handelt, lässt sich an konkreten Schwellwerten ablesen. S3 Files streamt Lesevorgänge ab einem Megabyte direkt aus dem S3-Bucket, auch wenn die Daten zusätzlich in der schnellen Dateisystemschicht vorliegen; kleine Dateien unterhalb von standardmäßig 128 Kilobyte werden dagegen asynchron in die latenzoptimierte Schicht importiert. Ein Hersteller trennt hier also innerhalb desselben Produkts nach Objektgröße zwischen zwei Datenpfaden. Der MLPerf-Storage-Benchmark behandelt die Dateigrößenverteilung entsprechend als Variable erster Ordnung: Die Testdatensätze werden synthetisch erzeugt, wobei die Größenverteilung der realen Vorlage entspricht, und die Spanne reicht von Wikipedia-Samples mit rund 2,5 Kilobyte bis zu medizinischen Bilddaten mit 602 × 512 × 512 Voxeln.
Vor diesem Hintergrund ist die Aussage, Object Storage sei schnell genug für KI, technisch zu unpräzise — und die Gegenbehauptung, für KI benötige man High-Performance File Storage, ebenso. Entscheidend ist das konkrete Zugriffsmuster.
Kapazität und Latenz gehören nicht zwingend in dieselbe Schicht
Ob ein AI Data Lake High-Performance Storage benötigt, lässt sich nicht pauschal beantworten, weil die Frage zwei Ebenen vermischt. Ein Data Lake kann primär darauf ausgelegt sein, sehr große Datenmengen wirtschaftlich, dauerhaft und skalierbar vorzuhalten. Eine aktive Trainings- oder Inference-Pipeline stellt dagegen deutlich höhere Anforderungen an den Datenzugriff. Daraus kann eine mehrstufige Architektur entstehen, in der ein kapazitätsoptimierter Object Store die Basis bildet, eine Performance- oder Cache-Schicht das häufig benötigte Working Set näher an den Compute-Ressourcen bereitstellt und die GPU-Systeme darauf zugreifen.
Das Prinzip findet sich in aktuellen Storage-Architekturen wieder. AWS beschreibt für S3 Files ausdrücklich zwei Storage-Tiers, zwischen denen jede Operation automatisch geleitet wird: Der S3-Bucket ist auf hohen Durchsatz optimiert, die High-Performance-Schicht des Dateisystems auf niedrige Zugriffslatenz. Dass beide Ebenen unterschiedliche Optimierungsziele verfolgen, ist dabei keine Notlösung, sondern das Konstruktionsprinzip. Aufschlussreich ist auch die Gegenrichtung: Der MLPerf-Storage-Benchmark skaliert die Datensatzgröße automatisch so, dass ein nennenswertes Caching auf den ausführenden Systemen verhindert wird. Caching-Effekte sind also groß genug, um eine Messung zu verfälschen, wenn man sie nicht ausdrücklich ausschließt.
Eine zusätzliche Performance-Schicht ist deshalb aber nicht automatisch erforderlich. Object Storage kann direkt als Datenquelle genügen, wenn der Workload ausreichend parallelisiert werden kann und überwiegend größere Datenmengen gelesen werden. Vereinfacht ergibt sich der aggregierte Durchsatz aus der Anzahl paralleler Datenströme multipliziert mit dem Durchsatz je Datenstrom, bis eine andere Ressource zum Engpass wird — und wie stark die erforderliche Parallelität ausfällt, lässt sich beziffern. AWS empfiehlt beim Lesen großer Objekte Byte-Range-Requests mit einer Granularität von acht bis sechzehn Megabyte und jeweils einen parallelen Request je 85 bis 90 Megabyte pro Sekunde angestrebtem Durchsatz. Zur Auslastung einer 10-Gbit/s-Schnittstelle sind demnach etwa fünfzehn parallele Requests über getrennte Verbindungen nötig, für 100 Gbit/s liegt die Größenordnung entsprechend bei rund 150.
Diese Rechnung halten wir für aussagekräftiger als die bloße Umrechnung der Schnittstellenbandbreite. Eine 100-Gbit/s-Anbindung erlaubt theoretisch eine Bruttodatenrate von 12,5 GB/s, doch bestimmen Protokolloverhead, Storage-System, Netzwerkpfad, Client, CPU, Parallelisierung, Objektgrößen und Anwendung den tatsächlich erreichbaren Wert; die Netzwerkschnittstelle definiert lediglich eine obere physikalische Grenze des betrachteten Pfades. Auch clientseitig bestehen Grenzen: Bei S3 Files liegt der maximale Lesedurchsatz pro Client bei 3 GiB/s, der aggregierte Durchsatz je Dateisystem dagegen im Terabyte-Bereich pro Sekunde. Aggregierte Systemwerte und die pro Client erreichbare Rate sind deshalb getrennt zu betrachten — eine Verwechslung dieser beiden Größen ist bei Kapazitätsplanungen die häufigere Fehlerquelle.
Damit lässt sich ein AI Data Lake als mehrstufige Datenarchitektur verstehen: Unternehmensdatenquellen aus File Storage, Object Storage, Datenbanken und Anwendungen speisen die persistente Datenbasis; darauf setzen Extraktion, Transformation und Chunking auf; daraus entstehen Embeddings, Vector Index und Metadaten; optional folgt eine Performance-Schicht aus Cache, High-Performance-Storage oder lokalem Speicher; darauf greifen CPU- und GPU-Compute zu, auf denen wiederum RAG, Training, Inference und Analytics aufsetzen.
[Diagrammkandidat 3: Schichtenmodell von Datenquellen bis AI Services]
Nicht jede Implementierung benötigt jede Ebene. Die Architektur sollte sich aus dem Datenpfad und dem Workload ergeben, nicht aus einem Referenzmodell.
Der Umweg über das Scratch-Dateisystem beginnt zu verschwinden
Dass der Datenpfad inzwischen selbst Gegenstand von Optimierungen ist, zeigt die Entwicklung rund um GPU-Direct-Zugriffe. NVIDIA dokumentiert mit cuObject, auch als GPUDirect Storage for Objects bezeichnet, eine Architektur für direkte Transfers zwischen GPU- beziehungsweise Systemspeicher und S3-kompatiblem Object Storage über RDMA. Da anstelle TCP-basierter Übertragungen RDMA-Operationen verwendet werden, entfällt die TCP-Verarbeitung im Kernel, und die CPU kann beim Transfer der Nutzdaten umgangen werden. NVIDIA benennt das adressierte Muster ausdrücklich: Klassische Object-Storage-Workflows führen häufig vom Data Lake über ein Scratch-Dateisystem zur GPU, was Latenz und Redundanz erzeugt.
Für die Bewertung entscheidend ist jedoch die Implementierungsform, und hier lohnt ein genauerer Blick als die Überschrift nahelegt. Die Lösung besteht aus zwei getrennten Bibliotheken. Die Client-Bibliothek wird in die GPU-Anwendung oder deren Middleware integriert, fängt S3-Requests ab und verwaltet die RDMA-Datenquelle beziehungsweise -senke; sie ist ab CUDA Toolkit13.1.1 verfügbar. Die Server-Bibliothek dagegen muss vom Storage-Hersteller in dessen Object-Server integriert werden und wird als separates Paket bereitgestellt.
Daraus folgt eine praktisch bedeutsame Einschränkung, die in der Diskussion regelmäßig untergeht: cuObject funktioniert nicht gegen beliebigen S3-kompatiblen Storage, sondern nur gegen Systeme, deren Hersteller die Server-Seite implementiert hat. Die Verfügbarkeit ist damit eine Eigenschaft des jeweiligen Storage-Produkts und keine Eigenschaft der S3-API. Wer die Fähigkeit im Auswahlprozess voraussetzt, muss sie produktspezifisch prüfen.
Technisch trennt cuObject Steuer- und Datenpfad. Über die Control Plane laufen reguläre S3-GET- und -PUT-Requests, die um Metadaten-Tags wie x-amz-rdma-token ergänzt werden, während über die Data Plane die eigentlichen Nutzdaten per RDMA unter Umgehung der Host-CPU übertragen werden. Als Transport ist Dynamic Connection erforderlich, das über InfiniBand und RoCEv2 arbeitet und im Unterschied zu Reliable Connections keine vorab aufgebauten Verbindungen zwischen jedem Client-Server-Paar benötigt.
[Diagrammkandidat 4: Control Plane und Data Plane getrennt]
Architektonisch zeigt diese Entwicklung, dass Object Storage nicht zwangsläufig ein langsames Capacity Tier weit entfernt vom Compute sein muss. Die Grenze zwischen Data-Lake-Storage und High-Performance-Datenversorgung verschiebt sich durch zusätzliche Protokolle, Caching, RDMA und spezialisierte Datenpfade.
Unter dem Begriff KI verbergen sich vier verschiedene Storage-Workloads
Für die Architektur ist es problematisch, dass sehr unterschiedliche Zugriffsprofile unter einem Sammelbegriff zusammengefasst werden. Wer eine Plattform für KI dimensioniert, sollte deshalb benennen, für welche Phase.
Bei der erstmaligen RAG-Ingestion eines großen Dokumentenbestands müssen sehr viele Dateien beziehungsweise Objekte gelesen werden; der Pfad führt vom Storage über Parser, Chunking und Embedding-Modell in den Vector Index, und Durchsatz wie Request Rate können gleichermaßen relevant werden. Nach der initialen Verarbeitung ändert sich das Bild grundlegend, denn bei der Aktualisierung des Bestands sind meist nur neue oder veränderte Inhalte zu verarbeiten, sodass der Storage-Workload erheblich kleiner ausfällt als beim Aufbau. Beim Retrieval schließlich wird im Regelfall nicht der gesamte Data Lake durchsucht, sondern ein zuvor erzeugter Index abgefragt und eine begrenzte Menge relevanter Inhalte für das LLM bereitgestellt — der Performance-Schwerpunkt verschiebt sich damit vom Data Lake weg.
Das Training folgt einem anderen Muster, weil sehr große Datenmengen wiederholt gelesen und an Compute-Systeme geliefert werden; die kontinuierliche Versorgung der Beschleuniger wird hier zur wesentlichen Anforderung. Ein eigenständiges und häufig übersehenes Profil besitzt das Checkpointing: Um den Trainingsfortschritt gegen Infrastrukturausfälle zu sichern, werden Zwischenstände in regelmäßigen Abständen persistiert. Der Workload ist damit schreiblastig und stoßweise statt lesedominiert und kontinuierlich, und die Größenordnung ist erheblich. MLPerfStorage führt Checkpointing als eigene Benchmark-Aufgabe und beziffert die Datenmenge für Llama-3 von rund 105 Gigabyte bei acht Milliarden Parametern bis zu 18 Terabyte bei einer Billion Parametern.
RAG, Training, Inference und Checkpointing benötigen deshalb nicht automatisch dieselbe Storage-Architektur.
Kapazität allein macht aus einer Datenablage keine Datenbasis
Der Begriff Data Lake legt nahe, das zentrale Problem sei die Speicherkapazität. Für eine produktive KI-Datenplattform reicht Storage jedoch nicht aus. Zusätzlich werden Funktionen benötigt, die beantworten, welche Daten existieren, woher sie stammen, welches Format sie besitzen, wer darauf zugreifen darf, wann sie verändert wurden, welche Version verarbeitet wurde und welche Daten für welches KI-System überhaupt verwendet werden dürfen. Neben dem eigentlichen Storage gehören damit Metadaten, Katalog, Identity und Access, Governance, Datenverarbeitung und Indizierung zur Architektur; erst ihr Zusammenspiel macht aus einer großen Ablage eine kontrollierbare Datenbasis.
Eng damit verbunden ist die Trennung zwischen ursprünglichen Unternehmensdaten und daraus erzeugten KI-Derivaten. Aus einem PDF entstehen extrahierter Text, Chunks, Embeddings und Indexstrukturen — Daten mit sehr unterschiedlichen Eigenschaften. Das Originaldokument muss möglicherweise langfristig erhalten bleiben, extrahierter Text lässt sich in der Regel erneut erzeugen, Embeddings hängen von der verwendeten Modellversion ab, und ein Index kann vollständig rekonstruierbar sein. Entsprechend unterscheiden sich die Anforderungen an Verfügbarkeit, Wiederherstellung, Versionierung, Retention, Backup, Performance und Kosten. Eine tragfähige Datenarchitektur behandelt diese Ebenen deshalb nicht identisch, sondern leitet für jede ab, was tatsächlich geschützt werden muss und was sich neu berechnen lässt.
Entfernung zwischen Storage und Compute ist eine Architekturentscheidung
Wenn Storage und Compute geografisch voneinander entfernt sind, muss jede Verarbeitung Daten über das Netzwerk transportieren. Für einen Datensatz der Größe D und eine verfügbare effektive Bandbreite B beträgt die theoretische Mindestübertragungszeit t ≥ D / B. Bei einem Petabyte wird selbst ein sehr schnelles Netzwerk damit zu einer relevanten Architekturkomponente, und hinzu kommen Übertragungsprotokolle, konkurrierende Workloads sowie gegebenenfalls Kosten für Datenbewegungen. Entscheidend ist deshalb nicht nur, wie schnell der Storage selbst ist, sondern wo sich Storage und Compute relativ zueinander befinden. AWS führt die Kolokation als eigene Performance-Empfehlung und rät, Buckets nach Möglichkeit von EC2-Instanzen in derselben Region anzusprechen, um Netzwerklatenz und Datentransfer zu reduzieren. Für On-Premises-Architekturen gilt dasselbe physikalische Grundprinzip, denn jeder Datenpfad zwischen Storage und Compute besitzt eine endliche Bandbreite und Latenz.
Die Frage nach File oder Object Storage lässt sich vor diesem Hintergrund nicht mit einem generellen Sieger beantworten. File Storage wird über Protokolle wie SMB und NFS angesprochen, organisiert Daten in Verzeichnissen und ist bei bestehenden Unternehmensdaten häufig unmittelbar vorhanden. Object Storage nutzt eine Object API, organisiert Daten in Buckets, Keys und Objekten, erfordert für vorhandene Bestände meist einen Ingestion-Schritt und ist in vielen Scale-out-Implementierungen von Grund auf auf horizontale Parallelisierung ausgelegt. Diese Zuordnung beschreibt Architekturprinzipien und keine Leistungsaussagen — die tatsächliche Performance hängt von der konkreten Implementierung ab, und die Trennlinie verschiebt sich, wie das Beispiel des Dateisystemzugriffs auf Object Storage zeigt.
Vor der Auswahl einer Architektur klären wir deshalb zunächst den Workload. Dazu gehört die Größenordnung des Datenbestands, also ob es um zehn Terabyte, fünfhundert Terabyte oder mehrere Petabyte geht, und ebenso die typische Objekt- beziehungsweise Dateigröße, weil Millionen kleiner Dokumente einen anderen Storage erfordern als große Trainingsdateien. Hinzu kommen das Zugriffsmuster aus sequenziellen, wahlfreien oder gemischten Zugriffen, der Grad der Parallelität zwischen einem einzelnen Prozess und Tausenden gleichzeitiger Worker sowie die Änderungsrate, die zwischen statischem Bestand und kontinuierlichem Zulauf variiert. Schließlich sind die Compute-Seite mit CPU-Cluster oder großer GPU-Infrastruktur, die Datenlokalität zwischen gemeinsamem Rechenzentrum, gemeinsamer Cloud-Region und WAN-Trennung, die Wiederverwendung derselben Daten über mehrere Verarbeitungsläufe und die Protokollanforderung zwischen POSIX-Zugriff und direktem S3-Zugriff zu bestimmen. Erst aus diesen Parametern ergibt sich, welche Storage-Eigenschaften tatsächlich benötigt werden.
Fazit
Ein AI Data Lake ist keine einzelne Storage-Technologie, sondern die persistente Datenbasis einer größeren KI-Datenarchitektur. File Storage bleibt relevant, weil dort ein erheblicher Teil unstrukturierter Unternehmensdaten entsteht und verarbeitet wird, während Object Storage sich aufgrund seines API-basierten Zugriffs und seiner horizontalen Architektur als Basis für sehr große Bestände und parallele Verarbeitung eignet. Die Grenze zwischen beiden verläuft dabei zunehmend entlang des Zugriffswegs und nicht entlang der Speicherform.
Entscheidend bleibt der Datenpfad. Für RAG müssen Originaldaten zunächst ingestiert, extrahiert, segmentiert, in Embeddings überführt und indexiert werden, sodass beim späteren Retrieval der Performance-Schwerpunkt nicht mehr auf dem ursprünglichen Data Lake liegt. Training erfordert dagegen große kontinuierliche Datenströme zum Compute, und Checkpointing erzeugt zusätzlich stoßweise Schreiblast.
Die zentrale Frage lautet deshalb nicht, ob Object Storage schnell genug für KI ist, sondern welche Daten in welcher Phase mit welcher Parallelität, Latenz und Bandbreite vom Storage zum Compute gelangen müssen. Erst wenn sie beantwortet ist, lässt sich entscheiden, ob ein skalierbarer Object Store als direkte Datenquelle genügt, File Storage eingebunden werden muss oder zwischen Data Lake und Compute eine zusätzliche High-Performance-Schicht sinnvoll ist.
Quellen
Quellen
Amazon Web Services: Performance guidelines for Amazon S3, Amazon Simple Storage Service User Guide.
Amazon Web Services: Performance design patterns for Amazon S3, Amazon Simple Storage Service User Guide.
Amazon Web Services: Best practices design patterns: optimizing Amazon S3 performance, Amazon Simple Storage Service User Guide.
Amazon Web Services: Performance specifications – S3 Files, Amazon Simple Storage Service User Guide.
MLCommons: MLPerf Storage Benchmark Suite, Ergebnisrunde v2.0, August 2025.
NVIDIA Corporation: NVIDIA cuObject: GPUDirect Storage for Objects, Release r1.16.
Zur Verwendung der MLPerf-Storage-Daten ist anzumerken, dass der Benchmark neben allgemein verfügbaren Systemen auch die Kategorien Preview sowie Research, Development or Internal umfasst. Letztere können Experimental- oder Entwicklungshardware enthalten, die möglicherweise nie allgemein verfügbar wird, weshalb einzelne Ergebniswerte nicht als Marktaussage lesbar sind. Im vorliegenden Text wird MLPerf ausschließlich als Messmethodik herangezogen, nicht mit konkreten Ergebniszahlen.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
