À mesure que l'infrastructure d'IA évolue, les pipelines de données deviennent plus rapides, plus étendus et plus complexes. De l'entraînement de modèles volumineux à l'inférence en temps réel à grande échelle, le sous-système de stockage est essentiel pour garantir que les GPU reçoivent les données nécessaires en continu. Le stockage devenant de plus en plus crucial dans les clusters d'IA, les entreprises repensent la manière d'assurer un débit élevé, des performances prévisibles et une résilience accrue, en particulier dans les environnements où la perte de données ou les temps d'arrêt sont tout simplement inacceptables.
Le défi devient encore plus important à mesure que la taille des modèles d'IA continue de croître de manière exponentielle. Les modèles de langage modernes volumineux et les modèles de base nécessitent des points de contrôle fréquents pour préserver la progression de l'apprentissage. À mesure que la taille des modèles passe de milliards à des milliers de milliards de paramètres, les besoins de stockage pour ces points de contrôle augmentent proportionnellement. Il en résulte un besoin urgent de grands espaces de stockage unifiés, capables de gérer des fichiers de points de contrôle volumineux, tout en maintenant des performances d'écriture et de lecture extrêmement rapides. Les architectures de stockage traditionnelles peinent à offrir à la fois la capacité et la vitesse requises pour ces charges de travail exigeantes.
Les approches actuelles de gestion des points de contrôle, telles que les points de contrôle asynchrones qui transfèrent les poids des modèles dans la mémoire du processeur pour permettre aux GPU de poursuivre l'entraînement, se heurtent à d'importantes limitations à mesure que les modèles se développent. Le stockage temporaire de ces points de contrôle dans la mémoire système devient de plus en plus coûteux et coûteux, nécessitant d'importantes quantités de RAM, ce qui augmente les coûts système et la consommation d'énergie. Plus grave encore, à mesure que la taille des modèles continue de croître, cette approche pourrait devenir totalement impraticable en raison du volume considérable de données qui devraient être temporairement conservées en mémoire.
Graid Technology a introduit une nouvelle approche spécifiquement adaptée à ces défis. S'appuyant sur le modèle défini par logiciel établi dans des solutions antérieures comme SupremeRAID SR1010, Le nouveau de Graid SupremeRAID AE (Édition IA) AE offre la fonctionnalité RAID d'entreprise aux charges de travail d'IA avec un minimum de modifications d'infrastructure. Au lieu d'une carte RAID matérielle dédiée ou d'une appliance personnalisée, AE est fourni sous forme de licence logicielle et n'utilise qu'une faible partie d'un GPU NVIDIA existant. Ainsi, les entreprises peuvent atteindre des performances et une fiabilité de stockage de niveau professionnel sans 1) consommer d'emplacements PCIe supplémentaires, 2) modifier leur infrastructure, ou 3) subir un impact significatif sur les performances du GPU pour les charges de travail d'entraînement et d'inférence.
Points clés à retenir
- Haute performance à grande échelle : SupremeRAID AE atteint un débit de lecture jusqu'à 183.60 Go/s et un débit d'écriture jusqu'à 54.23 Go/s, répondant ainsi aux exigences exigeantes de l'IA.
- Surcharge minimale du GPU : Introduit une surcharge minimale (~ 4 %) lors de l'inférence gourmande en GPU, maintenant ainsi de solides performances globales du système.
- Espace de noms de stockage unifié massif : Prend en charge jusqu'à 32 SSD NVMe par baie, offrant près de 1 Po de stockage dans un seul espace de noms unifié.
- Capacités d'intégration avancées : S'intègre entièrement avec NVIDIA GPUDirect Storage et les principaux systèmes de fichiers axés sur l'IA (BeeGFS, Lustre, Ceph).
- Infrastructure simplifiée : Élimine le matériel RAID dédié, réduisant ainsi considérablement la complexité, les coûts et les frais opérationnels.
Stockage et résilience optimisés pour les charges de travail d'IA avancées
SupremeRAID AE prend en charge jusqu'à 32 SSD NVMe dans une seule matrice, les agrégeant dans un espace de noms unifié. Cette structure permet aux charges de travail d'IA d'accéder efficacement à de grands ensembles de données tout en préservant leur résilience, ce qui est particulièrement important pour les environnements exécutant des tâches d'entraînement de longue durée. En cas de panne de disque, la matrice reste disponible et la progression des points de contrôle est préservée. Cette protection minimise le risque de perte de données ou de redémarrages fastidieux, ce qui constitue un avantage considérable pour les équipes gérant des modèles volumineux ou des pipelines d'inférence à volume élevé.
Les capacités de gestion intelligente des ressources de SupremeRAID AE offrent des opportunités d'optimisation supplémentaires pour les charges de travail d'IA. Bien que nos tests démontrent une charge minimale lors des opérations simultanées, l'impact peut être encore réduit grâce à une planification intelligente. Les opérations de point de contrôle ne s'exécutent généralement pas simultanément avec l'entraînement actif sur le même nœud ; il y a généralement une pause momentanée dans l'entraînement pendant les phases de point de contrôle. Pendant ces intervalles, SupremeRAID AE peut exploiter les ressources GPU inutilisées supplémentaires pour accélérer l'exécution des points de contrôle.
SupremeRAID AE prend également en charge NVIDIA GPUDirect Storage. Cela permet des chemins directs entre le stockage et la mémoire GPU, ce qui réduit la latence et améliore l'efficacité des E/S. Il s'intègre aux systèmes de fichiers centrés sur l'IA, tels que BeeGFS, Lustre et Ceph, et inclut un déchargement intelligent des données, ainsi que des API prêtes à l'orchestration pour l'automatisation. Au total, SupremeRAID AE offre une solution simplifiée, mais puissante, pour intégrer les avantages du RAID aux workflows d'IA modernes.
Au-delà des charges de travail d'entraînement, SupremeRAID AE répond aux exigences critiques des scénarios d'inférence d'IA modernes. À mesure que les entreprises étendent leurs opérations d'inférence, elles s'appuient de plus en plus sur des stratégies avancées telles que la gestion du cache KV persistant, l'optimisation du pré-remplissage et du décodage et les architectures mémoire hiérarchisées. Ces techniques nécessitent souvent de décharger les caches KV vers le stockage lorsqu'ils dépassent la capacité de la VRAM. Des solutions comme NVIDIA Dynamo, LLM-D de Red Hat et la pile de production vLLM intègrent toutes des intégrations de mise en cache KV hiérarchisée qui reposent sur un stockage rapide et haute capacité. Dans ces scénarios, disposer de pools de stockage importants et performants devient essentiel pour maintenir une inférence à faible latence, et la capacité de SupremeRAID AE à offrir à la fois une capacité massive et une vitesse exceptionnelle en fait une base idéale pour ces architectures d'inférence avancées.
Dans cette analyse, nous évaluons SupremeRAID AE sur notre plateforme Dell PowerEdge R770, équipée de deux GPU NVIDIA H100 et de 16 SSD NVMe Gen6550 Micron 61.44 de 5 To. Nous explorons les performances en RAID 5 à l'aide des outils GDSIO et FIO, et analysons l'impact de Graid AE sur le comportement du GPU lors d'une charge de travail d'inférence LLM en direct. L'objectif est de comprendre comment cette solution s'intègre aux environnements d'IA d'entreprise, où performances, capacité, résilience et simplicité doivent évoluer ensemble.
Chiffres clés : Analyse approfondie des performances de SupremeRAID AE
Pour tester les performances de Graid SupremeRAID AE, nous avons configuré un Dell PowerEdge R770 avec deux GPU NVIDIA H100 et 16 baies E3.S en façade. Basé sur la dernière plateforme Intel Xeon 6, ce système était équipé de deux processeurs Intel Xeon 6787P, chacun doté de 86 cœurs, pour gérer des charges de travail hautement parallèles dans les environnements d'IA, de calcul haute performance (HPC) et de traitement de données intensif.
Le R770 était configuré avec 16 baies E3.S et le stockage était entièrement équipé de SSD Micron 6550 ION 61.44 To Gen5 NVMe TLC, conçus pour offrir des performances constantes sur une large gamme de charges de travail. Les SSD Micron offrent un équilibre idéal entre performances exceptionnelles et capacité massive, permettant aux charges de travail d'IA de maintenir un débit élevé tout en simplifiant considérablement l'infrastructure d'IA. Avec un pétaoctet de stockage sur seulement 16 disques, les entreprises peuvent gérer efficacement des ensembles de données volumineux et des points de contrôle de modèles à grande échelle au sein d'un seul serveur, réduisant ainsi considérablement la complexité et la charge de travail de l'infrastructure.
Spécifications du système de test
- Plate-forme: Dell PowerEdge R770
- CPU: 2x Intel Xeon 6787P (86 cœurs chacun)
- Mémoire: Mémoire DDR32 double rang 64x Micron 5 Go 6400 MT/s Mémoire totale : 2 To
- Mise en réseau: Carte réseau DELL BRCM 4P 25G SFP 57504S OCP
- GPU 1 : NVIDIA H100 (VRAM 80 Go)
- GPU 2 : NVIDIA H100NVL (VRAM 96 Go)
- Stockage: 16 x Micron ION 61 6550 To SSD (pool RAID 915 de 5 To)
Dans le cadre de ces tests de performances, les SSD Micron ont été configurés dans un pool RAID 5 unique avec SupremeRAID AE. Cette configuration a été choisie pour évaluer l'équilibre entre performances et tolérance aux pannes de SupremeRAID AE dans un environnement piloté par l'IA exigeant un stockage haute capacité. RAID 5 répartit la parité sur tous les disques, ce qui protège contre les pannes d'un seul disque tout en préservant la capacité de stockage utilisable.
Avant d'aborder les tests de performances, il est important de noter les différences entre GDSIO et FIO lors de la mesure des performances de stockage avec Graid. Lors de nos précédentes évaluations des performances de Graid, une observation cruciale a été l'absence de goulots d'étranglement (tels qu'une carte RAID matérielle) limitant la bande passante maximale. Les cartes RAID matérielles gèrent les périphériques de stockage qui y sont connectés, et l'emplacement PCIe peut devenir un goulot d'étranglement dans ce processus. Graid utilise un GPU pour les opérations RAID, mais toutes les données ne doivent pas nécessairement transiter par celui-ci. Par conséquent, le GPU ne limite pas la bande passante.
Le benchmark de stockage FIO mesure les performances de stockage en utilisant le processeur pour accéder au stockage et n'est limité que par la solution de stockage. Le GDSIO, quant à lui, mesure les performances du stockage direct GPU, où le GPU peut être le facteur limitant. Le NVIDIA H100, par exemple, dispose d'une interface PCIe Gen5 x16 et offre une bande passante entrante et sortante d'environ 63 Go/s. Dans ce contexte, les goulots d'étranglement des performances GPU concernent la bande passante que le GPU peut prendre en charge avec le stockage direct GPU, et non un goulot d'étranglement Graid.
Stockage direct du GPU NVIDIA
L'un des tests que nous avons menés sur ce banc d'essai était le test Magnum IO GPU Direct Storage (GDS). GDS est une fonctionnalité développée par NVIDIA qui permet aux GPU de contourner le CPU lors de l'accès aux données stockées sur des disques NVMe ou d'autres périphériques de stockage haute vitesse. Au lieu de faire transiter les données par le CPU et la mémoire système, GDS permet une communication directe entre le GPU et le périphérique de stockage, réduisant ainsi considérablement la latence et améliorant le débit.
Comment fonctionne le stockage direct GPU
Traditionnellement, lorsqu'un GPU traite des données stockées sur un disque NVMe, les données doivent d'abord transiter par le processeur et la mémoire système avant d'atteindre le GPU. Ce processus introduit des goulots d'étranglement, car le processeur devient un intermédiaire, ce qui ajoute de la latence et consomme de précieuses ressources système. Le stockage direct GPU élimine cette inefficacité en permettant au GPU d'accéder directement aux données depuis le périphérique de stockage via le bus PCIe. Ce chemin direct réduit la surcharge associée au déplacement des données, permettant des transferts de données plus rapides et plus efficaces.
Les charges de travail de l’IA, en particulier celles impliquant l’apprentissage profond, sont très gourmandes en données. La formation de grands réseaux neuronaux nécessite le traitement de téraoctets de données, et tout retard dans le transfert de données peut entraîner une sous-utilisation des GPU et des temps de formation plus longs. Le stockage direct GPU relève ce défi en garantissant que les données sont transmises au GPU le plus rapidement possible, en minimisant les temps d’inactivité et en maximisant l’efficacité de calcul.
En outre, GDS est particulièrement utile pour les charges de travail impliquant la diffusion de grands ensembles de données, comme le traitement vidéo, le traitement du langage naturel ou l'inférence en temps réel. En réduisant la dépendance au processeur, GDS accélère le déplacement des données et libère les ressources du processeur pour d'autres tâches, améliorant ainsi encore les performances globales du système.
Débit de lecture aléatoire du lecteur GDSIO 16
Avant d'aborder les chiffres de performance, il est essentiel de noter que le facteur limitant les performances de lecture et d'écriture avec les valeurs GDSIO est le ou les GPU. Ce test vise à mesurer les performances de stockage maximales pouvant être poussées ou extraites du GPU. Vous rencontrerez éventuellement un goulot d'étranglement au niveau de l'emplacement PCIe, qui, pour PCIe Gen5 x16, est d'environ 63 Go/s.
En ce qui concerne le débit de lecture aléatoire GDSIO, la baie a obtenu ses meilleurs résultats avec des tailles de blocs plus importantes et un nombre de threads plus élevé, tout en peinant à évoluer efficacement à l'extrémité inférieure. À 16 128/7.3 threads, l'amélioration a commencé à être plus notable, atteignant 32 Gio/s, mais la véritable accélération du débit n'a été constatée qu'à partir de 15.5 64, où la baie a atteint 64 Gio/s avec 25.9 threads. Des gains substantiels ont été observés à 128 41.3, atteignant 64 Gio/s, et les performances ont décollé à partir de 40 128, atteignant 1 Gio/s avec 32 threads et se maintenant au-dessus de 88.5 Gio/s avec XNUMX threads. Le débit maximal a été atteint à XNUMX M de blocs avec XNUMX threads, où la baie a atteint XNUMX Gio/s et s'est maintenue à ce niveau avec le nombre de threads le plus élevé.
Latence de lecture aléatoire du lecteur GDSIO 16
Suite aux résultats de débit, le profil de latence de lecture aléatoire de la matrice reflétait le comportement de mise à l'échelle observé précédemment. La latence est restée exceptionnellement faible pour toutes les tailles de blocs et tous les nombres de threads jusqu'à 16 threads, avec des valeurs inférieures à 0.1 ms pour tous les blocs jusqu'à 128 Ko. Même les blocs plus volumineux, comme 128 Ko, sont restés entre 0.13 ms et 0.20 ms. Au-delà de 16 threads, cependant, la latence a sensiblement augmenté. À 16 32 / 980 threads, la latence a continué d'augmenter, atteignant finalement 128 ms à 1 threads. De même, les lectures de 0.242 M, qui présentaient le débit le plus élevé, sont passées de 2.892 ms à un thread à 128 ms à 32 threads. La tendance était constante pour toutes les tailles : la latence est restée stable avec une concurrence modérée, mais a fortement augmenté au-delà de XNUMX threads, en particulier avec des blocs plus importants.
Débit d'écriture aléatoire du lecteur GDSIO 16
Concernant le débit d'écriture GDSIO, la baie a de nouveau affiché d'excellentes performances avec des tailles de blocs plus importantes, tout en évoluant plus progressivement qu'en lecture. Les performances ont commencé à s'améliorer de manière significative à partir de 32 K, où le débit a dépassé 5.9 Gio/s, et en particulier à 64 threads et plus, où les blocs de 512 K et 1 M ont enregistré des gains soutenus même avec un nombre élevé de threads. À 64 threads et plus, les écritures de 512 K ont atteint 25.4 Gio/s et celles de 1 M ont culminé à 38.4 Gio/s, tandis qu'à 128 threads, les écritures de 1 M ont continué à évoluer jusqu'à un pic maximal de 45.9 Gio/s. Les tailles de blocs de 512 K et 128 K sont également restées constantes en cas de forte concurrence, se stabilisant respectivement autour de 26.2 Gio/s et 8.0 Gio/s.
Latence d'écriture aléatoire du lecteur GDSIO 16
Suite à la forte augmentation du débit d'écriture, le profil de latence des écritures aléatoires sur la baie a connu une augmentation constante avec l'augmentation de la taille des blocs et du nombre de threads. Même avec un faible nombre de threads, la latence d'écriture était nettement supérieure à celle des lectures, commençant à 0.367 ms et augmentant avec la taille des blocs jusqu'à 1.222 ms à 1 Mo. Avec l'augmentation de la concurrence, la latence a progressivement augmenté jusqu'à 16 threads, puis a connu une accélération plus importante. À 64 threads, les écritures atteignaient 0.663 ms, tandis que celles à 1 Mo atteignaient 3.255 ms. À 128 et 256 threads, la latence est devenue significativement élevée, en particulier avec les blocs de grande taille. Par exemple, les écritures à 512 Ko ont atteint 4.770 ms à 128 threads, et celles à 512 Ko et 1 Mo ont franchi la barre des 5 ms, culminant à 5.436 ms à 1 Mo.
FIO Benchmark de performance
Nous allons maintenant mesurer les performances FIO sur le pool RAID5. Si le GDSIO dépend en fin de compte des performances des GPU installés dans le système et de leur bande passante PCIe, le FIO peut être supérieur en fonction des performances des SSD et de la solution RAID elle-même.
L'ensemble de la matrice est soumis à un processus de test rigoureux, commençant par une phase de préconditionnement comprenant deux remplissages complets avec une charge de travail d'écriture séquentielle, suivie de nos charges de travail séquentielles et aléatoires. Cela garantit que les disques atteignent un état stable avant le début des mesures de performances.
Pour chaque nouveau type de charge de travail, nous avons relancé le préconditionnement en utilisant la taille de transfert correspondante pour maintenir la précision et la cohérence des résultats.
Cette section met en évidence les benchmarks FIO d'écriture/lecture aléatoires suivants appliqués à la matrice RAID 16 SSD Graid 5 :
- Écriture/lecture aléatoire de 1 M
- Écriture/lecture aléatoire de 64 K
- Écriture/lecture aléatoire de 16 K
- Écriture/lecture aléatoire de 4 K
Bande passante de lecture/écriture aléatoire de 1 M
En passant à des opérations aléatoires de 1 M, la bande passante en lecture a dominé la courbe de performance, atteignant un pic à 183.60 Go/s avec une profondeur d'E/S de 16 avec 172 tâches, la configuration la plus agressive testée. Des résultats similaires à haut débit ont été enregistrés à 8/172 et 4/172, dépassant tous deux 182 Go/s, ce qui souligne la capacité de la baie à évoluer avec l'augmentation du nombre et de la profondeur des tâches. Même les configurations milieu de gamme comme 4/86 et 16/43 ont maintenu leur niveau de performance, dépassant 147 Go/s, affichant des performances de lecture constantes quel que soit le niveau de concurrence. En écriture, la bande passante aléatoire de 1 M a atteint un pic de 54.233 Go/s à 8/172, avec un débit quasi identique de 53.77 Go/s à 2/86, validant une mise à l'échelle efficace de l'écriture sous charges de travail parallèles. Les performances ont été réduites en douceur dans les combinaisons de threads inférieurs comme 1/43 et 2/43, qui ont produit respectivement 24.88 Go/s et 42.48 Go/s, reflétant toujours une forte courbe de saturation même à des niveaux de concurrence modérés.
Latence de lecture/écriture aléatoire de 1 M
La latence est restée contrôlée en lecture sur toute la plage de test. La latence la plus faible observée était de 0.714 ms à 2/86 et 4/86, tandis que les charges plus profondes, telles que 8/172 et 4/172, restaient inférieures à 2 ms. La configuration générant le débit de lecture le plus élevé, 16/172, présentait la latence la plus élevée, soit 7.516 ms ; un compromis évident, car les files d'attente plus profondes augmentaient les temps de réponse. Côté écriture, la latence a suivi une tendance similaire. La latence d'écriture la plus faible a été mesurée à 1.727 ms avec 1/43. Un excellent équilibre entre débit et latence a été atteint à 2/86 avec 3.197 ms. Les options de concurrence plus élevées comme 8/43 ont enregistré 6.389 ms, et la configuration 16/172, tout en offrant des performances d'écriture maximales, a enregistré la latence la plus élevée à 50.741 ms, soulignant la relation inverse familière entre le débit et la réactivité à des profondeurs extrêmes.
Bande passante de lecture/écriture aléatoire de 64 K
En passant à des opérations aléatoires de 64 K, la bande passante en lecture s'est considérablement améliorée avec une profondeur de file d'attente et un nombre de tâches plus élevés, atteignant un pic de 91.65 Go/s à une profondeur d'E/S de 32 avec 172 tâches. Plusieurs autres configurations ont suivi de près, notamment 16/172 à 83.59 Go/s et 32/86 à 82.85 Go/s, mettant en évidence des gains de performances constants à mesure que la charge de travail augmentait. Les configurations milieu de gamme comme 8/172 et 16/86 ont maintenu d'excellents résultats entre 78 Go/s et 79 Go/s. En revanche, les combinaisons à faible concurrence comme 1/43 et 1/172 ont produit des niveaux de débit réduits allant de 21.89 Go/s à 42.63 Go/s, illustrant la dépendance de la matrice au parallélisme pour des performances optimales. Côté écriture, la bande passante aléatoire de 64 K a culminé à 6.44 Go/s avec 32/86. Les autres configurations les plus performantes, notamment 32/172 et 16/86, étaient très proches, enregistrant respectivement 6.41 Go/s et 6.36 Go/s. La plupart des points de test se situaient entre 6.3 Go/s et 6.4 Go/s, affichant une constance stable sur différentes profondeurs de file d'attente. Les configurations légères, comme 1/43, ont affiché les performances d'écriture les plus faibles, à 3.83 Go/s, confirmant ainsi la tendance à des gains progressifs sous des charges de travail plus lourdes.
Latence de lecture/écriture aléatoire de 64 K
La latence de lecture aléatoire de 64 Ko est restée faible dans la plupart des cas de test. La latence la plus faible était de 0.123 ms à 1/43, suivie de 0.175 ms à 1/86. À mesure que le débit augmentait, la latence restait dans une plage contrôlée : 4/172 affichait 0.666 ms, tandis que 16/172 atteignait 2.057 ms. Même sous des charges plus importantes, la réactivité est restée efficace, 32/86 enregistrant 2.076 ms malgré l'un des meilleurs résultats en termes de bande passante. Côté écriture, la latence a augmenté plus fortement avec la profondeur et le nombre de tâches. La latence la plus faible a été enregistrée à 2/43 (0.887 ms), suivie de près par 4/43 et 2/86 (1.694 ms et 1.697 ms respectivement). Les configurations plus lourdes ont montré des signes clairs de compromis en termes de temps de réponse : 8/172 ont enregistré 13.445 ms, 16/172 ont grimpé à 26.862 ms et 32/172 ont culminé à 63.201 ms, soulignant l'augmentation de la surcharge de file d'attente à mesure que les charges de travail s'intensifiaient.
16 XNUMX IOPS en lecture/écriture aléatoire
La latence de lecture aléatoire de 16 Ko est restée faible, même aux pics d'IOPS. La meilleure réactivité a été observée dans les configurations les plus légères : 1/43 a atteint seulement 0.087 ms et 1/86 0.114 ms. Les combinaisons de simultanéité plus élevées, comme 4/86 et 8/86, ont mesuré respectivement 0.236 ms et 0.420 ms. Même les configurations les plus performantes ont conservé une latence raisonnable : 16/172 a affiché 1.143 ms et 32/172 a atteint 2.372 ms, démontrant une mise à l'échelle efficace avec un impact gérable sur le temps de réponse. Pour les écritures aléatoires de 16 Ko, la latence la plus faible a été enregistrée à 2/43 avec 0.848 ms, suivie de 1.253 ms à 4/43 et de 1.415 ms à 1/43. À mesure que la profondeur et le nombre de tâches augmentaient, la latence augmentait progressivement : 8/172 atteignait 5.574 ms, tandis que 16/172 et 32/172 grimpaient respectivement à 10.455 ms et 22.958 ms, mettant en évidence le compromis attendu à mesure que la saturation de la file d'attente augmentait.
Latence de lecture/écriture aléatoire de 16 K
La latence de lecture aléatoire de 16 Ko est restée faible dans tous les cas. La configuration la plus réactive était 1/43 à 0.123 ms, suivie de près par 1/86 à 0.175 ms. Même sous pression maximale, des configurations comme 32/172 et 16/172 ont maintenu une latence inférieure à 2.1 ms, ce qui montre que la matrice a conservé des temps de réponse rapides tout en gérant des IOPS élevées. En revanche, la latence d'écriture aléatoire de 16 Ko a affiché une plus grande variance. La latence la plus faible était de 0.496 ms à 1/43, avec des exécutions efficaces supplémentaires comme 2/86 et 4/43 restant sous la barre de 1 ms. À mesure que la concurrence et la profondeur augmentaient, la latence a augmenté en conséquence : 16/172 a enregistré 7.017 ms et 32/172 a atteint 17.246 ms, renforçant le compromis attendu entre débit maximal et réactivité à saturation maximale.
4 XNUMX IOPS en lecture/écriture aléatoire
Sous une charge de concurrence plus importante, les IOPS aléatoires de 4 K en lecture ont atteint un pic impressionnant de 10.77 millions avec une profondeur d'E/S de 32, pour 344 jobs. D'autres configurations ont suivi de près, notamment 16/344 à 10.52 M, 4/344 à 10.51 M et 8/344 à 10.42 M, toutes affichant une évolutivité exceptionnelle avec des combinaisons agressives de profondeurs de file d'attente et de jobs. Même les options à profondeur réduite, comme 8/172 et 16/172, ont maintenu un débit élevé entre 5.23 M et 5.35 M d'IOPS, soulignant ainsi la capacité de la baie à gérer des charges de travail parallèles exigeantes. Côté écriture, les IOPS de 4 K ont culminé à 987.9 K avec 32/172. Des configurations similaires à haut rendement comprenaient 32/86 à 985.1 K, 16/172 à 985.6 K et 8/172 à 976.9 K. Des combinaisons supplémentaires, de 8/86 à 16/86, ont maintenu les performances entre 875 K et 977 K, renforçant la cohérence et la fiabilité de la matrice lorsqu'elle était entièrement saturée par des opérations d'écriture simultanées.
Latence de lecture/écriture aléatoire de 4 K
La latence de lecture aléatoire 4K est restée extrêmement faible dans tous les cas. Le temps de réponse le plus rapide était de 0.084 ms à 1/86, plusieurs autres configurations, dont 1/43, 2/43 et 4/43, étant toutes inférieures à 0.12 ms. Même aux pics d'IOPS, la latence est restée bien maîtrisée, la configuration 32/344 la plus performante se maintenant à seulement 1.142 ms. Cela témoigne d'une excellente réactivité, même lorsque la matrice a atteint son potentiel de débit maximal. Côté écriture, la latence aléatoire 4K a également été bien gérée. La valeur la plus basse enregistrée était de 0.352 ms à 1/43, tandis que d'autres configurations très performantes comme 1/86, 2/43 et 4/43 sont toutes restées inférieures à 0.6 ms. Les configurations à haut débit telles que 32/172 et 32/86 ont vu la latence augmenter modestement entre 2.79 ms et 5.87 ms, restant dans une plage acceptable compte tenu des niveaux de saturation d'écriture soutenus.
Mesure de la surcharge du GPU SupremeRAID AE de Graid
Lors de l'analyse des performances de stockage SupremeRAID AE de Graid, il est essentiel de prendre en compte l'impact potentiel de SupremeRAID, qui partage les ressources GPU, sur les charges de travail utilisant également ces mêmes GPU. Lors des précédents déploiements de SupremeRAID, le GPU du système était dédié à Graid. Avec cette solution, vous le déployez sur une plateforme contenant déjà des GPU que Graid peut utiliser et partager des ressources. Pour mesurer l'impact de la surcharge, nous avons élaboré un scénario d'inférence LLM à l'aide de vLLM. Nous avons mesuré les performances de base de la charge de travail avec Graid inactif, puis avec Graid lisant 172 Go sur le pool RAID 5. Cela simule la charge de travail d'inférence, préallouant la charge de travail suivante pendant son exécution. Avec vLLM poussant les GPU à 100 %, toute opération Graid affectera les débits de jetons et la latence.
Pour la charge de travail d'IA, nous avons exécuté l'inférence avec vLLM en utilisant le modèle Llama 3.3 70B à pleine précision (BF16) avec un cache de 16 KV. Cela a utilisé la quasi-totalité de la VRAM des deux cartes (78 Go sur la carte 80 Go et 86 Go sur la carte 94 Go). Nous avons ensuite exécuté le script d'analyse comparative de vLLM avec une longueur de sortie maximale de 256 jetons. Chaque test a exécuté 256 requêtes avec une simultanéité maximale de 32 requêtes, en utilisant le traitement par lots continu pour simuler un modèle de requête réaliste. Les métriques collectées sont le débit en Tok/s, le temps jusqu'au premier jeton (TTFT), le temps par jeton de sortie (TPOT) et la latence inter-jetons (ITL). La charge de travail FIO que nous avons lancée pendant le test d'inférence comprenait 172 tâches de lecture aléatoire de 16 Ko, chacune lisant 1 Go.
Le débit a connu une légère baisse générale. Le débit des requêtes est passé de 1.86 à 1.78 requête par seconde, soit une baisse de 4.3 %. Le débit des jetons de sortie est passé de 225.44 à 215.94 jetons par seconde, soit une baisse de 4.2 %. Le débit total des jetons est passé de 2029.77 1944.30 à 4.2 XNUMX jetons par seconde, soit une baisse similaire de XNUMX %. Cela suggère que le transfert a entraîné une surcharge qui a légèrement impacté les performances.
Les mesures de latence ont révélé des résultats mitigés. Le TTFT moyen a augmenté de 3.6 %, passant de 6,704 6,945 ms à 1.5 99 ms, tandis que le TTFT médian a progressé de 2.8 %. Il est intéressant de noter que le TTFT P14,199 s'est amélioré, diminuant de 13,803 %, passant de 5.3 0.65 ms à 99 24.6 ms, ce qui indique une meilleure performance de fin de chaîne pour cette mesure. Pour le TPOT, la moyenne a augmenté de 127.69 %, tandis que la médiane est restée relativement stable avec une augmentation de 159.15 %. En revanche, le TPOT P5.1 a fortement augmenté de 99 %, passant de 2.2 ms à XNUMX ms, ce qui montre que le temps de génération de jeton dans le pire des cas a été significativement impacté. La latence inter-jetons (ITL) a montré des tendances similaires, la moyenne augmentant de XNUMX %, la médiane restant essentiellement inchangée et le PXNUMX augmentant de XNUMX %.
SupremeRAID AE de Graid, exécuté parallèlement à notre charge de travail vLLM, a entraîné une baisse légère mais constante du débit (environ 4 %), ainsi qu'une augmentation modérée de la latence moyenne et une dégradation notable des performances P99 pour la génération de jetons. Malgré ces impacts, le système est resté parfaitement stable et réactif, démontrant que l'inférence à haute concurrence avec des modèles volumineux, tels que Llama 3.3 70B, peut toujours fonctionner de manière fiable avec SupremeRAID AE de Graid.
| Métrique (durée plus courte / tok/s plus élevé est meilleur) | Baseline | Avec 172 Go d'opération de lecture FIO |
| Demandes réussies | 256 | 256 |
| Durée de référence (s) | 137.68 | 143.73 |
| Total des jetons d'entrée | 248,414 | 248,414 |
| Total des jetons générés | 31,037 | 31,037 |
| Débit de requêtes (req/s) | 1.86 | 1.78 |
| Débit du jeton de sortie (tok/s) | 225.44 | 215.94 |
| Débit total de jetons (tok/s) | 2029.77 | 1944.30 |
| Temps jusqu'au premier jeton (TTFT) (une latence plus faible est meilleure) | ||
| TTFT moyen (ms) | 6,704.43 | 6,945.72 |
| TTFT médian (ms) | 6,469.88 | 6,569.80 |
| P99 TTFT (ms) | 14,199.21 | 13,803.62 |
| Temps par jeton de sortie (TPOT, excl. 1er jeton) (une latence plus faible est meilleure) | ||
| TPOT moyen (ms) | 81.44 | 85.72 |
| TPOT médian (ms) | 80.38 | 80.90 |
| P99 TPOT (ms) | 127.69 | 159.15 |
| Latence inter-jetons (ITL) (une latence plus faible est meilleure) | ||
| ITL moyen (ms) | 79.94 | 83.99 |
| ITL médiane (ms) | 49.75 | 49.78 |
| P99 ITL (ms) | 539.07 | 550.73 |
Réflexions de clôture
Graid SupremeRAID AE offre une solution pratique et performante aux entreprises qui développent ou font évoluer leur infrastructure d'IA. En remplaçant le RAID matériel traditionnel par une approche logicielle pilotée par GPU, SupremeRAID AE simplifie le déploiement tout en supprimant les goulots d'étranglement courants qui entravent les workflows d'IA modernes.
Nos tests ont démontré sa capacité à unifier jusqu'à 32 SSD NVMe dans un espace de noms unique et résilient, offrant près de 1 Po de capacité sur un seul serveur avec des performances exceptionnelles. Des débits de pointe de 183 Go/s en lecture et 54 Go/s en écriture, combinés à une charge GPU minimale lors de l'inférence en direct, valident sa capacité à répondre à la double exigence de points de contrôle de modèles massifs et d'inférence à faible latence à grande échelle.
En éliminant le coût et la complexité du matériel RAID dédié tout en s'intégrant parfaitement à des technologies telles que NVIDIA GPUDirect Storage et les systèmes de fichiers axés sur l'IA, SupremeRAID AE crée une base de stockage évolutive. Pour les entreprises soucieuses de rationaliser l'inférence et de réduire les risques opérationnels, SupremeRAID AE offre les performances, la simplicité et la résilience nécessaires aux environnements d'IA de production.
Amazon