Mit der Weiterentwicklung der KI-Infrastruktur werden Datenpipelines schneller, umfangreicher und komplexer. Vom Training großer Modelle bis hin zu Echtzeit-Inferenzen im großen Maßstab ist das Speichersubsystem entscheidend, um sicherzustellen, dass GPUs kontinuierlich die benötigten Daten erhalten. Da Speicher in KI-Clustern immer wichtiger wird, überdenken Unternehmen, wie sie hohen Durchsatz, vorhersehbare Leistung und Ausfallsicherheit gewährleisten können, insbesondere in Umgebungen, in denen Datenverlust oder Ausfallzeiten schlichtweg inakzeptabel sind.
Die Herausforderung wird noch größer, da KI-Modelle weiterhin exponentiell wachsen. Moderne große Sprachmodelle und Basismodelle erfordern häufige Checkpoints, um den Trainingsfortschritt zu sichern. Mit der Vergrößerung der Modellgrößen von Milliarden auf Billionen von Parametern steigt der Speicherbedarf für diese Checkpoints proportional. Dies schafft einen dringenden Bedarf an großen, einheitlichen Speichernamespaces, die riesige Checkpoint-Dateien verarbeiten und gleichzeitig eine extrem schnelle Schreib- und Leseleistung gewährleisten können. Herkömmliche Speicherarchitekturen haben Schwierigkeiten, die für diese anspruchsvollen Workloads erforderliche Kapazität und Geschwindigkeit bereitzustellen.
Aktuelle Ansätze zur Checkpoint-Verwaltung, wie beispielsweise asynchrones Checkpointing, bei dem Modellgewichte in den CPU-Speicher geschrieben werden, damit GPUs weiter trainieren können, stoßen bei wachsendem Modellwachstum an erhebliche Einschränkungen. Die temporäre Speicherung dieser Checkpoints im Systemspeicher wird zunehmend verschwenderischer und teurer und erfordert enorme Mengen an RAM, was die Systemkosten und den Stromverbrauch in die Höhe treibt. Kritischer noch: Mit zunehmender Modellgröße könnte dieser Ansatz aufgrund der enormen Datenmenge, die temporär im Speicher gehalten werden müsste, völlig unpraktisch werden.
Graid Technology hat einen neuen Ansatz eingeführt, der speziell auf diese Herausforderungen zugeschnitten ist. Aufbauend auf dem softwaredefinierten Modell früherer Lösungen wie dem SupremeRAID SR1010, Graids neue SupremeRAID AE (AI Edition) bringt Enterprise-RAID-Funktionalität mit minimalen Infrastrukturänderungen in KI-Workloads. Anstelle einer dedizierten Hardware-RAID-Karte oder eines benutzerdefinierten Geräts wird AE als Softwarelizenz bereitgestellt und nutzt nur einen kleinen Teil einer vorhandenen NVIDIA-GPU. Dies bedeutet, dass Unternehmen Speicherleistung und Zuverlässigkeit auf Enterprise-Niveau erreichen können, ohne 1) zusätzliche PCIe-Steckplätze zu belegen, 2) Infrastrukturänderungen vorzunehmen oder 3) die GPU-Leistung bei Trainings- und Inferenz-Workloads erheblich zu beeinträchtigen.
Wichtige Erkenntnisse
- Hohe Leistung im großen Maßstab: SupremeRAID AE erreicht einen Lesedurchsatz von bis zu 183.60 GB/s und einen Schreibdurchsatz von bis zu 54.23 GB/s und erfüllt damit anspruchsvolle KI-Anforderungen.
- Minimaler GPU-Overhead: Führt bei GPU-intensiver Inferenz zu minimalem Overhead (~4 %) und sorgt so für eine starke Gesamtsystemleistung.
- Massiver einheitlicher Speichernamespace: Unterstützt bis zu 32 NVMe-SSDs pro Array und bietet fast 1 PB Speicher in einem einzigen einheitlichen Namespace.
- Erweiterte Integrationsfunktionen: Vollständige Integration mit NVIDIA GPUDirect Storage und führenden KI-orientierten Dateisystemen (BeeGFS, Lustre, Ceph).
- Vereinfachte Infrastruktur: Macht dedizierte RAID-Hardware überflüssig und reduziert so Komplexität, Kosten und Betriebsaufwand erheblich.
Optimierter Speicher und Ausfallsicherheit für erweiterte KI-Workloads
SupremeRAID AE unterstützt bis zu 32 NVMe-SSDs in einem einzigen Array und fasst sie in einem einheitlichen Namespace zusammen. Diese Struktur ermöglicht KI-Workloads den effizienten Zugriff auf große Datensätze bei gleichzeitiger Wahrung der Ausfallsicherheit, was insbesondere für Umgebungen mit langwierigen Trainingsaufträgen wichtig ist. Im Falle eines Laufwerksausfalls bleibt das Array verfügbar, und der Checkpoint-Fortschritt bleibt erhalten. Dieser Schutz minimiert das Risiko von Datenverlust oder zeitaufwändigen Neustarts, was ein erheblicher Vorteil für Teams ist, die große Modelle oder Inferenzpipelines mit hohem Volumen verwalten.
Die intelligenten Ressourcenmanagementfunktionen von SupremeRAID AE bieten zusätzliche Optimierungsmöglichkeiten für KI-Workloads. Unsere Tests zeigen zwar einen minimalen Overhead bei gleichzeitigen Vorgängen, die Auswirkungen können jedoch durch intelligente Planung weiter reduziert werden. Checkpoint-Vorgänge laufen in der Regel nicht gleichzeitig mit aktivem Training auf demselben Knoten. Während der Checkpoint-Phasen kommt es in der Regel zu einer kurzen Trainingspause. Während dieser Zeit kann SupremeRAID AE zusätzliche ungenutzte GPU-Ressourcen nutzen, um den Checkpoint-Abschluss zu beschleunigen.
SupremeRAID AE unterstützt außerdem NVIDIA GPUDirect Storage. Dies ermöglicht direkte Pfade zwischen Speicher und GPU-Speicher, was zu geringerer Latenz und verbesserter I/O-Effizienz führt. Es lässt sich in KI-zentrierte Dateisysteme wie BeeGFS, Lustre und Ceph integrieren und umfasst intelligentes Daten-Offloading sowie orchestrierungsbereite APIs für die Automatisierung. Insgesamt bietet SupremeRAID AE eine vereinfachte und dennoch leistungsstarke Möglichkeit, RAID-Vorteile in moderne KI-Workflows zu integrieren.
Über Trainings-Workloads hinaus erfüllt SupremeRAID AE wichtige Anforderungen moderner KI-Inferenzszenarien. Unternehmen skalieren Inferenzvorgänge und setzen dabei zunehmend auf fortschrittliche Strategien wie persistentes KV-Cache-Management, Prefill-Decode-Optimierung und mehrstufige Speicherarchitekturen. Diese Techniken erfordern häufig die Auslagerung von KV-Caches in den Speicher, wenn sie die VRAM-Kapazität überschreiten. Lösungen wie NVIDIA Dynamo, Red Hats LLM-D und der vLLM-Produktionsstack beinhalten alle mehrstufige KV-Caching-Integrationen, die auf schnellen Speicher mit hoher Kapazität angewiesen sind. In diesen Szenarien sind große, leistungsstarke Speicherpools für die Aufrechterhaltung einer Inferenz mit geringer Latenz unerlässlich. Die Fähigkeit von SupremeRAID AE, sowohl enorme Kapazität als auch außergewöhnliche Geschwindigkeit bereitzustellen, macht es zur idealen Grundlage für diese fortschrittlichen Inferenzarchitekturen.
In dieser Analyse bewerten wir SupremeRAID AE auf unserer Dell PowerEdge R770-Plattform mit zwei NVIDIA H100-GPUs und 16 Micron 6550 61.44 TB Gen5 NVMe-SSDs. Wir untersuchen die Leistung unter RAID 5 mit GDSIO- und FIO-Tools und untersuchen, wie sich Graid AE auf das GPU-Verhalten während einer Live-LLM-Inferenz-Workload auswirkt. Ziel ist es zu verstehen, wie sich diese Lösung in KI-Umgebungen der Enterprise-Klasse integriert, in denen Leistung, Kapazität, Ausfallsicherheit und Einfachheit skaliert werden müssen.
Hinter den Zahlen: SupremeRAID AE Performance Deep Dive
Um die Leistung von Graid SupremeRAID AE zu testen, haben wir einen Dell PowerEdge R770 mit zwei NVIDIA H100-GPUs und 16 E3.S-Schächten an der Vorderseite konfiguriert. Dieses System basiert auf Intels neuester Xeon 6-Plattform und ist mit zwei Intel Xeon 6787P-Prozessoren mit jeweils 86 Kernen ausgestattet, um hochparallele Workloads in KI-, HPC- und datenintensiven Umgebungen zu bewältigen.
Der R770 wurde mit 16 E3.S-Einschüben konfiguriert und der Speicher vollständig mit Micron 6550 ION 61.44 TB Gen5 NVMe TLC SSDs bestückt, die für eine konstante Leistung bei einem breiten Spektrum von Workloads ausgelegt sind. Die Micron SSDs bieten eine ideale Balance aus außergewöhnlicher Leistung und enormer Kapazität, sodass KI-Workloads einen hohen Durchsatz gewährleisten und gleichzeitig die KI-Infrastruktur drastisch vereinfacht wird. Mit einem Petabyte Speicher auf nur 16 Laufwerken können Unternehmen umfangreiche Datensätze und groß angelegte Modell-Checkpoints effizient auf einem einzigen Server verwalten, was Komplexität und Infrastrukturaufwand deutlich reduziert.
Spezifikationen des Testsystems
- Plattform: Dell PowerEdge R770
- ZENTRALPROZESSOR: 2x Intel Xeon 6787P (je 86 Kerne)
- Erinnerung: 32x Micron 64 GB Dual-Rank DDR5 6400 MT/s Gesamtspeicher: 2 TB
- Netzwerk: DELL BRCM 4P 25G SFP 57504S OCP NIC
- GPU 1: NVIDIA H100 (VRAM 80 GB)
- GPU 2: NVIDIA H100NVL (VRAM 96 GB)
- Lagerung: 16 x 61 TB Micron ION 6550 SSDs (915 TB RAID 5-Pool)
Im Rahmen dieses Leistungstests wurden die Micron SSDs mit SupremeRAID AE in einem einzigen RAID 5-Pool konfiguriert. Dieses Layout wurde gewählt, um zu bewerten, wie gut SupremeRAID AE Leistung und Fehlertoleranz in einer KI-gesteuerten Umgebung mit hohem Speicherbedarf ausbalanciert. RAID 5 verteilt die Parität auf alle Laufwerke und schützt so vor dem Ausfall einzelner Laufwerke, ohne dass die nutzbare Speicherkapazität verloren geht.
Bevor wir uns mit den Leistungstests befassen, ist es wichtig, die Unterschiede zwischen GDSIO und FIO bei der Messung der Speicherleistung mit Graid zu beachten. Bei unseren vorherigen Bewertungen der Graid-Leistung war eine wichtige Beobachtung, dass es keine Engpässe (wie z. B. eine Hardware-RAID-Karte) gibt, die die maximale Bandbreite begrenzen. Hardware-RAID-Karten verwalten die an sie angeschlossenen Speichergeräte, und der PCIe-Steckplatz kann dabei zum Engpass werden. Graid nutzt eine GPU für RAID-Operationen, aber nicht alle Daten müssen sie durchlaufen. Daher begrenzt die GPU die Bandbreite nicht.
Der FIO-Speicherbenchmark misst die Speicherleistung, indem er die CPU für den Speicherzugriff nutzt und nur durch die Speicherlösung begrenzt wird. GDSIO hingegen misst die Leistung von GPU Direct Storage, wobei die GPU der limitierende Faktor sein kann. Die NVIDIA H100 verfügt beispielsweise über eine PCIe Gen5 x16-Schnittstelle und ermöglicht eine ein- und ausgehende Bandbreite von etwa 63 GB/s. Bei GPU-Leistungsengpässen in diesem Zusammenhang geht es um die Bandbreite, die die GPU mit GPU Direct Storage unterstützen kann, und nicht um einen Graid-Engpass.
NVIDIA GPU-Direktspeicher
Einer der Tests, die wir auf diesem Prüfstand durchgeführt haben, war der Magnum IO GPU Direct Storage (GDS)-Test. GDS ist eine von NVIDIA entwickelte Funktion, die es GPUs ermöglicht, die CPU beim Zugriff auf Daten auf NVMe-Laufwerken oder anderen Hochgeschwindigkeitsspeichern zu umgehen. Anstatt Daten über die CPU und den Systemspeicher zu leiten, ermöglicht GDS die direkte Kommunikation zwischen GPU und Speichergerät, was die Latenz deutlich reduziert und den Datendurchsatz verbessert.
So funktioniert GPU Direct Storage
Wenn eine GPU Daten verarbeitet, die auf einem NVMe-Laufwerk gespeichert sind, müssen die Daten normalerweise zuerst durch die CPU und den Systemspeicher laufen, bevor sie die GPU erreichen. Dieser Prozess führt zu Engpässen, da die CPU zum Mittelsmann wird, was zu Latenz führt und wertvolle Systemressourcen verbraucht. GPU Direct Storage beseitigt diese Ineffizienz, indem es der GPU ermöglicht, über den PCIe-Bus direkt vom Speichergerät auf Daten zuzugreifen. Dieser direkte Pfad reduziert den mit der Datenbewegung verbundenen Overhead und ermöglicht schnellere und effizientere Datenübertragungen.
KI-Workloads, insbesondere solche mit Deep Learning, sind äußerst datenintensiv. Das Training großer neuronaler Netzwerke erfordert die Verarbeitung von Terabyte an Daten, und jede Verzögerung bei der Datenübertragung kann zu einer Unterauslastung der GPUs und längeren Trainingszeiten führen. GPU Direct Storage bewältigt diese Herausforderung, indem es sicherstellt, dass die Daten so schnell wie möglich an die GPU übermittelt werden, wodurch Leerlaufzeiten minimiert und die Rechenleistung maximiert werden.
Darüber hinaus ist GDS besonders vorteilhaft für Workloads, die das Streamen großer Datensätze beinhalten, wie etwa Videoverarbeitung, Verarbeitung natürlicher Sprache oder Echtzeit-Inferenz. Durch die Reduzierung der Abhängigkeit von der CPU beschleunigt GDS die Datenbewegung und gibt CPU-Ressourcen für andere Aufgaben frei, was die Gesamtsystemleistung weiter verbessert.
GDSIO 16-Laufwerk – zufälliger Lesedurchsatz
Bevor wir uns mit den Leistungszahlen befassen, ist es wichtig zu beachten, dass der limitierende Faktor für die Lese- und Schreibleistung bei GDSIO-Werten die GPU(s) sind. Der Test misst die maximale Speicherleistung, die von der GPU gepusht oder gezogen werden kann. Im PCIe-Steckplatz tritt ein Engpass auf, der bei PCIe Gen5 x16 bei etwa 63 GB/s liegt.
Beim GDSIO-Durchsatz für wahlfreies Lesen lieferte das Array die besten Ergebnisse bei größeren Blockgrößen und einer höheren Threadzahl, während es am unteren Ende Probleme mit der effizienten Skalierung hatte. Bei 16K/128 Threads begannen die Dinge deutlicher zu bessern und erreichten 7.3 GiB/s, aber eine echte Durchsatzbeschleunigung setzte erst bei 32K und mehr ein, wo das Array 15.5 GiB/s mit 64 Threads erreichte. Erhebliche Zuwächse wurden bei 64K beobachtet, wo die Leistung auf 25.9 GiB/s anstieg, und die Leistung stieg ab 128K an, wo sie 41.3 GiB/s bei 64 Threads erreichte und bei 40 Threads über 128 GiB/s blieb. Der Spitzendurchsatz wurde bei einer Blockgröße von 1M mit 32 Threads erreicht, wo das Array 88.5 GiB/s erreichte und dieses Niveau bei der höchsten Threadzahl hielt.
GDSIO 16-Laufwerk – zufällige Leselatenz
Im Anschluss an die Durchsatzergebnisse spiegelte das Latenzprofil des Arrays für zufällige Lesevorgänge das zuvor beobachtete Skalierungsverhalten wider. Die Latenz blieb über alle Blockgrößen und Threadzahlen bis zu 16 Threads außergewöhnlich niedrig und blieben für alles bis 0.1 K unter 128 ms. Sogar größere Blöcke wie 128 K blieben bei etwa 0.13 ms bis 0.20 ms. Über 16 Threads hinaus stieg die Latenz jedoch merklich an. Bei 16 K/32 Threads stieg die Latenz weiter an und erreichte schließlich 980 ms bei 128 Threads. Ebenso stiegen 1-Millionen-Lesevorgänge, die den höchsten Durchsatz hatten, von 0.242 ms bei einem Thread auf 2.892 ms bei 128 Threads. Der Trend war über alle Größen hinweg konsistent, da die Latenz bei mäßiger Parallelität flach blieb, aber stark anstieg, als die Threadzahl über 32 stieg, insbesondere bei größeren Blockgrößen.
GDSIO 16-Laufwerk – zufälliger Schreibdurchsatz
Beim GDSIO-Schreibdurchsatz zeigte das Array erneut eine starke Leistung bei größeren Blockgrößen, wobei die Skalierung insgesamt langsamer war als bei den Lesevorgängen. Die Leistung verbesserte sich ab 32 KB deutlicher, wo der Durchsatz 5.9 GiB/s überschritt, und insbesondere ab 64 Threads, wo 512 KB- und 1-Mio-Blöcke bis weit in hohe Threadzahlen hinein anhaltende Zuwächse lieferten. Ab 64 Threads erreichten 512 KB-Schreibvorgänge 25.4 GiB/s und 1 M-Blöcke einen Spitzenwert von 38.4 GiB/s, während bei 128 Threads 1-Mio-Schreibvorgänge weiter auf einen maximalen Spitzenwert von 45.9 GiB/s skalierten. Die Blockgrößen von 512 KB und 128 KB blieben auch bei hoher Parallelität konstant und pendelten sich bei etwa 26.2 GiB/s bzw. 8.0 GiB/s ein.
GDSIO 16-Laufwerk – zufällige Schreiblatenz
Nach der starken Skalierung des Schreibdurchsatzes zeigte das Latenzprofil für zufällige Schreibvorgänge auf dem Array einen stetigen Anstieg mit zunehmender Blockgröße und Threadanzahl. Selbst bei geringer Threadanzahl war die Schreiblatenz anfangs deutlich höher als die Leselatenz. Sie begann bei 0.367 ms und stieg mit jeder Blockgröße auf bis zu 1.222 ms bei 1 M. Mit zunehmender Parallelität stieg die Latenz allmählich auf bis zu 16 Threads und wurde dann stärker beschleunigt. Bei 64 Threads erreichten Schreibvorgänge 0.663 ms, während 1-M-Schreibvorgänge auf 3.255 ms anstiegen. Bei 128 und 256 Threads wurde die Latenz deutlich erhöht, insbesondere bei großen Blockgrößen. Beispielsweise erreichten 512-K-Schreibvorgänge 4.770 ms bei 128 Threads, und 512 K und 1 M überschritten die 5-ms-Marke
FIO Leistungsbenchmark
Als Nächstes messen wir die FIO-Leistung im einzelnen RAID5-Pool. Während der GDSIO letztendlich von der Leistung der im System installierten GPUs und ihrer PCIe-Bandbreite abhängt, kann der FIO je nach Leistung der SSDs und der RAID-Lösung selbst höher ausfallen.
Das gesamte Array wird einem konsistenten Testprozess unterzogen. Der Prozess beginnt mit einer Vorkonditionierungsphase, die aus zwei Vollfüllungen mit sequenziellem Schreibworkload besteht, gefolgt von unseren sequenziellen und zufälligen Workloads. Dadurch wird sichergestellt, dass die Laufwerke einen stabilen Zustand erreichen, bevor mit der Leistungsmessung begonnen wird.
Für jeden neuen Workload-Typ haben wir die Vorkonditionierung mit der entsprechenden Übertragungsgröße erneut gestartet, um die Genauigkeit und Konsistenz der Ergebnisse aufrechtzuerhalten.
In diesem Abschnitt werden die folgenden FIO-Benchmarks für zufälliges Schreiben/Lesen hervorgehoben, die auf das Graid 16 SSD RAID 5-Array angewendet wurden:
- 1M zufälliges Schreiben/Lesen
- 64K zufälliges Schreiben/Lesen
- 16K zufälliges Schreiben/Lesen
- 4K zufälliges Schreiben/Lesen
1 M zufällige Lese-/Schreibbandbreite
Beim Wechsel zu zufälligen 1M-Operationen führte die Lesebandbreite die Leistungskurve an und erreichte einen Spitzenwert von 183.60 GB/s bei einer IO-Tiefe von 16 mit 172 Jobs, der aggressivsten getesteten Konfiguration. Ähnliche Durchsatzergebnisse wurden bei 8/172 und 4/172 verzeichnet, beide über 182 GB/s, was die Skalierbarkeit des Arrays mit zunehmender Jobanzahl und -tiefe unterstreicht. Sogar mittlere Konfigurationen wie 4/86 und 16/43 hielten sich stark und hielten über 147 GB/s, was eine konstante Leseleistung über verschiedene Parallelitätsstufen hinweg zeigte. Beim Übergang zu Schreibvorgängen erreichte die zufällige 1M-Bandbreite einen Spitzenwert von 54.233 GB/s bei 8/172 und nahezu identische 53.77 GB/s bei 2/86, was eine effiziente Schreibskalierung bei parallelen Arbeitslasten bestätigt. Bei Kombinationen mit niedrigeren Threads wie 1/43 und 2/43 verringerte sich die Leistung reibungslos und erreichte 24.88 GB/s bzw. 42.48 GB/s, was selbst bei moderaten Parallelitätsstufen immer noch eine starke Sättigungskurve widerspiegelt.
1M zufällige Lese-/Schreiblatenz
Die Latenz beim Lesen blieb im gesamten Testbereich unter Kontrolle. Die niedrigste beobachtete Latenz betrug 0.714 ms bei 2/86 und 4/86, während tiefere Lasten wie 8/172 und 4/172 unter 2 ms blieben. Die Konfiguration mit dem höchsten Lesedurchsatz, 16/172, hatte mit 7.516 ms auch die höchste Latenz – ein klarer Kompromiss, da tiefere Warteschlangen die Antwortzeiten verlängerten. Beim Schreiben folgte die Latenz einem ähnlichen Muster. Die niedrigste Schreiblatenz wurde mit 1.727 ms bei 1/43 gemessen. Ein gutes Gleichgewicht zwischen Durchsatz und Latenz wurde bei 2/86 mit 3.197 ms erreicht. Höhere Parallelitätsoptionen wie 8/43 verzeichneten 6.389 ms, und das 16/172-Setup lieferte zwar eine Spitzenschreibleistung, verzeichnete aber mit 50.741 ms die höchste Latenz, was die bekannte umgekehrte Beziehung zwischen Durchsatz und Reaktionsfähigkeit bei extremen Tiefen unterstreicht.
64K zufällige Lese-/Schreibbandbreite
Durch die Umstellung auf zufällige 64K-Operationen verbesserte sich die Lesebandbreite mit zunehmender Warteschlangentiefe und Jobanzahl deutlich und erreichte einen Spitzenwert von 91.65 GB/s bei 32 IO-Tiefe und 172 Jobs. Mehrere andere Konfigurationen folgten dicht dahinter, darunter 16/172 mit 83.59 GB/s und 32/86 mit 82.85 GB/s, was konstante Leistungssteigerungen bei steigender Arbeitslast verdeutlicht. Mittelklasse-Setups wie 8/172 und 16/86 erzielten weiterhin starke Ergebnisse zwischen 78 GB/s und 79 GB/s. Im Gegensatz dazu führten Kombinationen mit geringerer Parallelität wie 1/43 und 1/172 zu reduzierten Durchsatzwerten zwischen 21.89 GB/s und 42.63 GB/s, was die Abhängigkeit des Arrays von Parallelität für Spitzenleistung verdeutlicht. Auf der Schreibseite erreichte die zufällige 64K-Bandbreite einen Spitzenwert von 6.44 GB/s mit 32/86. Andere leistungsstarke Konfigurationen, darunter 32/172 und 16/86, lagen mit 6.41 GB/s bzw. 6.36 GB/s eng beieinander. Die meisten Testpunkte gruppierten sich zwischen 6.3 GB/s und 6.4 GB/s und zeigten eine stabile Konsistenz über verschiedene Warteschlangentiefen hinweg. Leichte Konfigurationen wie 1/43 zeigten mit 3.83 GB/s die niedrigste Schreibleistung und bestätigten damit den Trend progressiver Leistungssteigerungen bei höherer Arbeitslast.
64K zufällige Lese-/Schreiblatenz
Die zufällige 64K-Leselatenz blieb in den meisten Testfällen konstant niedrig. Die niedrigste Latenz betrug 0.123 ms bei 1/43, gefolgt von 0.175 ms bei 1/86. Bei steigendem Durchsatz blieb die Latenz in einem kontrollierten Bereich: 4/172 verzeichnete 0.666 ms, während 16/172 2.057 ms erreichte. Selbst unter höherer Last blieb die Reaktionsfähigkeit effizient: 32/86 verzeichnete 2.076 ms, obwohl es eines der besten Bandbreitenergebnisse lieferte. Beim Schreiben skalierte die Latenz stärker mit der Tiefe und der Anzahl der Jobs. Die niedrigste Latenz wurde bei 2/43 mit 0.887 ms erreicht, dicht gefolgt von 4/43 und 2/86 mit 1.694 ms bzw. 1.697 ms. Bei schwereren Konfigurationen waren deutliche Anzeichen für Kompromisse bei der Reaktionszeit zu erkennen: 8/172 verzeichneten 13.445 ms, 16/172 stiegen auf 26.862 ms und 32/172 erreichten einen Spitzenwert von 63.201 ms, was den erhöhten Warteschlangenaufwand bei zunehmender Arbeitsbelastung verdeutlicht.
16 zufällige Lese-/Schreib-IOPS
Die zufällige 16K-Leselatenz blieb selbst bei Spitzen-IOPS niedrig. Die beste Reaktionsfähigkeit wurde in leichteren Konfigurationen beobachtet, wobei 1/43 nur 0.087 ms und 1/86 0.114 ms erreichte. Höhere Parallelitätskombinationen wie 4/86 und 8/86 maßen 0.236 ms bzw. 0.420 ms. Selbst die leistungsstärksten Konfigurationen behielten eine angemessene Latenz bei, wobei 16/172 1.143 ms und 32/172 2.372 ms erreichten, was eine effiziente Skalierung mit überschaubaren Auswirkungen auf die Reaktionszeit demonstriert. Für zufällige 16K-Schreibvorgänge wurde die niedrigste Latenz bei 2/43 mit 0.848 ms gemessen, gefolgt von 1.253 ms bei 4/43 und 1.415 ms bei 1/43. Mit zunehmender Tiefe und Jobanzahl stieg die Latenz allmählich an: 8/172 erreichte 5.574 ms, während 16/172 und 32/172 auf 10.455 ms bzw. 22.958 ms stiegen, was den erwarteten Kompromiss bei zunehmender Warteschlangensättigung verdeutlicht.
16K zufällige Lese-/Schreiblatenz
Die zufällige 16K-Leselatenz blieb durch die Bank konstant niedrig. Die reaktionsschnellste Konfiguration war 1/43 mit 0.123 ms, dicht gefolgt von 1/86 mit 0.175 ms. Selbst unter maximaler Belastung hielten Konfigurationen wie 32/172 und 16/172 die Latenz unter 2.1 ms, was zeigt, dass das Array auch bei erhöhten IOPS schnelle Reaktionszeiten beibehielt. Im Gegensatz dazu zeigte die zufällige 16K-Schreiblatenz eine größere Varianz. Die niedrigste Latenz betrug 0.496 ms bei 1/43, wobei zusätzliche effiziente Läufe wie 2/86 und 4/43 unter der 1-ms-Marke blieben. Mit zunehmender Gleichzeitigkeit und Tiefe stieg die Latenz entsprechend: 16/172 verzeichnete 7.017 ms und 32/172 erreichte 17.246 ms
4 zufällige Lese-/Schreib-IOPS
Unter einer höheren Parallelitätslast erreichten die zufälligen 4K-Lese-IOPS einen beeindruckenden Spitzenwert von 10.77 Millionen bei einer IO-Tiefe von 32 mit 344 Jobs. Andere Konfigurationen folgten dicht dahinter, darunter 16/344 mit 10.52 M, 4/344 mit 10.51 M und 8/344 mit 10.42 M. Alle zeigten eine außergewöhnliche Skalierung mit aggressiven Warteschlangen- und Job-Tiefenkombinationen. Selbst Optionen mit reduzierter Tiefe wie 8/172 und 16/172 erzielten einen starken Durchsatz zwischen 5.23 M und 5.35 M IOPS, was die Fähigkeit des Arrays, anspruchsvolle parallele Workloads zu bewältigen, weiter unterstreicht. Auf der Schreibseite erreichten die 4K-IOPS einen Spitzenwert von 987.9 K mit 32/172. Ähnliche hocheffiziente Konfigurationen umfassten 32/86 bei 985.1 K, 16/172 bei 985.6 K und 8/172 bei 976.9 K. Zusätzliche Kombinationen von 8/86 bis 16/86 hielten die Leistung im Bereich von 875 K bis 977 K aufrecht und verstärkten so die Konsistenz und Zuverlässigkeit des Arrays bei voller Auslastung durch gleichzeitige Schreibvorgänge.
4K zufällige Lese-/Schreiblatenz
Die zufällige 4K-Leselatenz blieb durchweg extrem niedrig. Die schnellste Reaktionszeit betrug 0.084 ms bei 1/86, wobei mehrere andere Konfigurationen – darunter 1/43, 2/43 und 4/43 – alle unter 0.12 ms lagen. Selbst bei Spitzen-IOPS blieb die Latenz gut unter Kontrolle, wobei die leistungsstärkste 32/344-Konfiguration bei nur 1.142 ms lag. Dies zeugt von einer hervorragenden Reaktionsfähigkeit, selbst als das Array sein maximales Durchsatzpotenzial erreichte. Auch auf der Schreibseite wurde die zufällige 4K-Latenz gut im Griff behalten. Der niedrigste aufgezeichnete Wert lag bei 0.352 ms bei 1/43, während andere hocheffiziente Setups wie 1/86, 2/43 und 4/43 alle unter 0.6 ms blieben. Bei Hochdurchsatzkonfigurationen wie 32/172 und 32/86 stieg die Latenz leicht auf 2.79 bis 5.87 ms an und blieb in Anbetracht der anhaltenden Schreibsättigungsgrade in einem akzeptablen Bereich.
Messung des GPU-Overheads von Gray SupremeRAID AE
Bei der Untersuchung der Speicherleistungsmetriken von Graids SupremeRAID AE ist es wichtig zu berücksichtigen, wie sich SupremeRAID, das GPU-Ressourcen gemeinsam nutzt, auf Workloads auswirkt, die dieselben GPUs verwenden. In früheren SupremeRAID-Bereitstellungen war die GPU im System ausschließlich Graid vorbehalten. Mit dieser Lösung setzen Sie sie auf einer Plattform ein, die bereits GPUs enthält, die Graid nutzen und Ressourcen gemeinsam nutzen kann. Um die Auswirkungen auf den Overhead zu messen, haben wir ein LLM-Inferenzszenario mit vLLM erstellt. Wir haben die Basisleistung des Workloads gemessen, während Graid im Leerlauf war, und dann noch einmal, als Graid 172 GB über den RAID 5-Pool las. Dies simuliert den Inferenz-Workload und weist den nächsten Workload vorab zu, während einer ausgeführt wird. Da vLLM die GPUs zu 100 % auslastet, wirkt sich jeder Graid-Vorgang auf Token-Raten und Latenz aus.
Für die KI-Arbeitslast führten wir die Inferenz mit vLLM unter Verwendung des Llama 3.3 70B-Modells bei voller Präzision (BF16) mit einer KV-Cache-Größe von 16K aus. Dadurch wurde der VRAM auf beiden Karten fast vollständig ausgenutzt (78G auf der 80G-Karte und 86G auf der 94G-Karte). Anschließend führten wir das Benchmarking-Skript von vLLM mit einer maximalen Ausgabelänge von 256 Token aus. Jeder Test führte 256 Abfragen mit einer maximalen Gleichzeitigkeit von 32 Anfragen aus und nutzte kontinuierliches Batching, um ein realistisches Anfragemuster zu simulieren. Die von uns erfassten Messwerte sind Tok/s, Zeit bis zum ersten Token (TTFT), Zeit pro Ausgabetoken (TPOT) und Inter-Token-Latenz (ITL). Die während des Inferenztests initiierte FIO-Arbeitslast bestand aus 172 16K-Random-Leseaufträgen, die jeweils 1 GB lasen.
Der Durchsatz verzeichnete insgesamt einen leichten Rückgang. Der Anfragedurchsatz sank von 1.86 auf 1.78 Anfragen pro Sekunde, ein Rückgang von 4.3 %. Der Ausgabetokendurchsatz sank von 225.44 auf 215.94 Token pro Sekunde, was einem Rückgang von 4.2 % entspricht. Der Gesamttokendurchsatz sank von 2029.77 auf 1944.30 Token pro Sekunde, was einem Rückgang von 4.2 % entspricht. Dies deutet darauf hin, dass die Übertragung einen gewissen Overhead verursachte, der die Leistung leicht beeinträchtigte.
Die Latenzmetriken zeigten gemischte Ergebnisse. Die mittlere TTFT stieg um 3.6 % von 6,704 ms auf 6,945 ms, während die mediane TTFT um 1.5 % zunahm. Interessanterweise verbesserte sich die P99-TTFT und sank um 2.8 % von 14,199 ms auf 13,803 ms, was auf eine bessere Tail-End-Performance in dieser Metrik hindeutet. Bei der TPOT stieg der Mittelwert um 5.3 %, während der Median mit einem Anstieg von 0.65 % relativ unverändert blieb. Die P99-TPOT stieg jedoch stark um 24.6 % von 127.69 ms auf 159.15 ms, was zeigt, dass die Token-Generierungszeit im schlimmsten Fall erheblich beeinträchtigt wurde. Die Inter-Token-Latenz (ITL) zeigte ähnliche Trends: Der Mittelwert stieg um 5.1 %, der Median blieb im Wesentlichen unverändert und die P99 stieg um 2.2 %.
Graids SupremeRAID AE, das parallel zu unserem vLLM-Workload ausgeführt wurde, führte zu einem kleinen, aber konstanten Durchsatzrückgang (ca. 4 %), einhergehend mit moderaten Erhöhungen der durchschnittlichen Latenz und einer spürbaren Verschlechterung der P99-Leistung bei der Token-Generierung. Trotz dieser Auswirkungen blieb das System vollständig stabil und reaktionsfähig. Dies zeigt, dass hochkonkurrenzfähige Inferenz mit großen Modellen wie Llama 3.3 70B neben Graid SupremeRAID AE weiterhin zuverlässig funktioniert.
| Metrik (kürzere Dauer / Höhere Token/s sind besser) | Baseline | Mit 172 GB FIO-Lesevorgang |
| Erfolgreiche Anfragen | 256 | 256 |
| Benchmark-Dauer (s) | 137.68 | 143.73 |
| Gesamtanzahl der Eingabetoken | 248,414 | 248,414 |
| Gesamtzahl der generierten Token | 31,037 | 31,037 |
| Anforderungsdurchsatz (Anforderung/s) | 1.86 | 1.78 |
| Ausgabe-Token-Durchsatz (tok/s) | 225.44 | 215.94 |
| Gesamter Token-Durchsatz (tok/s) | 2029.77 | 1944.30 |
| Zeit bis zum ersten Token (TTFT) (niedrigere Latenz ist besser) | ||
| Mittlere TTFT (ms) | 6,704.43 | 6,945.72 |
| Mediane TTFT (ms) | 6,469.88 | 6,569.80 |
| P99 TTFT (ms) | 14,199.21 | 13,803.62 |
| Zeit pro Ausgabetoken (TPOT, exkl. 1. Token) (niedrigere Latenz ist besser) | ||
| Mittlere TPOT (ms) | 81.44 | 85.72 |
| Medianwert der TPOT (ms) | 80.38 | 80.90 |
| P99 TPOT (ms) | 127.69 | 159.15 |
| Inter-Token-Latenz (ITL) (niedrigere Latenz ist besser) | ||
| Mittlere ITL (ms) | 79.94 | 83.99 |
| Median-ITL (ms) | 49.75 | 49.78 |
| P99 ITL (ms) | 539.07 | 550.73 |
Abschließende Gedanken
Graid SupremeRAID AE bietet eine praktische, leistungsstarke Lösung für Unternehmen, die KI-Infrastrukturen aufbauen oder skalieren. Durch den Ersatz von herkömmlichem Hardware-RAID durch einen GPU-gesteuerten, softwaredefinierten Ansatz vereinfacht SupremeRAID AE die Bereitstellung und beseitigt gleichzeitig häufige Engpässe, die moderne KI-Workflows behindern.
Unsere Tests zeigten, dass bis zu 32 NVMe-SSDs in einem einzigen, robusten Namespace vereint werden können. Dadurch wird eine Kapazität von fast 1 PB auf einem Server mit außergewöhnlicher Leistung bereitgestellt. Spitzenergebnisse von 183 GB/s Lese- und 54 GB/s Schreibdurchsatz, kombiniert mit minimalem GPU-Overhead während der Live-Inferenz, bestätigen die Fähigkeit des Systems, die doppelten Anforderungen von massivem Modell-Checkpointing und Inferenz mit geringer Latenz im großen Maßstab zu erfüllen.
Durch den Wegfall der Kosten und Komplexität dedizierter RAID-Hardware und die nahtlose Integration mit Technologien wie NVIDIA GPUDirect Storage und KI-orientierten Dateisystemen schafft SupremeRAID AE eine zukunftssichere Speicherbasis. Unternehmen, die sich auf die Optimierung von Inferenzen und die Reduzierung von Betriebsrisiken konzentrieren, bietet SupremeRAID AE die Leistung, Einfachheit und Ausfallsicherheit, die für KI-Produktionsumgebungen erforderlich sind.
Amazon