La caché KV sale de la GPU: Scality mete el almacenamiento en la ruta de inferencia

Qué pasó

El 8 de octubre de 2026, la empresa de infraestructura de datos Scality anunció en San Francisco la disponibilidad inmediata de AI Inference Factory. Es una pila de software de código abierto para que empresas, organismos públicos y proveedores neo-cloud desplieguen y operen inferencia de IA en infraestructura propia; según el comunicado, una alternativa con soporte a los servicios de IA en la nube, sin ensamblar toda la pila desde cero.

La pila tiene cuatro partes: modelos abiertos validados y mantenidos dentro de la pila; una capa de servicio de inferencia desagregada, con prefill y decode escalando por separado; un plano de control con autenticación, medición, enrutamiento a las GPU con el contexto relevante y planificación por SLA; y Scality ADI, una infraestructura de gestión autónoma de datos con gobernanza de políticas que actúa como capa de almacenamiento compartido.

Se ofrece como licencia de software o servicio totalmente gestionado, y se demostró en el Scality Day de París el 8 de octubre. Scality dice que valida, distribuye y mantiene la pila integrada para seguir el ritmo de modelos, tecnologías de servicio y requisitos de seguridad.

[1]

Por qué ahora

El comunicado resume la motivación en tres cuentas. Primera: con el precio por token en la nube, cuanto más útil el flujo de trabajo, más impredecible la factura, e imposible de topar. Segunda: versiones y cuantizaciones pueden cambiar a discreción del proveedor, arrastrando los flujos construidos encima. Tercera: dónde se procesan prompts, documentos y código propietario, bajo qué jurisdicción y quién puede cortar el acceso; las tres preguntas de soberanía para datos sensibles y regulados. La apuesta de Scality: la mayoría acabará en híbrido, con los procesos críticos on-premises.

El comunicado cita a la analista de IDC Nataliya Yezhkova: donde la infraestructura pueda alojar y servir el estado del modelo con eficiencia, la inferencia local es una opción creíble para cada vez más cargas empresariales y del sector público. Nota: es una cita de respaldo dentro del comunicado del fabricante, no un informe independiente de IDC.

[1]

La sustancia técnica

Lo más sólido es el diseño de Scality ADI como capa compartida de caché KV. En inferencia, la caché KV crece con la longitud de contexto y desborda rápido la HBM de la GPU; lo convencional es dejarla en el servidor GPU donde nació. Scality propone: ADI ofrece una caché compartida multipetabyte que las GPU leen con latencia del mismo orden que la memoria GPU, restaurando contexto desde almacenamiento en vez de recomputarlo, con mejor utilización de GPU y menor coste.

Acompañado de desagregación prefill/decode: un pool de GPU solo hace prefill y escribe la caché KV en ADI; otro solo hace decode, leyéndola para generar tokens. Cualquier GPU de decode puede tomar cualquier contexto, el prefill ya no interrumpe al decode y ambos pools van a plena carga.

Merece citarse al CTO Giorgio Regni: la caché KV en ADI es lo bastante rápida para estar en la ruta de servicio; restaurar un contexto desde ADI es del mismo orden que la memoria GPU y 14 veces más rápido que recomputarlo, con las GPU ocupadas todo el tiempo; el almacenamiento ya no es motivo para dejar la caché KV dentro del servidor GPU. El CEO Jérôme Lecat enmarca la narrativa de soberanía: las organizaciones necesitan más control sobre dónde corre la inferencia, cómo se gestionan los modelos y qué pasa con sus datos.

[1]

Leyendo los números

Scality publicó cifras de sus propias pruebas, sin verificación independiente: Gemma-3 27B carga en 1,9 segundos vía RDMA en paralelo en el clúster, unas 10 veces el NVMe local; 166 ms de warm time-to-first-token restaurando un contexto de 14K tokens desde ADI, solo 83 ms tras HBM; recuperación de caché KV 14 veces más rápida que recomputar a 14K y 72 veces a 439K; caché de más de 80 veces la memoria de una GPU, con 1.000 sesiones concurrentes reanudables sin recomputar; 97% de la velocidad de línea entre GPU y almacenamiento; contexto restaurado antes del primer token, sin impacto medible en la generación.

Para la desagregación en sí, el comunicado cita dos estudios públicos de terceros: DistServe (OSDI 2024), hasta 7,4 veces más peticiones con los mismos objetivos de latencia; Mooncake, 75% más peticiones en tráfico de producción de Kimi. Son cifras de investigación pública, no pruebas de Scality; hay que separarlas de los números del fabricante.

Las condiciones de punto dulce son explícitas: 14K y 439K son las longitudes elegidas por el comunicado; el impacto no medible depende de que la restauración complete antes del primer token, sin distribución de latencia de cola publicada. Hasta que haya reproducción de terceros, la planificación de capacidad debe descontar las cifras del fabricante y exigir mediciones con tu propia distribución de contextos.

[1]

Soberanía y apertura

La lista de compatibilidad es amplia: frameworks OpenCode, Hermes, Goose, LangGraph y Pydantic AI; modelos abiertos validados como Mistral, Gemma, gpt-oss, Qwen, Kimi, GLM y DeepSeek; servidores estándar de Dell, HPE, Lenovo y Supermicro. Todo se entrega como código abierto: el cliente puede inspeccionar cómo se almacena y mueve el estado de inferencia y proponer contribuciones, pero Scality las revisa; la apertura es real, y el guardián también.

Dos cuentas que saldar. Primera: código abierto con revisión de Scality no es lo mismo que open source comunitario puro; se acerca más al open source comercial con tronco controlado por el fabricante. Hay que preguntar por criterios de revisión, SLA de parches de seguridad y límites de soporte tras un fork. Segunda: cuando la caché KV se vuelve un activo persistente, auditable y portable entre GPU, prompts y documentos descansan en almacenamiento compartido como caché; políticas de residencia, cifrado, auditoría de acceso y semántica de borrado deben reconstruirse; el comunicado promete gobernanza de políticas y ciclos de vida aprobados por humanos en ADI, pero calla los mecanismos, justo el detalle que un comprador regulado debe atar antes de firmar.

[1]

Implicaciones y acciones

Tres implicaciones para equipos que evalúan inferencia local o soberana. Primera: cambian las variables de optimización de coste; tasa de aciertos de caché KV, latencia de restauración y reparto prefill/decode pesan ya tanto como cuántas GPU comprar; exige al fabricante mediciones con tu distribución de contextos, no los números de punto dulce del comunicado.

Segunda: el plano de control decide la pila; autenticación, medición, enrutamiento y planificación por SLA determinan si la inferencia local es un servicio operable o un montón de GPU desnudas; que Scality lo ponga entre las cuatro partes muestra que entiende la lógica de compra enterprise, y el comprador debería recepcionar con la misma lista.

Tercera: tres cosas no se pueden afirmar aún; sin reproducción independiente, descuenta las cifras en tu planificación; cero clientes publicados, así que estabilidad en producción y rutas de actualización son incógnitas; y la pila local cambia la factura por token por costes fijos de depreciación, energía y operaciones: más predecible no es más barato, y el TCO necesita tus propios datos de carga. La narrativa de soberanía debe aterrizar en el plano de datos: los pesos abiertos son solo el primer paso; la residencia y jurisdicción de caché KV, prompts y logs de auditoría son la verdadera prueba.

[1]