Servir IA generativa 56× más rápido sin comprar GPUs: el paper de IBM, NVIDIA y Supermicro
Cuando el contexto crece, no cabe en la memoria de la GPU. El sistema descarta cálculos antiguos y los rehace en cuanto la sesión vuelve — y ahí se van las peticiones por segundo. IBM, NVIDIA y Supermicro publican en junio de 2026 el Redbook Context Without Limits con las cifras de otra opción: guardar esos cálculos en un almacenamiento compartido rápido. La latencia del primer token baja de 32 s a medio segundo y el sistema atiende 22 veces más peticiones.
Llevamos dos años discutiendo cuántas GPUs hacen falta para servir IA generativa. IBM, NVIDIA y Supermicro cambian la pregunta en el Redbook Context Without Limits (junio de 2026): si la GPU va lenta porque tiene que rehacer cálculos que ya hizo hace un momento, el problema no es cuánta GPU tienes, sino dónde guardas esos cálculos. Moviéndolos a un almacenamiento compartido rápido, sus pruebas dan una respuesta 56 veces más rápida al usuario, 22 veces más peticiones por segundo y un 95 % menos de tiempo total. Aquí explicamos qué han medido, cómo funciona, cuándo compensa y qué opciones tienes si prefieres hacerlo con Ceph en lugar de con IBM.
Un modelo grande (Llama 70B, gpt-oss 120B) con contexto de 100 000 tokens ya no cabe entero en la memoria de la GPU. El sistema tiene que descartar cálculos antiguos y, cuando la sesión vuelve, rehacerlos desde cero — es como releer el libro entero cada vez que respondes una pregunta sobre él. Guardar esos cálculos en un almacenamiento compartido rápido evita esa repetición. Eso es lo que mide el Redbook IBM MD260021 (29 de junio de 2026) con 8 nodos Supermicro, IBM Storage Scale ECE, NVIDIA Dynamo y vLLM 0.14.1.
¿Qué es el KV cache y por qué es el nuevo cuello de botella?
El KV cache (Key-Value cache) es la estructura donde un modelo transformer guarda las claves y valores de atención de cada token del contexto. Sin él, cada nuevo token obligaría a recalcular la atención sobre todo lo anterior; en contextos de 100 000 tokens eso deja de ser viable. Dicho de otra forma: el KV cache es lo que hace posible servir contextos largos con tiempos aceptables.
El problema aparece cuando la HBM de la GPU se llena. La HBM es rapidísima (microsegundos) pero cara y limitada: una NVIDIA H100 tiene 80 GB, una RTX PRO 6000 Blackwell llega a 96 GB. En un modelo de 120 000 millones de parámetros con contexto de 130 000 tokens, un solo request puede consumir 60-80 GB de KV cache. Con varios usuarios simultáneos, la GPU descarta caches antiguos y, si esa sesión vuelve, los recomputa desde cero. Cada recomputación es una pasada completa por el modelo: ciclos de GPU que se van sin producir un solo token nuevo.
Comprar más GPUs añade HBM al cluster, pero cada HBM sigue aislada por GPU. El cache generado para el usuario A no está disponible cuando su siguiente petición cae en la GPU B. Se paga el hardware sin mejorar el hit rate — hasta que el KV cache se mueve a un tier compartido.
¿Cuánto KV cache consume tu despliegue?
Elige un modelo, una longitud de contexto y una concurrencia. La calculadora aplica la fórmula estándar del KV cache y te indica si cabe en la HBM de una GPU típica o si necesitas un tier compartido tipo G4. Los valores por token están sacados de las configuraciones oficiales de cada modelo (Llama 3.1, gpt-oss 120B) — no son estimaciones.
La jerarquía de memoria de NVIDIA Dynamo: G1, G2, G3, G3.5 y G4
NVIDIA Dynamo define cinco tiers de almacenamiento para el KV cache, cada uno con un balance distinto de latencia, capacidad y coste. Los tiers G1-G3 están limitados por el hardware de un nodo. El G4 es el único tier compartido a nivel de cluster — el que permite que un cache generado por la GPU 12 se reutilice cuando la misma sesión aterriza en la GPU 47.
¿Qué pinta aquí IBM Storage Scale ECE?
IBM Storage Scale es el nombre comercial actual de lo que históricamente se llamó GPFS (General Parallel File System). Es un sistema de ficheros paralelo distribuido con más de 25 años en HPC — el mismo que hay detrás de sistemas como Summit o Sierra. ECE (Erasure Code Edition) es la variante software-defined que se despliega sobre servidores commodity, usa erasure coding en vez de RAID clásico y escala a exabytes.
En la arquitectura del Redbook, Storage Scale ECE cumple el rol de tier G4 por seis razones concretas:
- POSIX, S3, NFS, SMB y CSI desde el mismo backend — encaja tanto con vLLM/Dynamo como con pipelines de datos existentes.
- NVIDIA GPUDirect Storage (GDS): transferencia directa storage → GPU sin pasar por CPU, gracias a RDMA sobre Ethernet lossless o InfiniBand.
- Erasure coding 8+2P con 80 % de capacidad útil (vs 50-67 % de RAID6 clásico), sin sacrificar durabilidad.
- Tiering automático NVMe / SSD / HDD / cinta — el KV cache caliente vive en NVMe, el frío baja a HDD.
- Snapshots y clones instantáneos — útil para versionar datasets y checkpoints de entrenamiento.
- Escalado sin rediseño: de 3 nodos a 256 sin cambiar la arquitectura.
Los tres benchmarks del Redbook (medidos, no estimados)
IBM, NVIDIA y Supermicro montaron 8 nodos Supermicro Petascale ASG-1115S-NE316R (AMD EPYC 9535, 16 NVMe Micron E3 de 7,68 TB por nodo, ConnectX-7 a 400 Gb/s), interconectados por tres switches NVIDIA Spectrum-X SN5600 en spine-leaf con uplinks de 800 Gb/s. Como cliente de inferencia, un único nodo Supermicro SYS-212GB-FNR con 4 GPUs RTX PRO 6000 Blackwell. El software: IBM Storage Scale ECE v6.0.0.1 sobre RHEL 9.6, clientes en Ubuntu 24.04, NVIDIA Dynamo v0.9.0+, vLLM v0.14.1 y modelo openai/gpt-oss-120b cuantizado a MXFP4.
Benchmark 1 — Time-to-first-token (TTFT) por longitud de contexto
Los tiers G1 (HBM) y G2 (DRAM) se pusieron a capacidad cero para forzar el escenario: todo el KV cache — 1,4 millones de tokens — pasó por el G4.
Sin KV cache persistente, el tiempo hasta el primer token crece de forma cuadrática con la longitud del prompt. Con Storage Scale se mantiene por debajo del segundo en todo el rango medido. A 130 K tokens son 32 segundos frente a medio segundo: a 32 segundos el usuario ya cerró la pestaña; a medio segundo se queda.
Benchmark 2 — Throughput bajo carga concurrente
200 peticiones sobre el modelo de 120 000 millones de parámetros con 28 conexiones concurrentes (100 prompts únicos, 24 millones de tokens, 825 GB de KV cache):
22× más throughput, 95 % menos tiempo total. Y el cache empezó vacío: la aceleración se fue componiendo a lo largo de las 200 peticiones. Con cache precalentado, la cifra real sería aún mejor.
Benchmark 3 — Bajo estrés de "noisy neighbor"
Cuatro clientes concurrentes generando 200 GB/s de tráfico basura en paralelo, para simular un cluster multi-tenant realista.
18× de mejora bajo estrés, solo 18 % de degradación frente al escenario limpio. Es la prueba de que la arquitectura no colapsa cuando el cluster está lleno.
¿Cuántos nodos, GPUs y ancho de banda necesito?
El propio Redbook publica tres perfiles de dimensionado. Aquí los tienes lado a lado — pulsa el que se parezca a tu caso.
Producción multi-tenant, LLM de 70 B a 120 B parámetros, RAG y multi-turn de contexto largo. Es la configuración exacta que aparece en el Redbook con los 315 GB/s medidos.
En el benchmark del Redbook, la red se convirtió en el cuello de botella antes que el storage: los 8 nodos entregan hasta 315 GB/s de lectura, pero la red 2×400 GbE del lado cliente topa en 80 GB/s. Si vas a montar algo parecido, dimensiona la red del cliente al nivel del storage o las GPUs se pasarán el día esperando datos.
Alternativas open source: Ceph, Lustre, DAOS
La idea que hay detrás del paper — sacar el KV cache a un tier G4 compartido con GPUDirect y RDMA — no depende de IBM. Puedes montarla con otras piezas.
Si ya eres cliente IBM y tienes contrato con SLA, Storage Scale ECE es la opción más rápida de aterrizar. Si construyes desde cero y priorizas coste y control, empieza por Ceph. Si vienes de HPC puro y necesitas 300 GB/s por nodo, Lustre o DAOS son opciones legítimas. Si el diagnóstico no está claro, mejor validarlo antes de encargar el hardware.
La comparativa larga con benchmarks reales de las tres opciones open source la publicamos en julio: Ceph, Lustre o DAOS para IA y HPC.
Seis preguntas que te ahorran hardware
Un tier G4 bien montado devuelve las cifras del paper. Uno mal dimensionado son cientos de miles de euros en hardware caro que se pasa el día esperando datos. Estas seis preguntas separan el caso donde compensa del que no.
Si tu IA generativa va lenta o cuesta demasiado, probablemente la GPU no es la culpable
Trabajamos con IBM Storage Scale, Ceph, Lustre y GPUDirect en sistemas de producción. Somos IBM Business Partner y llevamos más de 15 años con infraestructuras críticas 24/7. Si sospechas que el cuello de botella no está en tu GPU, ayudamos a validar el diagnóstico antes de que se convierta en un proyecto de siete cifras.
Preguntas frecuentes
¿Qué es el KV cache en un LLM?
El KV cache (Key-Value cache) es la estructura donde un modelo transformer guarda las claves y valores de atención calculados para cada token del contexto. Sin él, el modelo tendría que recalcular la atención sobre todos los tokens anteriores en cada nuevo token generado. Es lo que hace viable servir contextos largos.
¿Por qué el KV cache es un cuello de botella para servir LLMs?
Porque la memoria HBM de la GPU es finita (80-96 GB en modelos actuales) y muy cara. Con varias sesiones concurrentes de contexto largo, el KV cache no cabe: la GPU evicta caches antiguos y los recomputa cuando la sesión vuelve, quemando ciclos que podrían generar tokens. La solución es sacar ese cache a un tier de almacenamiento compartido de alta velocidad.
¿Qué es IBM Storage Scale y qué relación tiene con GPFS?
IBM Storage Scale es el nombre actual de lo que se llamó GPFS (General Parallel File System). Es un sistema de ficheros paralelo distribuido de IBM con más de 25 años en HPC. La variante ECE (Erasure Code Edition) es software-defined, se despliega sobre servidores commodity y usa erasure coding en vez de RAID.
¿Puedo hacer lo mismo con Ceph en vez de Storage Scale?
Sí. Sacar el KV cache a un tier G4 compartido con GPUDirect y RDMA es independiente del sistema de ficheros. Ceph, Lustre y DAOS pueden cumplir ese rol. Storage Scale es la opción de menor fricción si ya eres cliente IBM; Ceph es la primera opción cuando se valora coste, control y flexibilidad.
¿Qué es GPUDirect Storage y por qué importa?
GPUDirect Storage (GDS) es una tecnología de NVIDIA que permite mover datos directamente entre el sistema de ficheros y la memoria de la GPU sin pasar por la CPU ni la RAM del host. Evita que la CPU se convierta en el siguiente cuello de botella al mover terabytes de KV cache entre storage y GPU.
¿Cuál es la ganancia realista si aplico esto a mi despliegue?
Depende del perfil de uso. Los 56× y 22× del paper son con contexto extremo (130 K tokens) y KV cache grande (825 GB). Para casos de contexto corto y bajo tráfico concurrente la ganancia es menor. Cuanto más largo el contexto, más multi-turn el uso y más concurrente el tráfico, mayor es el beneficio del tier G4.
¿Necesito NVIDIA Dynamo obligatoriamente?
Para orquestar KV cache multi-tier (G1-G4) con eviction inteligente entre tiers, Dynamo es la herramienta más completa hoy. Puedes construir algo similar con vLLM standalone y un scheduler propio, pero pierdes el KV-aware routing y el offloading transparente vía NIXL. En producción, vLLM + Dynamo + G4 compartido es la combinación más consolidada a agosto de 2026.
Blog!
Nuestra mision
SIXE garantiza que tus infraestructuras basadas en tecnologías IBM®, Red Hat®, Canonical® y SUSE® permanezcan estables, seguras y optimizadas durante todo el tiempo que las necesites.
En SIXE, nos comprometemos con la sostenibilidad. Por eso te ayudamos a diseñar, implementar y mantener soluciones tecnológicas duraderas y eficientes.
