Naarmate de AI-infrastructuur evolueert, worden datapijplijnen sneller, uitgebreider en steeds complexer. Van het trainen van grote modellen tot realtime inferentie op schaal, het opslagsubsysteem is essentieel om ervoor te zorgen dat GPU's continu de benodigde data ontvangen. Nu opslag steeds belangrijker wordt in AI-clusters, heroverwegen organisaties hoe ze hoge doorvoer, voorspelbare prestaties en veerkracht kunnen leveren, vooral in omgevingen waar dataverlies of downtime simpelweg onacceptabel zijn.
De uitdaging wordt nog groter naarmate AI-modellen exponentieel in omvang blijven toenemen. Moderne, grote taalmodellen en basismodellen vereisen frequente controlepunten om de trainingsvoortgang te behouden. Naarmate de modelgroottes toenemen van miljarden naar biljoenen parameters, schalen de opslagvereisten voor deze controlepunten evenredig mee. Dit creëert een dringende behoefte aan grote, uniforme opslagnaamruimten die enorme controlepuntbestanden kunnen verwerken en tegelijkertijd extreem snelle schrijf- en leesprestaties behouden. Traditionele opslagarchitecturen hebben moeite om zowel de capaciteit als de snelheid te bieden die nodig zijn voor deze veeleisende workloads.
Huidige benaderingen van checkpointbeheer, zoals asynchrone checkpointing waarbij modelgewichten in het CPU-geheugen worden geplaatst zodat GPU's kunnen blijven trainen, stuiten op aanzienlijke beperkingen naarmate modellen groeien. De tijdelijke opslag van deze checkpoints in het systeemgeheugen wordt steeds verspillender en duurder, en vereist enorme hoeveelheden RAM, wat de systeemkosten en het stroomverbruik opdrijft. Nog belangrijker is dat naarmate de modelgroottes blijven toenemen, deze aanpak volledig onpraktisch kan worden vanwege de enorme hoeveelheid data die tijdelijk in het geheugen moet worden opgeslagen.
Graid Technology heeft een nieuwe aanpak geïntroduceerd die specifiek is afgestemd op deze uitdagingen. Voortbouwend op het softwaregedefinieerde model dat is ontwikkeld voor eerdere oplossingen zoals de SupremeRAID SR1010 , biedt Graid's nieuwe SupremeRAID AE (AI Edition) RAID-functionaliteit op bedrijfsniveau voor AI-workloads met minimale aanpassingen aan de infrastructuur. In plaats van een speciale hardware-RAID-kaart of een aangepast apparaat, wordt AE geleverd als een softwarelicentie en gebruikt het slechts een klein deel van een bestaande NVIDIA GPU. Dit betekent dat organisaties opslagprestaties en -betrouwbaarheid van bedrijfsniveau kunnen bereiken zonder 1) extra PCIe-slots te gebruiken, 2) infrastructuurwijzigingen door te voeren of 3) een significante impact te ondervinden op de GPU-prestaties voor trainings- en inferentieworkloads.
Key Takeaways
- Hoge prestaties op schaal: SupremeRAID AE behaalt een leessnelheid tot 183.60 GB/s en een schrijfsnelheid tot 54.23 GB/s, waarmee wordt voldaan aan de veeleisende AI-vereisten.
- Minimale GPU-overhead: Zorgt voor minimale overhead (~4%) tijdens GPU-intensieve inferentie, waardoor de algehele systeemprestaties sterk blijven.
- Enorme Unified Storage-naamruimte: Ondersteunt maximaal 32 NVMe SSD's per array en levert daarmee bijna 1 PB aan opslag in één uniforme naamruimte.
- Geavanceerde integratiemogelijkheden: Integreert volledig met NVIDIA GPUDirect Storage en toonaangevende op AI gerichte bestandssystemen (BeeGFS, Lustre, Ceph).
- Vereenvoudigde infrastructuur: Maakt speciale RAID-hardware overbodig, waardoor de complexiteit, kosten en operationele overhead aanzienlijk worden verlaagd.
Geoptimaliseerde opslag en veerkracht voor geavanceerde AI-workloads
SupremeRAID AE ondersteunt tot 32 NVMe SSD's in één array en aggregeert deze in één uniforme naamruimte. Deze structuur stelt AI-workloads in staat om efficiënt toegang te krijgen tot grote datasets, met behoud van veerkracht. Dit is met name belangrijk voor omgevingen met langdurige trainingstaken. Bij een schijfstoring blijft de array beschikbaar en blijft de voortgang van de checkpoints behouden. Deze bescherming minimaliseert het risico op gegevensverlies of tijdrovende herstarts, wat een aanzienlijk voordeel is voor teams die grote modellen of inferentiepipelines met een hoog volume beheren.
De intelligente resourcebeheermogelijkheden van SupremeRAID AE bieden extra optimalisatiemogelijkheden voor AI-workloads. Hoewel onze tests minimale overhead aantonen tijdens gelijktijdige bewerkingen, kan de impact verder worden verminderd door slimme planning. Controlepuntbewerkingen worden doorgaans niet gelijktijdig met actieve training op dezelfde node uitgevoerd; er is meestal een korte pauze in de training tijdens controlepuntfasen. Tijdens deze intervallen kan SupremeRAID AE extra ongebruikte GPU-resources benutten om de voltooiing van controlepunten te versnellen.
SupremeRAID AE ondersteunt ook NVIDIA GPUDirect Storage. Dit maakt directe paden tussen opslag en GPU-geheugen mogelijk, wat resulteert in verminderde latentie en verbeterde I/O-efficiëntie. Het integreert met AI-gerichte bestandssystemen, zoals BeeGFS, Lustre en Ceph, en omvat intelligente data-offloading, samen met orkestratieklare API's voor automatisering. Al met al biedt SupremeRAID AE een vereenvoudigde – maar krachtige – manier om RAID-voordelen te integreren in moderne AI-workflows.
Naast trainingsworkloads voldoet SupremeRAID AE aan de kritische vereisten voor moderne AI-inferentiescenario's. Naarmate organisaties inferentiebewerkingen opschalen, vertrouwen ze steeds meer op geavanceerde strategieën zoals persistent KV-cachebeheer, prefill-decode-optimalisatie en gelaagde geheugenarchitecturen. Deze technieken vereisen vaak het offloaden van KV-caches naar storage wanneer deze de VRAM-capaciteit overschrijden. Oplossingen zoals NVIDIA Dynamo, Red Hat's LLM-D en vLLM-productiestack bevatten allemaal gelaagde KV-cachingintegraties die afhankelijk zijn van snelle opslag met hoge capaciteit. In deze scenario's worden grote, krachtige storagepools essentieel voor het handhaven van inferentie met lage latentie, en SupremeRAID AE's vermogen om zowel enorme capaciteit als uitzonderlijke snelheid te bieden, maakt het een ideale basis voor deze geavanceerde inferentiearchitecturen.
In deze analyse evalueren we SupremeRAID AE op ons Dell PowerEdge R770-platform, dat is uitgerust met twee NVIDIA H100 GPU's en 16 Micron 6550 61.44TB Gen5 NVMe SSD's. We onderzoeken de prestaties onder RAID 5 met behulp van GDSIO- en FIO-tools en onderzoeken hoe SupremeRAID AE het GPU-gedrag beïnvloedt tijdens een live LLM-inferentieworkload. Het doel is om te begrijpen hoe deze oplossing integreert in AI-omgevingen van enterprise-klasse, waar prestaties, capaciteit, veerkracht en eenvoud samen moeten schalen.
De cijfers in beeld: SupremeRAID AE-prestatie-diepgang
Om de prestaties van Graid SupremeRAID AE te testen, hebben we een Dell PowerEdge R770 geconfigureerd met twee NVIDIA H100 GPU's en 16 E3.S-bays aan de voorzijde. Dit systeem, gebouwd op Intels nieuwste Xeon 6-platform, was uitgerust met twee Intel Xeon 6787P-processors, elk met 86 cores voor zeer parallelle workloads in AI-, HPC- en data-intensieve omgevingen.
De R770 was geconfigureerd met 16 E3.S-bays en de opslag was volledig gevuld met Micron 6550 ION 61.44TB Gen5 NVMe TLC SSD's, die zijn ontworpen om consistente prestaties te leveren voor een breed scala aan workloads. De Micron SSD's bieden een ideale balans tussen uitzonderlijke prestaties en enorme capaciteit, waardoor AI-workloads een hoge doorvoersnelheid kunnen behouden en de AI-infrastructuur drastisch wordt vereenvoudigd. Met een petabyte aan opslag verdeeld over slechts 16 schijven kunnen organisaties uitgebreide datasets en grootschalige modelcontrolepunten efficiënt beheren binnen één server, waardoor de complexiteit en infrastructuuroverhead aanzienlijk worden verminderd.
Testsysteem specificaties
- Platform: Dell PowerEdge R770
- CPU: 2x Intel Xeon 6787P (elk 86 cores)
- Geheugen: 32x Micron 64 GB Dual-Rank DDR5 6400 MT/s Totaal geheugen: 2TB
- Netwerken: DELL BRCM 4P 25G SFP 57504S OCP-netwerkkaart
- GPU 1: NVIDIA H100 (VRAM 80GB)
- GPU 2: NVIDIA H100NVL (96GB VRAM)
- Opslag: 16 x 61TB Micron ION 6550 SSD's (915TB RAID 5-pool)
Als onderdeel van deze prestatietest werden de Micron SSD's geconfigureerd in één RAID 5-pool met SupremeRAID AE. Deze lay-out werd gekozen om te evalueren hoe goed SupremeRAID AE prestaties en fouttolerantie kan balanceren in een AI-gestuurde omgeving die opslag met hoge capaciteit vereist. RAID 5 verdeelt pariteit over alle schijven, wat bescherming biedt tegen uitval van één schijf, terwijl de bruikbare opslagcapaciteit behouden blijft.
Voordat we dieper ingaan op de prestatietests, is het belangrijk om de verschillen tussen GDSIO en FIO te noteren bij het meten van opslagprestaties met Graid. In onze eerdere beoordelingen van Graid-prestaties is een cruciale observatie dat er geen knelpunten zijn (zoals een hardwarematige RAID-kaart) die de piekbandbreedte beperken. Hardwarematige RAID-kaarten beheren de aangesloten opslagapparaten en de PCIe-sleuf kan een knelpunt vormen in dit proces. Graid gebruikt een GPU voor RAID-bewerkingen, maar niet alle gegevens hoeven erdoorheen te gaan. Hierdoor beperkt de GPU de bandbreedte niet.
De FIO-opslagbenchmark meet de opslagprestaties door de CPU te gebruiken voor toegang tot de opslag en wordt alleen beperkt door de opslagoplossing. GDSIO meet daarentegen de prestaties van GPU Direct Storage, waarbij de GPU de beperkende factor kan zijn. De NVIDIA H100 heeft bijvoorbeeld een PCIe Gen5 x16-interface en kan een bandbreedte van ongeveer 63 GB/s in- of uitsturen. Wanneer we het in deze context hebben over knelpunten in GPU-prestaties, gaat het om de bandbreedte die de GPU kan ondersteunen met GPU Direct Storage, niet om een GRID-knelpunt.
NVIDIA GPU Directe Opslag
Een van de tests die we op deze testbank hebben uitgevoerd, was de Magnum IO GPU Direct Storage (GDS)-test. GDS is een functie die is ontwikkeld door NVIDIA waarmee GPU's de CPU kunnen omzeilen bij het benaderen van gegevens die zijn opgeslagen op NVMe-schijven of andere snelle opslagapparaten. In plaats van gegevens via de CPU en het systeemgeheugen te routeren, maakt GDS directe communicatie tussen de GPU en het opslagapparaat mogelijk, wat de latentie aanzienlijk vermindert en de gegevensdoorvoer verbetert.
Hoe GPU Direct Storage werkt
Traditioneel, wanneer een GPU gegevens verwerkt die zijn opgeslagen op een NVMe-schijf, moeten de gegevens eerst door de CPU en het systeemgeheugen reizen voordat ze de GPU bereiken. Dit proces introduceert knelpunten, omdat de CPU een tussenpersoon wordt, latentie toevoegt en waardevolle systeembronnen verbruikt. GPU Direct Storage elimineert deze inefficiëntie door de GPU in staat te stellen om rechtstreeks vanaf het opslagapparaat toegang te krijgen tot gegevens via de PCIe-bus. Dit directe pad vermindert de overhead die gepaard gaat met gegevensverplaatsing, wat snellere en efficiëntere gegevensoverdrachten mogelijk maakt.
AI-workloads, met name die met deep learning, zijn zeer data-intensief. Het trainen van grote neurale netwerken vereist het verwerken van terabytes aan data, en elke vertraging in dataoverdracht kan leiden tot onderbenutte GPU's en langere trainingstijden. GPU Direct Storage pakt deze uitdaging aan door ervoor te zorgen dat data zo snel mogelijk naar de GPU wordt geleverd, waardoor inactieve tijd wordt geminimaliseerd en de rekenefficiëntie wordt gemaximaliseerd.
Bovendien is GDS met name gunstig voor workloads die het streamen van grote datasets omvatten, zoals videoverwerking, natuurlijke taalverwerking of realtime-inferentie. Door de afhankelijkheid van de CPU te verminderen, versnelt GDS de databeweging en maakt CPU-bronnen vrij voor andere taken, wat de algehele systeemprestaties verder verbetert.
GDSIO 16 Drive willekeurige leesdoorvoer
Voordat we ingaan op de prestatiecijfers, is het belangrijk om te weten dat de beperkende factor voor lees- en schrijfprestaties met GDSIO-cijfers de GPU('s) is. De test is ontworpen om de maximale opslagprestaties te meten die van de GPU kunnen worden gepusht of getrokken. Uiteindelijk zult u een bottleneck tegenkomen in de PCIe-sleuf, die voor PCIe Gen5 x16 ongeveer 63 GB/s bedraagt.
Wat betreft de willekeurige leessnelheid van GDSIO, leverde de array de beste resultaten met grotere blokgroottes en hogere threadaantallen, terwijl het aan de onderkant moeite had om efficiënt te schalen. Bij 16K/128 threads begonnen de zaken merkbaarder te verbeteren, met een snelheid van 7.3 GiB/s, maar de echte doorvoerversnelling trad pas op bij 32K en hoger, waar de array 15.5 GiB/s bereikte met 64 threads. Aanzienlijke verbeteringen werden waargenomen bij 64K, tot 25.9 GiB/s, en de prestaties stegen vanaf 128K, dat 41.3 GiB/s bereikte met 64 threads en boven de 40 GiB/s bleef tot 128 threads. De piekdoorvoer werd bereikt bij een blokgrootte van 1M met 32 threads, waarbij de array 88.5 GiB/s bereikte en dat niveau handhaafde bij de hoogste threadaantallen.
GDSIO 16 Drive willekeurige leeslatentie
Na de resultaten van de doorvoer weerspiegelde het willekeurige leeslatentieprofiel van de array het eerder waargenomen schaalgedrag. De latentie bleef uitzonderlijk laag voor alle blokgroottes en threadaantallen tot 16 threads, met waarden onder de 0.1 ms voor alles tot 128K. Zelfs grotere blokken, zoals 128K, bleven rond de 0.13 ms tot 0.20 ms. Boven de 16 threads nam de latentie echter merkbaar toe. Bij 16K / 32 threads bleef de latentie stijgen en bereikte uiteindelijk 980 ms bij 128 threads. Evenzo steeg de 1M-leessnelheid, die de hoogste doorvoer had, van 0.242 ms bij één thread naar 2.892 ms bij 128 threads. De trend was consistent voor alle groottes, aangezien de latentie vlak bleef bij matige gelijktijdigheid, maar sterk steeg naarmate het threadaantal boven de 32 uitkwam, vooral bij grotere blokgroottes.
GDSIO 16 Drive willekeurige schrijfsnelheid
Wat betreft de GDSIO-schrijfsnelheid, toonde de array opnieuw sterke prestaties bij grotere blokgroottes, terwijl de schaal over het algemeen geleidelijker werd geschaald dan bij leesbewerkingen. De prestaties begonnen aanzienlijk te verbeteren vanaf 32K, waar de doorvoer 5.9 GiB/s overschreed, en vooral bij 64 threads en hoger, waar blokken van 512K en 1M aanhoudende winst leverden tot ver in de hoge threadaantallen. Bij 64 threads en hoger bereikten schrijfbewerkingen van 512K 25.4 GiB/s en piekte 1M op 38.4 GiB/s, terwijl bij 128 threads de schrijfbewerkingen van 1M bleven schalen tot een maximale piek van 45.9 GiB/s. De blokgroottes van 512K en 128K bleven ook consistent bij hoge gelijktijdigheid, met een stabilisatie rond respectievelijk 26.2 GiB/s en 8.0 GiB/s.
GDSIO 16 Drive willekeurige schrijflatentie
Na de sterke schaalvergroting van de schrijfsnelheid vertoonde het latentieprofiel voor willekeurige schrijfbewerkingen op de array een gestage toename naarmate de blokgrootte en het aantal threads toenamen. Zelfs bij lage threadaantallen begon de schrijflatentie aanzienlijk hoger te liggen dan de leeslatentie, beginnend bij 0.367 ms en stijgend met elke blokgrootte tot 1.222 ms bij 1M. Naarmate de gelijktijdigheid toenam, steeg de latentie geleidelijk tot 16 threads, om vervolgens agressiever te versnellen. Bij 64 threads bereikten schrijfbewerkingen 0.663 ms, terwijl schrijfbewerkingen bij 1M opliepen tot 3.255 ms. Bij 128 en 256 threads nam de latentie aanzienlijk toe, vooral bij grote blokgroottes. Zo bereikten schrijfbewerkingen bij 512K bijvoorbeeld 4.770 ms bij 128 threads, en overschreden 512K en 1M de grens van 5 ms, met een piek van 5.436 ms bij 1M.
VOOR-EN ACHTERNAAM Prestatiebenchmark
Vervolgens meten we de FIO-prestaties over de enkele RAID5-pool. Hoewel de GDSIO uiteindelijk afhangt van de prestaties van de in het systeem geïnstalleerde GPU's en hun PCIe-bandbreedte, kan de FIO hoger uitvallen op basis van de prestaties van de SSD's en de RAID-oplossing zelf.
De gehele array ondergaat een consistent testproces, beginnend met een preconditioneringsfase bestaande uit twee volledige volumevullingen met een sequentiële schrijfwerklast, gevolgd door onze sequentiële en willekeurige werklasten. Dit zorgt ervoor dat de schijven een stabiele toestand bereiken voordat de prestatiemeting begint.
Voor elk nieuw type werklast hebben we de preconditionering opnieuw gestart met behulp van de bijbehorende overdrachtsgrootte, om de nauwkeurigheid en consistentie van de resultaten te behouden.
In dit gedeelte worden de volgende willekeurige schrijf-/lees-FIO-benchmarks belicht die zijn toegepast op de Graid 16 SSD RAID 5-array:
- 1M willekeurig schrijven/lezen
- 64K willekeurig schrijven/lezen
- 16K willekeurig schrijven/lezen
- 4K willekeurig schrijven/lezen
1M willekeurige lees-/schrijfbandbreedte
Bij de overgang naar willekeurige 1M-bewerkingen, voerde de leesbandbreedte de prestatiecurve aan met een piek van 183.60 GB/s bij een IO-diepte van 16 met 172 taken, de meest agressieve configuratie die werd getest. Vergelijkbare resultaten met hoge doorvoer werden geregistreerd bij 8/172 en 4/172, beide hoger dan 182 GB/s, wat het vermogen van de array om te schalen met een toenemend aantal taken en diepte benadrukt. Zelfs midrange-configuraties zoals 4/86 en 16/43 hielden stand en behaalden snelheden van meer dan 147 GB/s, wat consistente leesprestaties liet zien bij verschillende gelijktijdigheidsniveaus. Bij de overgang naar schrijfbewerkingen bereikte de willekeurige 1M-bandbreedte een piek van 54.233 GB/s bij 8/172, met een vrijwel identieke 53.77 GB/s bij 2/86, wat efficiënte schrijfschaling onder parallelle workloads valideert. De prestaties daalden geleidelijk in combinaties met minder threads, zoals 1/43 en 2/43, die respectievelijk 24.88 GB/s en 42.48 GB/s produceerden. Dit weerspiegelt nog steeds een sterke verzadigingscurve, zelfs bij matige gelijktijdigheidsniveaus.
1M willekeurige lees-/schrijflatentie
De latentie bleef onder controle voor leesbewerkingen over het gehele testbereik. De laagste waargenomen latentie was 0.714 ms bij zowel 2/86 als 4/86, terwijl ladingen met hogere diepte, zoals 8/172 en 4/172, onder de 2 ms bleven. De configuratie die de hoogste leesdoorvoer produceerde, 16/172, had de hoogste latentie van 7.516 ms – een duidelijk compromis, aangezien diepere wachtrijen de responstijden verhoogden. Aan de schrijfzijde volgde de latentie een vergelijkbaar patroon. De laagste schrijflatentie werd gemeten op 1.727 ms met 1/43. Een goede balans tussen doorvoer en latentie werd bereikt bij 2/86 met 3.197 ms. Hogere gelijktijdigheidsopties zoals 8/43 registreerden 6.389 ms en de 16/172-configuratie leverde, ondanks de maximale schrijfprestaties, de hoogste latentie van 50.741 ms, wat de bekende omgekeerde relatie tussen doorvoer en responsiviteit op extreme diepten onderstreept.
64K willekeurige lees-/schrijfbandbreedte
Bij de overstap naar willekeurige 64K-bewerkingen verbeterde de leesbandbreedte aanzienlijk met een hogere wachtrijdiepte en een hoger aantal taken, met een piek van 91.65 GB/s bij een IO-diepte van 32 met 172 taken. Verschillende andere configuraties volgden op de voet, waaronder 16/172 met 83.59 GB/s en 32/86 met 82.85 GB/s, wat consistente prestatieverbeteringen aantoonde naarmate de werklast toenam. Mid-range configuraties zoals 8/172 en 16/86 behielden sterke resultaten tussen 78 GB/s en 79 GB/s. Daarentegen produceerden combinaties met een lagere gelijktijdigheid, zoals 1/43 en 1/172, lagere doorvoersnelheden van 21.89 GB/s tot 42.63 GB/s, wat de afhankelijkheid van de array van parallellisme voor piekprestaties illustreert. Aan de schrijfzijde piekte de willekeurige bandbreedte van 64K op 6.44 GB/s met 32/86. Andere topconfiguraties, waaronder 32/172 en 16/86, kwamen dicht bij elkaar en registreerden respectievelijk 6.41 GB/s en 6.36 GB/s. De meeste testpunten lagen tussen 6.3 GB/s en 6.4 GB/s, wat een stabiele consistentie aantoonde over verschillende wachtrijdieptes. Lichte configuraties zoals 1/43 lieten de laagste schrijfprestaties zien met 3.83 GB/s, wat de trend van progressieve winst bij zwaardere workloads nog steeds versterkt.
64K willekeurige lees-/schrijflatentie
De willekeurige 64K-leeslatentie bleef consistent laag in de meeste testcases. De laagste latentie was 0.123 ms bij 1/43, gevolgd door 0.175 ms bij 1/86. Naarmate de doorvoer toenam, bleef de latentie binnen een gecontroleerd bereik: 4/172 noteerde 0.666 ms, terwijl 16/172 2.057 ms bereikte. Zelfs onder zwaardere belasting bleef de responsiviteit efficiënt, waarbij 32/86 2.076 ms noteerde, ondanks een van de hoogste bandbreedteresultaten. Aan de schrijfzijde nam de latentie scherper toe met de diepte en het aantal taken. De laagste latentie kwam van 2/43 met 0.887 ms, gevolgd door 4/43 en 2/86 met respectievelijk 1.694 ms en 1.697 ms. Bij zwaardere configuraties waren er duidelijke tekenen van een compromis op het gebied van responstijd: 8/172 noteerde 13.445 ms, 16/172 klom naar 26.862 ms en 32/172 piekte op 63.201 ms. Dit benadrukt de toenemende wachtrijoverhead naarmate de werklast toenam.
16K willekeurige lees-/schrijf-IOPS
De willekeurige 16K-leeslatentie bleef laag, zelfs bij piek-IOPS. De beste responsiviteit werd waargenomen in lichtere configuraties, waarbij 1/43 slechts 0.087 ms haalde en 1/86 0.114 ms. Hogere gelijktijdigheidscombinaties zoals 4/86 en 8/86 maten respectievelijk 0.236 ms en 0.420 ms. Zelfs de best presterende configuraties behielden een redelijke latentie, waarbij 16/172 1.143 ms noteerde en 32/172 2.372 ms, wat een efficiënte schaalbaarheid aantoont met een beheersbare impact op de responstijd. Voor willekeurige 16K-schrijfbewerkingen werd de laagste latentie gemeten bij 2/43 met 0.848 ms, gevolgd door 1.253 ms bij 4/43 en 1.415 ms bij 1/43. Naarmate de diepte en het aantal taken toenamen, nam de latentie geleidelijk toe: 8/172 bereikte 5.574 ms, terwijl 16/172 en 32/172 respectievelijk naar 10.455 ms en 22.958 ms stegen. Dit onderstreept de verwachte afweging die zou ontstaan naarmate de wachtrijverzadiging toenam.
16K willekeurige lees-/schrijflatentie
De willekeurige 16K-leeslatentie bleef over de hele linie consistent laag. De meest responsieve configuratie was 1/43 met 0.123 ms, op de voet gevolgd door 1/86 met 0.175 ms. Zelfs onder maximale druk hielden configuraties zoals 32/172 en 16/172 de latentie onder de 2.1 ms, wat aantoont dat de array snelle responstijden handhaafde bij het verwerken van verhoogde IOPS. Daarentegen vertoonde de willekeurige 16K-schrijflatentie een bredere variantie. De laagste latentie was 0.496 ms met 1/43, terwijl andere efficiënte runs zoals 2/86 en 4/43 onder de 1 ms bleven. Naarmate de gelijktijdigheid en diepte toenamen, steeg de latentie dienovereenkomstig: 16/172 registreerde 7.017 ms en 32/172 bereikte 17.246 ms, wat de verwachte afweging tussen piekdoorvoer en responsiviteit bij maximale verzadiging versterkte.
4K willekeurige lees-/schrijf-IOPS
Onder een zwaardere gelijktijdigheidsbelasting bereikte de willekeurige 4K-lees-IOPS een indrukwekkende piek van 10.77 miljoen bij een IO-diepte van 32 met 344 taken. Andere configuraties volgden op de voet, waaronder 16/344 met 10.52 M, 4/344 met 10.51 M en 8/344 met 10.42 M, die allemaal een uitzonderlijke schaalbaarheid vertoonden met agressieve combinaties van wachtrij en taakdiepte. Zelfs opties met een lagere diepte, zoals 8/172 en 16/172, behielden een sterke doorvoer tussen 5.23 M en 5.35 M IOPS, wat de capaciteit van de array om veeleisende parallelle workloads aan te kunnen verder onderstreept. Aan de schrijfzijde piekte de 4K IOPS op 987.9 K met 32/172. Vergelijkbare configuraties met een hoge efficiëntie omvatten 32/86 bij 985.1 K, 16/172 bij 985.6 K en 8/172 bij 976.9 K. Extra combinaties van 8/86 tot en met 16/86 handhaafden de prestaties in het bereik van 875 K tot 977 K, wat de consistentie en betrouwbaarheid van de array versterkte bij volledige verzadigdheid met gelijktijdige schrijfbewerkingen.
4K willekeurige lees-/schrijflatentie
De willekeurige 4K-leeslatentie bleef over de hele linie extreem laag. De snelste responstijd was 0.084 ms bij 1/86, terwijl verschillende andere configuraties – waaronder 1/43, 2/43 en 4/43 – allemaal onder de 0.12 ms bleven. Zelfs bij piek-IOPS bleef de latentie goed onder controle, waarbij de best presterende 32/344-configuratie slechts 1.142 ms bleef. Dit weerspiegelt een uitstekende responsiviteit, zelfs toen de array zijn maximale doorvoercapaciteit bereikte. Aan de schrijfzijde werd de willekeurige 4K-latentie ook goed beheerd. De laagste geregistreerde waarde was 0.352 ms bij 1/43, terwijl andere zeer efficiënte configuraties zoals 1/86, 2/43 en 4/43 allemaal onder de 0.6 ms bleven. Bij configuraties met een hoge doorvoer, zoals 32/172 en 32/86, steeg de latentie lichtjes naar tussen de 2.79 ms en 5.87 ms. Dit blijft binnen een acceptabel bereik, gezien de aanhoudende schrijfverzadiging.
Graid SupremeRAID AE GPU-overhead meten
Bij het onderzoeken van de SupremeRAID AE-opslagprestatiegegevens van Graid is het essentieel om te overwegen hoe SupremeRAID, dat GPU-resources deelt, van invloed kan zijn op workloads die ook diezelfde GPU's gebruiken. Bij eerdere implementaties van SupremeRAID was de GPU in het systeem toegewezen aan Graid. Met deze oplossing implementeert u deze op een platform dat al GPU's bevat die Graid kan gebruiken en resources kan delen. Om de overheadimpact te meten, hebben we een LLM-inferentiescenario ontwikkeld met behulp van vLLM. We hebben de basisprestaties van de workload gemeten met Graid inactief, en vervolgens opnieuw met Graid die 172 GB leest in de RAID 5-pool. Dit simuleert de inferentieworkload, waarbij de volgende workload vooraf wordt toegewezen terwijl er een actief is. Doordat vLLM de GPU's tot 100% benutting pusht, heeft elke Graid-bewerking invloed op de tokensnelheden en latentie.
Voor de AI-workload hebben we inferentie uitgevoerd met vLLM met behulp van het Llama 3.3 70B-model met volledige precisie (BF16) en een cachegrootte van 16 kV. Dit benutte bijna volledig het VRAM van beide kaarten (78 GB op de 80 GB-kaart en 86 GB op de 94 GB-kaart). Vervolgens hebben we het benchmarkscript van vLLM uitgevoerd met een maximale uitvoerlengte van 256 tokens. Elke test voerde 256 query's uit met een maximale gelijktijdigheid van 32 verzoeken, waarbij continue batchverwerking werd gebruikt om een realistisch verzoekpatroon te simuleren. De verzamelde gegevens zijn de Tok/s, Time to First Token (TTFT), Time per Output Token (TPOT) en Inter Token Latency (ITL). De FIO-workload die we tijdens de inferentietest hebben geïnitieerd, bestond uit 172 willekeurige leestaken van 16 kB, elk met een leesvolume van 1 GB.
De doorvoersnelheid daalde over de hele linie licht. De doorvoersnelheid van verzoeken daalde van 1.86 naar 1.78 verzoeken per seconde, een daling van 4.3%. De doorvoersnelheid van outputtokens daalde van 225.44 naar 215.94 tokens per seconde, een afname van 4.2%. De totale doorvoersnelheid van tokens daalde van 2029.77 naar 1944.30 tokens per seconde, een vergelijkbare daling van 4.2%. Dit suggereert dat de overdracht overhead met zich meebracht die de prestaties licht beïnvloedde.
Latency-metingen lieten gemengde resultaten zien. De gemiddelde TTFT steeg met 3.6%, van 6,704 ms naar 6,945 ms, terwijl de mediane TTFT met 1.5% steeg. Interessant is dat de P99 TTFT verbeterde en met 2.8% daalde van 14,199 ms naar 13,803 ms, wat wijst op betere tail-end prestaties in die metriek. Voor TPOT steeg het gemiddelde met 5.3%, terwijl de mediaan relatief gelijk bleef met een stijging van 0.65%. De P99 TPOT steeg echter scherp met 24.6%, van 127.69 ms naar 159.15 ms, wat aantoont dat de generatietijd van tokens in het slechtste geval aanzienlijk werd beïnvloed. De inter-token latency (ITL) vertoonde vergelijkbare trends. Het gemiddelde steeg met 5.1%, de mediaan bleef vrijwel ongewijzigd en de P99 steeg met 2.2%.
Graid's SupremeRAID AE, draaiend naast onze vLLM-workload, introduceerde een kleine maar consistente daling van de doorvoer (ongeveer 4%), samen met een gematigde toename van de gemiddelde latentie en een merkbare verslechtering van de P99-prestaties voor het genereren van tokens. Ondanks deze gevolgen bleef het systeem volledig stabiel en responsief, wat aantoont dat inferentie met hoge gelijktijdigheid met grote modellen, zoals Llama 3.3 70B, nog steeds betrouwbaar kan presteren naast Graid SupremeRAID AE.
| Metrisch (lagere duur / hogere tok/s is beter) | Baseline | Met 172 GB FIO-leesbewerking |
| Succesvolle verzoeken | 256 | 256 |
| Benchmarkduur (s) | 137.68 | 143.73 |
| Totaal aantal invoertokens | 248,414 | 248,414 |
| Totaal gegenereerde tokens | 31,037 | 31,037 |
| Aanvraagdoorvoer (req/s) | 1.86 | 1.78 |
| Doorvoersnelheid van uitvoertokens (tok/s) | 225.44 | 215.94 |
| Totale tokendoorvoer (tok/s) | 2029.77 | 1944.30 |
| Tijd tot eerste token (TTFT) (lagere latentie is beter) | ||
| Gemiddelde 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 |
| Tijd per output-token (TPOT, excl. 1e token) (lagere latentie is beter) | ||
| Gemiddelde TPOT (ms) | 81.44 | 85.72 |
| Mediane TPOT (ms) | 80.38 | 80.90 |
| P99 TPOT (ms) | 127.69 | 159.15 |
| Inter-token latentie (ITL) (lagere latentie is beter) | ||
| Gemiddelde ITL (ms) | 79.94 | 83.99 |
| Mediane ITL (ms) | 49.75 | 49.78 |
| P99 ITL (ms) | 539.07 | 550.73 |
Sluiting Gedachten
Graid SupremeRAID AE biedt een praktische, krachtige oplossing voor organisaties die AI-infrastructuur bouwen of schalen. Door traditionele hardware-RAID te vervangen door een GPU-gestuurde, softwaregedefinieerde aanpak, vereenvoudigt SupremeRAID AE de implementatie en verwijdert het tegelijkertijd veelvoorkomende knelpunten die moderne AI-workflows belemmeren.
Onze tests toonden aan dat het tot 32 NVMe SSD's kan verenigen in één veerkrachtige naamruimte, met bijna 1 PB aan capaciteit op één server en uitzonderlijke prestaties. Piekresultaten van 183 GB/s lees- en 54 GB/s schrijfsnelheid, gecombineerd met minimale GPU-overhead tijdens live inferentie, bevestigen dat het voldoet aan de dubbele eisen van grootschalige modelcontrole en inferentie met lage latentie op schaal.
Door de kosten en complexiteit van speciale RAID-hardware te elimineren en tegelijkertijd naadloos te integreren met technologieën zoals NVIDIA GPUDirect Storage en AI-gerichte bestandssystemen, creëert SupremeRAID AE een toekomstbestendige opslagbasis. Voor organisaties die zich richten op het stroomlijnen van inferentie en het verminderen van operationele risico's, biedt SupremeRAID AE de prestaties, eenvoud en veerkracht die nodig zijn voor AI-productieomgevingen.
Amazon