6 GPU-Cluster in großen Unternehmen laufen routinemäßig mit 30–50 % Auslastung – nicht weil die Hardware fehlerhaft ist, sondern weil die Speicher- und Datenpipelines, die sie versorgen, nicht mithalten können. KI-Recheneffizienz ist nicht allein ein GPU-Problem. Sie ist ein Systemproblem, und in der Datenebene steckt der größte Teil des ungenutzten Spielraums. Für einen CIO oder Head of AI Infrastructure bedeutet diese Lücke sowohl ein Kostenrisiko als auch einen Wettbewerbsnachteil. Die Investition in beschleunigte Rechenleistung ist real; ihre Rendite hängt vollständig davon ab, die GPUs ausgelastet zu halten. Dieser Leitfaden erklärt, was die KI-Recheneffizienz bestimmt, warum Speicher-I/O ein Hauptengpass ist, welche Optimierungsstrategien wirklich etwas bewegen, welche Metriken Fortschritte sichtbar machen und wie eine eigens für KI-Workloads entwickelte Infrastruktur den Speicher als Engpass beseitigt. Was ist KI-Recheneffizienz? KI-Recheneffizienz ist das Verhältnis der geleisteten nützlichen Rechenarbeit zur insgesamt verfügbaren Rechenkapazität. Ein Cluster mit 100 GPUs bei durchschnittlich 40 % Auslastung ist zu 60 % ineffizient – 60 GPU-Äquivalente an Investitionen, die keinen Modelldurchsatz liefern. Effizienzverluste entstehen auf jeder Ebene des Stacks: GPU-Leerlauf beim Laden von Daten, Engpässe bei der Übertragung zwischen CPU und GPU, ungünstige Batch-Größen, übermäßiger Checkpoint-Aufwand sowie thermische oder leistungsbedingte Drosselung. Hohe KI-Recheneffizienz bedeutet, dass jede Komponente der Pipeline nahezu ihre Nennleistung für sinnvolle Arbeit erbringt, statt darauf zu warten, dass eine andere Ebene aufholt. Für Enterprise-KI im großen Maßstab – Training großer Modelle, Inferencing in hohem Volumen, agentische Pipelines – wird Effizienz in Durchsatz pro Dollar, Zeit bis zur Erkenntnis pro Job und GPU-Stunden pro trainiertem Modell gemessen, nicht in Benchmark-Spitzen auf einem einzelnen Knoten. Warum GPUs ins Stocken geraten: die eigentlichen Engpässe Hardware-Marketing konzentriert sich auf Spitzen-FLOPS. Betriebsteams leben in der Lücke zwischen Spitzen- und Dauerdurchsatz. Mehrere Kategorien von Engpässen erzeugen diese Lücke. Speicher-I/O und Laden von Daten Der Trainingsdurchsatz wird durch die langsamste Stufe der Pipeline begrenzt. Bei den meisten KI-Workloads im großen Maßstab ist diese Stufe die Datenaufnahme. Kann die Speicherebene die Lesebandbreite, die die GPUs verlangen, nicht dauerhaft liefern, verharren die Beschleuniger im Leerlauf und warten auf das Prefetching. Das ist GPU-Starvation – und sie ist verbreitet. Das Problem verschärft sich mit der Größe des Datensatzes. Ein Modell, das auf Bild- oder Videodatensätzen im Multi-Petabyte-Bereich trainiert, braucht Speicher, der Hunderte Gigabyte pro Sekunde konstant und für viele gleichzeitige Leser liefert. Ein System, das im Benchmark auf einem einzelnen Knoten 10 GB/s erreicht, unter paralleler Last von 64 Knoten aber auf 3 GB/s fällt, hat das Problem nicht gelöst. Wie die Speicherarchitektur die Leistung von KI-Pipelines direkt prägt, zeigt der Beitrag KI-Datenspeicher ohne Hindernisse. Checkpoint-Aufwand Checkpointing ist bei langen Trainingsläufen unverzichtbar. Ein Ausfall ohne aktuellen Checkpoint vergeudet Stunden oder Tage an GPU-Zeit. Doch Checkpointing hat selbst seinen Preis: Das Schreiben großer Modellzustände in den Speicher hält die Trainingsschleife an. Schlecht konzipierter Checkpoint-Speicher – langsame Medien, hohe Latenz oder sequenzielle Schreibpfade – kann 10–20 % der gesamten Trainingslaufzeit verbrauchen. Die Speicherarchitektur für Modell-Checkpoints ist genauso wichtig wie die Checkpoint-Häufigkeit. Ineffizienzen in der Datenpipeline CPU-gebundene Vorverarbeitung, die den Data Loader nicht auslasten kann, zu geringe Prefetch-Tiefe und schlecht abgestimmte Batch-Größen führen alle zu GPU-Leerlaufzyklen. Der Engpass zeigt sich im Profiler oft als hohe GPU-Auslastung – doch diese Auslastung entfällt auf das Warten auf Speicherübertragungen, nicht auf die Ausführung von Matrixoperationen. Thermische und leistungsbedingte Drosselung Unter Dauerlast stoßen Knoten ohne genaue Stromtelemetrie an thermische Grenzen oder an das Energiebudget und drosseln. Ohne Einblick in den Stromverbrauch auf Workload-Ebene können Teams nicht erkennen, welche Jobs auf welchen Knoten wann gedrosselt werden – und damit auch nicht um die Einschränkungen herum planen. Optimierungsstrategien Die folgende Tabelle ordnet gängigen Engpässen den jeweils wichtigsten Optimierungsansatz zu. Engpass Optimierungsansatz GPU-Starvation (Laden von Daten) Tiered Storage mit Hot-Ebene für hohen Durchsatz; Prefetching von Daten Checkpoint-Latenz Checkpoint-Speicher mit niedriger Latenz; asynchrones Schreiben von Checkpoints Aufwand für CPU-GPU-Übertragungen GPU-Direct Storage (RDMA); Datenplatzierung nahe am Compute Prefetch-Tiefe der Pipeline Abgestimmte DataLoader-Worker; Software-Prefetch-Puffer Thermische/leistungsbedingte Drosselung Stromtelemetrie auf Knoten- und Workload-Ebene; Leitplanken für die Planung Lesezugriffe auf kalte Daten bremsen heiße Jobs Speicher-Tiering; Lifecycle-Richtlinien, die aktive Daten auf schnellen Medien halten Synchronisationsaufwand über mehrere Knoten Überprüfung der Modellparallelisierungsstrategie; Audit der NVLink-/InfiniBand-Topologie Tiered Storage Nicht alle KI-Daten brauchen zur selben Zeit dieselbe Speicherebene. Aktive Trainingsdatensätze gehören auf Flash mit hohem Durchsatz. Checkpoints brauchen Schreibvorgänge mit niedriger Latenz und zuverlässiger Ausfallsicherheit. Archivierte Modelle und historische Datensätze können auf Medien mit höherer Kapazität und geringeren Kosten liegen. Eine Tiered-Storage-Architektur ordnet die Medien den Zugriffsmustern zu. So bleibt schneller Speicher den Jobs vorbehalten, die ihn brauchen – das reduziert Verschwendung und verhindert, dass Workloads mit hoher Priorität mit Archivlesezugriffen um dieselbe Bandbreite konkurrieren. Eine praxisnahe Aufschlüsselung bietet der Beitrag Tiered Storage für KI: skalierbare Leistung und Kostenkontrolle im Detail. Prefetching von Daten und Pipeline-Tiefe Eine GPU, die einen Batch abgeschlossen hat und darauf wartet, dass der nächste aus dem Speicher eintrifft, trainiert nicht. Prefetch-Pipelines laden den nächsten Batch in den GPU-Speicher, während der aktuelle verarbeitet wird. Die Tiefe dieses Prefetch-Puffers – wie viele Batches die Pipeline im Voraus bereitstellt – entscheidet, ob die GPU jemals leerläuft. Zur Optimierung der Prefetch-Tiefe muss die tatsächliche Ladezeit der Daten pro Batch mit der Rechenzeit verglichen werden. In den meisten verteilten Trainingsumgebungen unterscheidet sich die optimale Konfiguration je nach Datensatztyp, Modellarchitektur und Clustergröße. Checkpoint-Design Asynchrones Checkpointing entkoppelt den Schreibvorgang von der Trainingsschleife. Der Modellzustand wird in einen CPU-Puffer kopiert und im Hintergrund in den Speicher geschrieben, während das Training weiterläuft. Das beseitigt den synchronen Stillstand bei Workloads, bei denen blockierende Schreibvorgänge aufgrund der Checkpoint-Größe teuer sind. Die Checkpoint-Häufigkeit sollte an die tatsächliche Ausfallrate und die Wiederherstellungskosten angepasst werden, statt aus Gewohnheit übervorsichtig gewählt zu werden. Zu häufige Checkpoints auf langsamem Speicher sind eine erhebliche Effizienzsteuer. Modell- und Datenparallelität Beim Training großer Modelle wirkt sich die Aufteilung von Modell und Daten auf die GPUs direkt auf die Auslastung aus. Tensor-, Pipeline- und Datenparallelität haben jeweils unterschiedliche Kommunikations- und Synchronisationskosten. Die richtige Strategie hängt von Modellarchitektur, GPU-Interconnect-Bandbreite und Clustertopologie ab. Stromtelemetrie und Planung Workloads, die das dauerhaft tragbare Energiebudget eines Knotens überschreiten, werden gedrosselt – und gedrosselte GPUs sind ineffiziente GPUs. Einblick in den Stromverbrauch auf System-, Knoten- und Workload-Ebene ermöglicht es Betriebsteams, eingeschränkte Knoten zu erkennen, energieintensive Jobs fernab thermischer Grenzen einzuplanen und genaue Nachhaltigkeitsberichte zu erstellen. Das Management des Energiebudgets ist eine betriebliche Disziplin, keine Hardwarefunktion, die man einmal kauft und dann vergisst. Metriken zur Messung der KI-Recheneffizienz Effizienz zu messen erfordert Instrumentierung auf mehreren Ebenen. Die folgenden Metriken ergeben ein vollständiges Bild: GPU-Auslastung (SM active %): Der übliche Ausgangspunkt. Liegt sie dauerhaft unter 60 %, lohnt sich eine Untersuchung. Auslastung der GPU-Speicherbandbreite: Hohe SM-Aktivität bei niedriger Speicherbandbreite deutet auf rechengebundene Arbeit hin; der umgekehrte Fall auf einen Speicherengpass. Ladezeit der Daten vs. Rechenzeit pro Batch: Messen Sie beides. Übersteigt die Ladezeit die Rechenzeit, ist die Speicherpipeline der begrenzende Faktor. Schreibzeit für Checkpoints: Gemessen pro Checkpoint-Ereignis und als Anteil an der gesamten Trainingslaufzeit. Speicherdurchsatz (Lesen/Schreiben in MB/s): Gemessen auf Clusterebene unter Produktionslast, nicht in Benchmarks auf einem einzelnen Knoten. Speicherlatenz (P50, P99): Besonders relevant für KV-Cache-Zugriffe und Inferencing-Workloads, bei denen die Tail-Latenz die für Nutzer sichtbare Antwortzeit beeinflusst. Stromverbrauch pro GPU-Stunde: Effizienz und Nachhaltigkeit in einer Metrik. GPU-Stunden pro trainiertem Modell: End-to-End-Effizienz über den gesamten Trainingslauf. Bei agentischer KI-Speicherinfrastruktur und retrievalintensiven Workloads sollten Sie zusätzlich die Abfragelatenz des Vektorindex und den Durchsatz beim Speicher für Vektordatenbanken als Effizienzsignale verfolgen. Wie Scality ADI den Speicher als Engpass beseitigt Für die meisten Infrastrukturteams in Unternehmen ist der Speicher die am leichtesten zu behebende Quelle für Ineffizienz bei KI-Compute – und zugleich die Ebene, die am häufigsten erst nachträglich bereitgestellt wird. Scality ADI (Autonomous Data Infrastructure) ) ist eigens dafür entwickelt, GPUs produktiv zu halten. Die Plattform ordnet jeder Phase des KI-Datenlebenszyklus – von aktiven Trainingsdatensätzen bis zu archivierten Modellversionen – das passende Medium, die passende Leistungsebene und das passende Governance-Modell zu. GPU-Direct-Ebene: Übertragungsaufwand beseitigen Die GPU-Direct-Ebene von Scality ADI nutzt TLC-Flash mit S3 over RDMA und liefert eine Latenz unter 50 Mikrosekunden. RDMA (Remote Direct Memory Access) umgeht bei Datenübertragungen die CPU und überträgt Speicherlesezugriffe direkt in den GPU-Speicher. Die Datenpipeline konkurriert dadurch nicht mehr mit dem Compute um CPU-Zyklen, und die Latenz der Speicherebene begrenzt die Prefetch-Tiefe nicht länger. Bei Workloads, bei denen KV-Cache-Zugriffe oder Checkpoint-Lesezugriffe im kritischen Pfad liegen – Inferencing, Training von Modellen mit langem Kontext –, verändert eine Latenz unter 50 µs den Leistungsrahmen. Hot-Ebene: Durchsatz im Multi-TB/s-Bereich für Training im großen Maßstab Die Hot-Ebene von Scality ADI nutzt QLC/NL-SSD und liefert einen Gesamtdurchsatz von mehreren Terabyte pro Sekunde. Beim Training mit 64 oder 128 Knoten hält dieser Durchsatz die Datenaufnahme aufrecht, die nötig ist, um die GPU-Beschleuniger über den gesamten Trainingslauf zu versorgen. Leistung sollte im großen Maßstab beurteilt werden, nicht nur an der Benchmark-Spitze. Ein Speichersystem, das unter paralleler Last an seine Grenzen stößt, erzeugt Latenzschwankungen genau dort, wo sie am meisten schaden: bei den kritischen Batch-Lesezugriffen, die über den GPU-Leerlauf entscheiden. AI Data Flow und Checkpoint-Speicher Die Funktion AI Data Flow von Scality ADI unterstützt KV-Cache und Checkpoint-Speicher nativ. Checkpoints werden auf die passende Ebene geschrieben, ohne dass eigene Tools oder komplexe Lifecycle-Konfigurationen nötig sind. Der Checkpoint-Aufwand sinkt auf das, was die Hardware hergibt, statt auf das, was ein generisches Speichersystem leisten kann. Stromtelemetrie Einblick in den Stromverbrauch auf System-, Knoten- und Workload-Ebene ist in Scality ADI integriert. Das ermöglicht Nachhaltigkeitsberichte und das Management des Energiebudgets auf Infrastrukturebene – und schließt die Lücke zwischen dem, was bereitgestellt wird, und dem, was pro Trainingsjob tatsächlich verbraucht wird. „Es gibt nicht den einen KI-Workload. Scality ADI ordnet jeder Phase des Datenlebenszyklus das passende Medium, die passende Leistung und das passende Governance-Modell zu.“ Designüberlegungen für KI-Rechenzentren und die Rolle des Speichers in der gesamten Infrastrukturplanung beschreibt der Beitrag zum KI-Rechenzentrum. Scality ADI für KI-Infrastruktur entdecken → Häufig gestellte Fragen Was ist KI-Recheneffizienz? KI-Recheneffizienz ist der Anteil der verfügbaren Rechenkapazität, der produktive Arbeit leistet – Trainingsschritte, verarbeitete Inferencing-Tokens oder Gradientenaktualisierungen –, statt im Leerlauf zu stehen, auf Daten zu warten oder gedrosselt zu werden. Sie wird auf Jobebene (GPU-Stunden pro trainiertem Modell) und auf Clusterebene (durchschnittliche GPU-Auslastung über die gesamte Flotte) gemessen. Warum bleiben GPUs beim KI-Training hinter ihren Möglichkeiten zurück? Die häufigsten Ursachen sind Engpässe beim Laden von Daten (das Speicher-I/O kann die GPUs nicht schnell genug versorgen), Checkpoint-Aufwand (synchrone Schreibvorgänge halten die Trainingsschleife an), ineffiziente Übertragungen zwischen CPU und GPU sowie thermische oder leistungsbedingte Drosselung bei Dauerlast. Hohe Auslastungswerte im Profiler können irreführend sein, wenn die GPU aktiv auf Speicherübertragungen wartet, statt Matrixoperationen auszuführen. Wie wirkt sich Speicher-I/O auf die KI-Recheneffizienz aus? Speicher-I/O ist oft die entscheidende Grenze für die GPU-Auslastung. Kann das Speichersystem die Lesebandbreite eines Trainingsjobs über mehrere Knoten nicht dauerhaft liefern, gehen die GPUs in den Prefetch-Wartezustand – einen Leerlauf, der in einfachen GPU-Metriken nicht als Unterauslastung erscheint, wohl aber als geringerer Durchsatz und längere Trainingslaufzeit. Parallele Lesezugriffe vieler Trainingsknoten gleichzeitig decken Bandbreitengrenzen des Speichers auf, die Benchmarks auf einem einzelnen Knoten verbergen. Welche Metriken eignen sich am besten zur Messung der KI-Recheneffizienz? Die aussagekräftigste Kombination ist: SM-Aktivität der GPU in Prozent, Ladezeit der Daten im Vergleich zur Rechenzeit pro Batch (gleichzeitig gemessen), Schreibzeit für Checkpoints als Anteil an der Laufzeit, Lesedurchsatz des Speichers unter voller Clusterlast sowie GPU-Stunden pro trainiertem Modell für eine End-to-End-Effizienzbetrachtung. Der Stromverbrauch pro GPU-Stunde ergänzt die Dimension Nachhaltigkeit und Kosten. Weiterführende Artikel Tiered Storage für KI: skalierbare Leistung und Kostenkontrolle KI-Datenspeicher ohne Hindernisse Speicher für Modell-Checkpoints Agentische KI-Speicherinfrastruktur Stromverbrauch bei hoher Dichte: HDD vs. QLC-Flash Ist All-Flash die beste Wahl? (auf Englisch) KI-Rechenzentrum
