Storage Scale vs Ceph para inferencia IA: cuál elegir
Storage Scale vs Ceph para inferencia IA: cuál elegir.
Implementamos los dos. Llevamos años con ambos en producción. Y no, la respuesta no es «usa los dos»: es entender qué hace bien cada uno, en qué fallan, y cuál encaja en tu caso.
Últimamente nos llega la misma pregunta con distintos disfraces: «¿Storage Scale o Ceph para inferencia IA?»
Somos IBM Business Partner. Vendemos Storage Scale. También damos formación en Ceph y hacemos consultoría de Ceph en producción. Así que cuando decimos «este es mejor para tu caso», es porque realmente analizamos y sabemos qué puede funcionar para cada cliente.
Esto es lo que le contamos a un cliente cuando se sienta con nosotros a diseñar la arquitectura de almacenamiento para inferencia IA.
Antes de elegir: qué le pide la inferencia al almacenamiento
Mucha gente empieza por el producto. Nosotros empezamos por el patrón de acceso, porque es lo que determina si la elección funciona o te da dolor de cabeza durante años.
Un entorno de inferencia de verdad — no un Llama corriendo en un portátil — tiene esta pinta:
Y esos datos los consume un zoo de procesos: nodos GPU con vLLM o TGI, nodos CPU, Spark o Ray preprocesando, pipelines de Docling y OCR, la base vectorial, aplicaciones legacy que entran por NFS, y alguien de compliance que quiere ver un PDF desde Windows por SMB.
Si tu caso se parece a esto — muchos consumidores, muchos protocolos, datos compartidos — ese patrón es el que tiene que mandar en la decisión. No el precio por TB ni el logo del vendor.
Dónde gana Storage Scale para inferencia IA
POSIX nativo: tus frameworks esperan un directorio, no un bucket
Esto parece obvio hasta que te toca montarlo. Mira cómo cargan modelos las herramientas que vas a usar:
Piden un path. Un directorio. No un endpoint S3. Storage Scale (el antiguo GPFS) es un filesystem paralelo POSIX nativo. Ese /models es un directorio compartido que todos los nodos leen a la vez, con acceso concurrente real, sin copias intermedias. No hay que inventar nada.
Cero copias entre capas: el argumento que más nos convence
Con Ceph S3, el patrón típico para servir un modelo es: descargar del bucket → escribir en disco local o PVC → arrancar el motor de inferencia → servir. Son tres pasos antes de que la primera query entre. Y si tienes 16 nodos, los 16 descargan su copia.
Con Storage Scale, el motor de inferencia apunta a /gpfs/models/llama-70b/ y arranca. Ya está. Sin descarga, sin caché, sin «¿este nodo tiene la última versión del modelo?». Cuando cambias el modelo, lo cambias una vez y todos los nodos lo ven.
Eso se nota especialmente cuando estás iterando — cambiando modelos, probando adapters LoRA, rotando entre configuraciones. Con caché local acabas manteniendo scripts de sincronización, invalidación y limpieza de disco. Con un filesystem paralelo no hay nada que mantener.
Multiprotocolo sobre el mismo fichero
Esto es lo que a los clientes enterprise les resuelve la vida. Un mismo fichero en Storage Scale se puede consumir por POSIX (nodo GPU), por S3 (app moderna), por NFS (equipo de datos), por SMB (alguien en Windows) y por CSI (pod en Kubernetes). El mismo fichero. No una copia por protocolo. No un namespace diferente por interfaz.
IBM lo implementa a través de Cluster Export Services (CES), que expone acceso S3, NFS y SMB sobre el mismo dato del filesystem paralelo.
En un entorno donde conviven contenedores modernos con aplicaciones legacy que no sabes ni quién mantiene, esto es lo que te permite montar una factoría de IA sin romper lo que ya funciona.
Metadata: cuando tienes millones de ficheros pequeños
RAG enterprise no es «tres PDFs en un bucket». Son millones de documentos, millones de chunks, millones de embeddings, ficheros de configuración, índices auxiliares, shards, logs. Operaciones intensivas sobre directorios grandes con muchos ficheros pequeños. Storage Scale lleva décadas resolviendo esto en entornos HPC — Summit, Sierra y otros supercomputadores corrían sobre GPFS. CephFS puede funcionar para esto, pero en nuestra experiencia hay que afinar bastante más el diseño para que no sufra.
Dónde gana Ceph para inferencia IA
Object storage masivo: S3 de verdad, no S3 como feature
Ceph nació como almacenamiento distribuido para objetos, bloques y ficheros. Su RGW (RADOS Gateway) ofrece una API S3 completa, con lifecycle policies, versioning, multitenancy, IAM — todo lo que necesitas para operar un object store serio. No es un add-on. Es su razón de ser.
Si tu pipeline de inferencia es S3-native — los modelos se descargan de un bucket, los datasets se leen por API, los resultados se escriben como objetos — Ceph va como un tiro. Un cluster Ceph bien diseñado escala horizontalmente a cientos de PB añadiendo nodos commodity.
Coste por TB: aquí Ceph arrasa
Seamos directos: Storage Scale cuesta más. Necesita licencias IBM, hardware con ciertos requisitos, y gente que sepa operarlo (no abunda). Ceph corre en hardware commodity, no tiene coste de licencias de software, y un equipo con experiencia en Linux puede operarlo.
Para un cliente con petabytes de datos donde la mayoría son «fríos» — datasets de entrenamiento, archivos históricos, backups de modelos — no tiene sentido pagar Storage Scale por TB que se leen una vez al mes. Ceph con erasure coding bien configurado es la respuesta correcta ahí.
Kubernetes: Rook lo hace todo trivial
Para equipos que viven en Kubernetes u OpenShift, Ceph con Rook es difícil de superar. Un operador que te da RBD (ReadWriteOnce), CephFS (ReadWriteMany) y RGW (S3) desde un solo clúster. OpenShift Data Foundation (ODF) es literalmente Ceph empaquetado por Red Hat — lo contamos en detalle en nuestra guía Ceph vs MinIO 2026.
Storage Scale también tiene CSI, pero Rook/Ceph lleva más tiempo en el ecosistema Kubernetes y la comunidad es mucho más grande. Si tu equipo piensa en operadores, en Helm charts y en GitOps, Ceph es su idioma.
Block storage para VMs y bases de datos
Si además de inferencia tienes OpenStack, virtualización o necesitas volúmenes de bloque para bases de datos, el RBD de Ceph es de lo mejor que hay. Storage Scale no compite aquí — no es su territorio.
El CERN opera más de 60 PB en Ceph en producción, vertebrando su infraestructura OpenStack. Ha pasado de unos pocos PB a escala exabyte en una década, añadiendo nodos sin saltos arquitectónicos. Lo contamos con más detalle en nuestro artículo sobre almacenamiento open source para IA y HPC.
En lo que falla cada uno — y nadie te quiere contar
Aquí es donde la mayoría de artículos se ponen tibios. Nosotros no. Implementamos los dos, y los dos tienen cosas que no nos gustan.
Lo que no nos gusta de Storage Scale
- Es caro. Licencias IBM, hardware con requisitos específicos, y un rack con Storage Scale ECE + GPUs no baja de una inversión considerable. Para un piloto de IA o una startup, no tiene sentido.
- Operarlo exige un perfil HPC. No es que sea difícil — es que es un mundo diferente al cloud-native. Si tu equipo vive en Kubernetes y nunca ha tocado un filesystem paralelo, la curva de aprendizaje es real.
- S3 no es su punto fuerte. Storage Scale tiene acceso S3 vía CES, y funciona. Pero si lo comparas con RGW de Ceph en features S3 puras — lifecycle, multitenancy, versioning avanzado — Ceph le saca ventaja.
- Block storage: prácticamente no existe. Si necesitas RBD o volúmenes de bloque para VMs, Storage Scale no es tu herramienta.
Lo que no nos gusta de Ceph
- CephFS no es GPFS. CephFS funciona, pero para muchos clientes concurrentes haciendo I/O paralelo sobre millones de ficheros (el patrón clásico de IA/HPC), Storage Scale tiene bastante más rodaje. Lo explicamos en nuestra comparativa de 2023.
- El patrón de caché local añade complejidad. Si tus modelos viven en S3, cada nodo de inferencia descarga su copia. Con 4 nodos es trivial. Con 32, estás manteniendo scripts de sincronización, controlando versiones de caché, y rezando para que no se llene el disco local.
- Multiprotocolo no es limpio. Ceph habla RGW (S3), RBD (bloque), CephFS (fichero) y NFS (vía Ganesha). Pero cada protocolo opera sobre su pool o namespace. No puedes leer el mismo fichero por S3 y por NFS a la vez de forma transparente como en Storage Scale.
- Metadata bajo presión. Operaciones intensivas sobre directorios con millones de ficheros pequeños (el caso RAG) pueden ser un cuello de botella en CephFS si no se diseña bien. Ceph no se improvisa.
Montar s3fs o goofys para darle POSIX a Ceph S3 y poder usar from_pretrained() directamente. Técnicamente funciona. En producción, la semántica POSIX es parcial, el rendimiento es impredecible y los errores son creativos. No lo recomendamos como solución permanente.
Storage Scale vs Ceph para almacenamiento de inferencia IA: resumen
En crudo: Storage Scale gana cuando los datos están «vivos» — muchos procesos leyendo modelos compartidos, pipelines POSIX, entornos mixtos donde coexisten Kubernetes y aplicaciones legacy. Ceph gana cuando los datos son objetos — S3 como interfaz principal, modelos que se cachean en local, equipos cloud-native, presupuesto ajustado.
Intentar usar Storage Scale como object store barato es tirar dinero. Intentar que CephFS se comporte como un filesystem paralelo HPC es buscar problemas. Cada uno es muy bueno en lo suyo.
Lo que le diríamos a un cliente que nos preguntase hoy
Si nos pones contra la pared: para inferencia IA en entornos enterprise con datos compartidos y RAG, Storage Scale da menos quebraderos de cabeza. Los modelos están vivos, compartidos, accesibles por el protocolo que necesite cada consumidor. No hay que mantener scripts de sincronización ni cruzar los dedos con la caché.
Pero si tu patrón es cloud-native de verdad — pods stateless, S3 como fuente de verdad, equipo SRE que sabe operar Ceph — entonces Ceph es la respuesta correcta y te va a costar bastante menos. No lo decimos por quedar bien: lo hemos visto funcionar así en producción muchas veces.
Y si tu entorno tiene datos sensibles en IBM Power, integración con DB2 u Oracle, y la inferencia va a convivir con cargas HPC o analytics — ahí Storage Scale no tiene rival real. Es su terreno natural. Lo contamos con más detalle en el contexto de IBM Fusion y las GPUs NVIDIA Blackwell, donde Storage Scale + Content-Aware Storage empieza a convertir el almacenamiento en un motor activo de preparación de datos para RAG.
Depende. Cuéntanoslo y te decimos.
Implementamos los dos en producción. Te ayudamos a elegir el que encaja en tu caso, no el que nos da más margen.
