7 Infrastrukturteams rüsten Speicher, der für Dateien und Backup im Unternehmen konzipiert wurde, nachträglich für KI-Workloads auf. Dieser Ansatz bricht im großen Maßstab zusammen. KI-Compute-Infrastruktur verlangt eine grundlegend andere Architektur – eine, die auf die Versorgung von GPUs mit hohem Durchsatz, disaggregierten Speicher und auf Workloads abgestimmte Ebenen ausgelegt ist. Ob Ihre KI-Plattform skaliert oder ins Stocken gerät, hängt davon ab, diese Komponenten von Anfang an richtig zu gestalten. Dieser Leitfaden erklärt die Komponenten von KI-Compute-Infrastruktur, die Designprinzipien, die funktionierende Deployments von solchen unterscheiden, die im Petabyte-Maßstab an Grenzen stoßen, und wie moderne Speicherplattformen sich in den gesamten Compute-Stack einfügen. Was ist KI-Compute-Infrastruktur? KI-Compute-Infrastruktur ist die Kombination aus Hardware, Netzwerk, Speicher und Orchestrierungssoftware, die Workloads für Machine-Learning-Training, Inferencing und Datenaufbereitung unterstützt. Sie unterscheidet sich in drei Punkten von universeller Compute-Infrastruktur: Die Workloads sind GPU-zentriert statt CPU-zentriert, die Datenmengen wachsen viel schneller als bei klassischen Unternehmensanwendungen, und die I/O-Muster sind in jeder Phase des KI-Datenlebenszyklus stoßweise, parallel und latenzkritisch. Ein Trainingscluster, der einen Datensatz von 100 TB über Tausende GPU-Stunden verarbeitet, stellt andere Anforderungen an die Infrastruktur als eine Transaktionsdatenbank oder ein Dateiserver. Speicherbandbreite, Speicherdurchsatz und Netzwerk-Fabric müssen gemeinsam entworfen werden. KI-Workloads auf Legacy-Infrastruktur aufzupfropfen, führt jedes Mal zum selben Ergebnis: geringe GPU-Auslastung, Engpässe beim Training und Ingenieure, die ihre Zeit mit Infrastruktur statt mit Modellen verbringen. Die wichtigsten Komponenten von KI-Compute-Infrastruktur Diese Infrastruktur besteht aus fünf Ebenen. Jede Ebene hat spezifische Leistungsanforderungen, und die Ebenen müssen gemeinsam entworfen werden – nicht aus dem zusammengesetzt, was gerade verfügbar ist. Komponente Rolle Zentrale Metrik GPU-Cluster Parallele Matrixberechnungen für Training und Inferencing GPU-Auslastung in %, Speicherbandbreite Hochgeschwindigkeitsnetzwerk / RDMA Datenbewegung mit niedriger Latenz zwischen Compute und Speicher Latenz (µs), Bandbreite (Tbit/s) Speicherebenen Versorgung mit Trainingsdaten, Checkpoints, Embeddings, Inferencing-Cache Durchsatz (GB/s), IOPS, Kapazität Orchestrierung (Kubernetes / Slurm) Planung von GPU-Jobs, Steuerung konkurrierender Ressourcenzugriffe Tiefe der Job-Warteschlange, Planungsaufwand Monitoring und Observability Überwachung von GPU-Auslastung, Speicher-I/O und Job-Fortschritt Durchgängige Transparenz über die Pipeline GPU-Cluster Die Recheneinheit ist die GPU, nicht die CPU. Modernes KI-Training läuft auf Clustern mit GPUs der H100- oder A100-Klasse, die innerhalb eines Knotens über NVLink und zwischen Knoten über InfiniBand oder RoCE verbunden sind. Die Clustergröße reicht von wenigen Knoten für das Fine-Tuning bis zu Tausenden von Knoten für umfangreiches Pretraining. Die GPU-Auslastung ist die wichtigste Effizienzmetrik. Eine dauerhafte Auslastung unter 80 % während eines Trainingslaufs deutet auf einen Engpass an anderer Stelle hin – meist beim Laden von Daten oder bei Checkpoint-I/O. Infrastrukturteams, die die Compute-Ebene optimieren, ohne die Speicherebene anzugehen, sehen regelmäßig GPU-Auslastungen von 40–60 %. Hochgeschwindigkeitsnetzwerk und RDMA Remote Direct Memory Access (RDMA) ist der Mechanismus, mit dem Speichersysteme GPUs ohne Beteiligung der CPU versorgen. Klassische TCP/IP-Netzwerke verursachen Latenz und CPU-Aufwand, die im großen Maßstab zu einer harten Obergrenze für den Durchsatz werden. InfiniBand- und RoCEv2-Fabrics mit RDMA beseitigen diesen Aufwand und ermöglichen GPU-Direct-Speicherzugriffe. In KI-Compute-Infrastruktur verbindet das Netzwerk-Fabric drei Bereiche: GPU zu GPU für kollektive Operationen (AllReduce beim Training), GPU zu Speicher für das Laden von Daten und das Schreiben von Checkpoints sowie CPU zu Orchestrierung für die Job-Planung. Jeder Bereich hat andere Anforderungen an Latenz und Bandbreite, und wer sie auf einem einzigen Fabric vermischt, erzeugt Konflikte. Speicherebenen Speicher ist die am häufigsten unterdimensionierte Komponente von KI-Compute-Infrastruktur. Teams kaufen zu viel GPU-Compute und stellen dann fest, dass die Trainingsjobs auf Daten warten. Eine gut konzipierte Speicherebene bietet: GPU-Direct-Ebene: Flash mit extrem niedriger Latenz, angebunden über S3 over RDMA. Versorgt laufende Trainingsläufe, den KV-Cache für das Inferencing und Checkpoint-Schreibvorgänge in Echtzeit. Latenzziel: unter 50 Mikrosekunden. Hot-Ebene: QLC oder NL-SSD mit hoher Dichte für aktive Datensätze, Embeddings und aktuelle Checkpoints. Liefert einen Gesamtdurchsatz von mehreren Terabyte pro Sekunde für das parallele Laden von Daten auf GPUs. Warm-Ebene: Für seltener genutzte Datensätze – bereitgestellte Trainingsdaten, Zwischen-Embeddings, RAG-Indizes. Cold-Ebene: Langzeitaufbewahrung von Rohdaten für das Training, regulatorischen Archiven und Artefakten zur Modell-Lineage. Das Designmuster Tiered Storage für KI ordnet die Datentemperatur der Speicherökonomie zu und erhält zugleich den Durchsatz, den der heiße Pfad braucht. Orchestrierung Kubernetes und Slurm werden beide in produktiver KI-Compute-Infrastruktur eingesetzt, erfüllen aber unterschiedliche Zwecke. Slurm dominiert Trainingscluster im HPC-Stil, in denen Jobs groß und lang laufend sind und eine strikte Ressourcenreservierung erfordern. Kubernetes wird für Inferencing, Pipelines zur Datenaufbereitung und gemischte Workloads bevorzugt, bei denen dynamische Planung wichtig ist. Die Wahl der Orchestrierungsebene beeinflusst, wie Speicher bereitgestellt wird. Kubernetes-native KI-Workloads nutzen Persistent Volume Claims auf Basis von S3-kompatiblem Objektspeicher. Slurm-Jobs binden Speicher meist direkt ein. Infrastrukturteams, die zertifizierte KI-Infrastrukturpipelines aufbauen, brauchen Speicher, der mit beiden Paradigmen sauber funktioniert. Monitoring und Observability Die GPU-Auslastung zeigt, ob die Infrastruktur funktioniert; das Speicher-I/O zeigt, wo der Engpass liegt. Wirksame Observability umfasst Compute-Metriken (GPU-Auslastung, Speicherbandbreite, NVLink-Durchsatz), Speichermetriken (Lese-/Schreibdurchsatz pro Ebene, Warteschlangentiefe, Cache-Trefferquoten) und Metriken auf Jobebene (Ladezeit der Daten, Schreiblatenz von Checkpoints, Dauer einer Epoche). Designprinzipien für KI-Compute-Infrastruktur Drei Prinzipien unterscheiden Infrastruktur, die skaliert, von Infrastruktur, die ständige Feuerwehreinsätze erfordert. Disaggregation Disaggregation bedeutet, Compute und Speicher zu trennen, damit beide unabhängig voneinander skalieren. Hyperkonvergente Infrastruktur war für allgemeine Unternehmens-Workloads sinnvoll. Bei KI erzwingt sie eine unbequeme Wahl: Speicher zusammen mit Compute skalieren, auch wenn nur eines gebraucht wird, oder eines an das andere anpassen und damit begrenzen. Disaggregierte Architekturen ermöglichen es Teams, GPU-Knoten hinzuzufügen, ohne Speicher zu kaufen, und die Speicherkapazität zu erweitern, ohne GPU-Zyklen hinzuzufügen. Der Speichercluster ist über das Hochgeschwindigkeits-Fabric mit dem Compute-Cluster verbunden. So werden KI-Rechenzentren im großen Maßstab heute konzipiert. Scale-out statt Scale-up Bei KI-Workloads ist horizontale Skalierung durch zusätzliche Knoten der vertikalen Skalierung durch größere Knoten überlegen. Scale-out-Objektspeichercluster bieten mit jedem hinzugefügten Knoten ein lineares Wachstum des Durchsatzes. Ein einzelner großer NAS-Head wird im Petabyte-Maßstab zum Durchsatzengpass; ein verteilter Objektspeicher nicht. Für Trainings-Workloads, die über Tausende von GPUs gleichzeitig aus Hunderten von Dateien lesen, ist die gesamte I/O-Bandbreite eines Scale-out-Clusters die einzige Architektur, bei der der Speicher nicht zum Engpass wird. Auf Workloads abgestimmte Speicherebenen Nicht jeder KI-Workload hat dieselben Speicheranforderungen. Checkpoint-I/O beim Training erfordert hohen Schreibdurchsatz und niedrige Latenz. Die Aufnahme von Datensätzen erfordert eine dauerhaft hohe Lesebandbreite. RAG-Retrieval erfordert schnelle zufällige Lesezugriffe. Die langfristige Archivierung von Modellen erfordert Dichte und Ausfallsicherheit, nicht Geschwindigkeit. Eine einzige Speicherebene zu entwerfen, die all das abdecken soll, ist teuer und wirkungslos. Auf Workloads abgestimmte Ebenen ordnen das Speicherprofil den Anforderungen des Workloads zu und verschieben Daten per Lifecycle-Automatisierung ohne manuelle Eingriffe zwischen den Ebenen. Speicher für multimodale KI-Daten profitiert besonders von diesem Ansatz – Bild-, Video- und Textdatensätze haben sehr unterschiedliche Zugriffsmuster. Speicherdesign für KI-Compute-Workloads Der KI-Datenlebenszyklus durchläuft fünf Phasen mit jeweils eigenen Speicheranforderungen. Aufnahme und Aufbereitung: Rohdaten für das Training kommen aus externen Quellen, Data Lakes oder Gerätedatenströmen. Der Speicher für die Aufnahme braucht hohe Schreibbandbreite und genügend Kapazität für große Arbeitsdatenbestände. Die Datenaufbereitung – Bereinigen, Tokenisieren, Formatieren – führt CPU-intensive Jobs aus, die Daten wiederholt lesen und neu schreiben. Objektspeicher mit flachem Namespace bewältigt das im großen Maßstab effizient; das Muster KI-Datenspeicher ohne Hindernisse beschreibt den Weg von der Aufnahme bis zum Training im Detail. Trainingsdatensätze: Sind die Daten aufbereitet, lesen Trainingsjobs sie über viele Epochen hinweg wiederholt. Das Speichersystem muss einen hohen Gesamtdurchsatz für parallele Lesezugriffe vieler GPUs gleichzeitig halten. Das Caching heißer Datensätze auf Flash-Ebenen verringert die Latenz erneuter Lesezugriffe deutlich. Checkpoints: Trainingsläufe schreiben regelmäßig Checkpoints, um sich nach Ausfällen wiederherstellen zu können. Checkpoint-Schreibvorgänge sind stoßweise, bandbreitenintensiv und latenzkritisch – ein langsamer Checkpoint hält den gesamten Trainingslauf an. Für laufende Checkpoints wird meist die GPU-Direct-Ebene genutzt; abgeschlossene Checkpoints werden auf die Hot-Ebene verschoben. Inferencing: Inferencing stellt andere Speicheranforderungen als Training. Modellgewichte müssen beim Start schnell geladen werden. Der KV-Cache für Inferencing mit langem Kontext erfordert zufällige Lesezugriffe mit extrem niedriger Latenz. Speicher für Vektordatenbanken und RAG-Speicher für RAG-Pipelines liegen auf der Hot-Ebene, mit Leistungsprofilen, die eher einer Datenbank als einem Dateisystem ähneln. Aufbewahrung und Archivierung: Trainierte Modelle, Evaluierungsergebnisse und Rohdatensätze unterliegen langen Aufbewahrungspflichten aus Governance, Reproduzierbarkeit und regulatorischer Compliance. Cold-Speicher mit starken Garantien für die Ausfallsicherheit und automatisierten Lifecycle-Richtlinien bewältigt das ohne manuellen Aufwand für die Datenverwaltung. Wie sich Scality ADI in KI-Compute-Infrastruktur einfügt Scality ADI (Autonomous Data Infrastructure) ist eigens für die Speicherebene in KI-Compute-Infrastruktur entwickelt. Die Plattform adressiert die spezifischen Fehlerbilder, die auftreten, wenn universeller Speicher KI-Workloads im Petabyte-Maßstab bewältigen soll. Architektur. Scality ADI läuft auf der disaggregierten RING10-Architektur – einer objektnativen verteilten Speicher-Engine für extreme Umgebungen im Bereich von Petabyte bis Exabyte. RING10 bietet einen einheitlichen Namespace, hohe Ausfallsicherheit und automatisiertes Lifecycle-Management über alle Speicherebenen. ScalityOS ist die gehärtete, standardisierte Laufzeitumgebung, die über den gesamten Hardware-Stack ein Erlebnis wie bei einer Appliance schafft, die Fragmentierung über Lebenszyklen hinweg reduziert und den Betrieb vereinfacht. Das Verhältnis der Ebenen: Scality RING ist der Motor, ScalityOS das Chassis, Scality ADI die Plattform. Vier auf Workloads abgestimmte Speicherebenen. Scality ADI wird mit vier vorkonfigurierten Ebenen ausgeliefert, die den oben beschriebenen Phasen des KI-Datenlebenszyklus entsprechen: GPU-Direct-Ebene – TLC-Flash mit S3 over RDMA. Latenz unter 50 Mikrosekunden für laufende Trainingsläufe, Checkpoint-I/O und KV-Cache. Direkt an das GPU-Fabric angebunden, ohne Beteiligung der CPU. Hot-Ebene – QLC und NL-SSD mit einem Gesamtdurchsatz von mehreren Terabyte pro Sekunde. Für aktive Trainingsdatensätze, Embeddings und aktuelle Checkpoints. Warm-Ebene – Für bereitgestellte Datensätze, RAG-Indizes und Zwischen-Embeddings. Cold-Ebene – Kapazität mit hoher Dichte für Rohdatenarchive, regulatorische Aufbewahrung und Modell-Lineage. Lifecycle-Automatisierung verschiebt Daten zwischen den Ebenen, ohne neue Speichersilos zu schaffen. Der Vergleich des Stromverbrauchs bei hoher Dichte zwischen HDD und QLC-Flash (auf Englisch) beschreibt die Wirtschaftlichkeit der Übergänge von warm zu kalt im Detail. GPU-Direct über S3 over RDMA. Scality ADI unterstützt GPU-Direct-Speicherzugriffe über S3 over RDMA, sodass GPU-Knoten Trainingsdaten ohne Beteiligung der CPU direkt aus dem Speicher-Fabric lesen. Das beseitigt den CPU-Engpass, der den Durchsatz in TCP-basierten Speicherarchitekturen begrenzt, und ist der Mechanismus, der bei datenintensiven Trainingsläufen eine dauerhafte GPU-Auslastung von über 90 % ermöglicht. Auf Workloads abgestimmte Software-Hardware-Profile. Statt von Infrastrukturteams zu verlangen, Speicherkonfigurationen für jeden Workload-Typ abzustimmen, wird Scality ADI mit vorab validierten Profilen ausgeliefert, die die Hardwarekonfiguration den Anforderungen des Workloads zuordnen. Ein Team, das einen neuen Fine-Tuning-Cluster bereitstellt, wählt das passende Profil; die Plattform konfiguriert Ebene, Netzwerkparameter und Einstellungen für die Ausfallsicherheit automatisch. Infrastrukturteams, die agentische KI-Speicherinfrastruktur auf Scality ADI aufbauen, erhalten eine Plattform, die den gesamten KI-Datenfluss abdeckt – von der Aufnahme über Aufbereitung, RAG- und VSS-Workloads, Checkpoints, Embeddings und Logs bis zur Langzeitaufbewahrung –, ohne die betriebliche Komplexität getrennter Speichersysteme für jede Phase. So fügt sich Scality ADI in KI-Compute-Infrastruktur ein → Häufig gestellte Fragen Was ist KI-Compute-Infrastruktur? KI-Compute-Infrastruktur ist der integrierte Stack aus GPU-Clustern, Hochgeschwindigkeitsnetzwerk, Speicherebenen und Orchestrierungssoftware, der Machine-Learning-Training, Inferencing und Datenaufbereitung im großen Maßstab unterstützt. Sie unterscheidet sich von universeller Rechenzentrumsinfrastruktur dadurch, dass die Workloads GPU-zentriert sind, die Datenmengen schnell wachsen und die I/O-Muster über den gesamten KI-Datenlebenszyklus stoßweise und parallel sind. Was sind die wichtigsten Komponenten von KI-Compute-Infrastruktur? Die fünf Hauptkomponenten sind GPU-Cluster (paralleles Compute), Hochgeschwindigkeitsnetzwerke mit RDMA-Unterstützung (Datenbewegung mit niedriger Latenz), auf Workloads abgestimmte Speicherebenen (Datenversorgung und Aufbewahrung), Orchestrierungssoftware wie Kubernetes oder Slurm (Job-Planung und Ressourcenverwaltung) sowie Werkzeuge für Monitoring und Observability (Überwachung von GPU-Auslastung und I/O-Leistung). Speicher ist häufig die am stärksten unterdimensionierte Komponente und die häufigste Ursache für geringe GPU-Auslastung. Worin unterscheidet sich KI-Compute-Infrastruktur von klassischer Rechenzentrumsinfrastruktur? Klassische Rechenzentrumsinfrastruktur ist für CPU-zentrierte, latenztolerante Workloads mit moderatem und vorhersehbarem I/O ausgelegt. KI-Compute-Infrastruktur muss einen extrem hohen Gesamtdurchsatz des Speichers halten, um GPU-Cluster zu versorgen, stoßweise Checkpoint-Schreibvorgänge bewältigen, ohne Trainingsjobs anzuhalten, und die Speicherkapazität unabhängig vom Compute skalieren. Auch das Netzwerk-Fabric unterscheidet sich: KI-Infrastruktur erfordert RDMA-fähige Fabrics, um den CPU-Aufwand im Datenpfad zu beseitigen, während klassische Rechenzentren durchgängig TCP/IP-Netzwerke nutzen. Welche Speicherarchitektur eignet sich am besten für KI-Compute-Workloads? Disaggregierter Scale-out-Objektspeicher mit auf Workloads abgestimmten Ebenen eignet sich am besten für KI-Compute-Workloads. Der Speichercluster ist über ein Hochgeschwindigkeits-Fabric mit RDMA an den Compute-Cluster angebunden, statt neben den GPU-Knoten zu liegen. Mehrere Ebenen – GPU-Direct-Flash, heiß mit QLC/NL-SSD, warm und kalt – bedienen unterschiedliche Phasen des KI-Datenlebenszyklus. Lifecycle-Automatisierung verschiebt Daten ohne manuelle Eingriffe zwischen den Ebenen. Diese Architektur vermeidet die Durchsatzgrenzen hyperkonvergenter Designs und skaliert horizontal mit der Größe des GPU-Clusters. Hinweise zur Dimensionierung jeder Ebene bietet der Beitrag zur Planung der Speicherkapazität im Detail. Weiterführende Artikel Tiered Storage für KI: skalierbare Leistung und Kostenkontrolle Agentische KI-Speicherinfrastruktur KI-Rechenzentrum KI-Datenspeicher ohne Hindernisse Zertifizierte KI-Infrastrukturpipeline Retrieval-Augmented Generation und Speicher für KI Objektspeicher vs. Block-Speicher
