Niveaux de stockage dans un serveur d'IA : Modèle, Jeu de données, Espace de travail temporaire, Point de contrôle

Nous avons régulièrement une discussion avec nos clients au sujet des disques NVMe. Ils demandent « le plus rapide possible » car les fiches techniques annoncent 14 Go/s pour un disque de 5e génération et une carte graphique 4090 comparée à une Samsung 9100 PRO semble parfaitement adaptée. Puis, quand on leur demande à quoi servira le serveur, la réponse est « principalement pour l'inférence », et la configuration optimale se résume souvent à un seul disque au lieu de huit. Dans un serveur d'IA, le surdimensionnement du stockage est facile, sans conséquence pour le fournisseur et quasiment imperceptible pour les utilisateurs.

Cet article aborde les quatre niveaux de stockage réels d'un serveur d'IA, leur rôle respectif, les perspectives du marché NVMe en 2026, les situations où la 5e génération justifie son prix, l'obsolescence du RAID matériel avec NVMe et le dimensionnement optimal de chaque niveau. Le choix du système de fichiers est traité séparément dans L04 ; le stockage partagé du cluster (NFS, BeeGFS, Lustre, stockage d'objets) est abordé dans K04. Nous nous concentrons ici sur le stockage interne au châssis.

Les quatre niveaux de stockage

Un serveur d'IA performant possède quatre rôles de stockage distincts. Leurs caractéristiques (taille, débit, endurance et coût) sont très différentes. Les considérer comme un seul et même espace de stockage constitue une première erreur.

Un serveur d'inférence à 4 GPU n'a généralement besoin que du premier niveau et éventuellement d'une petite partie du second. Un serveur d'entraînement à 8 GPU nécessite les quatre, et chacun requiert un disque différent. La question « Combien de téraoctets de NVMe ? » n'a aucun sens sans préciser le niveau de stockage.

Modèle de stockage

La couche de modèles contient votre bibliothèque de poids — toutes les variantes Llama, Qwen, Mistral, Stable Diffusion, Flux et Whisper que vous prévoyez de charger. Elle héberge également le système d'exploitation, les images de conteneurs, les environnements conda et les binaires du serveur d'inférence. Dans la plupart des configurations, ces éléments sont installés sur le disque de démarrage.

Le dimensionnement dépend du nombre de modèles résidents. Voici quelques exemples de quantifications courantes :

• Llama 3 70B Q4 : ~40 Go
• Llama 3 70B FP8 : ~70 Go
• Qwen2.5-VL 72B Q4 : ~45 Go plus quelques Go de vision tower
• Mistral Large 2 (123B) Q4 : ~70 Go
• Llama 4 Maverick MoE FP8 : ~250 Go
• Une bibliothèque VLM modeste (8 modèles, quantifications mixtes) : 300 à 500 Go
• Un laboratoire de recherche maintenant 30 modèles en fonctionnement : 2 à 4 To

Principalement en lecture. Le modèle est chargé une seule fois au démarrage du processus et reste en mémoire VRAM pour le reste de la journée. Le disque effectue une lecture séquentielle de 40 Go au démarrage de vLLM, puis reste largement inactif. Un seul SSD NVMe Gen4 de 2 à 4 To — même un modèle grand public comme le Samsung 990 PRO — gère cela sans problème. Privilégiez la capacité au débit.

stockage des ensembles de données

L'ensemble de données contient les corpus d'entraînement et les éléments de réglage fin. C'est ce niveau que les clients ont tendance à sous-estimer systématiquement, car l'ensemble de données qu'ils utilisent actuellement leur convient et ils oublient que le suivant ne conviendra pas.

Plages réalistes :

• Corpus LoRA à domaine unique pour l'ajustement fin : 10 à 100 Go
• Ensemble de réglage fin multimodal (images + texte) : 1 à 10 To
• Corpus textuel de pré-entraînement (sous-ensemble FineWeb, etc.) : 5 à 50 To
• Ensemble de pré-formation vidéo ou de démonstration robotique : 20 à 200 To
• Archives génomiques, scientifiques ou issues du web : 100 To – 1 Po+

Le modèle d'accès est une lecture séquentielle, répétée sur plusieurs époques, répartie en parallèle sur de nombreux nœuds de calcul DataLoader. Le débit est critique (en raison de l'attente du GPU), mais la latence est tolérée. Le taux d'écriture est quasiment nul une fois les données préparées.

Pour les volumes de données supérieurs à environ 10 To, la solution optimale consiste généralement à utiliser des disques externes (voir K04 pour les configurations NFS, BeeGFS et de stockage objet). À l'intérieur du châssis, un système RAIDZ2 (économique, grande capacité, lente mais suffisante une fois le cache de pages initialisé) ou un RAID NVMe U.2 de milieu de gamme convient jusqu'à environ 50 To.

Résistance

Scratch est le héros méconnu. Il absorbe tout ce qui ne trouve pas sa place ailleurs : les fragments d'images décodés, les activations intermédiaires renvoyées par ZeRO-Offload, les caches de jeux de données construits par webdataset/DALI, des réorganisations temporaires de jeux de données, des artefacts de construction de conteneurs et le vidage d'une exécution ayant planté. Opérations de lecture et d'écriture intensives simultanément.

Dimensionnement : 2 à 8 To représentent la taille idéale. Moins de 2 To suffisent, et un seul réglage fin suffit. Au-delà de 8 To, vous créez généralement un petit niveau de stockage pour vos données, que vous considérez comme une solution de facilité ; soit, mais assumez vos actes.

L'endurance est ici cruciale, contrairement aux autres niveaux de stockage. Le stockage temporaire consomme beaucoup d'écritures : il n'est pas rare d'écrire entre 5 et 20 To par jour sur un disque dur de formation très sollicité. Un disque d'entreprise de 4 To avec une vitesse d'écriture de 1 DWPD permet d'écrire 4 To par jour pendant cinq ans ; un disque de formation dédié au stockage temporaire nécessite une vitesse d'écriture de 1 à 3 DWPD, pour une utilisation mixte.

Point de contrôle

Le niveau de point de contrôle correspond à l'état d'entraînement. Mode rafale : écriture silencieuse pendant dix minutes, puis 50 à 500 Go écrits en quelques secondes, puis de nouveau silence.

Un point de contrôle de modèle de 70 octets en FP16 représente environ 140 Go de poids. Avec FSDP, les gradients et l'état de l'optimiseur portent l'empreinte mémoire par point de contrôle à 400–700 Go. Avec DeepSpeed ​​ZeRO-3 et l'état complet de l'optimiseur (Adam : 8 octets par paramètre pour le maître FP32 + premier/second moment), un point de contrôle de 70 octets peut atteindre près de 1 To.

Le débit d'écriture soutenu d'un seul SSD NVMe Gen5 est d'environ 10 à 13 Go/s. L'écriture d'un point de contrôle de 700 Go prend environ une minute, dans des conditions optimistes. if Chaque séquence de données est enregistrée sur son propre disque dur. Les blocs d'entraînement sont synchronisés pour la minute correspondante. La solution consiste en un système de points de contrôle asynchrone et fragmenté (décrit ci-dessous).

NVMe Gen4 vs Gen5 : quand le surcoût est-il justifié ?

Le marché NVMe de 2026 se divise entre la génération 4 (Gen4), mature (5 à 7 Go/s), et la génération 5 (Gen5), désormais généralisée (12 à 14 Go/s). En tête du segment grand public, on trouve le Samsung 9100 PRO avec 14.8 Go/s en lecture séquentielle et 13.4 Go/s en écriture séquentielle. Le segment professionnel de la génération 5 se situe dans la même gamme : Solidigm D7-PS1010 à 14.5 Go/s en lecture, Micron 9550 MAX à 14 Go/s en lecture, Kioxia CD8 et SanDisk DC SN861 offrent tous des vitesses de lecture de 13 à 14 Go/s et des vitesses d’écriture soutenues de 8 à 10 Go/s.

Le surcoût de la Gen5 par rapport à la Gen4 de capacité comparable sera de 30 à 50 % pour le consommateur et de 20 à 35 % pour l'entreprise à la mi-2026.

Quand la 5e génération rapporte réellement :

• Chargement du modèle à froid. Un modèle MoE de 250 Go se charge en 18 secondes sur la 5e génération contre 36 secondes sur la 4e génération. Cela a son importance si vous changez souvent de modèle.
• Formation liée aux E/S. Pipelines de vision décodant des JPEG bruts à partir d'un disque, ensembles de données multimodaux où le prétraitement constitue le goulot d'étranglement.
• Point de contrôle sur le NVMe local avant la copie asynchrone. Plus vite la rédaction locale sera effective, plus vite la formation reprendra.
• Serveur de stockage en cluster prenant en charge plus de 8 nœuds d'entraînement. La demande globale des clients dépasse le plafond de la génération 4.

Quand la 4e génération est satisfaisante et la 5e génération représente un gaspillage d'argent :

• Serveurs d'inférence. Le modèle se charge une seule fois au démarrage ; le reste de la journée, le disque fonctionne à un débit de quelques Mo/s.
• Système d'exploitation racine et stockage des conteneurs. Démarrer une fois par mois, installer des paquets occasionnellement.
• Niveau de données où les fragments sont pré-décodés et volumineux. PyTorch DataLoader avec 8 workers lisant des fragments de WebDataset sature à environ 4–6 Go/s agrégés ; Gen4 couvre ce problème.

Pour être honnête : environ 70 % des configurations client que nous livrons servent uniquement à l’inférence, et pour celles-ci, l’utilisation de SSD NVMe de 4e génération est systématiquement recommandée. Le choix de la 5e génération concerne la phase d’entraînement.

Formats de mémoire : M.2, U.2/U.3, E3.S

Le M.2 Gen5 va réduire sa vitesse. Un SSD Samsung 9100 PRO de 2 To, fonctionnant à 13 Go/s dans un châssis chaud, atteint 75 °C et sa fréquence diminue. Les modèles équipés d'un dissipateur thermique améliorent la situation. Le format M.2 convient parfaitement au démarrage et aux charges de travail modérées ; il n'est cependant pas adapté à un stockage temporaire en écriture continue.

U.2 est le cheval de bataille. Tous les disques NVMe d'entreprise livrés par Kentino dans un châssis Bone64c ou Supermicro sont au format U.2, quasiment interchangeables avec les fonds de panier U.3. Avec une enveloppe thermique de 25 W, deux ports pour le multipath, la possibilité d'échange à chaud et des capacités de 7.68 To et 15.36 To, ils offrent un excellent rapport prix/densité.

E3.S, c'est l'avenir, lentement. Conçue dès le départ pour les processeurs Gen5/Gen6, la plateforme U.2/U.3 reste le choix idéal pour une configuration Kentino mono-serveur ou petit cluster jusqu'en 2026 ; la plateforme E3.S prendra le relais à partir de 2027.

Évitez d'empiler les supports M.2 dans un châssis chaud. Les adaptateurs PCIe pouvant accueillir quatre disques M.2 derrière une puce de commutation fonctionnent, mais dans un serveur 4U équipé de huit GPU, la ventilation autour de ces supports est insuffisante. On observe une limitation thermique après seulement dix minutes de charge soutenue. Si vous avez besoin de quatre disques NVMe dans un serveur, privilégiez le format U.2.

Endurance — DWPD comme signal d'achat

Pour un serveur d'IA, le mappage est simple :

• Niveau du modèle : lecture intensive, 0.3–1 DWPD.
• Niveau de l'ensemble de données : lecture intensive, 0.3–1 DWPD.
• Niveau Scratch : Usage mixte, 1 à 3 DWPD. C'est ce niveau qui justifie son budget d'endurance.
• Niveau de point de contrôle : Utilisation mixte, 1 à 3 DWPD. Les écritures en rafales s'accumulent ; 1 DWPD sur un disque de 4 To ne permet que 4 To/jour, ce qu'une cadence d'entraînement intensive dépasse.

Une architecture à forte intensité d'écriture (3+ DWPD) est surdimensionnée pour la quasi-totalité des charges de travail d'IA. Choisir un niveau d'endurance inadapté est récupérable par remplacement ; en revanche, choisir une classe de débit inadaptée est souvent irréversible. Optimisez le débit dès la conception et considérez l'endurance comme une fonctionnalité évolutive.

RAID pour NVMe — le matériel est mort, le logiciel est la solution

Ce sujet mérite une section à part entière, car les clients le demandent encore. En résumé : si votre configuration inclut un contrôleur RAID matériel devant des disques NVMe en 2026, elle est incorrecte.

Les contrôleurs RAID matériels (LSI/Broadcom MegaRAID, Microchip SmartRAID, HPE Smart Array, Dell PERC) ont été conçus pour les interfaces SAS/SATA. Leur circuit intégré spécifique (ASIC) gère la parité, la mise en cache et la mise en file d'attente des commandes, et à la bande passante SAS (12 Gbit/s = 1.5 Go/s), il dispose d'une marge de sécurité confortable.

Avec un débit de 14 Go/s par disque pour les disques NVMe Gen5, un contrôleur RAID monocarte sature dès deux disques. Huit disques connectés à une carte RAID matérielle génèrent une bande passante supérieure à celle que peut gérer la liaison montante PCIe de la carte. Le contrôleur devient alors le goulot d'étranglement, puis le point de défaillance.

Les réponses pratiques sont des logiciels :

• mdadm (RAID logiciel Linux). Gestion intégrée et mature du RAID au niveau du noyau : prise en charge optimale du RAID 0/1/10. Le RAID 5/6 fonctionne sur les disques NVMe, mais le calcul de la parité est gourmand en ressources CPU. Configuration idéale pour 4 disques NVMe en miroir ou en RAID 0.
• ZFS RAIDZ2. Meilleure gestion de l'intégrité des données (sommes de contrôle de bout en bout), outils améliorés pour le nettoyage et le remplacement, sémantique des instantanés et des clones. Plus gourmand en ressources CPU que mdadm. Le choix idéal pour les niveaux d'archivage et de gestion des ensembles de données où l'intégrité des données prime sur le débit maximal.
• Codage de réplication/effacement par disque au niveau de la couche application. Pour les très grandes baies, le striping MinIO/Ceph EC ou BeeGFS déplace entièrement la décision de redondance hors de la couche bloc.

Pour la plupart des constructions Kentino :

• Bateau: 2× M.2 NVMe en RAID1 mdadm.
• Rayure: RAID0 sur 2 à 4 NVMe (les données sont régénérables).
• Ensemble de données/point de contrôle : RAID10 dans mdadm ou RAIDZ2 dans ZFS.

Le RAID matériel n'a plus qu'un seul cas d'utilisation dans un serveur d'IA : une petite copie de démarrage derrière une carte Broadcom/MegaRAID de base, sur un serveur où une redondance de démarrage avant le système d'exploitation est absolument nécessaire. Même dans ce cas, un RAID 1 avec mdadm et EFI sur les deux disques fonctionne parfaitement.

Stockage en réseau pour la couche de données

En résumé : au-delà de 10 To, le stockage des données doit presque toujours être placé en dehors du serveur d’IA. À l’intérieur du châssis, il faut privilégier un espace de travail rapide, un système de points de contrôle rapide et un espace de stockage des modèles ; le stockage des données peut être distant.

Comment PyTorch charge réellement les données

Un modèle utile pour dimensionner le stockage consiste à suivre les recommandations de PyTorch. DataLoader oui. Avec num_workers=8 et pin_memory=True:

1. Huit processus de travail ouvrent chaque fichier de données en parallèle.
2. Chaque travailleur lit, décode (JPEG, images vidéo, rééchantillonnage audio) et tensorise un échantillon.
3. Le tenseur décodé est placé en mémoire partagée.
4. Le processus principal extrait les données de la file d'attente partagée, les transfère vers la RAM hôte et les copie sur le GPU via DMA.

Les implications pratiques :

• Un pipeline de vision est rarement limité par le stockage. sauf si l'ensemble de données est si volumineux que le cache de pages ne peut pas contenir un ensemble de travail.
• Un pipeline de pré-entraînement LLM lisant des fragments pré-tokenisés Le stockage est souvent limité sur les systèmes de 4e génération. La 5e génération améliore la situation. Il en va de même pour le placement du jeu de partitions actif sur un disque NVMe local plutôt que sur un système NFS.
• L'inférence n'est pratiquement jamais limitée par le stockage. Après le chargement du modèle, l'indicateur d'activité du disque sur le boîtier de service est plat.

La falaise du point de contrôle

Un point de contrôle de modèle 70 octets en FP16 représente 140 Go de poids. En ajoutant l'état de l'optimiseur Adam (environ 8 octets par paramètre pour le maître FP32 + premier et deuxième moments), on ajoute environ 560 Go. L'ajout des gradients, si une capture est effectuée en cours d'étape, ajoute environ 140 Go. Un point de contrôle « complet » de 70 octets peut atteindre 800 Go à 1 To selon les données enregistrées.

Sauvegarde synchrone de toutes les données sur un seul disque NVMe Gen5 à une vitesse d'écriture soutenue de 13 Go/s : environ 75 secondes pour une sauvegarde de 1 To. Blocs d'entraînement pendant toute la durée. Effectuer cette opération toutes les 100 étapes, sachant que chaque étape dure 5 secondes, ralentit l'entraînement de 15 %.

Deux solutions, toutes deux essentielles :

1. Point de contrôle fragmenté. Chaque nœud FSDP écrit son propre fragment sur son propre disque NVMe local. Avec 8 GPU et 8 disques locaux, la taille d'écriture par nœud est de 125 Go et les écritures sont parallélisées. Le temps d'exécution réel est réduit à environ 10 secondes.

2. Point de contrôle asynchrone. PyTorch DCP (torch.distributed.checkpointL'écriture est alors déportée vers un thread du processeur. Le GPU est brièvement interrompu pour la copie intermédiaire GPU→CPU (quelques secondes), puis l'entraînement reprend et l'écriture proprement dite sur le stockage s'effectue en arrière-plan.

Cette combinaison (partitionnement asynchrone) transforme le stockage des points de contrôle, qui doit « absorber 1 To en quelques secondes », en un stockage qui doit « maintenir une copie de fond stable à quelques centaines de Mo/s ». Presque tous les niveaux de stockage sont compatibles. L'erreur à éviter : les points de contrôle synchrones, avec un état complet par rang, écrits directement sur NFS. C'était courant en 2022. C'est une mauvaise pratique en 2026.

Plans de stockage K-AI en béton

Serveur d'inférence à 4 GPU (par exemple K-AI 192 Genoa, 4× RTX 5090 ou 4× RTX Pro 6000 Blackwell) :

Boot + model:    1× 2 TB Gen5 M.2 NVMe (consumer or read-intensive enterprise)
Scratch:         optional, often unnecessary for pure inference
Dataset:         not needed on the box
Checkpoint:      not needed on the box

Total: 2 TB NVMe. Cost: low. Sufficient for any inference workload.

Serveur d'entraînement à 8 GPU (par exemple K-AI 256 Turin Dual, 8× RTX 5090 ou 8× RTX Pro 6000) :

Boot:            2× 480 GB M.2 NVMe, mdadm RAID1, ext4 → /
Model storage:   2× 4 TB U.2 Gen5 NVMe, mdadm RAID1, ext4 → /models
Scratch:         2× 8 TB U.2 Gen5 NVMe, mdadm RAID0, XFS → /scratch
Checkpoint:      2× 8 TB U.2 Gen5 NVMe, mdadm RAID10, XFS → /checkpoints
Dataset:         NFS mount from external storage server, 100 GbE

Total local NVMe: ~36 TB. Cost: meaningful but matched to GPU spend.

Nœud de stockage partagé du cluster (distinct du calcul) :

Boot:            2× 960 GB M.2 NVMe, RAID1, ext4
Hot tier:        12× 7.68 TB U.2 Gen5 NVMe, ZFS RAIDZ2 or BeeGFS storage target, XFS
Cold tier:       8× 16 TB SAS HDD, ZFS RAIDZ2 → /archive
Network:         2× 100 GbE, RoCE or NVMe-oF capable

Serves the cluster's dataset tier. See K04 for distributed FS choice.

Deux points à noter. Le serveur d'inférence possède un lecteurLe serveur de formation comporte quatre niveaux, mais chaque disque est dimensionné en fonction de son rôle, sans être surdimensionné pour offrir la plus grande capacité disponible. Le nœud de stockage du cluster est une machine entièrement distincte.

En toute franchise, la plupart des clients surdimensionnent leur espace de stockage.

Un schéma récurrent qu'il est important de souligner : un client monte un serveur à 8 GPU « pour assurer sa pérennité », opte pour huit disques NVMe U.2 de 15.36 To (parce que les emplacements sont disponibles), puis exécute des charges de travail d'inférence qui utilisent environ 200 Go de fichiers de modèles, laissant le reste du système inactif. Résultat : 25 000 € de SSD NVMe inutilisés.

Les règles honnêtes du dimensionnement :

• Inférence pure, serveur unique : 2 à 4 To de capacité NVMe au total. Un seul disque. Terminé.
• Inférence et ajustements ponctuels : 4 à 8 To au total. Disque de démarrage + disque de travail.
• Entraînement intensif, serveur unique : 16 à 40 To répartis entre démarrage/modèle/réseau/point de contrôle, avec l'ensemble de données externe sur un NAS ou un stockage d'objets.
• Grappe: L'ensemble de données et le point de contrôle sont déplacés vers un stockage partagé ; le NVMe local par nœud se réduit au profil d'inférence (2 à 8 To) pour le démarrage, le modèle et le scratch de réécriture.

Dans le domaine de l'IA, le stockage est le seul domaine où l'instinct du « plus on en a, mieux c'est » se révèle systématiquement erroné. Les performances des GPU augmentent de façon quasi linéaire par rapport à leur coût ; la RAM évolue de façon raisonnable ; quant au stockage, une fois la capacité suffisante atteinte, son évolution devient souvent nulle.

Qu'est-ce qui casse ?

Les modes de défaillance que nous observons sur le terrain, dans l'ordre :

• Le disque de démarrage est un SSD M.2 grand public sans redondance. Le disque tombe en panne après 18 mois, le serveur devient inutilisable. Les versions restent intactes sur le RAID, mais la reconstruction prend une journée. Solution : 2 SSD M.2 en RAID 1 (mdadm), même sur les serveurs dédiés.
• Des rayures sont ajoutées en cours de course. Le cache des données, les fragments décodés et les fichiers temporaires du framework sont en conflit. Solution : surveiller, déclencher une alarme à 80 % de remplissage, et dimensionner le cache à 1.5 fois la taille maximale du jeu de données de travail attendu.
• Carte RAID matérielle derrière NVMe. Les performances sont réduites de moitié, le contrôleur constitue un point de défaillance unique et son remplacement est complexe. Solution : retirer la carte, utiliser mdadm ou ZFS directement.
• Point de contrôle synchrone vers NFS, blocage de l'entraînement. Correction : point de contrôle fragmenté asynchrone, NVMe local d’abord, puis copie asynchrone.
• Papillon thermique Gen5 M.2. Un disque annoncé à 14 Go/s atteint 4 Go/s après 3 minutes d'écriture continue. Solutions : dissipateur thermique, meilleure ventilation ou passage à l'interface U.2.
• L'ensemble de données au niveau de l'ensemble de données sature la génération 4. Le pipeline d'entraînement de la vision est limité à 30 % par le stockage. Solution : utiliser un système de données temporaires Gen5, pré-décodage vers WebDataset, ou les deux.
• ZFS ARC consomme de la RAM destinée à l'entraînement. L'allocation par défaut de 50 % provoque une erreur de mémoire insuffisante lors de l'entraînement. Solution : plafonner zfs_arc_max à 10–20 % de la RAM. Voir L04.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.