Almacenamiento on lo0 — Blog Técnico

Almacenamiento en la era de la IA (1/4): el estado del arte

Mon, 22 Jun 2026 12:00:00 +0200

La conversación pública sobre infraestructura de IA gira casi siempre alrededor de la GPU: cuántos FLOPs, cuánta HBM, cuántos vatios. Pero quien diseña o explota un AI factory sabe que el cuello de botella se ha desplazado. Una GPU Blackwell que se queda esperando datos cuesta lo mismo que una GPU Blackwell trabajando; la diferencia la marca el subsistema que la alimenta. Este primer artículo de la serie traza el estado del arte del almacenamiento para IA a mediados de 2026: la jerarquía de memoria y almacenamiento, las tecnologías de medio (NAND, NVMe, CXL), los sistemas de archivos paralelos que dominan los clústeres GPU y la nueva pila de inferencia que ha convertido al SSD en un componente de la jerarquía de memoria.

Los tres artículos siguientes profundizan en las tres propiedades que importan a un arquitecto cuando ese almacenamiento entra en producción: el rendimiento, la seguridad y la disponibilidad.

El problema de fondo: el muro de la memoria

Una GPU moderna es, ante todo, una máquina de mover datos. El cómputo en sí mismo casi nunca es el límite: lo es el ancho de banda con el que se alimentan las unidades funcionales. La jerarquía que va desde los registros de la GPU hasta el NVMe abarca seis órdenes de magnitud de latencia y varios de ancho de banda. Los registros son del orden de un millón de veces más rápidos que un acceso a NVMe, y entre medias se apilan la SRAM on-chip, la HBM, la DRAM del host y, finalmente, el almacenamiento persistente.

La consecuencia práctica es bien conocida: en muchas cargas de entrenamiento las GPU operan a un 30-50 % de su utilización teórica de FLOPs porque pasan una fracción significativa del tiempo esperando datos. Es el llamado memory wall. Su formulación cuantitativa más útil es la intensidad aritmética, el cociente entre operaciones y bytes movidos:

$$I = \frac{\text{FLOPs}}{\text{bytes}}$$

Cuando la intensidad de una carga cae por debajo del punto de equilibrio del hardware (el ridge point del modelo roofline), el rendimiento queda limitado por el ancho de banda y no por el cómputo. La carrera de la industria por la HBM, por el NVLink y, en la capa que nos ocupa, por NVMe de 28 GB/s y redes de 800 Gb/s, es en el fondo una guerra contra ese muro.

El problema se agrava porque el cómputo ha crecido mucho más rápido que el ancho de banda de memoria. Cada generación de GPU multiplica los FLOPs con más holgura que los TB/s de memoria que los alimentan, de modo que el ridge point se desplaza hacia intensidades aritméticas cada vez mayores: más cargas caen del lado limitado por ancho de banda. Esta es la razón estructural por la que el almacenamiento y la memoria han pasado a primer plano. No es que el almacenamiento haya mejorado menos —ha mejorado muchísimo—, sino que la GPU le exige cada vez más. Un arquitecto que diseñe pensando solo en FLOPs construirá sistemas que pasan la mitad del tiempo esperando.

Conviene tener presente toda la pirámide cuando hablamos de “almacenamiento” en IA, porque las decisiones de diseño en un nivel condicionan los demás:

Nivel	Tecnología	Ancho de banda típico	Latencia	Capacidad por dispositivo
On-package	HBM3e / HBM4	1,2-3,3 TB/s por stack	ns	36-64 GB
Memoria host	DDR5 / CXL	0,3-0,5 TB/s	~100 ns	TB
Flash caliente	NVMe Gen5/Gen6	14-28 GB/s	10-100 µs	4-256 TB
Capacidad	QLC nearline / HDD	1-7 GB/s	ms	30-245 TB
Archivo	Objeto / cinta	variable	s	EB (agregado)

El estado del arte de 2026 consiste, en buena medida, en cómo se difumina la frontera entre estos niveles: la HBM se desborda hacia la DRAM, la DRAM hacia CXL, y el KV-cache de inferencia hacia el NVMe. El almacenamiento ha dejado de ser el sótano de la jerarquía para integrarse en ella.

HBM4: el techo se eleva, pero sigue siendo caro

En la cúspide, la memoria de alto ancho de banda apilada junto a la GPU. En abril de 2025 JEDEC publicó el estándar HBM4 (JESD270-4), que duplica la interfaz a 2048 bits por stack frente a los 1024 bits de HBM3e, alcanza hasta 8 Gb/s por pin y se sitúa alrededor de 2 TB/s típicos con picos de hasta 3,3 TB/s por stack. Admite configuraciones de 4 a 16 capas con dies de 24 o 32 Gb, hasta 64 GB por cubo. HBM3e, la generación que domina los aceleradores en producción a mediados de 2026, ronda 1,2 TB/s y un máximo de 36 GB.

El dato relevante para un arquitecto no es el pico de ancho de banda, sino la escasez. Micron tiene prácticamente vendida toda su producción de HBM hasta 2026, y la expansión de capacidad no se espera antes de finales de 2027-2028. Esa restricción es la que empuja la carga hacia abajo en la jerarquía: si no puedes ampliar la HBM, tienes que aprender a desbordar con elegancia hacia DRAM, CXL y flash. De ahí gran parte de la innovación reciente.

NAND y SSD: la capacidad explota, la interfaz se ensancha

La capa de flash es donde más se nota la presión de la IA sobre el mercado. Dos vectores simultáneos: capacidad e interfaz.

En capacidad, 2025-2026 ha sido el año de la carrera por los 245 TB. El Solidigm D5-P5336 alcanzó los 122 TB (PCIe 4.0) y se convirtió en la SSD de mayor capacidad disponible, a la venta por unos 12.400 USD; Solidigm ha confirmado modelos de 245 TB o más para finales de 2026. Micron presentó el 6600 ION con 245 TB en formato E3.L. Para mediados de 2026 ya hay al menos ocho SSD de 245 TB anunciadas por SanDisk, Samsung, Kioxia, Micron, SK hynix y otros, todas tirando de NAND QLC de alta densidad —SK hynix produce ya QLC de 321 capas— para saciar la demanda de los hyperscalers. El QLC enterprise se está consolidando como sustituto del HDD nearline, cuya oferta va muy por detrás de la demanda y cuyos lead times se han alargado.

El QLC merece un matiz que a veces se olvida en el entusiasmo por la capacidad: la resistencia a escritura (endurance). La NAND QLC almacena cuatro bits por celda, lo que multiplica la densidad pero reduce el número de ciclos de borrado que soporta frente a TLC. Para datasets de IA que se escriben una vez y se leen muchas —el caso típico del training set— esto es irrelevante y el QLC es la opción correcta. Para cargas con escritura intensiva y constante —ciertos checkpoints, KV-cache muy rotativo— hay que vigilar el desgaste y, a menudo, reservar TLC. Conocer el patrón de escritura de cada carga es lo que permite asignar el medio adecuado sin pagar de más ni desgastar de menos.

En interfaz, PCIe Gen6 ha entrado en producción de datacenter. El Micron 9650 fue la primera SSD PCIe Gen6 de datacenter en producción en masa (febrero de 2026), con un throughput de 28 GB/s, aproximadamente el doble de Gen5. Los controladores acompañan: el Silicon Motion SM8466 anuncia 28 GB/s secuenciales y 7 millones de IOPS aleatorias; el Gen6 de FADU (“Lhotse”) apunta a 28,5 GB/s de lectura, 6,9 millones de IOPS, NVMe 2.2 y SR-IOV nativo con 128 funciones virtuales. La ruta de adopción es nítida: Gen6 llega primero a IA, HPC y datacenter, y solo después —si llega— al PC de consumo.

Sobre la red, NVMe-oF se reparte entre dos mundos. NVMe/TCP lidera los despliegues greenfield array-a-host por su simplicidad operativa, con latencias de 100-200 µs. NVMe sobre RDMA (RoCEv2, iWARP) sigue siendo el patrón oro de baja latencia (10-20 µs) cuando ya existe una fabric sin pérdidas, como las que despliegan los clústeres de IA. Ethernet a 25-100 Gb/s erosiona de forma sostenida la cuota de Fibre Channel en el tráfico de almacenamiento.

La elección entre TCP y RDMA no es una preferencia estética. NVMe/TCP corre sobre cualquier red Ethernet existente y simplifica enormemente la operación, a costa de una latencia mayor y de un consumo de CPU en el host que, en cargas intensas, compite con el cómputo. NVMe/RoCE exige una fabric sin pérdidas —con control de flujo por prioridad y congestion control bien afinados— y NICs capaces, pero entrega la latencia que las cargas de IA latency-sensitive necesitan, y descarga el procesamiento de la NIC. En un clúster de IA que ya despliega InfiniBand o RoCE para el tráfico GPU-a-GPU, reutilizar esa fabric para el almacenamiento es la decisión natural; en una infraestructura empresarial mixta, NVMe/TCP suele ganar por operatividad.

CXL: del PowerPoint a la producción

Compute Express Link llevaba años siendo la promesa eterna. A comienzos de 2026 ha alcanzado por fin adopción mainstream en plataformas de producción con CXL 3.0/3.1, alineado con PCIe 6.1. El soporte de hardware está ahí: Intel Xeon 6 (Granite Rapids y posteriores) incorpora CXL 3.0 nativo en CPU, y AMD EPYC Turin es plataforma objetivo. Los switches de pooling multi-host CXL 3.0 ya operan en algunos proveedores de colocation.

El caso de uso que ha pasado de la teoría a los números es el tiering de memoria: mantener los datos calientes en la HBM de la GPU y empujar los fríos a un pool de DRAM CXL compartido. Proveedores de la cadena (Astera Labs, MemVerge, XConn) reportan mejoras notables al descargar el KV-cache de inferencia a memoria CXL frente a soluciones basadas en SSD o RDMA. Conviene tomar las cifras concretas con cautela —proceden en buena parte de los propios fabricantes— pero la dirección es real: CXL se ha convertido en una capa de memoria desagregada utilizable, no en un experimento de laboratorio. El soporte de tiering en el kernel de Linux (6.1 en adelante) madura, aunque sacarle partido sigue exigiendo aplicaciones conscientes de NUMA.

Sistemas de archivos paralelos: el campo de batalla de las GPU

Si la capa de medio es donde compiten los fabricantes de silicio, la capa de sistema de archivos paralelo es donde compiten los fabricantes de plataforma, y es la que un arquitecto de IA toca a diario. El mercado se ha reordenado en pocos años.

WEKA ha sido probablemente el caso más comentado. Su sistema (WekaFS, hoy reempaquetado como NeuralMesh) evita el kernel de Linux ejecutándose como un RTOS en espacio de usuario, usa RDMA en lugar de TCP/IP y distribuye los metadatos mediante hashing consistente. Las cifras publicadas hablan de latencias de 100-200 µs frente a más de 1000 µs de las pilas tradicionales y un rendimiento de metadatos que duplica al de Lustre. En 2026 ha lanzado su NeuralMesh AI Data Platform sobre el diseño de referencia de NVIDIA, con un “Augmented Memory Grid” pensado para la memoria de contexto de la IA agéntica.

VAST Data ha apostado por una arquitectura distinta, DASE (Disaggregated Shared-Everything), un único tier all-flash sobre el que ha construido lo que llama un “AI OS”: una pila con base de datos, motor de datos, InsightEngine para pipelines de IA en tiempo real, búsqueda vectorial y RAG, y gobernanza integrada. Azure ha incorporado su sistema, señal de la tracción que ha conseguido.

Lustre (DDN) sigue siendo el sistema de archivos más extendido en supercomputación clásica, pero está siendo erosionado en la arena GPU por VAST y WEKA. DAOS brilla en el top end de HPC tradicional pero apenas aparece en clústeres de IA comercial. IBM Storage Scale (la antigua Spectrum Scale/GPFS) se ha reposicionado con Content Awareness para RAG y soporte para la plataforma de datos de NVIDIA, acompañado de una renovación de la gama FlashSystem.

El denominador común de toda esta generación es el alineamiento con NVIDIA. Las plataformas se certifican contra DGX SuperPOD y se integran con GPUDirect Storage, que permite DMA directo entre el almacenamiento y la memoria de la GPU saltándose la CPU y el bounce buffer. En las arquitecturas GB200 NVL72 —un rack refrigerado por líquido que presenta 72 GPU como una sola GPU gigante a través de NVLink, con 13,4 TB de memoria GPU unificada— la certificación de GPUDirect Storage deja de ser un adorno y se convierte en requisito.

Para situar a los principales actores frente a frente, conviene resumir sus apuestas arquitectónicas, que son genuinamente distintas y no meras variaciones de un mismo diseño:

Plataforma	Arquitectura	Rasgo diferencial	Encaje en IA
WEKA NeuralMesh	RTOS en espacio de usuario, RDMA	Latencia muy baja, metadatos distribuidos por hashing	Entrenamiento e inferencia agéntica, memoria de contexto
VAST DataStore	DASE all-flash desagregado	Namespace único multiprotocolo a exabyte, AI OS	Lakehouse + RAG + inferencia
IBM Storage Scale	Paralelo (ex-GPFS)	Content Awareness para RAG, madurez HPC	Empresa y HPC con datos no estructurados
DDN EXAScaler/Lustre	Lustre endurecido	Throughput bruto por rack, despliegues masivos	Supercomputación y AI factories
Pure Storage	All-flash con Purity	Operación Evergreen, simplicidad	Empresa que prioriza operativa sobre pico

La elección entre ellas rara vez se decide por el pico de GB/s, sino por el patrón de carga (entrenamiento secuencial frente a inferencia aleatoria), por el modelo operativo y por el grado de integración exigido con la pila de NVIDIA. Un arquitecto sensato evalúa primero su mezcla de cargas y solo después compara cifras.

Del rack como unidad de cómputo: GB200, Rubin y BlueField-4

El cambio de granularidad merece detenerse. Durante décadas la unidad de diseño fue el servidor; hoy, en IA, es el rack. El GB200 NVL72 integra 72 GPU Blackwell y 36 CPU Grace en un único dominio NVLink de 130 TB/s, presentado al software como una sola GPU lógica con 13,4 TB de memoria unificada y capaz de hasta 30 veces la inferencia de un LLM de billón de parámetros en tiempo real frente a la generación anterior. A esa escala, el almacenamiento no compite con el ancho de banda interno —no podría—, pero sí debe alimentar la carga de modelos y el KV-cache de inferencia (y, en su caso, el checkpointing de entrenamiento) sin estrangular a las 72 GPU que se comportan como una.

La hoja de ruta acentúa la tendencia. La generación Rubin y, en particular, la Rubin CPX —una GPU especializada en inferencia de contexto largo, con más de un millón de tokens— empujan aún más datos hacia las capas de memoria y almacenamiento. Y la pieza que cose todo esto es la DPU: la BlueField-4 de NVIDIA habilita una plataforma de “Inference Context Memory Storage” que convierte el KV-cache en un recurso flash compartido a nivel de pod, conectado por Spectrum-X Ethernet. La DPU descarga de la CPU el movimiento de datos de almacenamiento y seguridad, y se está convirtiendo en el verdadero controlador de almacenamiento del nodo de IA. Para el arquitecto, esto significa que el diseño de almacenamiento ya no termina en la cabina: incluye la NIC, la DPU y la fabric.

La pila de inferencia: cuando el SSD entra en la jerarquía de memoria

El cambio conceptual más importante de los últimos dos años, y el que mejor resume el estado del arte, es este: el almacenamiento flash ha pasado a formar parte de la jerarquía de memoria de inferencia. La causa son las ventanas de contexto. A medida que los modelos manejan cientos de miles —o millones— de tokens, el KV-cache que genera la fase de prefill desborda la HBM. Ese KV-cache desbordado baja primero a la DRAM del host y luego al SSD NVMe.

NVIDIA ha estandarizado este patrón. Su capa de orquestación Dynamo opera a lo largo de toda la jerarquía HBM → DRAM de CPU → NVMe → almacenamiento en red, con un motor de offload de KV-cache y una librería de transferencia (NIXL) para compartir caché entre nodos. En enero de 2026 estandarizó el offload del KV-cache a SSD NVMe, y ha presentado una plataforma de “Inference Context Memory Storage” basada en DPUs BlueField-4 que convierte el KV-cache en un recurso compartido de alto ancho de banda a nivel de pod. Solidigm y otros fabricantes de SSD han alineado su mensaje en torno a esta idea: la inferencia de contexto largo es, en parte, un problema de almacenamiento flash.

Las consecuencias de diseño son concretas. Un servidor de inferencia de 2026 lleva entre 8 y 32 SSD —se espera que la cifra crezca a 32 en un par de años— con patrón de acceso aleatorio, frente al patrón secuencial y la decena de discos de un servidor de entrenamiento. La proporción de servidores de inferencia frente a entrenamiento puede llegar a 50 a 1. El centro de gravedad de la inversión en almacenamiento se está desplazando hacia la inferencia.

Anatomía del almacenamiento de una factoría de inferencia

Conviene detenerse aquí, porque una factoría de IA de inferencia —un sistema diseñado para servir modelos en producción, no para entrenarlos— tiene un perfil de almacenamiento propio, distinto del clúster de entrenamiento que domina la literatura. Mientras el entrenamiento es un trabajo por lotes que tolera paradas y se mide en semanas, la inferencia es un servicio continuo, sensible a la latencia y sometido a un SLA: cada milisegundo y cada fallo se notan en el cliente. Su almacenamiento se organiza en cuatro planos que conviene diseñar por separado.

El primer plano es el repositorio de modelos (model registry). Los pesos de los modelos que se sirven —que pueden ser decenas, con versiones, variantes cuantizadas y adapters LoRA— residen en almacenamiento de objetos o en un sistema de archivos compartido, y se cargan en la HBM de la GPU cuando un modelo se activa. El requisito crítico aquí no es el throughput sostenido sino el tiempo de carga: cuando hay que arrancar una réplica nueva o cambiar de modelo en una GPU, leer decenas o cientos de GB de pesos determina el cold start. Un repositorio lento se traduce en autoescalado perezoso y en GPU que tardan en entrar en servicio, justo cuando sube la demanda.

El segundo plano es la jerarquía de KV-cache, el corazón del rendimiento de inferencia moderno. Como vimos, el KV-cache desborda la HBM y baja a DRAM, CXL y NVMe. En una factoría de inferencia este no es un detalle marginal: es una capa de almacenamiento de primera clase, con su propio dimensionamiento, su patrón de acceso aleatorio y latencia crítica, y una vida útil de segundos. La estandarización por NVIDIA del offload de KV-cache a SSD NVMe y la plataforma ICMS sobre BlueField-4 existen precisamente para esto: permitir contextos largos y reutilización de caché entre peticiones (y entre nodos) sin pagar el precio de recomputar o de ampliar la HBM, que es escasa y cara.

El tercer plano es el almacén de conocimiento para RAG: las bases de datos vectoriales (Milvus, Weaviate, Pinecone, o S3 Vectors) y los documentos fuente que el sistema recupera para enriquecer las respuestas. Aquí el patrón es de lectura intensiva, con búsquedas de similitud sobre índices que pueden ocupar TB y que conviene mantener en flash de baja latencia. La disponibilidad y la frescura de este almacén determinan la calidad de las respuestas tanto como el propio modelo, y su actualización —reindexar, incorporar documentos nuevos— es un flujo de escritura constante que el diseño debe contemplar.

El cuarto plano es el de observabilidad y registro: las trazas, los logs de peticiones y respuestas, las métricas y, cuando la regulación lo exige, el archivo auditable de las interacciones. Es un flujo de escritura append-only de gran volumen que suele acabar en objeto, y que un diseño centrado solo en GPU tiende a olvidar hasta que satura algo.

La conclusión para quien construye una factoría de inferencia es que su almacenamiento no se parece al de un clúster de entrenamiento reescalado. Se dimensiona por tiempo de carga de modelos, por capacidad y latencia de KV-cache, por rendimiento de búsqueda vectorial y por volumen de telemetría, con un imperativo transversal de servicio continuo bajo SLA. El entrenamiento, si existe, es el invitado ocasional; la inferencia es el residente permanente.

El otro extremo: objeto, lakehouse y vectores

No todo es flash caliente. La base de datos de entrenamiento y el sistema de registro viven en almacenamiento de objetos. La novedad de 2025-2026 es la convergencia con formatos de tabla abiertos: Apache Iceberg, Delta Lake y Hudi aportan transacciones ACID, time travel y evolución de esquema sobre object storage barato. AWS ha lanzado S3 Tables (Iceberg gestionado, con consultas más rápidas) y S3 Vectors (almacenamiento vectorial nativo con ahorros de hasta el 90 % para cargas de IA). Las bases de datos vectoriales —Pinecone, Milvus, Weaviate— se integran con los data lakes para alimentar RAG, y formatos columnares como Parquet, junto con Lance para datos multimodales, se consolidan como el sustrato del lakehouse.

La computación cerca del dato (computational storage) sigue siendo un I+D activo más que un despliegue masivo. Las especificaciones NVMe correspondientes están publicadas desde finales de 2023, con eBPF como entorno de ejecución de funciones descargables, pero su adopción real es todavía marginal. La idea —ejecutar filtrado, descompresión o búsqueda directamente en el dispositivo para no mover el dato hasta la CPU— es seductora para cargas de IA que leen datasets enormes con baja intensidad aritmética, pero el modelo de programación y la falta de estandarización de las herramientas frenan su despliegue. Es una tecnología a vigilar, no aún a desplegar en producción.

El ciclo de vida del dato: el tiering como decisión de arquitectura

Visto todo el panorama, queda claro que ningún dato vive en un solo sitio durante todo su ciclo de vida. Un dataset llega en bruto al data lake de objetos, se transforma y se cataloga en formato de tabla abierta (Iceberg, Delta), se promociona a la capa flash caliente del sistema de archivos paralelo para alimentar el entrenamiento, genera checkpoints que viven días en NVMe, y finalmente —junto con los modelos resultantes— se archiva en objeto frío o cinta. El tiering automático entre estas capas ha pasado de ser una optimización de coste a ser una decisión de arquitectura de primer orden, sobre todo en un contexto de escasez de NAND y HBM.

La regla práctica que emerge es ubicar cada byte en el tier más barato que satisfaga su requisito de latencia y ancho de banda en cada momento, y automatizar las transiciones. El flash caliente (NVMe Gen5/Gen6) absorbe el working set de entrenamiento y el KV-cache de inferencia; el QLC de capacidad sustituye al HDD nearline para datasets que se leen secuencialmente; el objeto es el sistema de registro durable y versionado; y la cinta resurge como archivo activo a escala de exabyte para combatir el coste del flash. Diseñar esas fronteras —y medir cuánto dato cruza cada una— es hoy parte del trabajo del arquitecto de almacenamiento de IA, no del administrador.

El contexto de mercado: una supercrisis de oferta

Nada de esto ocurre en el vacío económico. La demanda de almacenamiento de los servidores de IA es entre 8 y 10 veces la de un servidor tradicional, y crece por encima del 20 % anual, mientras que la oferta global de NAND solo crece un 15-17 %. El resultado, en palabras de varios analistas, es una “supercrisis” de memoria: subidas de precio de contrato de DRAM y NAND de doble dígito alto en 2026, lead times alargados y efectos colaterales sobre smartphones y PCs. Para un arquitecto, esto convierte la eficiencia de capacidad —QLC, compresión, erasure coding, tiering— en una palanca de coste de primer orden, no en un detalle de implementación.

Lo que esto cambia para el arquitecto

Si hubiera que destilar el estado del arte en un puñado de implicaciones prácticas, serían estas. Primero, el almacenamiento se diseña por patrón de carga, no por capacidad: un servidor de entrenamiento y uno de inferencia tienen requisitos opuestos —secuencial frente a aleatorio, pocos discos frente a muchos— y mezclarlos en una misma plantilla es un error común. Segundo, el límite ya no está casi nunca en el medio sino en la cadena completa medio-NVMe-DPU-NIC-fabric-sistema de archivos; optimizar un eslabón con los demás sin tocar no mueve la aguja. Tercero, la escasez de oferta convierte la eficiencia de capacidad —QLC, compresión, erasure coding, tiering— en una palanca de coste comparable a la propia compra de discos. Y cuarto, la frontera entre memoria y almacenamiento se ha disuelto: pensar en “RAM por un lado, disco por otro” ya no describe un sistema de IA moderno, donde la HBM, la DRAM, CXL y el NVMe forman un continuo gestionado por software.

Para llevarse a casa

El estado del arte del almacenamiento para IA en 2026 se resume en una idea: la jerarquía se ha vuelto continua. La HBM se desborda hacia DRAM, la DRAM se desagrega sobre CXL, el KV-cache de inferencia baja hasta el NVMe, y el sistema de archivos paralelo orquesta el todo para que la GPU no espere nunca. Las tecnologías de medio (HBM4, QLC de 245 TB, NVMe Gen6) elevan los techos, pero la escasez de oferta convierte la eficiencia en una restricción de diseño. Y el campo de batalla del software —WEKA, VAST, IBM, DDN— se libra alrededor de una única métrica: mantener alimentadas a las GPU.

Con este mapa sobre la mesa, los tres artículos siguientes entran en el detalle de las propiedades que deciden si una arquitectura de almacenamiento sirve o no en producción.

Ver también

Fuentes

FADU, From Training to Inference: FADU at CFMS 2026 — https://blogs.fadu.io/ai-inference-ssd-data-centers/
Avnet, Riding the AI Supercycle: 2026 Memory & Storage Market — https://www.avnet.com/integrated/resources/article/2026-memory-shortage-ai-supercycle/
JEDEC, JESD270-4 HBM4 Standard — https://www.jedec.org/news/pressreleases/jedec%C2%AE-and-industry-leaders-collaborate-release-jesd270-4-hbm4-standard-advancing
Tom’s Hardware, JEDEC finalizes HBM4 memory standard — https://www.tomshardware.com/pc-components/ram/jedec-finalizes-hbm4-memory-standard-with-major-bandwidth-and-efficiency-upgrades
StorageNewsletter, Micron 9650 PCIe Gen6 data center SSDs in mass production — https://www.storagenewsletter.com/2026/02/19/micron-9650-pcie-gen6-data-center-ssds-in-mass-production/
Tom’s Hardware, Solidigm reveals 122TB SSD — https://www.tomshardware.com/pc-components/ssds/solidigm-reveals-122tb-ssd-the-worlds-highest-capacity-drive-for-ai-workloads-d5-p5336-offers-unlimited-write-durability
TechRadar, Solidigm confirms 245TB SSDs before end of 2026 — https://www.techradar.com/pro/solidigm-confirms-245-tb-ssds-set-to-launch-before-end-of-2026
KAD, CXL in 2026: How Memory Pooling is Reshaping Data Centers — https://www.kad8.com/hardware/cxl-in-2026-how-memory-pooling-is-reshaping-data-centers/
Blocks & Files, Parallel filesystem definitions — https://blocksandfiles.com/2025/11/26/parallel-filesystem-definitions-and-powerscale/
NAND Research, WEKA NeuralMesh AIDP & STX integration — https://nand-research.com/weka-neuralmesh-aidp-stx-integration-gtc-2026/
VAST Data, InsightEngine — https://www.vastdata.com/platform/insightengine
NVIDIA, GB200 NVL72 — https://www.nvidia.com/en-us/data-center/gb200-nvl72/
Blocks & Files, Nvidia standardizes GPU cluster KV cache offload to NVMe SSDs — https://blocksandfiles.com/2026/01/06/nvidia-standardizes-gpu-cluster-kv-cache-offload-to-nvme-ssds/
AWS, Building AI-Ready Data Lakes: S3 Tables, Iceberg, S3 Vectors — https://builder.aws.com/content/34vssNUviyG5WPv3IRiGZFKZYkn/building-ai-ready-data-lakes-amazon-s3-tables-apache-iceberg-and-s3-vectors
TrendForce, AI Server Demand to Drive Memory Contract Price Increases 2Q26 — https://www.trendforce.com/presscenter/news/20260331-12995.html

Almacenamiento en la era de la IA (2/4): rendimiento

Mon, 22 Jun 2026 11:00:00 +0200

En el primer artículo dibujamos el mapa: la jerarquía memoria-almacenamiento, las tecnologías de medio y la pila de software que domina los clústeres GPU. Este segundo artículo entra en la propiedad que justifica toda esa complejidad: el rendimiento. La pregunta que debe responder un arquitecto no es “¿cuántos GB/s da mi cabina?”, sino “¿consigo que mis GPU trabajen al 95 % en lugar de al 40 %?”. Esa diferencia es, literalmente, la mitad de la factura de cómputo.

La métrica que de verdad importa: utilización del acelerador

Es tentador medir el almacenamiento de IA con las métricas clásicas —throughput secuencial, IOPS aleatorias, latencia—, y las necesitamos. Pero ninguna de ellas captura lo que paga el negocio. La métrica integradora es la utilización del acelerador: qué fracción del tiempo la GPU está calculando en lugar de esperando datos.

La mayoría de los pipelines de ML reales corren entre el 30 % y el 60 % de utilización de GPU. Las encuestas del sector son demoledoras: solo en torno al 7 % de los equipos de IA/ML logra superar el 85 % en picos, y una mala previsión o un autoescalado deficiente pueden dejar GPUs ociosas el 70-85 % del tiempo. Un job que corre al 30 % de utilización está pagando el 70 % de su capacidad de cómputo para nada.

Podemos formalizarlo. Si ( t_{\text{cmp}} ) es el tiempo de cómputo por batch y ( t_{\text{io}} ) el tiempo que la GPU pasa bloqueada esperando I/O que no logra solaparse con el cómputo, la utilización efectiva es:

$$U = \frac{t_{\text{cmp}}}{t_{\text{cmp}} + t_{\text{io}}}$$

El objetivo de toda la ingeniería de almacenamiento para IA es llevar ( t_{\text{io}} ) hacia cero, ya sea aumentando el ancho de banda, reduciendo la latencia o solapando la I/O con el cómputo mediante prefetching y pipelining. Y hay un agravante: cuanto más rápida es la GPU, más difícil es alimentarla. El paso de V100 a H100 redujo el tiempo de cómputo por batch del modelo 3D U-Net en un 76 %, convirtiendo una carga que era sensible al ancho de banda en una sensible a la latencia. Cada generación de acelerador sube el listón para el almacenamiento.

Este cambio de régimen —de limitado por ancho de banda a limitado por latencia— tiene una consecuencia de diseño que conviene interiorizar. Cuando una carga está limitada por ancho de banda, la solución es añadir capacidad de transferencia: más NVMe, más lanes, más nodos. Cuando pasa a estar limitada por latencia, esa receta deja de funcionar; lo que importa entonces es el tiempo de respuesta por operación, que se ataca con caché, con prefetching inteligente y con rutas de datos que eliminan saltos (como GPUDirect). Diagnosticar correctamente en cuál de los dos regímenes está cada carga es la primera tarea de cualquier optimización: invertir en ancho de banda una carga limitada por latencia es gastar dinero sin mover la utilización.

MLPerf Storage: el banco de pruebas que sí mide lo correcto

Durante años faltó una forma neutral de comparar plataformas de almacenamiento para IA. MLPerf Storage, de MLCommons, la ha proporcionado. Su acierto de diseño es no medir GB/s en abstracto, sino simular el “think time” de los aceleradores para generar un patrón de I/O realista, y exigir que esos aceleradores simulados mantengan un nivel mínimo de utilización. Es decir, mide exactamente lo que importa: cuántos aceleradores puede mantener alimentados una plataforma sin que su utilización caiga por debajo del umbral.

La v1.0 (septiembre de 2024) usaba los modelos 3D U-Net, ResNet-50 y CosmoFlow, simulando A100 y H100, con umbrales de utilización del 90 % para los dos primeros y del 70 % para CosmoFlow. La v2.0 (agosto de 2025) marcó un salto: más de 200 resultados de 26 organizaciones —Alluxio, DDN, Hammerspace, HPE, IBM, KIOXIA, Micron, Oracle, Samsung, WDC, entre otras—, sistemas capaces de sostener aproximadamente el doble de aceleradores que en v1.0, y, sobre todo, una nueva carga de checkpointing (a la que volveremos).

Algunos resultados de v2.0 sirven para calibrar el estado del arte:

Sistema	Throughput	Aceleradores	Utilización GPU
Volumez	1,079 TB/s	—	92,21 %
Hammerspace (5 nodos)	420,8 GB/s	140	>94,7 %
Hammerspace (3 nodos)	253,1 GB/s	84	>94,7 %
Hammerspace (1 nodo)	85,6 GB/s	28	>94,7 %
Alluxio	24,14 GiB/s	128	99,57 %

El dato de Hammerspace ilustra una propiedad que un arquitecto debe exigir: escalado lineal. De 1 a 5 nodos el throughput crece de 85,6 a 420,8 GB/s manteniendo la utilización por encima del 94,7 % con un coeficiente de variación ínfimo (0,08-0,14 %). El escalado lineal es lo que separa una plataforma de IA de un NAS rápido.

Las cifras de las plataformas comerciales

Fuera del banco de pruebas, las plataformas certificadas para DGX SuperPOD publican cifras agregadas que conviene tener como referencia de orden de magnitud:

WEKA WEKApod Nitro: 720 GB/s de lectura y 186 GB/s de escritura por configuración, 18 millones de IOPS, con NIC ConnectX-8 a 800 Gb/s. Por nodo, 70 GB/s de lectura y 40 GB/s de escritura; la configuración mínima de 8 nodos entrega 560 GB/s de lectura. Un único equipo de entrada cubre la demanda de I/O de una “scalable unit” GB200 de 1.152 GPUs.
DDN AI400X2: más de 90 GB/s y 3 millones de IOPS por appliance; la variante Turbo satura cerca de 100 GB/s (800 Gbps) por DGX B200. La nueva plataforma de DDN declara más de 1 TB/s de lectura por appliance con escalado por rack, y ha alimentado al supercomputador Eos de NVIDIA con 4 TB/s.
VAST Data: múltiples TB/s desde un único mount point vía multipathing NFS, RDMA sobre NFS y GPUDirect, gestionando exabytes en un único espacio de nombres multiprotocolo.
Pure Storage: certificado para DGX SuperPOD con GB200 y GB300.

Estas cifras solo significan algo en relación con el cluster que alimentan. Un GB200 NVL72 mueve 130 TB/s de comunicación interna entre GPU; el almacenamiento no compite con eso, pero sí debe sostener el data loading y el checkpointing sin estrangular a 72 GPU que se comportan como una sola.

El patrón de I/O del entrenamiento y GPUDirect Storage

Entender el patrón de I/O es la clave para no sobredimensionar ni infradimensionar. El entrenamiento combina varios patrones: lecturas grandes y secuenciales del dataset, lecturas pequeñas y aleatorias en el shuffling entre épocas, y escrituras masivas y periódicas en el checkpointing. Cada uno estresa el almacenamiento de forma distinta.

El camino tradicional de datos atraviesa la CPU: del almacenamiento a un bounce buffer en memoria del host y de ahí a la memoria de la GPU. Cada byte de cada checkpoint y de cada carga de pesos paga la latencia y el overhead de CPU de ese doble salto. GPUDirect Storage (GDS) lo corta: habilita DMA directo entre la memoria de la GPU y el NVMe mediante la librería de espacio de usuario cuFile y el módulo de kernel nvidia-fs, que intercepta las llamadas POSIX y las redirige por el motor DMA. El resultado es zero-copy, con transferencias directas que superan los 40 GB/s y, sobre todo, sin robar ciclos a la CPU.

Hay un matiz que los despliegues ingenuos pasan por alto: GDS está optimizado para transferencias grandes, alineadas y secuenciales. Para cargas dominadas por archivos pequeños o acceso muy aleatorio, el camino tradicional con caché en la CPU puede ser más eficiente. GDS no es un interruptor mágico de “más rendimiento”; es una herramienta para un patrón concreto. Diseñar el data pipeline —formato de dataset, tamaño de shard, número de workers del DataLoader— importa tanto como elegir la cabina.

Merece la pena detenerse en el data pipeline, porque es donde se pierde rendimiento de forma más silenciosa. El entrenamiento no lee el dataset de cualquier manera: lo recorre en batches, lo baraja entre épocas para evitar sesgos de orden, y a menudo aplica transformaciones (decodificación de imágenes, tokenización, augmentation) en CPU antes de entregar el tensor a la GPU. Cada uno de esos pasos puede convertirse en el cuello de botella. Un número insuficiente de workers del DataLoader deja a la GPU esperando; un formato de dataset que obliga a abrir millones de ficheros pequeños hunde el rendimiento de metadatos; un shuffle mal diseñado convierte lecturas secuenciales eficientes en accesos aleatorios costosos. La práctica habitual en cargas serias es empaquetar el dataset en shards grandes (formatos como WebDataset, TFRecord o Parquet) precisamente para que el patrón de lectura sea secuencial y grande, el terreno donde GDS y los sistemas de archivos paralelos rinden mejor. La regla mental: el almacenamiento más rápido del mundo no salva a un pipeline de datos mal diseñado.

El coste real del checkpointing (cuando hay entrenamiento)

El checkpointing es la carga de escritura más exigente del mundo de la IA, pero conviene situarla: es un problema de entrenamiento. Una factoría de inferencia pura apenas lo sufre —sus escrituras pesadas son otras: KV-cache, índices vectoriales, telemetría—. Lo tratamos aquí porque muchas instalaciones combinan algo de fine-tuning o entrenamiento ocasional con el servicio, y porque ilustra mejor que ningún otro caso cómo la asincronía vence a la fuerza bruta. Si tu plataforma es de inferencia, puedes leer esta sección como contexto y saltar a la siguiente, que es la que de verdad te concierne.

Dicho esto, la intuición de la mayoría sobre el checkpointing es errónea en dos puntos: el tamaño y la frecuencia.

El tamaño. Un checkpoint no son solo los pesos. La regla práctica es de unos 16 bytes por parámetro, porque el grueso es el estado del optimizador. Las cifras de la carga de checkpointing de MLPerf Storage v2.0, basadas en el Llama 3 Herd de Meta, lo dejan claro:

Modelo	Procesos	Tamaño del checkpoint	Del cual, estado del optimizador
8B	8	105 GB	90 GB
70B	64	912 GB	—
405B	512	5,29 TB	—
1T	1024	15 TB	13,2 TB

La frecuencia. A escala, los fallos de hardware son constantes (lo desarrollamos en el artículo sobre disponibilidad). El modelo de Meta para un cluster de 16.000 aceleradores predice un fallo cada pocas horas. Para perder menos del 5 % del progreso entre fallos hay que hacer del orden de 20 checkpoints en ese intervalo. Eso se traduce en cadencias agresivas:

16.000 aceleradores: unos 155 checkpoints al día, uno cada 9,3 minutos.
100.000 aceleradores: unos 967 checkpoints al día, uno cada 1,5 minutos.

Y aquí aparece el problema de ancho de banda. El checkpoint síncrono detiene el entrenamiento mientras escribe. Si ( S_{\text{ckpt}} ) es el tamaño del checkpoint y ( t_{\text{win}} ) la ventana de tiempo aceptable para escribirlo manteniendo el overhead por debajo del 5 %, el ancho de banda requerido es:

$$B_{\text{req}} = \frac{S_{\text{ckpt}}}{t_{\text{win}}}$$

Para un modelo de 1T en 100.000 aceleradores, la ventana cae a unos 4,4 segundos. Escribir 15 TB en ese tiempo exige del orden de 3,6 TB/s a través del cluster, o unos 200 GB/s sostenidos a lo largo de todo el job. Solo en checkpoints, ese escenario genera más de 14 PB de escrituras al día. No es una carga marginal: es una de las cargas de escritura más exigentes que existen.

Conviene ver el cálculo desplegado, porque revela dónde está la palanca. Tomemos el modelo de 405B, cuyo checkpoint pesa 5,29 TB. Si la política exige escribirlo manteniendo el overhead por debajo del 5 % en una cadencia donde la ventana aceptable es, digamos, de 30 segundos, el ancho de banda síncrono necesario es de unos 176 GB/s sostenidos —al alcance de una cabina de gama alta, pero solo dedicada a esa tarea—. Si en lugar de 30 segundos la ventana se contrae a 5 (clúster más grande, fallos más frecuentes), el requisito salta por encima de 1 TB/s. La sensibilidad a la ventana es brutal: la diferencia entre un diseño viable y uno imposible está en cómo se gestiona el tiempo, no en cuántos discos se compran. Ahí es donde la asincronía cambia las reglas.

La solución no es solo más ancho de banda; es asincronía. El checkpointing asíncrono desacopla el snapshot (copia GPU→CPU, rápida) de la persistencia (escritura en segundo plano, solapada con el cómputo). El Distributed Async Checkpointing de PyTorch reduce el tiempo efectivo de checkpoint entre 10 y 20 veces; en un ejemplo de IBM, un modelo de 7B bajó su down time de 148,8 a 6,3 segundos, una mejora de 23,6 veces. Técnicas como CheckFreq pipelinean el snapshot y la persistencia con el entrenamiento, permitiendo checkpointear cada 14-19 iteraciones. Por eso proveedores como VAST sostienen que la métrica relevante no es GB/s sino el checkpoint overlap: qué fracción del checkpoint se solapa con el cómputo. Un 10 % de solapamiento suele bastar.

La lección de diseño es clara: dimensionar el almacenamiento de entrenamiento por el pico de escritura del checkpointing síncrono es caro y, a menudo, innecesario si la pila de software hace bien la asincronía. Pero confiar en la asincronía sin medir el overlap es jugar a la ruleta con semanas de cómputo.

El rendimiento de una factoría de inferencia

Aquí está el corazón del asunto para quien explota una factoría de inferencia. En una factoría de inferencia el almacenamiento no se mide en épocas ni en GPU-horas, sino en la experiencia que percibe el cliente, y esa experiencia se condensa en dos métricas: el TTFT (time to first token, el tiempo hasta el primer token de respuesta) y la latencia inter-token (la velocidad a la que llegan los tokens siguientes). A escala de flota, la métrica que paga las facturas es el throughput en tokens por segundo por GPU, porque determina cuántas peticiones atiende cada acelerador. El almacenamiento toca las tres, y de formas que un diseño centrado solo en entrenamiento no anticipa.

Prefill, decode y su desagregación

La inferencia tiene dos fases con perfiles opuestos. El prefill procesa todo el prompt de entrada de una vez, genera los pares clave-valor del KV-cache y es una fase intensiva en cómputo; domina el TTFT. El decode genera los tokens uno a uno reutilizando ese caché, es intensivo en ancho de banda de memoria y domina la latencia inter-token. Como sus cuellos de botella son distintos, la tendencia de 2025-2026 es desagregarlas: ejecutar el prefill y el decode en pools de GPU separados y transferir el KV-cache entre ellos. Esa transferencia —que puede ir por NVLink, por red o a través de una capa de almacenamiento compartida— convierte el movimiento del KV-cache en una operación de rendimiento crítico. Una factoría que desagrega prefill y decode necesita una vía de KV-cache de altísimo ancho de banda y baja latencia entre ambos pools; el almacenamiento (o la DPU que lo gobierna) deja de ser un actor pasivo y entra en el camino crítico de cada petición.

El KV-cache como capa de rendimiento

El problema central es el tamaño del KV-cache con contextos largos: desborda la HBM, que es escasa y cara. Las opciones son recomputarlo en cada petición —carísimo en cómputo y letal para el TTFT— o descargarlo a una capa más lenta y reutilizarlo. Aquí compiten dos enfoques. El offload a memoria CXL ofrece mejoras de más de 5 veces frente al caching basado en SSD o RDMA, según los proveedores de la cadena CXL, y permite manejar batches hasta un 30 % más grandes manteniendo los objetivos de latencia, lo que sube el throughput y la utilización de GPU. El offload a NVMe, estandarizado por NVIDIA en 2026 con su plataforma ICMS sobre BlueField-4, es más lento pero mucho más barato y capaz, idóneo para KV-cache a escala de pod.

La gran palanca de rendimiento aquí es la reutilización de KV-cache (prefix caching). Muchas peticiones comparten prefijos: el mismo system prompt, el mismo documento de contexto, la misma conversación previa. Si el KV-cache de esos prefijos se conserva en una capa de almacenamiento rápida y se reutiliza en lugar de recomputarse, el prefill se acorta drásticamente y el TTFT se desploma. Esto convierte una capa de almacenamiento de baja latencia en un multiplicador directo del throughput de la factoría: cuanto más caché útil quepa y más rápido se sirva, menos cómputo se desperdicia recalculando lo ya calculado. Dimensionar bien esta capa —capacidad, ancho de banda, latencia, política de expulsión— es una de las decisiones de rendimiento más rentables de toda la factoría.

El tiempo de carga de modelos y el cold start

Hay un coste de almacenamiento específico de la inferencia que el entrenamiento ignora: arrancar una réplica. Cuando el autoescalado decide levantar una instancia nueva de un modelo —porque sube la demanda, porque falla una réplica o porque se rota una versión—, hay que leer los pesos del repositorio y cargarlos en la HBM. Para un modelo de decenas o cientos de GB, ese cold start puede ir de segundos a minutos según el ancho de banda del repositorio y la ruta de carga. Y durante ese tiempo, la GPU nueva no atiende peticiones mientras el sistema, quizá, está saturado. Un repositorio de modelos lento se traduce directamente en SLA incumplidos en los picos. Las mitigaciones —mantener los pesos en flash local caliente, usar formatos de carga rápida, streaming de pesos a medida que se necesitan, o GPUDirect Storage para cargar directamente a la HBM— son decisiones de almacenamiento que determinan la elasticidad real de la factoría.

El rendimiento de RAG y la búsqueda vectorial

Si la factoría sirve RAG, hay un eslabón más en el camino crítico de cada petición: la recuperación. Antes de que el modelo genere nada, el sistema busca en una base de datos vectorial los fragmentos relevantes, y esa búsqueda de similitud —sobre índices que pueden ocupar TB— se suma al TTFT. El rendimiento de la búsqueda vectorial depende de mantener los índices en flash de baja latencia y de un patrón de lectura aleatoria eficiente; un índice que no cabe en memoria y se sirve desde almacenamiento lento añade latencia a cada petición. Además, los KV-cache precomputados de los documentos recuperados aceleran el prefill, porque el modelo reutiliza claves y valores ya calculados y solo codifica la consulta del usuario. La factoría de inferencia con RAG, por tanto, tiene dos cargas de lectura sensibles a latencia conviviendo —el índice vectorial y el KV-cache— que compiten por el mismo flash rápido y que hay que dimensionar juntas.

Para un arquitecto de inferencia, todo esto introduce un plano de almacenamiento con un perfil propio: lecturas aleatorias sensibles a latencia (índices, prefijos de KV-cache reutilizables), escrituras efímeras de alta rotación (KV-cache nuevo), lecturas grandes y esporádicas pero urgentes (carga de modelos) y un flujo append-only de telemetría. No se dimensiona, en absoluto, como el almacenamiento de un clúster de entrenamiento.

Cómo medir lo propio: más allá de la hoja de especificaciones

Las cifras de los fabricantes y de MLPerf son útiles como referencia, pero el rendimiento real depende de la carga concreta, y un arquitecto debe medir, no asumir. La metodología que funciona parte de tres principios.

El primero es medir la utilización del acelerador, no el almacenamiento en abstracto. Una cabina puede entregar 500 GB/s en una prueba sintética y, sin embargo, dejar las GPU al 50 % porque el patrón real es de archivos pequeños y aleatorios que la prueba secuencial no reproduce. La pregunta correcta siempre es: ¿qué fracción del tiempo está calculando mi GPU con esta carga, este formato de dataset y este pipeline?

El segundo es reproducir el patrón de I/O real, no uno cómodo. Esto implica probar con el mismo formato de dataset, el mismo tamaño de shard, el mismo número de workers y la misma cadencia de checkpointing que se usarán en producción. El acierto de MLPerf Storage fue precisamente simular el think time del acelerador para generar un patrón realista; replicar ese rigor a escala propia es lo que separa una medición útil de un número de marketing.

El tercero es buscar el escalado, no el pico. Una plataforma que entrega un pico altísimo en una configuración pequeña pero se aplana al añadir nodos no sirve para crecer. Las pruebas deben hacerse a varias escalas para verificar que el throughput crece de forma aproximadamente lineal y que la utilización del acelerador se mantiene, como mostraba el ejemplo de Hammerspace en MLPerf v2.0. Un coeficiente de variación bajo entre configuraciones es tan importante como el pico.

El coste de equivocarse

Conviene poner número al problema. El precio de una H100 en la nube a mediados de 2026 se mueve en un rango amplio según proveedor, con una mediana de mercado en torno a 2,3-3,1 USD por hora y GPU. Multiplíquese por miles de GPU y por las semanas que dura un entrenamiento, y un 40 % de utilización en lugar de un 90 % se traduce en millones de euros de cómputo desperdiciado. Por eso más del 50 % de las organizaciones reportan en 2026 cuellos de botella de datos o almacenamiento que limitan su IA, y por eso el ancho de banda de almacenamiento ha emergido como un techo duro al escalado, comparable a la energía y la refrigeración: cuando hay data starvation, añadir cómputo da rendimientos decrecientes.

La recomendación operativa que se repite es dimensionar el pipeline de I/O para 300 Gbps o más en cargas serias, y medir —no asumir— la utilización del acelerador como indicador de salud. Un almacenamiento optimizado puede entregar hasta 5 veces el throughput de un acceso S3 estándar sobre HTTP: más de 100 GB/s agregados frente a unos 20 GB/s.

La capa física: redes y PCIe Gen6

Todo lo anterior se apoya en una capa física que también ha avanzado. La NIC ConnectX-8 de NVIDIA combina PCIe Gen6 con 800 GbE u 800 Gb de InfiniBand XDR, diseñada para los sistemas Blackwell. InfiniBand XDR ofrece 800 Gbps por dirección (el doble que NDR, que sigue siendo el storage fabric habitual), y el switch Quantum-X800 añade cómputo en red que acelera las operaciones colectivas. La transición a XDR se acelera con los despliegues Blackwell de 2025-2026. La regla mental es sencilla: el almacenamiento debe estar a la altura de la red, y la red, a la altura de la GPU. Un eslabón lento define el rendimiento de toda la cadena.

Merece la pena traducir esto a números concretos. Una NIC de 800 Gb/s entrega, en el mejor caso, unos 100 GB/s a un nodo. Si la cabina puede servir más de lo que la NIC absorbe, la red es el cuello de botella; si la cabina sirve menos, lo es el almacenamiento. El equilibrio se busca dimensionando cada capa para que ninguna estrangule a la siguiente, y verificándolo con medidas de extremo a extremo, no con las especificaciones aisladas de cada componente. Es habitual encontrar instalaciones con una cabina excelente y una fabric infradimensionada —o al revés— que rinden muy por debajo de la suma de sus partes. La capa física también impone su geografía: la topología de la red (cuántos saltos hay entre el nodo de cómputo y la cabina, si comparten conmutador o atraviesan la columna vertebral del clúster) afecta a la latencia tanto como la propia cabina, y un diseño de almacenamiento para IA que ignore la topología de red está incompleto.

Tres preguntas antes de dimensionar

Toda esta complejidad se puede ordenar en tres preguntas que un arquitecto debería responder antes de comprar nada. ¿Cuál es el patrón de I/O dominante de mi carga —secuencial grande, aleatorio pequeño, escritura en ráfagas— y, por tanto, qué métrica me limita? ¿Está mi carga limitada por ancho de banda o por latencia, y en consecuencia dónde invierto? ¿Y cuál es mi presupuesto de checkpointing —tamaño, cadencia y, sobre todo, qué fracción puedo solapar con el cómputo? Quien responde estas tres con datos medidos, y no con intuiciones, dimensiona bien; quien las salta acaba con GPU ociosas o con una cabina sobredimensionada y carísima que nunca se aprovecha. El rendimiento del almacenamiento de IA es, en el fondo, un ejercicio de adecuación: poner la capacidad correcta donde la carga la necesita, ni más ni menos.

Para llevarse a casa

El rendimiento del almacenamiento para IA no se mide en GB/s sino en utilización del acelerador, y esa utilización depende de tres cosas: ancho de banda suficiente, latencia baja y, sobre todo, solapamiento de la I/O con el cómputo. MLPerf Storage v2.0 ha dado por fin un lenguaje común para comparar plataformas con esa óptica. El checkpointing es la carga de escritura más exigente y se domina con asincronía, no solo con hardware. La inferencia de contexto largo añade una capa de almacenamiento nueva alrededor del KV-cache. Y el coste de equivocarse se mide en GPU ociosas, que es la partida más cara del presupuesto.

El rendimiento, sin embargo, no sirve de nada si los datos no están protegidos ni disponibles. El tercer artículo aborda la seguridad de esta nueva capa de almacenamiento.

Ver también

Fuentes

MLCommons, MLPerf Storage v2.0 Results — https://mlcommons.org/2025/08/mlperf-storage-v2-0-results/
MLCommons, Announcing the MLPerf Storage v2.0 Checkpointing Workload — https://mlcommons.org/2025/08/storage-2-checkpointing/
MLCommons, MLPerf Storage v1.0 Benchmark Results — https://mlcommons.org/2024/09/mlperf-storage-v1-0-benchmark-results/
Hammerspace, MLPerf Storage v2.0 Benchmark Results — https://hammerspace.com/hammerspace-mlperf-storage-v2-0-benchmark-results/
Alluxio, Strong Performance in MLPerf Storage v2.0 — https://www.alluxio.io/blog/alluxio-demonstrates-strong-performance-in-mlperf-storage-v2-0-benchmarks
NVIDIA, GPUDirect Storage Overview Guide — https://docs.nvidia.com/gpudirect-storage/overview-guide/index.html
Spheron, GPU Direct Storage Guide 2026 — https://www.spheron.network/blog/gpu-direct-storage-nvme-ai-training-inference-guide/
PyTorch, Reducing Checkpointing Times with Async Checkpointing — https://pytorch.org/blog/reducing-checkpointing-times/
VAST Data, Optimizing Checkpoint Bandwidth for LLM Training — https://www.vastdata.com/blog/optimizing-checkpoint-bandwidth-for-llm-training
Astera Labs, How CXL Transforms RAG and KV Cache Performance — https://www.asteralabs.com/breaking-through-the-memory-wall-how-cxl-transforms-rag-and-kv-cache-performance/
MinIO, AI Storage Architecture: Overcoming the Bottleneck in 2026 — https://www.min.io/blog/ai-storage-architecture-bottleneck-2026
WEKA, WEKApod Nitro reference architecture — https://www.weka.io/resources/reference-architecture/nvidia-gb200-nvl72-systems-reference-architecture-for-cloud-partners/
Blocks & Files, Storage vendors rally behind Nvidia at GTC 2025 — https://blocksandfiles.com/2025/03/18/nvidia-storage-announcements/
ServeTheHome, NVIDIA ConnectX-8 SuperNIC PCIe Gen6 800G — https://www.servethehome.com/nvidia-connectx-8-supernic-pcie-gen6-800g-nic-detailed/
SpendArk, GPU Cloud Pricing 2026 — https://spendark.com/blog/machine-learning-cloud-cost/

Almacenamiento en la era de la IA (3/4): seguridad

Mon, 22 Jun 2026 10:00:00 +0200

Los datos son el activo más valioso y más duradero de un sistema de IA. Los modelos se reentrenan; los pesos se sustituyen; pero los datasets de entrenamiento, los datos de clientes que alimentan el RAG y los propios pesos de un modelo puntero representan años de inversión y, a menudo, información regulada. En los dos artículos anteriores hablamos de cómo mover esos datos rápido. Este tercero trata de cómo protegerlos: cifrado, integridad, control de acceso, soberanía y la amenaza que obliga a empezar a actuar hoy aunque parezca lejana, la computación cuántica.

Cifrado en reposo: SED, AES-XTS y la transición a FIPS 140-3

La primera línea de defensa de cualquier dato persistente es el cifrado en reposo. En almacenamiento empresarial el patrón dominante son los SED (Self-Encrypting Drives), discos que implementan los estándares Opal, Ruby y Enterprise del Trusted Computing Group e integran un motor de cifrado AES-XTS de 256 bits en el controlador. La ventaja operativa es doble: cifran a velocidad de interfaz, sin penalización perceptible de rendimiento y sin robar ciclos a la CPU, y habilitan el borrado criptográfico instantáneo.

El mecanismo que hace posible ese borrado es el modelo de claves de dos niveles de TCG Opal 2.0. Los datos se cifran realmente contra una clave de cifrado de datos (DEK) que nunca sale del disco; esa DEK, a su vez, está protegida por una clave de autenticación derivada de la passphrase del usuario. Destruir o regenerar la DEK convierte instantáneamente en ilegibles teras de datos sin tener que sobrescribirlos: el cryptographic erase. Para una organización que retira discos de 245 TB, esta propiedad no es un lujo, es la única forma práctica de garantizar el borrado.

El cifrado por hardware del SED y el cifrado por software con AES-NI no son excluyentes, pero sí tienen perfiles distintos. La aceleración por hardware mantiene una ventaja medible —del orden de 2 veces en lecturas y escrituras aleatorias 4K frente a software puro—, aunque la brecha se estrecha en las CPU modernas con AES-NI y ARMv8. La regla práctica: SED para la línea base sin coste de rendimiento, y cifrado de software por encima cuando se necesita separación de dominios de claves o cifrado de extremo a extremo.

El talón de Aquiles del cifrado nunca es el algoritmo, sino la gestión de claves. Un AES-256 impecable no protege nada si la clave está mal custodiada. Por eso el cifrado de almacenamiento serio se apoya en un gestor de claves externo que habla KMIP (Key Management Interoperability Protocol) con las cabinas, separando la custodia de la clave del medio que cifra. Las claves se rotan periódicamente, se respaldan con sus propias garantías de disponibilidad —perder la clave es perder el dato de forma tan definitiva como un incendio— y su acceso se audita. En entornos regulados, esas claves residen en módulos de hardware (HSM) certificados. Para un arquitecto, la decisión de diseño no es “¿ciframos?” —la respuesta es siempre sí— sino “¿quién tiene las claves y cómo se gobiernan?”, una pregunta que, como veremos, está en el corazón de la soberanía del dato.

El punto que ningún arquitecto debería ignorar en 2026 es la transición a FIPS 140-3. El CMVP dejó de aceptar nuevas validaciones FIPS 140-2 en abril de 2022, y el 21 de septiembre de 2026 moverá todos los certificados 140-2 restantes a la lista “histórica”. A partir de esa fecha, las agencias federales estadounidenses no deben incluir módulos históricos en nuevas adquisiciones; los sistemas existentes pueden seguir operando, pero el reloj de cumplimiento corre. Y hay un efecto colateral logístico: los tiempos de validación han crecido de 367 a 542 días, un 42 % más, lo que tensiona los roadmaps de los fabricantes. Quien planifique compras de almacenamiento con horizonte plurianual debe verificar la certificación 140-3, no la 140-2, de cada módulo criptográfico. El marco de referencia para el diseño global sigue siendo el NIST SP 800-209, que cubre cifrado, aislamiento, autenticación y autorización para almacenamiento de bloque, archivo y objeto.

Cifrado en tránsito: el punto débil de las fabrics de IA

Los datos también se exponen en movimiento, y aquí las fabrics de alto rendimiento de IA introducen tensiones específicas. Para NVMe-oF sobre TCP existe autenticación in-band, y para mayor protección el grupo de trabajo de NVMe propone IPsec sobre RoCEv2. Las NIC modernas —ConnectX-6 Dx, BlueField-2— aseguran las conexiones NVMe-oF con IPsec y TLS acelerados por hardware, de modo que el cifrado en tránsito no estrangula el ancho de banda.

El problema es InfiniBand. IPsec no se implementa sobre InfiniBand —no es un protocolo IP—, lo que deja esa fabric, omnipresente en clústeres de IA, sin una de las herramientas habituales de confidencialidad. Tampoco IPsec aísla bien las conexiones RDMA de distintos usuarios que comparten una misma interfaz. La investigación académica ha documentado ataques que explotan errores de RDMA en aplicaciones de almacenamiento NVMe-oF. La conclusión para un arquitecto es incómoda pero importante: la seguridad en tránsito de una fabric de IA no se hereda de los buenos hábitos de las redes IP, y exige diseño explícito de segmentación y aislamiento.

La amenaza que llega del futuro: criptografía post-cuántica

Ningún tema de seguridad de almacenamiento ha cambiado tanto su urgencia como la criptografía post-cuántica (PQC), y la razón es un patrón de ataque que no necesita un ordenador cuántico para empezar: "harvest now, decrypt later" (HNDL). Actores estatales bien financiados recolectan hoy datos cifrados con la intención de descifrarlos cuando dispongan de capacidad cuántica. Para cualquier dato cuya confidencialidad deba durar una década —historiales médicos, secretos industriales, datasets de entrenamiento propietarios— la amenaza es presente, no futura.

En agosto de 2024 el NIST finalizó los tres primeros estándares PQC, y a mediados de 2026 son la base sobre la que se construye toda la migración:

Estándar	Algoritmo	Función	Origen
FIPS 203	ML-KEM	Encapsulado de claves	CRYSTALS-Kyber
FIPS 204	ML-DSA	Firma digital (por defecto)	CRYSTALS-Dilithium
FIPS 205	SLH-DSA	Firma de respaldo (basada en hash)	SPHINCS+

En marzo de 2025 el NIST seleccionó además HQC, un mecanismo de encapsulado basado en códigos, como respaldo de ML-KEM con supuestos matemáticos distintos. La NSA, por su parte, fijó en CNSA 2.0 un calendario exigente: para 2030 todo el software y firmware desplegado en sistemas de seguridad nacional debe usar firmas CNSA 2.0, con plena aplicación esperada hacia 2031-2033 y resistencia cuántica completa en 2035.

La presión se ha intensificado por el lado del hardware cuántico. Entre mayo de 2025 y principios de 2026, varios trabajos redujeron las estimaciones de qubits necesarios para romper RSA-2048 desde unos 20 millones a menos de un millón, e incluso a cifras del orden de 100.000 con nuevas arquitecturas. El “Q-Day” hacia 2030 es cada vez más citado por analistas, el NIST y la NSA. No es una certeza, pero el margen de seguridad se ha estrechado lo suficiente como para que la inacción sea imprudente.

La industria del almacenamiento ya se mueve. NetApp anunció en 2025 PQC para datos en reposo conforme a los algoritmos del NIST, integrada tanto en reposo como en vuelo. Western Digital empezó a integrar PQC aprobada por el NIST en sus discos Ultrastar en 2026, uno de los primeros despliegues en infraestructura de producción. Cohesity, Commvault y Quantum tienen también productos en esta línea. El patrón dominante en 2026 no es la sustitución total, sino los enfoques híbridos que combinan criptografía clásica y post-cuántica: protegen frente a un fallo de los algoritmos nuevos y permiten una migración gradual. Para un arquitecto, la acción concreta de hoy es el inventario criptográfico —crypto-agility—: saber qué algoritmos protegen qué datos y planificar su rotación.

Seguridad específica de los datos de IA: integridad y envenenamiento

Más allá del cifrado clásico, la IA introduce una clase de amenaza propia que recae directamente sobre la capa de datos: el envenenamiento de datos (data poisoning). Un adversario manipula los datos de entrenamiento o de fine-tuning para corromper lo que el modelo aprende. Su rasgo distintivo es el sigilo: un modelo envenenado opera con normalidad durante largos periodos antes de manifestar el comportamiento malicioso, lo que lo hace muy difícil de detectar a posteriori. El OWASP Top 10 para aplicaciones LLM de 2025 reconoce formalmente el “data and model poisoning” como categoría de ataque de integridad, con riesgo especialmente alto cuando se ingieren fuentes externas.

La defensa se ha movido hacia la procedencia y el linaje. Las organizaciones adoptan documentación rigurosa de cada fuente de datos —una “cadena de custodia digital”— y el concepto de ML-BOM (Machine Learning Bill of Materials), análogo al SBOM del software. Marcos como el de gobernanza de IA de FINOS catalogan explícitamente el envenenamiento de datos entre sus riesgos. Para el almacenamiento, esto significa que el sistema debe ser capaz de garantizar la integridad e inmutabilidad del dato de entrenamiento y de registrar su linaje de forma verificable. La integridad deja de ser una propiedad deseable para convertirse en un control de seguridad.

El robo de modelos: cuando el activo a proteger son los pesos

Hay un activo que la conversación tradicional de seguridad de almacenamiento no contemplaba: los pesos del modelo. Entrenar un modelo puntero cuesta decenas o cientos de millones, y el resultado —un fichero de unos pocos TB— concentra todo ese valor. El robo de pesos (model exfiltration) es, en consecuencia, una amenaza de primer orden, y su superficie de ataque es precisamente la capa de almacenamiento donde residen los checkpoints y los modelos finales.

La protección combina varias de las capas ya descritas, aplicadas con un foco específico. El cifrado en reposo con control estricto de claves impide que un atacante que acceda a los discos se lleve un modelo utilizable. El control de acceso de mínimo privilegio limita quién puede leer los directorios de pesos, y la auditoría registra cada acceso para detectar exfiltraciones anómalas —un proceso que de repente lee 4 TB de un directorio de modelos es una señal—. Y el confidential computing, que veremos más abajo, protege los pesos incluso mientras se cargan en la GPU para inferir. La lección para el arquitecto es que el modelo entrenado merece, como mínimo, las mismas defensas que los datos de clientes, porque su pérdida puede ser irreversible y su valor, mayor.

Inmutabilidad y ransomware: la segunda fase del ataque

El ransomware sigue siendo la amenaza de mayor impacto económico sobre el almacenamiento, y su evolución reciente apunta directamente a los backups. La defensa de referencia es la inmutabilidad WORM (Write-Once-Read-Many). En el mundo del objeto, S3 Object Lock impide modificar o borrar datos incluso a un atacante con credenciales administrativas, neutralizando la segunda fase del ataque —el cifrado de los datos de la víctima—. Tiene dos modos: Governance, anulable con permisos específicos, y Compliance, que no puede anular nadie, ni siquiera la cuenta root. Object Lock crea un air-gap lógico que, para muchos casos de uso, hace redundantes las cintas y los air-gaps físicos.

Las cifras justifican la inversión. Los pagos de rescate alcanzaron un récord de 1.100 millones de USD en 2023; el coste total medio de un ataque de ransomware rondó los 5,13 millones de USD en 2024, con un coste medio de recuperación —al margen del rescate— de 1,53 millones en 2025. Dos de cada tres organizaciones sufrieron ransomware en el último año según Sophos.

Para una factoría de inferencia el ransomware tiene un ángulo propio: el objetivo más valioso no es solo el dato de cliente, sino el repositorio de modelos. Cifrar o borrar los pesos que sirve la factoría la deja inoperante de inmediato, con un impacto de negocio directo —el servicio cae— además del coste de recuperación. La defensa es la misma que para cualquier activo crítico, aplicada con prioridad: copias inmutables WORM del repositorio de modelos y de los índices vectoriales, de modo que una versión limpia de cada modelo siempre pueda restaurarse aunque la copia en caliente quede comprometida. Un modelo que tardó meses y millones en producirse, o cuyos pesos no se pueden regenerar, merece la protección de inmutabilidad más estricta disponible.

La respuesta del lado del almacenamiento ha sido integrar la detección en el propio array. Dell PowerProtect Cyber Recovery ofrece una bóveda aislada e inmutable con air-gap automatizado, y su componente CyberSense usa IA y análisis de contenido completo —no solo metadatos— para detectar corrupción por ransomware, con cifras de precisión muy altas anunciadas por el fabricante. NetApp integra Autonomous Ransomware Protection en el almacenamiento, creando snapshots inmutables en tiempo real al analizar patrones de datos en la capa de almacenamiento. Conviene tratar las cifras de precisión (99 % y superiores) como reclamaciones del fabricante, no como benchmarks independientes, pero la tendencia de fondo es real: el array de almacenamiento ha dejado de ser un componente pasivo y se ha convertido en un actor de la defensa.

Un marco útil para priorizar estas inversiones es la expectativa de pérdida anualizada, que relaciona el impacto de un incidente con su frecuencia:

$$\text{ALE} = \text{SLE} \times \text{ARO}$$

donde ( \text{SLE} ) es la pérdida esperada por incidente y ( \text{ARO} ) la frecuencia anual esperada. La inmutabilidad y la recuperación rápida actúan reduciendo el ( \text{SLE} ): aunque el ataque ocurra, la pérdida y el tiempo de recuperación se acotan.

Control de acceso y el coste de la brecha

El cifrado protege el dato; el control de acceso decide quién lo toca. El informe de IBM Cost of a Data Breach 2025 aporta el dato de referencia: el coste medio global de una brecha bajó a 4,44 millones de USD, un 9 % menos y la primera caída en cinco años, impulsada por una contención más rápida gracias a defensas potenciadas por IA —el tiempo medio de identificación y contención cayó a 241 días, el más bajo en nueve años—. Estados Unidos, en cambio, marcó un récord de 10,22 millones. El mayor componente de coste sigue siendo la detección y el escalado.

Las arquitecturas maduras combinan Zero Trust con RBAC como base, atributos ABAC para grano fino y microsegmentación para impedir el movimiento lateral dentro de la red. En un entorno de IA, donde el dato de entrenamiento se mueve entre data lake, pipeline y cluster GPU, la microsegmentación y la autorización contextual y continua dejan de ser opcionales.

Soberanía del dato: la dimensión regulatoria

Para una empresa europea, la seguridad del almacenamiento de IA es inseparable de la soberanía del dato. El EU Data Act, aplicable desde el 12 de septiembre de 2025, obliga a la portabilidad e interoperabilidad de datos para eliminar el vendor lock-in, y en su Capítulo VII exige a los proveedores cloud que operan en la UE medidas técnicas, legales y organizativas para impedir el acceso de gobiernos no comunitarios a datos no personales almacenados en la UE cuando ese acceso sea ilegal bajo derecho europeo. Esto entra en tensión documentada con la US CLOUD Act, que faculta a las autoridades estadounidenses a reclamar datos a proveedores bajo su jurisdicción con independencia de dónde se almacenen.

La respuesta técnica que gana tracción en 2026 es el cifrado del lado del cliente con propiedad total de las claves: quien controla las claves controla el dato, con independencia de dónde resida físicamente. “Quien permite texto plano en la nube cede el control” se ha convertido en el lema de la soberanía real. Para un arquitecto europeo de IA, la residencia del dato y la titularidad de las claves son decisiones de diseño tan importantes como el rendimiento.

El EU AI Act, además, se aplica por fases que tocan la gobernanza del dato: las prácticas prohibidas son exigibles desde febrero de 2025, las obligaciones para modelos de propósito general desde agosto de 2025, y los poderes sancionadores desde agosto de 2026 —si bien el acuerdo provisional del Digital Omnibus de mayo de 2026 aplazó el plazo de los sistemas de alto riesgo del Anexo III a diciembre de 2027, un dato que conviene seguir verificando por su carácter reciente—.

Confidential computing: proteger el dato en uso

El cifrado en reposo y en tránsito deja un hueco: el dato en uso, descifrado en memoria mientras se procesa. El confidential computing lo cierra mediante entornos de ejecución confiables (TEE). En CPU, Intel TDX y AMD SEV-SNP lanzan máquinas virtuales confidenciales con la memoria cifrada. La novedad para la IA está en la GPU.

NVIDIA introdujo confidential computing en la H100 (Hopper) con un modo CC y una raíz de confianza en silicio: la VM confidencial de la CPU intercambia datos cifrados con un enclave en la GPU, extendiendo la cadena de confianza de la CPU a la GPU. La arquitectura Blackwell (B200, GB200) ha dado el salto cualitativo: es la primera GPU del sector con capacidad TEE-I/O, con protección inline sobre NVLink y NVSwitch que elimina los cuellos de botella de I/O por PCIe de las generaciones anteriores. Y lo más relevante para el rendimiento: gracias a motores de cifrado específicos para IA y a un acceso a HBM cifrado y acelerado por hardware, el HGX B200 mantiene su ventaja de aproximadamente 2 veces en entrenamiento y 2,5 veces en inferencia sobre el HGX H200 incluso con el confidential computing plenamente activo. Esto habilita entrenamiento, inferencia y federated learning confidenciales sin la penalización prohibitiva que antes hacía inviable cifrar el dato en uso, protegiendo a la vez los datos sensibles y los propios pesos del modelo frente al robo.

Seguridad en una factoría de inferencia multi-tenant

El confidential computing cobra un sentido especial en una factoría de inferencia, sobre todo si sirve a varios clientes o equipos sobre la misma infraestructura. Aquí la superficie de ataque no es solo el disco en reposo, sino el dato en uso de cada petición: los prompts, los documentos de contexto, las respuestas y, crucialmente, el KV-cache. Y el KV-cache introduce un riesgo propio de la inferencia que conviene nombrar: si una capa de caché se comparte entre inquilinos para ahorrar cómputo —reutilizando prefijos, como vimos en el artículo de rendimiento—, una reutilización mal aislada puede filtrar contenido de un cliente a otro. La regla de diseño es que el prefix caching solo debe compartirse dentro de un mismo dominio de confianza; entre inquilinos distintos, el aislamiento del KV-cache —en memoria, en CXL o en NVMe— es un control de seguridad, no una optimización opcional.

El mismo principio se extiende a los demás planos de la factoría. El repositorio de modelos debe aplicar control de acceso por inquilino para que nadie cargue ni extraiga un modelo ajeno. La base de datos vectorial de RAG debe segmentar los índices por cliente, porque un embedding recuperado del corpus equivocado es a la vez un fallo de calidad y una fuga de datos. Y la telemetría —que registra prompts y respuestas— es uno de los repositorios más sensibles de toda la instalación, sujeto a las mismas exigencias de cifrado, retención y residencia que los datos de cliente. Una factoría de inferencia bien diseñada trata cada uno de estos planos como un dominio de aislamiento, no como un recurso compartido por comodidad.

Un matiz técnico importante del confidential computing es la atestación (attestation). De nada sirve un enclave seguro si no se puede demostrar que el dato se está ejecutando realmente dentro de él y no en un entorno comprometido que finge serlo. La atestación es el mecanismo criptográfico por el que el hardware —la raíz de confianza en silicio de la GPU o la CPU— emite una prueba verificable de su estado e identidad antes de que se le confíen las claves o los datos. En una arquitectura de IA confidencial, la cadena de confianza se extiende desde la VM confidencial de la CPU hasta el enclave de la GPU, y cada eslabón se atesta. Para el arquitecto, la pregunta operativa es quién verifica esas atestaciones y dónde se custodian las claves que solo se liberan tras una atestación válida: ahí es donde el confidential computing se conecta de nuevo con la gestión de claves del principio del artículo.

Una lista de comprobación para el arquitecto

Reunir todo lo anterior en una práctica accionable ayuda a no dejar capas sin cubrir. En reposo: SED con AES-XTS-256 como línea base, gestión de claves externa vía KMIP con HSM, y verificación de certificación FIPS 140-3 en cada módulo, anticipando septiembre de 2026. En tránsito: TLS 1.3 e IPsec donde sea posible, con atención especial al aislamiento en fabrics InfiniBand, donde las herramientas IP no aplican. Frente a la amenaza cuántica: inventario criptográfico, crypto-agility y adopción de esquemas híbridos clásico-PQC para los datos de larga vida, sin esperar al Q-Day. Frente al ransomware: inmutabilidad WORM con S3 Object Lock en modo Compliance para las copias críticas, detección integrada en el array y recuperación probada. En integridad: linaje verificable y ML-BOM para los datos de entrenamiento, con protección reforzada de los pesos del modelo. En la factoría de inferencia, además: aislamiento del KV-cache y del prefix caching entre inquilinos, segmentación por cliente del repositorio de modelos y de los índices vectoriales de RAG, y tratamiento de la telemetría de prompts y respuestas como dato sensible. En gobierno: control de acceso Zero Trust, microsegmentación y auditoría. Y en soberanía: titularidad de las claves y residencia del dato alineadas con el EU Data Act y el EU AI Act. Ninguna de estas capas sustituye a otra; la seguridad real emerge de su combinación.

Para llevarse a casa

La seguridad del almacenamiento de IA es un sistema de capas que hay que diseñar a la vez: cifrado en reposo con SED y migración a FIPS 140-3; cifrado en tránsito con cuidado especial en las fabrics InfiniBand; crypto-agility y enfoques híbridos para anticiparse al riesgo cuántico y al harvest now, decrypt later; integridad y linaje del dato frente al envenenamiento; inmutabilidad WORM frente al ransomware; control de acceso Zero Trust; soberanía del dato mediante titularidad de claves; y confidential computing para proteger el dato y los modelos en uso. La buena noticia es que el array ya no es pasivo: defiende. La mala, que la amenaza más seria —la cuántica— exige actuar antes de ser visible.

El último artículo de la serie cierra con la propiedad sin la cual ninguna de las anteriores importa: la disponibilidad.

Ver también

Fuentes

NIST, FIPS 140-3 Transition Effort — https://csrc.nist.gov/projects/fips-140-3-transition-effort
SafeLogic, What Happens on September 21, 2026 — https://www.safelogic.com/blog/what-happens-on-september-21-2026
NIST, Security Guidelines for Storage Infrastructure (SP 800-209) — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
NIST, NIST Releases First 3 Finalized Post-Quantum Encryption Standards — https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
PostQuantum.com, NSA Unveils CNSA 2.0 — https://postquantum.com/quantum-policy/nsa-cnsa-2-0-pqc/
Blocks & Files, NetApp boosts storage security with post-quantum encryption — https://www.blocksandfiles.com/security/2025/04/29/netapp-boosts-storage-security-with-post-quantum-encryption/1610355
The Quantum Insider, Western Digital Adds Post-Quantum Cryptography to Hard Drives — https://thequantuminsider.com/2026/05/19/western-digital-adds-post-quantum-cryptography-to-hard-drives/
FINOS AI Governance Framework, Data Poisoning (RI-9) — https://air-governance-framework.finos.org/risks/ri-9_data-poisoning.html
Object First, S3 Object Lock for Ransomware Protection — https://objectfirst.com/guides/immutability/s3-object-lock-for-ransomware-protection/
StorageReview, Dell enhances PowerProtect portfolio for cyber resilience — https://www.storagereview.com/news/dell-technologies-enhances-powerprotect-portfolio-for-improved-cyber-resilience
NetApp, Autonomous Ransomware Protection — https://www.netapp.com/cyber-resilience/autonomous-ransomware-protection/
IBM, Cost of a Data Breach Report 2025 — https://www.ibm.com/reports/data-breach
European Commission, Data Act — https://digital-strategy.ec.europa.eu/en/policies/data-act
artificialintelligenceact.eu, Implementation Timeline — https://artificialintelligenceact.eu/implementation-timeline/
NVIDIA, Confidential Computing on H100 GPUs — https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/
Corvex, Confidential Computing Meets NVIDIA HGX B200 — https://www.corvex.ai/blog/confidential-computing-meets-nvidia-hgxtm-b200-secure-ai-without-the-performance-trade-off

Almacenamiento en la era de la IA (4/4): disponibilidad

Mon, 22 Jun 2026 09:00:00 +0200

Hemos recorrido el estado del arte, el rendimiento y la seguridad. Cierra la serie la propiedad de la que dependen todas las demás: la disponibilidad. Un almacenamiento rapidísimo y perfectamente cifrado no vale nada si un fallo tumba una factoría de inferencia bajo SLA, detiene un entrenamiento de miles de GPUs o deja que un dataset de petabytes se corrompa en silencio. Y a la escala de la IA, los fallos no son un evento excepcional: son el régimen permanente de operación. La diferencia está en cómo se convive con ellos: el entrenamiento se reanuda desde un checkpoint; una factoría de inferencia, en cambio, no puede permitirse parar, y debe seguir respondiendo mientras un componente falla por debajo. Veremos ambos casos, con el foco puesto en el servicio continuo.

Disponibilidad y durabilidad no son lo mismo

Conviene empezar separando dos conceptos que se confunden a menudo. La disponibilidad mide qué fracción del tiempo el dato es accesible; la durabilidad mide la probabilidad de no perderlo. Un sistema puede ser muy duradero pero poco disponible (los datos están a salvo pero ahora mismo no se pueden leer) y viceversa.

La disponibilidad se modela con la conocida relación entre tiempo medio entre fallos y tiempo medio de reparación:

$$A = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$$

De ahí salen los “nueves” que todo el mundo cita, cuya traducción a tiempo de inactividad anual conviene tener interiorizada:

Disponibilidad	“Nueves”	Inactividad anual
99,9 %	tres nueves	~8,8 horas
99,99 %	cuatro nueves	~52,6 minutos
99,999 %	cinco nueves	~5,3 minutos
99,9999 %	seis nueves	~32 segundos

Un detalle que sorprende a quien viene del mundo on-premise: los servicios de almacenamiento de cloud público no suelen ofrecer un SLA superior a cuatro nueves (99,99 %). AWS S3, por ejemplo, garantiza 99,99 % de disponibilidad por región. Los seis nueves son territorio de cabinas empresariales en configuración stretch cluster: Pure Storage los ofrece en esa topología, frente a “cinco nueves y pico” en nodo único. La fórmula deja claro por qué reducir el MTTR —recuperar rápido— suele ser más rentable que perseguir un MTBF imposible.

Durabilidad: los “once nueves” y lo que esconden

La durabilidad se expresa en cifras que parecen de marketing pero tienen un significado preciso. Los “once nueves” de S3 (99,999999999 %) significan que, si almacenas diez millones de objetos, esperarías perder uno cada diez mil años. ¿Cómo se llega ahí? AWS parte de las tasas de fallo irrecuperable del hardware, replica en tres zonas de disponibilidad independientes por región y aplica erasure coding con fragmentación solapada. La advertencia honesta es que no existe un estándar acordado de cómo se calculan los nueves: cada fabricante usa su metodología, y comparar cifras de durabilidad entre proveedores es, en rigor, comparar supuestos.

El mecanismo que produce esas cifras estratosféricas es la combinación de redundancia e independencia de fallos. Si un sistema guarda cada objeto de forma que tolere la pérdida de varios fragmentos, y distribuye esos fragmentos en dominios de fallo independientes —discos, nodos, racks, zonas de disponibilidad distintas—, la probabilidad de perder simultáneamente todos los fragmentos necesarios se vuelve astronómicamente pequeña. La palabra clave es independientes: si los fragmentos comparten un punto único de fallo —la misma fuente de alimentación, el mismo conmutador, la misma zona—, la independencia es ficticia y la durabilidad calculada, una ilusión. Buena parte de las pérdidas de datos reales en sistemas teóricamente durables provienen de correlaciones de fallo que el modelo no contempló: un lote de discos defectuosos del mismo fabricante, un error de software que corrompe todas las réplicas a la vez, un borrado accidental que se propaga. La durabilidad de verdad exige diversidad, no solo cantidad.

Para anclar esos supuestos en la realidad hay una fuente impagable: las estadísticas de discos de Backblaze. En sus datos de 2025 (publicados en febrero de 2026) la tasa anualizada de fallos (AFR) de su flota de 344.196 discos bajó al 1,36 %, desde el 1,55 % de 2024, lo más bajo desde 2022; el AFR de por vida se mantiene estable en el 1,30 %. Los discos de 14-16 TB ya son el 52 % de la flota y los de 20 TB o más rondan el 23 %. Estos números son la materia prima con la que se calcula cualquier durabilidad creíble.

Pero el fallo total del disco no es la amenaza más insidiosa. Lo es la corrupción silenciosa (bit rot). Los discos enterprise tienen una tasa de error de lectura no recuperable del orden de un bit por cada ( 10^{14} ) bits leídos —unos 11 TB—, y esa tasa apenas ha mejorado mientras la capacidad se disparaba. Un estudio clásico de NetApp sobre 1,53 millones de discos durante 41 meses encontró más de 400.000 discordancias de checksum, de las cuales 30.000 no fueron detectadas por el controlador RAID y solo aparecieron durante el scrubbing; los discos nearline se corrompen a diez veces la tasa de los enterprise. La lección: a escala de petabytes, el scrubbing periódico y los checksums de extremo a extremo (como los de ZFS) no son opcionales, porque la corrupción que el RAID no ve es la que destruye un dataset de entrenamiento sin avisar.

Redundancia: por qué el RAID clásico ya no basta

La forma tradicional de tolerar fallos de disco —el RAID con paridad— se ha vuelto problemática precisamente por el crecimiento de la capacidad. El motivo es el tiempo de reconstrucción. La velocidad de escritura secuencial de los discos no ha crecido al ritmo de su capacidad, de modo que reconstruir un disco grande tarda cada vez más: un HDD nearline de 16 TB en RAID 5 puede tardar entre 24 y 72 horas en reconstruirse. Durante esa ventana, el array está degradado y expuesto a un segundo fallo.

Y hay un riesgo más sutil. Reconstruir un disco obliga a leer todos los demás por completo, lo que multiplica la exposición a un error de lectura no recuperable. Reconstruir un RAID 5 de ocho discos de 8 TB implica leer 56 TB; con discos enterprise eso supone alrededor de un 30 % de probabilidad de toparse con un URE que aborte la reconstrucción, y con discos de consumo la probabilidad se acerca al 96 %. Por eso RAID 5 está, sencillamente, deprecado para arrays nuevos con discos de más de 4 TB. A esto se suma el write hole: si un corte de energía interrumpe una escritura, datos y paridad pueden quedar desincronizados y corromper el array —ZFS lo elimina con copy-on-write—.

La respuesta moderna tiene dos piezas. La primera es el erasure coding (códigos Reed-Solomon, esquemas ( k+m )): el objeto se divide en ( k ) fragmentos de datos y ( m ) de paridad, y cualquier ( k ) de los ( k+m ) bastan para reconstruirlo. Su eficiencia frente a la replicación es notable. El overhead de almacenamiento es:

$$O = \frac{k+m}{k}$$

Un esquema ( k=4 ), ( m=2 ) da un overhead de 1,5 —1 TB lógico ocupa 1,5 TB físicos y tolera dos fallos simultáneos— frente al factor 3 de la replicación triple. A escala de exabytes, esa diferencia entre 1,5 y 3 es decisiva en coste. El precio del erasure coding es más CPU en escrituras y reconstrucciones y una operativa más compleja, por lo que la replicación sigue prefiriéndose para datos sensibles a la latencia que se leen localmente.

La segunda pieza es el RAID declustered (dRAID): en lugar de concentrar la reconstrucción en un disco spare dedicado, distribuye la I/O de rebuild entre todos los discos del pool. El efecto sobre el tiempo de recuperación es drástico: un disco de 20 TB que en RAID tradicional tardaría más de 60 horas puede resilverarse en menos de 15 porque todos los discos supervivientes contribuyen a la vez. OpenZFS dRAID e IBM Storage Scale lo implementan. La idea de fondo conecta con la fórmula de disponibilidad: si no puedes evitar el fallo, minimiza el MTTR repartiendo el trabajo de recuperación.

Hay una variable que amplifica todo esto y que el flash ha cambiado de raíz: la velocidad del medio durante la reconstrucción. Reconstruir 10 TB sobre HDD, cuya transferencia ronda los 300 MB/s, puede llevar más de 55 horas; sobre SSD, con transferencias por encima de 6.000 MB/s, baja a menos de 3 —veinte veces más rápido—. Cuando se combina flash con dRAID, la ventana de vulnerabilidad tras un fallo se reduce de días a horas o minutos, y con ella la probabilidad de un segundo fallo concurrente que provoque pérdida de datos. Esta es una de las razones de fondo por las que las plataformas all-flash se han impuesto en IA: no solo rinden más, sino que se recuperan antes, y a esta escala la velocidad de recuperación es seguridad de los datos.

Replicación y RPO/RTO: cuánto puedes perder y cuánto puedes esperar

Para tolerar el fallo de un sitio entero entran en juego la replicación y dos métricas que todo plan de continuidad debe fijar: el RPO (Recovery Point Objective, la máxima pérdida de datos aceptable, medida en tiempo) y el RTO (Recovery Time Objective, el máximo tiempo de inactividad aceptable).

La replicación síncrona espeja cada escritura a un segundo emplazamiento antes de confirmarla, garantizando un RPO de cero —cero pérdida de datos—, pero su alcance está limitado por la latencia: en la práctica exige enlaces metropolitanos por debajo de unos 10 ms, y no sirve para distancias intercontinentales. La replicación asíncrona confirma la escritura localmente y propaga después, lo que permite cualquier distancia geográfica a cambio de un RPO de minutos u horas. Las topologías de stretch cluster activo-activo (como Pure ActiveCluster) consiguen RPO y RTO cero dentro del rango metropolitano, y algunas añaden un tercer sitio asíncrono para combinar consistencia local y protección geográfica. La decisión es siempre el mismo triángulo: distancia, coste y pérdida tolerable. No se pueden optimizar las tres a la vez.

Conviene desmontar un mito sobre la alta disponibilidad de los arrays. Se suele asumir que “activo-activo” es siempre superior a “activo-pasivo”, pero hay un matiz de rendimiento que importa. En una configuración activo-pasivo, el controlador secundario asume la carga tras un fallo sin haber estado sirviendo I/O, de modo que el rendimiento posterior al failover es predecible. En activo-activo, ambos controladores sirven carga en operación normal; cuando uno falla, el superviviente debe absorber su propia carga más la transferida, y puede no cumplir el SLA de rendimiento justo cuando más se necesita. No hay una respuesta universal: la elección depende de si se prioriza el rendimiento agregado en operación normal o la garantía de rendimiento en modo degradado. Lo que sí es innegociable son las actualizaciones no disruptivas (NDU): una cabina de IA seria se actualiza con el sistema encendido y sirviendo I/O, usando la misma rutina de failover dinámico que emplea ante un fallo. Si una actualización exige parar, esa cabina no está a la altura de una carga crítica.

El régimen de fallo permanente: por qué importa a la inferencia

Aquí es donde la disponibilidad del almacenamiento de IA se separa de todo lo anterior: a la escala de la IA, los fallos de hardware no son raros, son continuos. El dato más citado procede del entrenamiento de Llama 3 de Meta sobre un cluster de 16.384 GPUs H100: durante 54 días sufrió 419 fallos inesperados de componentes, un fallo de media cada tres horas, con un MTBF del cluster de aproximadamente 1,8 horas. Más del 66 % de las interrupciones se debieron a fallos de hardware —GPU defectuosas, memoria HBM3, SRAM, switches y cables de red—.

Aunque la cifra procede de un entrenamiento, la estadística subyacente se aplica igual a una factoría de inferencia: el mismo hardware falla a la misma tasa, y una flota de inferencia de cientos o miles de GPUs verá caer componentes a diario. La diferencia está en la respuesta. El entrenamiento absorbe el fallo reanudando desde un checkpoint; la inferencia lo absorbe con redundancia y conmutación en caliente, porque no puede pararse. En ambos casos, el almacenamiento es la pieza que hace posible la recuperación: en entrenamiento, como medio donde vive el checkpoint; en inferencia, como repositorio replicado desde el que se levanta al instante una réplica que sustituya a la caída. Por eso conviene entender bien el mecanismo de checkpointing aunque la factoría sea de inferencia: es el mismo principio de “asumir el fallo y recuperar rápido” llevado a su forma más extrema.

La razón es puramente estadística. Si un componente individual tiene un MTBF dado, el MTBF de un cluster de ( N ) componentes idénticos se reduce de forma inversamente proporcional:

$$\text{MTBF}{\text{cl}} = \frac{\text{MTBF}{\text{dev}}}{N}$$

Aunque cada GPU fallara solo una vez cada seis años (unas 50.000 horas), un cluster de 100.000 GPUs vería un fallo cada media hora, y uno de un millón, cada tres minutos. Esta es la realidad operativa que ningún diseño de almacenamiento de IA puede ignorar.

¿Cómo se convive con esto? Con checkpointing, que es tanto una herramienta de rendimiento (lo vimos en el artículo 2) como el mecanismo central de resiliencia: tras un fallo, el entrenamiento reanuda desde el último checkpoint en lugar de empezar de cero, salvando potencialmente semanas de cómputo. Esto invierte la relación habitual: el almacenamiento no es solo lo que hay que proteger, sino el instrumento que protege a la GPU. Existe incluso un debate de fondo —Epoch AI argumenta que con checkpointing basado en memoria distribuida entre GPUs, en lugar de basado en almacenamiento, los fallos de hardware dejarían de limitar el tamaño de los entrenamientos incluso más allá del millón de GPUs—. Sea cual sea el enfoque, la conclusión para el arquitecto es que la disponibilidad del subsistema de checkpointing es la disponibilidad del entrenamiento.

Un detalle revelador de los datos de Meta es que más de dos tercios de las interrupciones fueron de hardware —GPU, HBM3, SRAM, conmutadores y cables—, y que el almacenamiento, cuando está bien diseñado, no figura entre las causas principales de fallo, sino entre los mecanismos de recuperación. Esto invierte la psicología habitual del arquitecto de almacenamiento: a esta escala su trabajo no consiste tanto en evitar que su subsistema falle —aunque debe hacerlo— como en garantizar que, cuando falle cualquier otra cosa, el entrenamiento pueda reanudarse rápido. El almacenamiento de un clúster de IA es, en buena medida, infraestructura de resiliencia para el resto del clúster. Dimensionar el ancho de banda de escritura del checkpointing y la velocidad de relectura tras un reinicio es, por tanto, una decisión de disponibilidad de todo el sistema, no una métrica aislada de la cabina.

Disponibilidad en una factoría de inferencia: el servicio no para

Todo lo anterior —fallos a escala, checkpointing, MTBF de clústeres— está descrito desde la óptica del entrenamiento, que es un trabajo por lotes: si se cae, se reanuda y se pierde tiempo, pero nadie está esperando al otro lado. Una factoría de inferencia es lo contrario: un servicio en línea sometido a un SLA, donde cada segundo de indisponibilidad es una petición fallida y, a menudo, una penalización contractual. Su disponibilidad se diseña con otra mentalidad.

El primer principio es que el plano de servicio debe sobrevivir al fallo de cualquier componente sin interrumpir las peticiones. Eso implica réplicas redundantes de cada modelo servido, balanceo que retira automáticamente una réplica caída, y —en el plano de almacenamiento— que ninguno de los cuatro planos de la factoría sea un punto único de fallo. El repositorio de modelos debe estar replicado y disponible, porque si se cae no se pueden arrancar réplicas nuevas justo cuando se necesitan para sustituir a las que fallan. La base de datos vectorial de RAG necesita su propia alta disponibilidad, porque sin ella el servicio degrada su calidad o deja de responder. Y la capa de KV-cache, aunque sea efímera, condiciona la latencia: perder una caché compartida obliga a recomputar y dispara el TTFT de golpe para todos los clientes afectados.

El segundo principio es la actualización de modelos sin downtime. En una factoría de inferencia los modelos se rotan con frecuencia —versiones nuevas, ajustes, rollbacks—, y hacerlo sin cortar el servicio exige patrones de despliegue progresivo: blue-green (levantar la versión nueva en paralelo y conmutar el tráfico cuando está caliente) o canary (enviar una fracción del tráfico a la versión nueva y ampliarla si se comporta). Ambos patrones tienen una implicación de almacenamiento directa: durante la transición conviven dos conjuntos de pesos en el repositorio y, a veces, en la HBM, lo que exige capacidad y ancho de banda de carga para que la versión nueva esté lista antes de recibir tráfico. Un repositorio de modelos lento no solo retrasa el autoescalado: ralentiza cada despliegue y alarga la ventana de riesgo.

El tercer principio es el autoescalado elástico, que convierte el tiempo de cold start —el de cargar pesos desde el almacenamiento, que vimos en el artículo de rendimiento— en una métrica de disponibilidad. Si arrancar una réplica nueva tarda minutos porque el repositorio es lento, la factoría no absorbe los picos y degrada o rechaza peticiones precisamente cuando más demanda hay. La elasticidad real de una factoría de inferencia está limitada por la velocidad a la que su almacenamiento entrega los modelos. Por eso muchas instalaciones mantienen una reserva de pesos en flash local caliente y usan rutas de carga aceleradas: la disponibilidad bajo carga variable se gana, en buena parte, en la capa de almacenamiento.

El cuarto principio es la redundancia del propio plano de servicio, que se puede dimensionar con números. Si una réplica de servicio tiene una disponibilidad individual ( a ) (limitada por su GPU, su nodo y su acceso al almacenamiento), un servicio con ( n ) réplicas independientes en el que basta una para responder alcanza una disponibilidad de:

$$A = 1 - (1 - a)^{n}$$

La fórmula explica por qué la redundancia es tan eficaz: con réplicas razonablemente disponibles, cada réplica adicional añade nueves al servicio. Pero su hipótesis es la misma que vimos en la durabilidad: la independencia. Si todas las réplicas dependen del mismo repositorio de modelos, de la misma base de datos vectorial o de la misma capa de KV-cache, ese componente compartido es el verdadero límite de la disponibilidad por mucho que se multipliquen las réplicas de GPU. De ahí que, en una factoría de inferencia, replicar y dar alta disponibilidad a los planos de almacenamiento —repositorio, vector DB, caché— sea tan importante como replicar las propias GPU de servicio: son ellos, y no el cómputo, los puntos únicos de fallo que suelen pasarse por alto.

La conclusión es que en una factoría de inferencia la disponibilidad del almacenamiento se mide en términos de servicio continuo: no “¿cuánto tardo en recuperar el dato?” sino “¿sigue respondiendo el servicio mientras se cae un componente, se actualiza un modelo o se duplica la demanda?”. Es un objetivo de cinco o seis nueves sobre un sistema vivo, no de durabilidad sobre un archivo en reposo.

Recuperación ante desastres: la regla 3-2-1 y el problema del petabyte

Para el desastre mayor —pérdida de un sitio, ataque destructivo— la referencia sigue siendo la regla 3-2-1: tres copias del dato, en dos tipos de medio distintos, con al menos una fuera del emplazamiento. Su evolución en 2025 le añade dos exigencias: inmutabilidad (la copia off-site debe ser inalterable, conectando con la defensa anti-ransomware del artículo de seguridad) y recuperabilidad verificada (un backup que no se ha probado restaurar no es un backup).

A escala de IA aparece un obstáculo físico difícil de eludir: el tiempo de recuperación de datasets masivos. Restaurar petabytes desde una copia off-site puede tardar días o semanas sobre conexiones estándar, un RTO inaceptable para muchas operaciones. Las organizaciones con petabytes ni siquiera pueden hacer el backup inicial a cloud por internet convencional; necesitan transferencia física o enlaces dedicados. Dimensionar la recuperación —no solo la copia— es donde fallan la mayoría de los planes de DR de IA.

Cuando la nube también cae

Conviene recordar que delegar en un hyperscaler no elimina el problema, solo lo traslada. 2025 dejó un recordatorio contundente: la gran caída de AWS del 19-20 de octubre de 2025, originada por una condición de carrera en un microservicio interno de DynamoDB que generó un registro DNS vacío, cascadeó a EC2 y se prolongó unas quince horas, con más de diecisiete millones de reportes y servicios globales caídos. Hubo precedentes en julio de 2024 (us-east-1, por Kinesis) y febrero de 2025 (Estocolmo). La moraleja para una arquitectura de IA crítica es la de siempre: la resiliencia multirregión o multinube es una decisión de diseño consciente, no una propiedad que se hereda por contratar cloud.

La tendencia: almacenamiento que se cura solo

El vector de evolución para 2026 es la incorporación de IA a la propia capa de almacenamiento para defensa self-healing: predicción de fallos antes de que ocurran, tiering y migración automáticos, remediación previa y recuperación instantánea ante ransomware. El hardware de almacenamiento “ya no es pasivo”, como vimos en seguridad. A escala de exabyte, el almacenamiento de objetos se consolida como núcleo por combinar durabilidad masiva con metadatos flexibles y versionado, mientras la cinta resurge como tier de archivo activo para datasets de IA, combatiendo el coste del flash y el HDD. Con un crecimiento de datos del 30-40 % anual, la automatización de la resiliencia deja de ser una comodidad para convertirse en una necesidad: a esa escala, ningún equipo humano gestiona los fallos a mano.

Las garantías comerciales se han movido en la misma dirección. Algunos fabricantes ofrecen ya SLA contractuales que antes eran impensables: Pure, con su modelo Evergreen//One, anuncia hasta diez SLA garantizados distintos, incluyendo seis nueves de uptime, cero pérdida de datos, un colchón de capacidad y cero tiempo de parada planificado por actualizaciones, además de un SLA específico de recuperación tras ciberataque que garantiza arrays limpios. Sea cual sea el fabricante, la tendencia indica un cambio de modelo: de vender hardware a garantizar resultados de disponibilidad. Para el arquitecto, esto traslada parte del riesgo al proveedor, pero no exime de diseñar: un SLA contractual compensa económicamente una caída, no la evita, y la continuidad de un entrenamiento de millones de euros no se restaura con una nota de crédito.

La disponibilidad se gobierna con observabilidad

Ninguna de estas técnicas funciona a ciegas. Sostener la disponibilidad a escala de IA exige observabilidad: monitorización del estado de cada disco (con telemetría tipo SMART y predicción de fallos), del progreso y la integridad de los scrubs, de la latencia de replicación frente a su objetivo de RPO, y de la salud de los checkpoints —que se escriben, sí, pero también que se pueden releer—. La métrica que más engaña es la del backup que nunca se ha restaurado: una copia no verificada es una hipótesis, no una garantía. La disciplina operativa que distingue a una infraestructura resiliente es la prueba periódica de recuperación, a escala realista, midiendo el RTO real frente al objetivo. A la escala de petabytes y miles de GPU, lo que no se mide no se puede garantizar, y lo que no se ensaya tiende a fallar precisamente el día que se necesita.

Para llevarse a casa, y cierre de la serie

La disponibilidad del almacenamiento de IA se diseña sobre cuatro pilares: redundancia eficiente (erasure coding y dRAID en lugar de RAID clásico, que ya no aguanta los discos grandes), durabilidad verificada (con scrubbing y checksums frente a la corrupción silenciosa), replicación con RPO/RTO explícitos según la criticidad, y una resiliencia de pipeline que asume el fallo como estado normal y se apoya en el checkpointing. La fórmula de disponibilidad recuerda la prioridad práctica: cuando no puedes evitar el fallo —y a escala de IA no puedes—, lo que marca la diferencia es recuperar rápido.

Con esto cerramos la serie. El estado del arte nos dio el mapa; el rendimiento, la razón de ser; la seguridad, la protección; y la disponibilidad, la garantía de que todo lo anterior siga estando ahí mañana. En la era de la IA, el almacenamiento ha dejado de ser el sótano silencioso del datacenter para convertirse en lo que decide si las GPU —el recurso más caro y escaso— trabajan o esperan.

Ver también

Fuentes

ActualTech Media, RAID5 and Large Disks: Dealing with Rebuild Times — https://www.actualtechmedia.com/io/raid-disk-rebuild-times/
DiskInternals, RAID Rebuild Time and URE risk — https://www.diskinternals.com/raid-recovery/raid-rebuild-time/
Tech Buzz Online, Erasure Coding vs Replication — https://techbuzzonline.com/erasure-coding-vs-replication-storage-systems/
simplyblock, Declustered RAID (dRAID) — https://simplyblock.io/glossary/draid/
The Register, Data durability statements (11 nines) — https://www.theregister.com/2018/07/19/data_durability_statements/
Backblaze, Drive Stats for 2025 — https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/
StorageReview, Backblaze 2025 Year-End Drive Stats — https://www.storagereview.com/news/backblaze-2025-year-end-drive-stats-annual-afr-falls-to-1-36-as-high-capacity-drives-dominate-fleet
Backup Central, Does Undetectable Bit Error Rate Matter? — https://backupcentral.com/does-undetectable-bit-error-rate-matter/
Pure Storage / Everpure, The Storage Reliability Imperative — https://blog.everpuredata.com/perspectives/data-storage-reliability/
Pure Storage, ActiveCluster — https://www.purestorage.com/products/purity/activecluster.html/
Tom’s Hardware, Faulty H100 GPUs and HBM3 — one failure every three hours (Llama 3) — https://www.tomshardware.com/tech-industry/artificial-intelligence/faulty-nvidia-h100-gpus-and-hbm3-memory-caused-half-of-the-failures-during-llama-3-training-one-failure-every-three-hours-for-metas-16384-gpu-training-cluster
Epoch AI, Hardware failures won’t limit AI scaling — https://epoch.ai/blog/hardware-failures-wont-limit-ai-scaling
Acronis, What is the 3-2-1 Backup Strategy (2025) — https://www.acronis.com/en/blog/posts/backup-rule/
InfoQ, Race Condition in DynamoDB DNS System (AWS Oct 2025 outage) — https://www.infoq.com/news/2025/11/aws-dynamodb-outage-postmortem/
TechTarget, Top data storage trends 2026 — https://www.techtarget.com/searchstorage/tip/Top-data-storage-trends