Niveles de almacenamiento en un servidor de IA: modelo, dataset, scratch y checkpoint

Hay una conversación que repetimos una y otra vez con los compradores a propósito del NVMe. Piden «lo más rápido posible» porque las fichas técnicas muestran 14 GB/s en una unidad Gen5 y una 4090 junto a una Samsung 9100 PRO suena a pareja perfecta. Entonces preguntamos para qué va a servir la máquina, la respuesta es «sobre todo inferencia» y resulta que el montaje correcto lleva una unidad en lugar de ocho. El almacenamiento en un servidor de IA es la parte de la configuración en la que sobredimensionar es fácil, indoloro para el vendedor y casi completamente invisible para la carga de trabajo.

Este artículo repasa los cuatro niveles reales de almacenamiento dentro de un único servidor de IA, qué tiene que hacer cada uno, qué aspecto tiene el mercado NVMe en 2026, cuándo merece la pena pagar el sobreprecio de Gen5, por qué el RAID por hardware dejó de importar para NVMe y cómo dimensionar cada nivel sin quemar dinero. La elección de sistema de archivos es una cuestión aparte que se trata en L04; el almacenamiento compartido de clúster (NFS, BeeGFS, Lustre, almacenes de objetos) es K04. Aquí nos quedamos dentro del chasis.

Los cuatro niveles de almacenamiento

Un servidor de IA serio tiene cuatro funciones de almacenamiento diferenciadas, con perfiles de tamaño, rendimiento, resistencia y coste radicalmente distintos. Tratarlas como un único pool es el primer error.

Un servidor de inferencia de 4 GPU normalmente solo necesita el primer nivel y, como mucho, una porción del segundo. Una máquina de entrenamiento de 8 GPU necesita los cuatro, y cada uno de ellos pide unidades distintas. La pregunta «¿cuántos TB de NVMe?» carece de sentido si no se elige antes un nivel.

Almacenamiento de modelos

El nivel de modelos es el que guarda su biblioteca de pesos: todas las variantes de Llama, Qwen, Mistral, Stable Diffusion, Flux y Whisper que espere cargar alguna vez. También es donde viven el SO, las imágenes de contenedor, los entornos conda y los binarios del servidor de inferencia. En la mayoría de los montajes, todo eso se concentra en la unidad de arranque.

El dimensionado depende de cuántos modelos mantenga residentes. Algunos ejemplos con cuantizaciones habituales:

• Llama 3 70B Q4: ~40 GB
• Llama 3 70B FP8: ~70 GB
• Qwen2.5-VL 72B Q4: ~45 GB más unos pocos GB de torre de visión
• Mistral Large 2 (123B) Q4: ~70 GB
• Llama 4 Maverick MoE FP8: ~250 GB
• Una biblioteca VLM modesta (8 modelos, cuantizaciones mixtas): 300–500 GB
• Un laboratorio de investigación con 30 modelos calientes: 2–4 TB

Casi todo es lectura. El modelo se carga una vez al arrancar el proceso y vive en la VRAM el resto del día. La unidad ve una lectura secuencial de 40 GB al iniciar vLLM y después queda prácticamente ociosa. Un único NVMe Gen4 de 2–4 TB —incluso una unidad de consumo como una Samsung 990 PRO— se ocupa de esto sin despeinarse. Pague por capacidad, no por rendimiento.

Almacenamiento de datos

El nivel de datos es donde se asientan los corpus de entrenamiento y el material de ajuste fino. Es el nivel que los clientes infradimensionan de forma crónica, porque el conjunto de datos con el que trabajan hoy cabe y se olvidan de que el siguiente no lo hará.

Rangos realistas:

• Corpus de ajuste fino LoRA de un solo dominio: 10–100 GB
• Conjunto de ajuste fino multimodal (imágenes + texto): 1–10 TB
• Corpus de texto a escala de preentrenamiento (subconjunto de FineWeb, etc.): 5–50 TB
• Preentrenamiento de vídeo o conjunto de demostraciones robóticas: 20–200 TB
• Archivo genómico, científico o de scraping web: 100 TB – 1 PB o más

El patrón de acceso es de lectura secuencial, repetida a lo largo de las épocas y en paralelo desde muchos procesos DataLoader. Sensible al rendimiento (porque la GPU está esperando) y tolerante a la latencia. La tasa de escritura es prácticamente cero una vez preparados los datos.

Para conjuntos de datos por encima de ~10 TB, la respuesta correcta suele estar fuera del chasis: vea K04 para los patrones de NFS, BeeGFS y almacén de objetos. Dentro del chasis, un nivel de datos con discos duros en RAIDZ2 (baratos, grandes, lentos pero suficientes una vez que la caché de página se calienta) o un RAID NVMe U.2 de gama media resulta razonable hasta quizá 50 TB.

Scratch

El scratch es el héroe anónimo. Absorbe todo lo que no encaja limpiamente en otro sitio: shards de imagen decodificados, activaciones intermedias volcadas por ZeRO-Offload, cachés de datos creadas por webdataset/DALI, barajados temporales del conjunto de datos, artefactos de compilación de contenedores y el volcado de una ejecución caída. Mucha lectura y mucha escritura al mismo tiempo.

Dimensionado: entre 2 y 8 TB es el punto óptimo. Con menos de 2 TB, un solo ajuste fino lo llena. Con más de 8 TB, lo normal es que esté construyendo un pequeño nivel de datos y llamándolo scratch; está bien, pero reconozca lo que está haciendo.

Aquí la resistencia importa de un modo que no se da en los demás niveles. El scratch devora escrituras: 5–20 TB escritos al día no es raro en una máquina de entrenamiento muy usada. Una unidad empresarial de 1 DWPD y 4 TB permite escribir 4 TB al día durante cinco años; un scratch de entrenamiento serio pide entre 1 y 3 DWPD, de grado mixto.

Checkpoints

El nivel de checkpoints es donde aterriza el estado del entrenamiento. A ráfagas: silencio durante diez minutos, después 50–500 GB escritos en unos segundos y de nuevo silencio.

Un checkpoint de un modelo de 70B en FP16 ocupa ~140 GB de pesos. Con FSDP, los gradientes y el estado del optimizador elevan la huella por checkpoint a 400–700 GB. Con DeepSpeed ZeRO-3 y el estado completo del optimizador (Adam: 8 bytes por parámetro para el maestro FP32 más el primer y el segundo momento), un checkpoint de 70B puede acercarse a 1 TB.

La tasa de escritura sostenida de un único NVMe Gen5 es de ~10–13 GB/s. Un checkpoint de 700 GB se escribe en aproximadamente un minuto, siendo optimistas, siempre que cada rango escriba en su propia unidad. De forma síncrona, el entrenamiento se bloquea durante ese minuto. La solución es el checkpointing asíncrono y fragmentado (lo vemos más abajo).

NVMe Gen4 frente a Gen5: cuándo compensa el sobreprecio

El mercado NVMe de 2026 se reparte entre un Gen4 maduro (5–7 GB/s) y un Gen5 ya generalizado (12–14 GB/s). En lo más alto de la gama de consumo está la Samsung 9100 PRO, con 14.8 GB/s de lectura secuencial y 13.4 GB/s de escritura secuencial. El Gen5 empresarial se mueve en la misma zona —Solidigm D7-PS1010 con 14.5 GB/s de lectura, Micron 9550 MAX con 14 GB/s de lectura, Kioxia CD8, SanDisk DC SN861—, todas ellas con 13–14 GB/s de lectura y 8–10 GB/s de escritura sostenida.

El sobreprecio del Gen5 frente a un Gen4 de capacidad comparable a mediados de 2026 es del 30–50% en la gama de consumo y del 20–35% en la empresarial.

Cuándo se amortiza de verdad el Gen5:

• Carga de modelos en frío. Un modelo MoE de 250 GB se carga en 18 segundos en Gen5 frente a 36 segundos en Gen4. Importa si cambia de modelo a menudo.
• Entrenamiento limitado por E/S. Pipelines de visión que decodifican JPEG en bruto desde disco, conjuntos multimodales en los que el preprocesado es el cuello de botella.
• Checkpoint en NVMe local antes de la copia asíncrona. Cuanto más rápida sea la escritura local, antes se reanuda el entrenamiento.
• Servidor de almacenamiento de clúster que sirve a 8 o más nodos de entrenamiento. La demanda agregada de los clientes supera el techo de Gen4.

Cuándo basta con Gen4 y el Gen5 es dinero tirado:

• Servidores de inferencia. El modelo se carga una vez al arrancar; el resto del día la unidad va a unos pocos MB/s.
• Raíz del SO y almacén de contenedores. Se arranca una vez al mes y de vez en cuando se instalan paquetes.
• Nivel de datos con shards grandes y predecodificados. Un DataLoader de PyTorch con 8 workers leyendo shards de WebDataset se satura quizá en 4–6 GB/s agregados; Gen4 lo cubre.

La versión honesta: alrededor del 70% de los equipos que enviamos a clientes son de inferencia pura, y para esos lo correcto es NVMe Gen4 en todas partes. El Gen5 es una decisión del nivel de entrenamiento.

Formatos: M.2, U.2/U.3, E3.S

El M.2 Gen5 se ralentizará. Una Samsung 9100 PRO de 2 TB sostenida a 13 GB/s en un chasis caliente llega a 75 °C y baja frecuencias. Los modelos con disipador ayudan. El M.2 vale para el arranque y para cargas moderadas; no es el formato adecuado para un nivel de scratch con escritura sostenida.

El U.2 es el caballo de batalla. Todas las unidades NVMe empresariales que Kentino envía en un chasis Bone64c o Supermicro son U.2, prácticamente siempre intercambiables con backplanes U.3. Envolvente térmica de 25 W, doble puerto para multipath, intercambio en caliente, y las capacidades de 7.68 TB y 15.36 TB se sitúan en el punto óptimo de precio por densidad.

El E3.S es el futuro, pero despacio. Diseñado desde cero para las térmicas de Gen5/Gen6. Para un servidor único o un clúster pequeño de Kentino, U.2/U.3 sigue siendo la elección práctica a lo largo de 2026; el E3.S entra en escena en los ciclos de renovación de 2027.

Evite apilar portadoras M.2 en un chasis caliente. Las tarjetas PCIe que alojan cuatro unidades M.2 tras un chip conmutador funcionan, pero en un servidor de 4U con ocho GPU el flujo de aire sobre esas portadoras es malo. Vemos limitación térmica a los diez minutos de carga sostenida. Si necesita cuatro NVMe en un servidor, use U.2.

Resistencia: el DWPD como señal de compra

Para un servidor de IA, la correspondencia es directa:

• Nivel de modelos: intensivo en lectura, 0.3–1 DWPD.
• Nivel de datos: intensivo en lectura, 0.3–1 DWPD.
• Nivel de scratch: uso mixto, 1–3 DWPD. Este es el nivel que justifica su presupuesto de resistencia.
• Nivel de checkpoints: uso mixto, 1–3 DWPD. Las ráfagas de escritura se acumulan; 1 DWPD en una unidad de 4 TB solo permite 4 TB al día, cifra que una cadencia de entrenamiento intensa supera.

La clase intensiva en escritura (3+ DWPD) es excesiva para casi cualquier carga de trabajo de IA. Equivocarse de nivel de resistencia se arregla sustituyendo la unidad; equivocarse de clase de rendimiento, a menudo no. Acierte con el rendimiento en el momento del montaje y trate la resistencia como algo que puede ampliar después.

RAID para NVMe: el hardware ha muerto, la respuesta es el software

Esto merece su propio apartado porque los clientes siguen preguntándolo. La versión corta: si su equipo lleva una controladora RAID por hardware delante de unidades NVMe en 2026, está mal configurado.

Las controladoras RAID por hardware (LSI/Broadcom MegaRAID, Microchip SmartRAID, HPE Smart Array, Dell PERC) se diseñaron para SAS/SATA. El ASIC integrado de la controladora se encarga de la paridad, la caché y las colas de comandos y, al ancho de banda de SAS (12 Gbit/s = 1.5 GB/s), le sobra margen.

El NVMe Gen5 a 14 GB/s por unidad satura una controladora RAID de una sola tarjeta a partir de dos unidades. Ocho unidades detrás de una tarjeta RAID por hardware producen más ancho de banda del que puede mover el enlace PCIe de la tarjeta. La controladora se convierte en el cuello de botella y, después, en el punto de fallo.

Las respuestas prácticas son de software:

• mdadm (RAID por software de Linux). Maduro, integrado en el kernel, con buen soporte de RAID0/1/10. El RAID5/6 sobre NVMe funciona, pero el cálculo de paridad se come la CPU. Para 4 NVMe en espejo o en stripe: perfecto.
• ZFS RAIDZ2. Mejor en integridad (sumas de comprobación de extremo a extremo), mejores herramientas para scrubs y sustituciones, y semántica de instantáneas y clones. Más exigente con la CPU que mdadm. Es la elección adecuada para los niveles de archivo y de datos, donde la integridad importa más que el rendimiento máximo.
• Replicación por unidad o codificación de borrado en la capa de aplicación. Para arrays muy grandes, el EC de MinIO/Ceph o el striping de BeeGFS sacan por completo la decisión de redundancia de la capa de bloques.

Para la mayoría de los montajes de Kentino:

• Arranque: 2× NVMe M.2 en mdadm RAID1.
• Scratch: RAID0 entre 2–4 NVMe (los datos son regenerables).
• Datos/checkpoints: RAID10 con mdadm o RAIDZ2 con ZFS.

Al RAID por hardware le queda exactamente un caso de uso en un servidor de IA: un pequeño espejo de arranque detrás de una tarjeta Broadcom/MegaRAID básica, en un servidor en el que quiera a toda costa redundancia arrancable antes del SO. Incluso ahí, mdadm RAID1 con EFI en ambas unidades funciona perfectamente.

Almacenamiento en red para el nivel de datos

La conclusión: por encima de 10 TB, el nivel de datos casi siempre pertenece fuera del servidor de IA. Dentro del chasis quiere un scratch rápido, un checkpoint rápido y un almacén de modelos; los datos pueden estar en remoto.

Cómo carga datos PyTorch en realidad

Un buen modelo mental para dimensionar el almacenamiento es seguir lo que hace el DataLoader de PyTorch. Con num_workers=8 y pin_memory=True:

1. Ocho procesos worker abren en paralelo archivos del conjunto de datos.
2. Cada worker lee, decodifica (JPEG, fotogramas de vídeo, remuestreo de audio) y tensoriza una muestra.
3. El tensor decodificado se coloca en memoria compartida.
4. El proceso principal extrae de la cola compartida, fija en la RAM del host y copia a la GPU por DMA.

Las implicaciones prácticas:

• Un pipeline de visión rara vez está limitado por el almacenamiento, salvo que el conjunto de datos sea tan grande que la caché de página no pueda mantener el conjunto de trabajo.
• Un pipeline de preentrenamiento de LLM que lee shards pretokenizados sí suele estar limitado por el almacenamiento en Gen4. Gen5 ayuda. También ayuda poner el conjunto de shards activo en NVMe local en lugar de en NFS.
• La inferencia prácticamente nunca está limitada por el almacenamiento una vez cargado el modelo. El medidor de actividad de disco de una máquina de servicio está plano.

El precipicio de los checkpoints

Un checkpoint de un modelo de 70B en FP16 ocupa 140 GB de pesos. Añada el estado del optimizador Adam (~8 bytes por parámetro para el maestro FP32 más el primer y el segundo momento): ~560 GB más. Añada los gradientes si captura la instantánea a mitad de paso: ~140 GB más. Un checkpoint «completo» de 70B puede alcanzar entre 800 GB y 1 TB según lo que guarde.

Checkpoint síncrono, en el que un solo rango lo escribe todo en un único NVMe Gen5 a 13 GB/s de escritura sostenida: ~75 segundos para un checkpoint de 1 TB. El entrenamiento se bloquea durante todo ese tiempo. Hacerlo cada 100 pasos cuando cada paso tarda 5 segundos significa que acaba de hacer el entrenamiento un 15% más lento.

Dos soluciones, ambas imprescindibles:

1. Checkpointing fragmentado. Cada rango de FSDP escribe su propio fragmento en su propio NVMe local. Con 8 GPU y 8 unidades locales, la escritura por rango es de 125 GB y las escrituras se paralelizan. El tiempo real baja a ~10 segundos.

2. Checkpointing asíncrono. El DCP de PyTorch (torch.distributed.checkpoint) descarga la escritura a un hilo de CPU. La GPU se detiene brevemente para la copia de preparación de GPU a CPU (unos segundos), después el entrenamiento se reanuda y la escritura real en el almacenamiento ocurre en segundo plano.

La combinación —asíncrono y fragmentado— convierte el almacenamiento de checkpoints de «debe absorber 1 TB en segundos» en «debe seguir el ritmo de una copia de fondo estable de unos cientos de MB/s». Eso lo soporta casi cualquier nivel de almacenamiento. El error que hay que evitar: checkpoints síncronos, con el estado completo por rango, escritos directamente en NFS. Eso era normal en 2022. En 2026 es una negligencia.

Configuraciones concretas de almacenamiento de Kentino AI

Servidor de inferencia de 4 GPU (p. ej. Kentino AI 192 Genoa, 4× RTX 5090 o 4× RTX Pro 6000 Blackwell):

Arranque + modelos: 1× NVMe M.2 Gen5 de 2 TB (consumo o empresarial intensivo en lectura)
Scratch:            opcional, a menudo innecesario para inferencia pura
Datos:              no hace falta en la máquina
Checkpoints:        no hacen falta en la máquina

Total: 2 TB de NVMe. Coste: bajo. Suficiente para cualquier carga de inferencia.

Servidor de entrenamiento de 8 GPU (p. ej. Kentino AI 256 Turin Dual, 8× RTX 5090 u 8× RTX Pro 6000):

Arranque:        2× NVMe M.2 de 480 GB, mdadm RAID1, ext4 → /
Almacén modelos: 2× NVMe U.2 Gen5 de 4 TB, mdadm RAID1, ext4 → /models
Scratch:         2× NVMe U.2 Gen5 de 8 TB, mdadm RAID0, XFS → /scratch
Checkpoints:     2× NVMe U.2 Gen5 de 8 TB, mdadm RAID10, XFS → /checkpoints
Datos:           montaje NFS desde servidor de almacenamiento externo, 100 GbE

Total de NVMe local: ~36 TB. Coste: notable, pero acorde al gasto en GPU.

Nodo de almacenamiento compartido del clúster (separado del cómputo):

Arranque:     2× NVMe M.2 de 960 GB, RAID1, ext4
Nivel caliente: 12× NVMe U.2 Gen5 de 7.68 TB, ZFS RAIDZ2 o destino de almacenamiento BeeGFS, XFS
Nivel frío:     8× HDD SAS de 16 TB, ZFS RAIDZ2 → /archive
Red:            2× 100 GbE, con capacidad RoCE o NVMe-oF

Sirve el nivel de datos del clúster. Vea K04 para la elección de FS distribuido.

Hay dos cosas en las que conviene fijarse. El servidor de inferencia tiene una sola unidad. El servidor de entrenamiento tiene cuatro niveles, pero cada unidad está dimensionada para su función, no sobredimensionada para ser la mayor disponible. El nodo de almacenamiento del clúster es una máquina completamente aparte.

Opinión honesta: la mayoría de los clientes sobredimensiona el almacenamiento

Un patrón que vemos lo bastante a menudo como para señalarlo: un cliente monta un servidor de 8 GPU «para que no se quede obsoleto», especifica ocho unidades NVMe U.2 de 15.36 TB porque las bahías están ahí y después ejecuta cargas de inferencia que tocan quizá 200 GB de archivos de modelo y dejan el resto del array ocioso para siempre. 25.000 € de NVMe criándose polvo.

Las reglas honestas de dimensionado:

• Inferencia pura, un solo servidor: 2–4 TB de NVMe en total. Una unidad. Listo.
• Inferencia más ajuste fino ocasional: 4–8 TB en total. Arranque + scratch.
• Entrenamiento serio, un solo servidor: 16–40 TB repartidos entre arranque, modelos, scratch y checkpoints, con los datos fuera, en un NAS o un almacén de objetos.
• Clúster: los datos y los checkpoints pasan al almacenamiento compartido; el NVMe local por nodo se encoge hasta el perfil de inferencia (2–8 TB) para arranque, modelos y scratch de escritura diferida.

El almacenamiento es el único punto de un montaje de IA en el que el instinto de «cuanto más, mejor» se equivoca sistemáticamente. Las GPU escalan en beneficio de forma más o menos lineal con el coste; la RAM escala razonablemente; el almacenamiento, en cambio, a menudo no escala en absoluto una vez que tiene suficiente.

Qué falla

Los modos de fallo que vemos sobre el terreno, por orden:

• La unidad de arranque es un M.2 de consumo sin redundancia. La unidad falla a los 18 meses, el servidor no arranca, los modelos siguen a salvo en el RAID, pero la reconstrucción cuesta un día. Solución: 2× M.2 en mdadm RAID1, incluso en máquinas de inferencia.
• El scratch se llena a mitad de ejecución. La caché de datos, los shards decodificados y los archivos temporales del framework conspiran. Solución: monitorizar, alarma al 80% de ocupación y dimensionar 1.5 veces el mayor conjunto de trabajo previsto.
• Tarjeta RAID por hardware delante del NVMe. El rendimiento es la mitad del que debería, la controladora es un punto único de fallo y sustituirla es un ejercicio exótico. Solución: quitar la tarjeta y usar mdadm o ZFS directamente.
• Checkpoint síncrono a NFS y el entrenamiento se atasca. Solución: checkpoint asíncrono y fragmentado, primero a NVMe local y después copia asíncrona.
• Limitación térmica de un M.2 Gen5. Una unidad homologada a 14 GB/s da 4 GB/s tras 3 minutos de escritura sostenida. Solución: disipador, mejor flujo de aire o pasar a U.2.
• Los datos en el nivel de datos saturan el Gen4. El pipeline de entrenamiento de visión está limitado por almacenamiento un 30% del tiempo. Solución: scratch Gen5, predecodificar a WebDataset, o ambas cosas.
• El ARC de ZFS se come la RAM destinada al entrenamiento. La asignación por defecto del 50% provoca un OOM en el proceso de entrenamiento. Solución: limitar zfs_arc_max al 10–20% de la RAM. Vea L04.

---

Esto forma parte de la Kentino Wiki, una serie de referencia sobre cómputo de IA, robótica y los sistemas que los conectan. Comentarios y correcciones bienvenidos en info@kentino.com.