6 Die meisten KI-Infrastrukturprogramme scheitern nicht in der Prototypphase. Sie scheitern, wenn das Team zum ersten Mal versucht, von einem GPU-Rack auf zehn oder von einem Trainingscluster auf mehrere Standorte zu wachsen. Die Skalierung von KI-Compute ist der Punkt, an dem sich die Annahmen der frühen Architektur entweder auszahlen oder zusammenbrechen. Für Infrastrukturverantwortliche ist Skalierung kein Zukunftsproblem. Die Entscheidungen der ersten 90 Tage eines KI-Aufbaus – Knotentopologie, Interconnect, Speicher-Tiering und Namespace-Design – legen die Obergrenze für jeden nachfolgenden Workload fest. Wer sie falsch trifft, verbringt Jahre damit, sie zu umgehen. Dieser Leitfaden erklärt, was die Skalierung von KI-Compute wirklich bedeutet, welche zwei Wachstumsachsen es gibt, mit welchen Parallelisierungstechniken Arbeit über Knoten verteilt wird, welche Muster für Multi-Node-Cluster in Produktion genutzt werden und warum Speicher, der mit dem Compute skaliert, die Einschränkung ist, die die meisten Teams unterschätzen. Was ist die Skalierung von KI-Compute? Die Skalierung von KI-Compute bezeichnet die Praxis, Trainings- und Inferencing-Kapazität an größere Modelle, größere Datensätze und höhere Parallelität anzupassen und dabei Auslastung und Wirtschaftlichkeit im Griff zu behalten. Es ist die Disziplin, Kapazität hinzuzufügen, ohne proportional mehr Reibung zu erzeugen – betrieblich, finanziell oder architektonisch. Skalierung ist etwas anderes als Effizienz. Effizienz fragt, wie viel nützliche Arbeit sich aus den vorhandenen GPUs herausholen lässt. Skalierung fragt, wie sich mehr Kapazität hinzufügen lässt – mehr GPUs, mehr Knoten, mehr Standorte –, ohne dass sich die neue Kapazität anders verhält als die alte. Ein Cluster, der mit 32 Knoten sauber läuft und mit 256 ins Stocken gerät, wurde nicht skaliert. Er wurde lediglich vergrößert. Drei Kräfte treiben den Skalierungsbedarf heute an: Modellgröße. Parameterzahlen und Kontextfenster von Frontier-Modellen sind weit schneller gewachsen als der Speicher pro GPU. Datensatzgröße. Multimodale Datensätze überschreiten regelmäßig die Petabyte-Schwelle; Long-Tail-Unternehmensdaten überschreiten über mehrere Jahre hinweg die Exabyte-Schwelle. Parallelität. Produktives Inferencing, agentische Workflows und zentraler KV-Cache für verteiltes Inferencing treiben das Volumen gleichzeitiger Anfragen weit über das hinaus, was ein einzelner Knoten bedienen kann. Jede dieser Kräfte allein reicht aus, um eine Skalierungsentscheidung zu erzwingen. In der Praxis treffen Infrastrukturteams auf alle drei gleichzeitig. Horizontale vs. vertikale Skalierung Es gibt zwei Wachstumsachsen, und die meisten produktiven KI-Programme nutzen beide. Achse Bedeutung Wann sie passt Grenzen Vertikale Skalierung (Scale-up) Mehr Ressourcen pro Knoten: größere GPUs, mehr GPU-Speicher, schnellerer lokaler Interconnect Training einzelner Modelle, bei dem kollektive Kommunikation dominiert; latenzkritisches Inferencing Begrenzt durch Silizium-Roadmap, Energiebudget pro Rack sowie Knotenausfälle und deren Schadensradius Horizontale Skalierung (Scale-out) Mehr Knoten, verbunden über ein Hochgeschwindigkeits-Fabric Datensätze und Modelle, die einen einzelnen Knoten übersteigen; Ingestion- und Aufbereitungspipelines; mandantenfähiges Inferencing Begrenzt durch Interconnect-Topologie, Speicherdurchsatz und Koordinationsaufwand der Orchestrierung Wann vertikale Skalierung sinnvoll ist Vertikale Skalierung ist der richtige Ausgangspunkt, wenn der Workload bequem auf einen Knoten passt. Ein Trainingslauf auf einem einzelnen Knoten mit GPU-zu-GPU-Bandbreite auf NVLink-Niveau vermeidet den Koordinationsaufwand verteilten Trainings vollständig. Beim Inferencing senkt ein größerer Knoten die Latenz in den Randbereichen (Tail-Latenz), weil das gesamte Modell im HBM verbleibt. Die vertikale Obergrenze ist allerdings real. Der Speicher pro GPU wächst von Generation zu Generation, aber nicht so schnell wie die Modellgrößen, die die Forschung hervorbringt. Strom und Kühlung pro Rack sind in den meisten Rechenzentren harte Grenzen. Und ein einzelner großer Knoten ist zugleich eine einzelne große Fehlerdomäne – fällt er aus, kann das einen Trainingslauf zum Erliegen bringen, der tagelang Zustand angesammelt hat. Wann horizontale Skalierung sinnvoll ist Horizontale Skalierung ist das, was Enterprise-KI tatsächlich tut, sobald sie die Testphase hinter sich lässt. Trainingsläufe über Dutzende oder Tausende von GPUs erfordern ein Scale-out-Fabric. Inferencing-Plattformen, die Tausende gleichzeitiger Nutzer bedienen, brauchen eine Scale-out-Ebene aus Replikaten, oft mit einem vorgelagerten gemeinsamen KV-Cache, der selbst auf Scale-out-Speicher liegt. Das horizontale Muster verlagert den Engpass vom Silizium auf die Koordination. Interconnect-Latenz, Aufwand für kollektive Kommunikation und Speicher-I/O über das Fabric werden zu bestimmenden Faktoren. Hier beginnen früh getroffene Speicherentscheidungen an jeder Workload-Grenze ins Gewicht zu fallen. Parallelisierungstechniken: wie sich die Arbeit tatsächlich aufteilt Sobald Sie über einen einzelnen Knoten hinaus skalieren, stellt sich die Frage: Wie wird die Arbeit aufgeteilt? Zwei Muster dominieren. Datenparallelität Bei der Datenparallelität hält jede GPU eine vollständige Kopie des Modells und verarbeitet einen anderen Teil der Trainingsdaten. Nach jedem Batch tauschen die GPUs über eine kollektive AllReduce-Operation Gradienten aus und aktualisieren ihre Modellkopien im Gleichschritt. Datenparallelität skaliert gut, wenn: das Modell bequem in den Speicher einer einzelnen GPU passt. der Trainingsdatensatz groß genug ist, dass die Teile pro GPU noch sinnvolle Batches ergeben. der Interconnect das AllReduce der Gradienten im Takt jedes Trainingsschritts bewältigen kann. Die Auswirkungen der Datenparallelität auf den Speicher sind erheblich. Jede GPU im Cluster liest aus demselben Datensatz. Ein Cluster mit 1.024 GPUs, der datenparallel trainiert, erzeugt 1.024 gleichzeitige Lesestreams auf der Speicherebene. Ob die GPUs ausreichend versorgt werden, entscheidet der Gesamtdurchsatz, nicht der Durchsatz pro Stream. Das ist das Fehlerbild, das aus einem Benchmark mit 10 GB/s pro Knoten eine Realität von 3 GB/s unter Last macht. Modellparallelität Passt das Modell selbst nicht mehr in den Speicher einer einzelnen GPU, verteilt die Modellparallelität das Modell auf mehrere GPUs. Zwei Untermuster sind verbreitet: Tensorparallelität teilt einzelne Schichten auf GPUs auf – eine einzelne Matrixmultiplikation läuft parallel auf mehreren Geräten. Pipeline-Parallelität teilt das Modell in Stufen auf, wobei verschiedene GPUs unterschiedliche aufeinanderfolgende Schichten halten und Microbatches durch die Pipeline fließen. Modellparallelität ist die einzige Option für Modelle im Frontier-Maßstab, aber sie ist kommunikationsintensiv. Vor allem Tensorparallelität erfordert Verbindungen mit sehr niedriger Latenz und sehr hoher Bandbreite zwischen den beteiligten GPUs. Deshalb werden modellparallele Gruppen meist innerhalb eines einzelnen Knotens oder einer kleinen Gruppe von Knoten mit Fabric auf NVLink-Niveau gehalten, während die Datenparallelität knotenübergreifend angewendet wird. Hybride Parallelität Produktive Trainingsläufe im großen Maßstab kombinieren beides. Ein verbreitetes Muster ist die 3D-Parallelität: Tensorparallelität innerhalb eines Knotens, Pipeline-Parallelität über eine kleine Gruppe von Knoten und Datenparallelität über viele solcher Gruppen. Jede Achse hat ihr eigenes Kommunikationsmuster, und jede wirkt anders auf die Speicherebene. Wie diese Muster die Datenebene prägen, vertiefen die Beiträge zu Speicher für KI-Trainingspipelines und Speicher für LLM-Trainingsdaten. Multi-Node-GPU-Cluster: das entscheidende Skalierungsmuster Ein Multi-Node-GPU-Cluster ist die Standardeinheit für die Skalierung von KI-Compute im Unternehmen. Das Muster ist gut verstanden, doch die Details entscheiden, ob der Cluster linear skaliert oder an Koordinationsgrenzen stößt. Interconnect-Topologie Innerhalb des Knotens kommunizieren die GPUs über NVLink oder Vergleichbares. Zwischen den Knoten ist das Fabric meist InfiniBand oder RoCEv2. Die Topologie zählt: Fat-Tree-, Dragonfly- und Rail-optimierte Designs haben je nach Clustergröße unterschiedliche Vor- und Nachteile für kollektive Kommunikation. Ein Cluster mit 64 Knoten verkraftet Topologieentscheidungen, die ein Cluster mit 1.024 Knoten nicht verkraftet. Fehlerdomänen Ein Multi-Node-Cluster fällt an Knoten, Racks, Switches, Kühlzonen und der Speicherebene aus. Lange Trainingsläufe überstehen kein nachlässig geplantes Layout der Fehlerdomänen – ein einziger Switch-Ausfall kann jeden laufenden Job anhalten. Dasselbe Prinzip gilt für Speicher. Ein Speichersystem mit kleinen Fehlerdomänen, das häufig neu aufgebaut werden muss, wird zur Hauptursache für Ausfallzeiten des Clusters. Hier zahlt sich eine Speicherarchitektur im Exabyte-Maßstab aus. Eine Speicherebene, die für Fehlerdomänen von mehreren Petabyte bis Exabyte ausgelegt ist und standortübergreifenden Schutz sowie Erasure Coding integriert, hält den Cluster nicht jedes Mal an, wenn ein Laufwerk oder ein Einschub ausfällt. Mehr zu diesem Design finden Sie unter Datenhaltbarkeit in Speichersystemen mit hoher Dichte. Orchestrierung Slurm dominiert Trainingscluster im HPC-Stil. Kubernetes wird für Inferencing, Aufbereitung und gemischte Workloads bevorzugt. Im großen Maßstab zeigen beide Ansätze dieselbe Anforderung: Die Speicherebene muss für jeden Knoten gleich aussehen – mit konsistenter Semantik und konsistenter Leistung, egal wie viele Jobs gleichzeitig geplant sind. Speicherskalierung: die Einschränkung, die die meisten Teams unterschätzen Das Muster ist in jedem KI-Programm von Unternehmen gleich, das ich in Analystenmaterial beschrieben gesehen habe: Teams skalieren das Compute und stellen fest, dass der Speicher die Mauer ist. Speicherskalierung darf kein nachträglicher Gedanke sein. Sie muss vom ersten Tag an zusammen mit der Compute-Roadmap geplant werden. Warum Speicher auf mehreren Achsen skalieren muss Compute ist nicht die einzige Dimension, die wächst. Speicher muss unabhängig auf drei Achsen skalieren: Kapazität – heute Petabytes, morgen mehrere Petabyte bis Exabyte, während sich Rohdaten, Embeddings, Modell-Checkpoints und Audit-Artefakte ansammeln. Durchsatz – eine Gesamtbandbreite von mehreren Terabyte pro Sekunde, damit Multi-Node-GPU-Cluster ohne Leerlauf versorgt werden. Parallelität – S3-Zugriff mit hoher Parallelität für Tausende gleichzeitiger Leser bei Datenparallelität, KV-Cache-Treffern und Inferencing-Replikaten. Eine Speicherebene, die die Kapazität skaliert, aber nicht den Durchsatz, ist ein Backup-Ziel. Eine Ebene, die den Durchsatz skaliert, aber nicht die Kapazität, hat keinen Platz mehr, bevor das Modell fertig trainiert ist. Eine Ebene, die beides skaliert, aber keinen gleichzeitigen S3-Zugriff über den Cluster bewältigt, wird zum Engpass am Eingang. Alle drei müssen zusammen wachsen. Temperaturübergreifendes Tiering Nicht jedes Byte gehört auf die heißeste Ebene. Der KI-Datenlebenszyklus bewegt Arbeit über verschiedene Temperaturen: Rohdaten-Ingestion, aufbereitete Trainingsdatensätze, heiße aktive Datensätze, Checkpoints, Embeddings und Langzeitaufbewahrung haben jeweils unterschiedliche Zugriffsmuster. Eine skalierbare Speicherarchitektur ordnet jeder Phase das passende Medium zu, statt alles auf Premium-Flash zu zwingen. Hintergrund dazu bieten Tiered Storage für KI und Speicherebenen im Rechenzentrum. Upgrades ohne Unterbrechung Skalierung bedeutet, dass der Speicher im Laufe der Lebensdauer des Clusters immer wieder erweitert, ersetzt und neu ausbalanciert wird. Ist jede Erweiterung ein geplanter Ausfall, summieren sich die Betriebskosten mit jedem Wachstumszyklus. Eine Speicherplattform mit unterbrechungsfreien Upgrades – Kapazitätserweiterungen, Hardware-Refreshes und Rebalancing, ohne den Namespace offline zu nehmen – ist das einzige Modell, das über mehrjährige KI-Roadmaps trägt. Wo Scality ADI bei der Skalierung von KI-Compute ansetzt Speicherentscheidungen bei der Skalierung binden das Team meist für Jahre. Scality ADI (Autonomous Data Infrastructure) ist darauf ausgelegt, dass diese Entscheidungen Bestand haben. Scality ADI ist eine Dateninfrastruktur für Enterprise-KI, Cyber-Resilienz und souveräne Kontrolle, die autonom und nachhaltig jeder Phase des Datenlebenszyklus die passenden Speichermedien zuordnet – im Maßstab von mehreren Petabyte bis Exabyte. Für die Skalierung von KI-Compute zählen vier Eigenschaften. Ein S3-Namespace mit vier Ebenen, der mit dem Cluster skaliert. Scality ADI umfasst eine GPU-Direct-Ebene (TLC-Flash mit S3 over RDMA, Latenz unter 50 Mikrosekunden), eine Hot-Ebene (QLC und NL-SSD mit einem Durchsatz von mehreren Terabyte pro Sekunde), eine Warm-Ebene (NL-SSD, NL-HDD, HDD) und eine Cold-Ebene (Band und Cloud-nahe Archivierung) in einem einzigen Namespace. Wächst der GPU-Footprint, wächst der Speicher auf der entscheidenden Achse mit – Kapazität, Durchsatz oder Parallelität –, ohne dass das Team Daten zwischen getrennten Plattformen kopieren muss. Fehlerdomänen im Exabyte-Maßstab. Die RING10-Architektur unter Scality ADI ist für Fehlerdomänen von mehreren Petabyte bis Exabyte ausgelegt – mit Erasure Coding, Metadatenschutz und standortübergreifendem Schutz als Teil der Architektur statt als spätere Ergänzung. Ein Scale-out-Trainingscluster wird weder durch ein Laufwerk noch durch einen Einschub oder einen Knoten angehalten. Upgrades ohne Unterbrechung und Betrieb wie bei einer Appliance. ScalityOS bietet eine standardisierte Laufzeitumgebung, die die Fragmentierung über Lebenszyklen hinweg auffängt. Kapazitätserweiterungen, Medien-Refreshes und Versions-Upgrades erfolgen, ohne den Namespace offline zu nehmen. Für ein Infrastrukturteam, das einen GPU-Cluster über mehrere Jahre und Hardwaregenerationen skaliert, ist das der Unterschied zwischen betrieblicher Reibung und betrieblicher Stabilität. Auf den Workload abgestimmte Profile statt Einheitslösung. Die autonome Betriebsschicht liefert Erkenntnisse und Empfehlungen innerhalb kundendefinierter Richtlinien, sodass jeder Workload beim Wachstum des Clusters das passende Speicherprofil erhält. So unterstützt Scality ADI Enterprise-KI im großen Maßstab. Best Practices für die Skalierung von KI-Compute Eine kurze Liste, abgeleitet aus den oben beschriebenen Mustern. Planen Sie die Speicherebene zusammen mit der Compute-Ebene – nicht danach. Beide skalieren gemeinsam oder gar nicht. Wählen Sie das Parallelisierungsmuster, das zu Ihrem Engpass passt, nicht das, das am modernsten klingt. Datenparallelität reicht, wenn das Modell passt; Modellparallelität nur, wenn es nicht passt. Planen Sie Fehlerdomänen explizit. Wissen Sie, was der Ausfall eines Switches, eines Knotens, eines Racks oder eines Speichereinschubs für laufende Jobs bedeutet. Vermeiden Sie Premium-Flash für jedes Byte. Ordnen Sie das Medium der Datentemperatur zu. Die kalte Ebene gibt es aus gutem Grund. Behandeln Sie Speicher-Upgrades als zentrales Thema. Ist jede Erweiterung ein geplanter Ausfall, ist der Plan falsch. Messen Sie jede Achse. Die GPU-Auslastung zeigt, dass der Cluster beschäftigt ist. Der Speicherdurchsatz pro Ebene zeigt, ob er mit nützlicher Arbeit beschäftigt ist oder auf I/O wartet. Häufig gestellte Fragen Ist horizontale oder vertikale Skalierung besser für KI-Workloads? Beides, nacheinander. Beginnen Sie vertikal für Prototypen und Training im kleinen Maßstab. Wechseln Sie zur horizontalen Skalierung, wenn das Modell einen einzelnen Knoten übersteigt, wenn der Datensatz den lokalen Speicher übersteigt oder wenn die Parallelität ein einzelnes Replikat übersteigt. Die meisten produktiven KI-Umgebungen in Unternehmen skalieren innerhalb der Knoten vertikal und über die Knoten hinweg horizontal. Was ist der Unterschied zwischen Daten- und Modellparallelität? Bei der Datenparallelität liegt auf jeder GPU eine vollständige Kopie des Modells, und die Trainingsdaten werden auf die GPUs verteilt. Bei der Modellparallelität wird das Modell selbst auf GPUs verteilt, entweder nach Schichten (Pipeline) oder innerhalb einer Schicht (Tensor). Datenparallelität skaliert am saubersten; Modellparallelität ist nötig, wenn das Modell nicht mehr auf eine GPU passt. Wie begrenzt Speicher die Skalierung von KI-Compute? Indem er auf einer von drei Achsen zu wenig liefert: Kapazität, Durchsatz oder Parallelität. Ein Multi-Node-GPU-Cluster läuft leer, sobald der Speicher nicht jede GPU parallel versorgen kann. Speicher, der auf allen drei Achsen unabhängig skaliert – und Knoten- sowie Standortausfälle übersteht, ohne den Cluster anzuhalten –, ist die Voraussetzung dafür, Compute über ein einzelnes Rack hinaus zu skalieren. Welche Rolle spielt Scality ADI bei der Skalierung von KI-Infrastruktur? Scality ADI bietet einen S3-Namespace mit vier Ebenen, der Kapazität, Durchsatz und Operationen unabhängig voneinander skaliert – mit Fehlerdomänen im Exabyte-Maßstab und unterbrechungsfreien Upgrades. Die Plattform ist so gebaut, dass die Speicherebene nie zu der Einschränkung wird, die die Obergrenze des GPU-Clusters bestimmt. Weiterführende Artikel KI-Compute-Infrastruktur: Komponenten und Design-Leitfaden KI-Datenpipelines: Architektur, Phasen und Best Practices Mehrdimensionale Skalierung von Cloud-Speicher Speicher im Petabyte-Maßstab GPU-Direct Storage Scality ADI: KI-Dateninfrastruktur Fazit Die Skalierung von KI-Compute ist kein Problem des Hardwareeinkaufs, sondern ein Architekturproblem. Teams, die erfolgreich skalieren, behandeln Compute, Interconnect und Speicher als ein einziges Design – nicht als drei unabhängige Beschaffungszyklen. In der Speicherebene scheitern die meisten Skalierungsprogramme unbemerkt. Kapazität, Durchsatz und Parallelität müssen jeweils auf ihrer eigenen Achse wachsen, ohne den Namespace offline zu nehmen und ohne die Annahmen zu den Fehlerdomänen zu brechen, auf die sich die Trainingsjobs verlassen. Scality ADI ist für genau dieses Profil gebaut: eine Plattform, vier Ebenen, Fehlerdomänen im Exabyte-Maßstab, unterbrechungsfreie Upgrades und ein Betriebsmodell wie bei einer Appliance, das mit dem wachsenden GPU-Footprint trägt. Der Cluster skaliert, weil der Speicher mit ihm skaliert.
