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

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:

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:

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

• Almacenamiento en la era de la IA (2/4): rendimiento
• Almacenamiento en la era de la IA (3/4): seguridad
• Almacenamiento en la era de la IA (4/4): disponibilidad

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