Storage Scale vs Ceph pour l’inférence IA : comment choisir
Storage Scale vs Ceph pour l'inférence IA : comment choisir.
Nous déployons les deux. Nous les exploitons tous les deux en production depuis des années. Et non, la réponse n'est pas « utilisez les deux » : c'est comprendre ce que chacun fait bien, où chacun pèche, et lequel correspond à votre charge de travail.
La même question revient sous différents déguisements : « Storage Scale ou Ceph pour l'inférence IA ? »
Nous sommes IBM Business Partner. Nous vendons Storage Scale. Nous dispensons aussi des formations Ceph et du conseil Ceph en production. Nous travaillons avec les deux au quotidien, donc ce qui suit vient de la construction d'architectures réelles — pas de la lecture de datasheets.
Voici ce que nous dirions à un client assis en face de nous pour concevoir son architecture de stockage pour l'inférence IA.
Avant de choisir : ce que l'inférence IA attend du stockage
La plupart des gens commencent par le produit. Nous, on commence par le pattern d'accès, parce que c'est ça qui détermine si le choix fonctionne ou vous donne des migraines pendant des années.
Un environnement d'inférence réel — pas une démo Llama sur un laptop — ressemble à ça :
Et tout ça est consommé par un zoo de processus : des nœuds GPU avec vLLM ou TGI, des nœuds CPU, Spark ou Ray en prétraitement, des pipelines Docling et OCR, la base vectorielle, des applications legacy qui entrent par NFS, et quelqu'un de la conformité qui veut voir un PDF depuis Windows en SMB.
Si votre setup ressemble à ça — beaucoup de consommateurs, beaucoup de protocoles, des données partagées — c'est ce pattern qui doit guider la décision. Pas le prix par To ni le logo du fournisseur.
Où Storage Scale gagne pour l'inférence IA
POSIX natif : vos frameworks attendent un répertoire, pas un bucket
Ça paraît évident jusqu'à ce que vous deviez le mettre en place. Regardez comment les outils que vous allez utiliser chargent les modèles :
Ils demandent un chemin. Un répertoire. Pas un endpoint S3. Storage Scale (anciennement GPFS) est un système de fichiers parallèle POSIX natif. Ce /models est un répertoire partagé que tous les nœuds lisent simultanément, avec un accès concurrent réel, sans copies intermédiaires. Rien à inventer.
Zéro copie entre couches : l'argument le plus convaincant
Avec Ceph S3, le schéma typique pour servir un modèle : télécharger depuis le bucket → écrire sur disque local ou PVC → démarrer le moteur d'inférence → servir. Trois étapes avant la première requête. Et si vous avez 16 nœuds, les 16 téléchargent leur copie.
Avec Storage Scale, le moteur d'inférence pointe vers /gpfs/models/llama-70b/ et démarre. C'est tout. Pas de téléchargement, pas de cache, pas de « ce nœud a-t-il la dernière version ? ». Quand vous mettez le modèle à jour, vous le faites une fois et tous les nœuds le voient.
C'est particulièrement visible quand vous itérez — changement de modèles, test d'adaptateurs LoRA, rotation entre configurations. Avec le cache local, vous finissez par maintenir des scripts de synchronisation, de l'invalidation et du nettoyage de disque. Avec un système de fichiers parallèle, il n'y a rien à maintenir.
Multi-protocole sur le même fichier
C'est ce qui résout le casse-tête enterprise. Un même fichier dans Storage Scale peut être consommé par POSIX (nœud GPU), par S3 (app moderne), par NFS (équipe data), par SMB (quelqu'un sous Windows) et par CSI (pod Kubernetes). Le même fichier. Pas une copie par protocole. Pas un namespace différent par interface.
IBM implémente cela via Cluster Export Services (CES), qui expose l'accès S3, NFS et SMB sur les mêmes données du système de fichiers parallèle.
Métadonnées : quand vous avez des millions de petits fichiers
Le RAG enterprise, ce n'est pas « trois PDFs dans un bucket ». Ce sont des millions de documents, millions de chunks, millions d'embeddings, fichiers de configuration, index auxiliaires, shards, logs. Des opérations intensives sur de grands répertoires avec beaucoup de petits fichiers. Storage Scale résout ce problème dans les environnements HPC depuis des décennies — Summit, Sierra et d'autres supercalculateurs tournaient sur GPFS. CephFS peut gérer ça, mais d'après notre expérience, il faut beaucoup plus de travail de conception pour éviter les problèmes de performance.
Où Ceph gagne pour le stockage IA
Stockage objet massif : du vrai S3, pas du S3 en option
Ceph est né comme stockage distribué pour objets, blocs et fichiers. Son RGW (RADOS Gateway) fournit une API S3 complète, avec lifecycle policies, versioning, multi-tenancy, IAM — tout ce qu'il faut pour un object store sérieux. Ce n'est pas un accessoire. C'est le cœur du produit.
Si votre pipeline d'inférence est S3-natif — les modèles téléchargés depuis un bucket, les datasets lus par API, les résultats écrits comme objets — Ceph fait très bien le travail. Un cluster Ceph bien conçu scale horizontalement à des centaines de Po en ajoutant des nœuds commodity.
Coût par To : Ceph l'emporte nettement
Soyons directs : Storage Scale coûte plus cher. Il faut des licences IBM, du matériel avec des exigences spécifiques, et des gens qui savent l'opérer (il n'y en a pas beaucoup). Ceph tourne sur du matériel commodity, n'a pas de coût de licence logicielle, et une équipe avec une solide expérience Linux peut l'opérer.
Pour un client avec des pétaoctets de données dont la majorité sont « froides » — datasets d'entraînement, archives historiques, sauvegardes de modèles — ça n'a pas de sens de payer Storage Scale pour des To lus une fois par mois. Ceph avec un erasure coding bien configuré est la bonne réponse.
Kubernetes : Rook rend tout trivial
Pour les équipes qui vivent dans Kubernetes ou OpenShift, Ceph avec Rook est difficile à battre. Un opérateur qui donne RBD (ReadWriteOnce), CephFS (ReadWriteMany) et RGW (S3) depuis un seul cluster. OpenShift Data Foundation (ODF) est littéralement Ceph packagé par Red Hat.
Storage Scale a aussi CSI, mais Rook/Ceph est dans l'écosystème Kubernetes depuis plus longtemps et la communauté est bien plus large. Si votre équipe pense en opérateurs, en Helm charts et en GitOps, Ceph parle leur langue.
Stockage bloc pour VMs et bases de données
Si en plus de l'inférence vous faites tourner OpenStack, de la virtualisation ou avez besoin de volumes bloc pour des bases de données, le RBD de Ceph est ce qu'il y a de mieux. Storage Scale ne joue pas ici — ce n'est pas son terrain.
Le CERN exploite plus de 60 Po sur Ceph en production, comme socle de son infrastructure OpenStack. Ils sont passés de quelques Po à l'échelle exabyte en une décennie, en ajoutant des nœuds sans rupture architecturale.
Ce que chacun fait mal — et que personne ne veut dire
C'est là que la plupart des articles restent vagues. Pas nous. Nous déployons les deux, et les deux ont des choses qui ne nous plaisent pas.
Ce qui ne nous plaît pas dans Storage Scale
- C'est cher. Licences IBM, matériel avec des exigences spécifiques, et un rack avec Storage Scale ECE + GPUs représente un investissement conséquent. Pour un pilote IA ou une startup, ça n'a pas de sens.
- L'exploitation demande un profil HPC. Ce n'est pas que ce soit difficile — c'est un monde différent du cloud-native. Si votre équipe vit dans Kubernetes et n'a jamais touché un système de fichiers parallèle, la courbe d'apprentissage est réelle.
- S3 n'est pas son point fort. Storage Scale propose l'accès S3 via CES, et ça marche. Mais comparé au RGW de Ceph sur les fonctionnalités S3 pures — lifecycle, multi-tenancy, versioning avancé — Ceph a l'avantage.
- Stockage bloc : quasi inexistant. Si vous avez besoin de RBD ou de volumes bloc pour des VMs, Storage Scale n'est pas votre outil.
Ce qui ne nous plaît pas dans Ceph
- CephFS n'est pas GPFS. CephFS fonctionne, mais pour de nombreux clients concurrents faisant de l'I/O parallèle sur des millions de fichiers (le pattern classique IA/HPC), Storage Scale a considérablement plus d'expérience.
- Le cache local ajoute de la complexité. Si vos modèles vivent dans S3, chaque nœud d'inférence télécharge sa copie. Avec 4 nœuds, c'est trivial. Avec 32, vous entretenez des scripts de synchronisation, contrôlez les versions du cache, et espérez que les disques locaux ne se remplissent pas.
- Le multi-protocole n'est pas propre. Ceph parle RGW (S3), RBD (bloc), CephFS (fichier) et NFS (via Ganesha). Mais chaque protocole opère sur son propre pool ou namespace. Vous ne pouvez pas lire le même fichier en S3 et en NFS de façon transparente comme avec Storage Scale.
- Métadonnées sous pression. Des opérations intensives sur des répertoires avec des millions de petits fichiers (le cas RAG) peuvent devenir un goulot d'étranglement dans CephFS si la conception n'est pas bonne.
Monter s3fs ou goofys pour donner une sémantique POSIX à Ceph S3 et pouvoir utiliser from_pretrained() directement. Techniquement ça marche. En production, la sémantique POSIX est partielle, les performances sont imprévisibles et les erreurs sont créatives. Nous ne le recommandons pas comme solution permanente.
Storage Scale vs Ceph pour le stockage IA : résumé
En résumé : Storage Scale gagne quand les données sont « vivantes » — beaucoup de processus lisant des modèles partagés, des pipelines POSIX, des environnements mixtes où Kubernetes coexiste avec des applications legacy. Ceph gagne quand les données sont des objets — S3 comme interface principale, modèles mis en cache localement, équipes cloud-native, budget serré.
Utiliser Storage Scale comme un object store bon marché, c'est jeter de l'argent. Essayer de faire de CephFS un système de fichiers parallèle HPC, c'est chercher les ennuis. Chacun est très bon dans ce qu'il fait.
Ce que nous dirions à un client qui nous pose la question aujourd'hui
Si on nous pousse dans nos retranchements : pour l'inférence IA en environnement enterprise avec des données partagées et du RAG, Storage Scale pose moins de problèmes. Les modèles sont vivants, partagés, accessibles par le protocole dont chaque consommateur a besoin. Pas de scripts de synchronisation, pas de prières sur le cache.
Mais si votre pattern est vraiment cloud-native — pods stateless, S3 comme source de vérité, une équipe SRE qui sait exploiter Ceph — alors Ceph est la bonne réponse et vous coûtera considérablement moins cher. On ne le dit pas pour être polis : on l'a vu fonctionner comme ça en production de nombreuses fois.
Et si votre environnement traite des données sensibles sur IBM Power, s'intègre avec DB2 ou Oracle, et que l'inférence va cohabiter avec des charges HPC ou analytics — Storage Scale n'a pas de rival réel. C'est son terrain naturel. Storage Scale combiné avec Content-Aware Storage dans IBM Fusion commence à transformer le stockage en moteur actif de préparation de données pour le RAG.
Ça dépend. Parlez-nous de votre cas et on vous dit lequel.
Nous exploitons les deux en production. Décrivez votre charge de travail et nous vous orienterons.
