7 min de lectura
La utilización media de las GPU en las empresas ronda el cinco por ciento. El resto permanece inactivo porque los datos primero deben copiarse, almacenarse en staging y posicionarse antes de que una carga de trabajo llegue siquiera a iniciarse. Qumulo y Cisco presentaron el 26 de mayo una arquitectura diseñada precisamente para cerrar esta brecha: hacer que los aceleradores existentes trabajen más rápido, en lugar de comprar otros nuevos.
Lo más importante en resumen
- Liquidez en lugar de compra: El Cloud AI Accelerator pone a disposición de las GPU los datos distribuidos de la empresa en tiempo real, sin replicación ni semanas de staging.
- Conexión en lugar de copia: Los sistemas locales y en la nube se conectan a AWS Bedrock, Azure AI Foundry y Google Vertex AI sin necesidad de copiar datos.
- Cisco como ancla híbrida: La red, la seguridad y la computación UCS sustentan la arquitectura a través de AWS, Azure, Google Cloud y OCI.
Relacionado:AWS y Nvidia: el millón de GPU obliga a los equipos de plataforma / FinOps lo ve todo, pero no puede hacer nada
Lo que han anunciado Qumulo y Cisco
¿Qué es la liquidez de GPU? La liquidez de GPU designa el enfoque de hacer que los procesadores gráficos existentes sean productivos más rápidamente, en lugar de adquirir otros nuevos. Los datos están disponibles sin un largo proceso de staging, de modo que el acelerador comienza antes con el trabajo real. El cuello de botella se desplaza así de la compra de hardware a la cuestión de la rapidez con la que la capacidad existente realiza realmente los cálculos.
El 26 de mayo, Qumulo presentó el Cloud AI Accelerator, y poco después le siguió un segundo componente con la arquitectura CloudBridge, programado antes de la Cisco Live 2026. El núcleo de ambos anuncios es la misma idea: la capacidad de las GPU es cara y escasa, pero en su mayor parte permanece inactiva. No porque falte potencia de cálculo, sino porque los datos no están a tiempo donde el acelerador los necesita.
Técnicamente, la arquitectura agrupa tres componentes existentes de Qumulo: Cloud Native Qumulo, la Cloud Data Fabric y una capa de caché llamada NeuralCache. Juntos, deben entregar datos distribuidos a las GPU como una única fuente lógica a través de entornos locales, edge y múltiples nubes. Cisco aporta la red, la seguridad y, con UCS, la base de computación local. Según el fabricante, la oferta está disponible a través de AWS, Azure, Google Cloud y Oracle Cloud Infrastructure. El calendario no es casualidad: antes de una feria propia, se presentan los componentes que definirán el portfolio del año.
1. La brecha del 95 % es un problema de datos
La cifra clave del anuncio resulta incómoda. Si las GPU, de media, solo están aprovechadas al cinco por ciento, el concepto más caro del presupuesto de IA es el tiempo en el que no ocurre nada. En la mayoría de los casos, esto no se debe a la arquitectura del modelo ni a clusters demasiado pequeños. El problema reside en la canalización previa: los datos se exportan del sistema de origen, se convierten a un formato, se cargan en una capa flash cercana a la GPU y solo entonces se procesan.
Esta observación coincide con lo que los equipos de plataforma conocen por experiencia. Un cluster que espera tres días a sus datos de entrenamiento no es, desde el punto de vista económico, un cluster, sino un pasivo. El debate sobre la escasez de GPU se desplaza así de la compra a la cuestión de cómo de rápido puede trabajar realmente la capacidad existente. Quien el año pasado consiguió presupuesto para aceleradores adicionales debería comprobar primero si los antiguos estaban realmente aprovechados.
2. Conectar en lugar de copiar es la verdadera palanca
El requisito técnico es claro: nada de copias. En lugar de replicar datos en un entorno cercano a la GPU, el acelerador debe conectar directamente los sistemas Qumulo existentes con los servicios de inferencia y entrenamiento de los hyperscalers. Qumulo menciona específicamente AWS Bedrock, Azure AI Foundry y Google Vertex AI como objetivos accesibles sin necesidad de copiar previamente los datos.
La diferencia no es cosmética. Cada copia implica costes de almacenamiento, riesgos de inconsistencia y tiempo. Quien elimina la copia, elimina también las semanas en las que el costoso silicio espera por su «alimento». Para los equipos DACH con ubicaciones distribuidas, hay un segundo punto casi más importante: los datos que no se copian rara vez abandonan su lugar controlado. Esto afecta directamente a las normativas de residencia de datos, que en sectores regulados ya determinan cada decisión arquitectónica.
| Dimensión | Staging clásico | Acelerador de IA en la nube |
|---|---|---|
| Movimiento de datos | Exportación, copia, replicación | Conexión directa sin copia |
| Time-to-GPU | Días a semanas | Minutos en lugar de fase de staging |
| Costes de inactividad | Altos, domina el tiempo muerto | Reducidos por inicio más temprano |
| Alcance | Por región, por nube | AWS, Azure, GCP, OCI más UCS |
3. Lo que aporta Cisco en el entorno híbrido
La asociación con Cisco va más allá de un logo en una diapositiva. Cisco aporta la capa de red y seguridad necesaria para que los datos fluyan de manera rápida y controlada más allá de los límites de la nube y las ubicaciones. Con UCS, se añade una base de computación on-premises que saca el modelo del mundo puramente cloud y lo hace interesante para empresas que no quieren o no pueden trasladar todo a un hyperscaler.
El segundo anuncio, CloudBridge, aborda un punto crítico relacionado: el llamado «impuesto flash». Se refiere al sobrecoste del almacenamiento flash cercano a la GPU, que Qumulo cuantifica en hasta un 400 por ciento. Quien ya no necesita cargar todos los datos de entrenamiento en esta capa tan cara, evita parte de la escasez de hardware sin tener que comprar nueva capacidad. Este es el núcleo económico de toda la historia: no más rendimiento, sino menos desperdicio.
4. Donde la arquitectura alcanza sus límites
Por muy atractiva que suene la promesa, traslada los problemas en lugar de resolverlos. Si se elimina la copia, la red se convierte en el camino crítico. La latencia y el ancho de banda entre la fuente de datos y la GPU determinan entonces si la teoría se traduce en rendimiento real. Es manejable, pero requiere trabajo, y este surge durante la operación, no en la presentación comercial.
Qué queda por verificar
- La latencia de la red se convierte en el nuevo cuello de botella
- Dependencia de la Qumulo-Fabric como base
- Gobernanza más allá de los límites de la nube y la ubicación
Qué aporta claras ventajas
- Sin recopiado, menor riesgo de inconsistencia
- Inicio más rápido de las GPU disponibles
- Multi-nube más opción on-premises a través de UCS
A esto se suma la dependencia. Una data fabric que lo mantiene todo unido se convierte en un fundamento que ya no se puede reemplazar fácilmente. Esto no es un argumento en contra de la arquitectura, pero sí un punto clave para la negociación contractual y la planificación de salida. Quien implemente la fabric debería documentar desde el principio cómo sería una salida, mientras la pregunta aún sea teórica.
Qué deben evaluar ahora los equipos DACH
La prueba más honesta no es la hoja de datos, sino la propia pipeline. Quien quiera saber si la liquidez de GPU aporta algo, debe medir primero su propia time-to-GPU: ¿cuánto tiempo transcurre desde el inicio de un workload hasta el primer batch procesado? Si este intervalo se sitúa en el rango de días, la palanca es real. Si se reduce a minutos, el acelerador resuelve un problema que no existe.
El segundo paso es la cuestión de costes sin marketing. Los costes de las GPU inactivas pueden cuantificarse en cuanto se comparan la utilización y la tarifa por hora. Solo esta cifra decide si la nueva fabric es una inversión o una capa adicional. Un piloto bien diseñado con un workload real, una medición previa de la utilización y una condición clara de cancelación dice más que cualquier arquitectura de referencia. Quien mide ambos aspectos, lleva la discusión con el proveedor a un plano de igualdad, no de presentaciones.
Preguntas frecuentes
¿Qué significa liquidez de GPU?
Se refiere a poner en producción más rápido la capacidad de GPU existente, asegurando que los datos estén disponibles sin largas etapas de preparación. El cuello de botella pasa de la compra de nuevo hardware a la cuestión de cuán pronto pueden trabajar los aceleradores ya disponibles.
¿Tengo que copiar mis datos a la nube?
Según las indicaciones del fabricante, no. El acelerador de IA en la nube conecta directamente los sistemas Qumulo existentes con AWS Bedrock, Azure AI Foundry y Google Vertex AI, sin necesidad de copiar previamente los datos.
¿Qué nubes son compatibles?
Qumulo menciona AWS, Azure, Google Cloud y Oracle Cloud Infrastructure. A través de Cisco UCS, se añade una variante on-premises para configuraciones híbridas.
¿Qué papel juega Cisco?
Cisco proporciona la red, la seguridad y, con UCS, la base de computación on-premises. Esta capa determina si los datos llegan con suficiente rapidez a las GPU, superando los límites entre la nube y las ubicaciones físicas.
¿Para quién resulta rentable este enfoque?
Principalmente para empresas con datos distribuidos y un tiempo medible hasta la GPU (Time-to-GPU) prolongado. Quienes ya inician sus cargas de trabajo en minutos tienen el cuello de botella en otro lugar y apenas se benefician.
Más del MBF Media Network
Fuente de la imagen: Imagen de portada e imágenes del artículo generadas por IA (mayo 2026), certificado C2PA incluido en la imagen
