Lo m\u00e1s importante en resumen<\/h2>\n\n\n- Liquidez en lugar de compra:<\/strong> El Cloud AI Accelerator pone a disposici\u00f3n de las GPU los datos distribuidos de la empresa en tiempo real, sin replicaci\u00f3n ni semanas de staging.<\/li>\n
- Conexi\u00f3n en lugar de copia:<\/strong> Los sistemas locales y en la nube se conectan a AWS Bedrock, Azure AI Foundry y Google Vertex AI sin necesidad de copiar datos.<\/li>\n
- Cisco como ancla h\u00edbrida:<\/strong> La red, la seguridad y la computaci\u00f3n UCS sustentan la arquitectura a trav\u00e9s de AWS, Azure, Google Cloud y OCI.<\/li>\n<\/ul>\n<\/div>\n
Relacionado:<\/span>AWS y Nvidia: el mill\u00f3n de GPU obliga a los equipos de plataforma<\/a> \/<\/span> FinOps lo ve todo, pero no puede hacer nada<\/a><\/p>\nLo que han anunciado Qumulo y Cisco<\/h2>\n
\u00bfQu\u00e9 es la liquidez de GPU?<\/strong> La liquidez de GPU designa el enfoque de hacer que los procesadores gr\u00e1ficos existentes sean productivos m\u00e1s r\u00e1pidamente, en lugar de adquirir otros nuevos. Los datos est\u00e1n 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\u00ed de la compra de hardware a la cuesti\u00f3n de la rapidez con la que la capacidad existente realiza realmente los c\u00e1lculos.<\/p>\nEl 26 de mayo, Qumulo present\u00f3 el Cloud AI Accelerator, y poco despu\u00e9s le sigui\u00f3 un segundo componente con la arquitectura CloudBridge, programado antes de la Cisco Live 2026. El n\u00facleo 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\u00e1lculo, sino porque los datos no est\u00e1n a tiempo donde el acelerador los necesita.<\/p>\n
T\u00e9cnicamente, la arquitectura agrupa tres componentes existentes de Qumulo: Cloud Native Qumulo, la Cloud Data Fabric y una capa de cach\u00e9 llamada NeuralCache. Juntos, deben entregar datos distribuidos a las GPU como una \u00fanica fuente l\u00f3gica a trav\u00e9s de entornos locales, edge y m\u00faltiples nubes. Cisco aporta la red, la seguridad y, con UCS, la base de computaci\u00f3n local. Seg\u00fan el fabricante, la oferta est\u00e1 disponible a trav\u00e9s 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\u00e1n el portfolio del a\u00f1o.<\/p>\n
1. La brecha del 95 % es un problema de datos<\/h2>\n
La cifra clave del anuncio resulta inc\u00f3moda. Si las GPU, de media, solo est\u00e1n aprovechadas al cinco por ciento, el concepto m\u00e1s caro del presupuesto de IA es el tiempo en el que no ocurre nada. En la mayor\u00eda de los casos, esto no se debe a la arquitectura del modelo ni a clusters demasiado peque\u00f1os. El problema reside en la canalizaci\u00f3n 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.<\/p>\n
\n5 %<\/div>\nutilizaci\u00f3n media de las GPU en la empresa; el resto permanece inactivo porque los datos deben prepararse previamente.<\/div>\nFuente: Qumulo, Cloud AI Accelerator Announcement, 26 de mayo de 2026<\/div>\n<\/div>\nEsta observaci\u00f3n coincide con lo que los equipos de plataforma conocen por experiencia. Un cluster que espera tres d\u00edas a sus datos de entrenamiento no es, desde el punto de vista econ\u00f3mico, un cluster, sino un pasivo. El debate sobre la escasez de GPU se desplaza as\u00ed de la compra a la cuesti\u00f3n de c\u00f3mo de r\u00e1pido puede trabajar realmente la capacidad existente. Quien el a\u00f1o pasado consigui\u00f3 presupuesto para aceleradores adicionales deber\u00eda comprobar primero si los antiguos estaban realmente aprovechados.<\/p>\n
2. Conectar en lugar de copiar es la verdadera palanca<\/h2>\n
El requisito t\u00e9cnico 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\u00edficamente AWS Bedrock, Azure AI Foundry y Google Vertex AI como objetivos accesibles sin necesidad de copiar previamente los datos.<\/p>\n
La diferencia no es cosm\u00e9tica. Cada copia implica costes de almacenamiento, riesgos de inconsistencia y tiempo. Quien elimina la copia, elimina tambi\u00e9n las semanas en las que el costoso silicio espera por su \u00abalimento\u00bb. Para los equipos DACH con ubicaciones distribuidas, hay un segundo punto casi m\u00e1s 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\u00f3n arquitect\u00f3nica.<\/p>\n
\n\n\n\nDimensi\u00f3n<\/th>\n Staging cl\u00e1sico<\/th>\n Acelerador de IA en la nube<\/th>\n<\/tr>\n<\/thead>\n \n\nMovimiento de datos<\/strong><\/td>\nExportaci\u00f3n, copia, replicaci\u00f3n<\/td>\n Conexi\u00f3n directa sin copia<\/td>\n<\/tr>\n \nTime-to-GPU<\/strong><\/td>\nD\u00edas a semanas<\/td>\n Minutos en lugar de fase de staging<\/td>\n<\/tr>\n \nCostes de inactividad<\/strong><\/td>\nAltos, domina el tiempo muerto<\/td>\n Reducidos por inicio m\u00e1s temprano<\/td>\n<\/tr>\n \nAlcance<\/strong><\/td>\nPor regi\u00f3n, por nube<\/td>\n AWS, Azure, GCP, OCI m\u00e1s UCS<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n![\"Representaci\u00f3n](\"https:\/\/www.cloudmagazin.com\/wp-content\/uploads\/2026\/05\/post-iav0-hero-2.jpg\")
Conectar en lugar de copiar: conexi\u00f3n directa de datos fuente on-premises a servicios de GPU en tiempo real.<\/figcaption><\/figure>\n3. Lo que aporta Cisco en el entorno h\u00edbrido<\/h2>\n
La asociaci\u00f3n con Cisco va m\u00e1s all\u00e1 de un logo en una diapositiva. Cisco aporta la capa de red y seguridad necesaria para que los datos fluyan de manera r\u00e1pida y controlada m\u00e1s all\u00e1 de los l\u00edmites de la nube y las ubicaciones. Con UCS, se a\u00f1ade una base de computaci\u00f3n 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.<\/p>\n
El segundo anuncio, CloudBridge, aborda un punto cr\u00edtico relacionado: el llamado \u00abimpuesto flash\u00bb. 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\u00facleo econ\u00f3mico de toda la historia: no m\u00e1s rendimiento, sino menos desperdicio.<\/p>\n
4. Donde la arquitectura alcanza sus l\u00edmites<\/h2>\n
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\u00edtico. La latencia y el ancho de banda entre la fuente de datos y la GPU determinan entonces si la teor\u00eda se traduce en rendimiento real. Es manejable, pero requiere trabajo, y este surge durante la operaci\u00f3n, no en la presentaci\u00f3n comercial.<\/p>\n
\n\nQu\u00e9 queda por verificar<\/p>\n
\n- La latencia de la red se convierte en el nuevo cuello de botella<\/li>\n
- Dependencia de la Qumulo-Fabric como base<\/li>\n
- Gobernanza m\u00e1s all\u00e1 de los l\u00edmites de la nube y la ubicaci\u00f3n<\/li>\n<\/ul>\n<\/div>\n\n
Qu\u00e9 aporta claras ventajas<\/p>\n
\n- Sin recopiado, menor riesgo de inconsistencia<\/li>\n
- Inicio m\u00e1s r\u00e1pido de las GPU disponibles<\/li>\n
- Multi-nube m\u00e1s opci\u00f3n on-premises a trav\u00e9s de UCS<\/li>\n<\/ul>\n<\/div>\n<\/div>\n
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\u00e1cilmente. Esto no es un argumento en contra de la arquitectura, pero s\u00ed un punto clave para la negociaci\u00f3n contractual y la planificaci\u00f3n de salida. Quien implemente la fabric deber\u00eda documentar desde el principio c\u00f3mo ser\u00eda una salida, mientras la pregunta a\u00fan sea te\u00f3rica.<\/p>\n
Qu\u00e9 deben evaluar ahora los equipos DACH<\/h2>\n
La prueba m\u00e1s 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: \u00bfcu\u00e1nto tiempo transcurre desde el inicio de un workload hasta el primer batch procesado? Si este intervalo se sit\u00faa en el rango de d\u00edas, la palanca es real. Si se reduce a minutos, el acelerador resuelve un problema que no existe.<\/p>\n
El segundo paso es la cuesti\u00f3n de costes sin marketing. Los costes de las GPU inactivas pueden cuantificarse en cuanto se comparan la utilizaci\u00f3n y la tarifa por hora. Solo esta cifra decide si la nueva fabric es una inversi\u00f3n o una capa adicional. Un piloto bien dise\u00f1ado con un workload real, una medici\u00f3n previa de la utilizaci\u00f3n y una condici\u00f3n clara de cancelaci\u00f3n dice m\u00e1s que cualquier arquitectura de referencia. Quien mide ambos aspectos, lleva la discusi\u00f3n con el proveedor a un plano de igualdad, no de presentaciones.<\/p>\n
Preguntas frecuentes<\/h2>\n\n\u00bfQu\u00e9 significa liquidez de GPU?<\/strong><\/summary>\nSe refiere a poner en producci\u00f3n m\u00e1s r\u00e1pido la capacidad de GPU existente, asegurando que los datos est\u00e9n disponibles sin largas etapas de preparaci\u00f3n. El cuello de botella pasa de la compra de nuevo hardware a la cuesti\u00f3n de cu\u00e1n pronto pueden trabajar los aceleradores ya disponibles.<\/p>\n<\/details>\n\n\u00bfTengo que copiar mis datos a la nube?<\/strong><\/summary>\nSeg\u00fan 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.<\/p>\n<\/details>\n\n\u00bfQu\u00e9 nubes son compatibles?<\/strong><\/summary>\nQumulo menciona AWS, Azure, Google Cloud y Oracle Cloud Infrastructure. A trav\u00e9s de Cisco UCS, se a\u00f1ade una variante on-premises para configuraciones h\u00edbridas.<\/p>\n<\/details>\n\n\u00bfQu\u00e9 papel juega Cisco?<\/strong><\/summary>\nCisco proporciona la red, la seguridad y, con UCS, la base de computaci\u00f3n on-premises. Esta capa determina si los datos llegan con suficiente rapidez a las GPU, superando los l\u00edmites entre la nube y las ubicaciones f\u00edsicas.<\/p>\n<\/details>\n\n\u00bfPara qui\u00e9n resulta rentable este enfoque?<\/strong><\/summary>\nPrincipalmente 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.<\/p>\n<\/details>\n
- \n
- Liquidez en lugar de compra:<\/strong> El Cloud AI Accelerator pone a disposici\u00f3n de las GPU los datos distribuidos de la empresa en tiempo real, sin replicaci\u00f3n ni semanas de staging.<\/li>\n
- Conexi\u00f3n en lugar de copia:<\/strong> Los sistemas locales y en la nube se conectan a AWS Bedrock, Azure AI Foundry y Google Vertex AI sin necesidad de copiar datos.<\/li>\n
- Cisco como ancla h\u00edbrida:<\/strong> La red, la seguridad y la computaci\u00f3n UCS sustentan la arquitectura a trav\u00e9s de AWS, Azure, Google Cloud y OCI.<\/li>\n<\/ul>\n<\/div>\n
Relacionado:<\/span>AWS y Nvidia: el mill\u00f3n de GPU obliga a los equipos de plataforma<\/a> \/<\/span> FinOps lo ve todo, pero no puede hacer nada<\/a><\/p>\n
Lo que han anunciado Qumulo y Cisco<\/h2>\n
\u00bfQu\u00e9 es la liquidez de GPU?<\/strong> La liquidez de GPU designa el enfoque de hacer que los procesadores gr\u00e1ficos existentes sean productivos m\u00e1s r\u00e1pidamente, en lugar de adquirir otros nuevos. Los datos est\u00e1n 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\u00ed de la compra de hardware a la cuesti\u00f3n de la rapidez con la que la capacidad existente realiza realmente los c\u00e1lculos.<\/p>\n
El 26 de mayo, Qumulo present\u00f3 el Cloud AI Accelerator, y poco despu\u00e9s le sigui\u00f3 un segundo componente con la arquitectura CloudBridge, programado antes de la Cisco Live 2026. El n\u00facleo 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\u00e1lculo, sino porque los datos no est\u00e1n a tiempo donde el acelerador los necesita.<\/p>\n
T\u00e9cnicamente, la arquitectura agrupa tres componentes existentes de Qumulo: Cloud Native Qumulo, la Cloud Data Fabric y una capa de cach\u00e9 llamada NeuralCache. Juntos, deben entregar datos distribuidos a las GPU como una \u00fanica fuente l\u00f3gica a trav\u00e9s de entornos locales, edge y m\u00faltiples nubes. Cisco aporta la red, la seguridad y, con UCS, la base de computaci\u00f3n local. Seg\u00fan el fabricante, la oferta est\u00e1 disponible a trav\u00e9s 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\u00e1n el portfolio del a\u00f1o.<\/p>\n
1. La brecha del 95 % es un problema de datos<\/h2>\n
La cifra clave del anuncio resulta inc\u00f3moda. Si las GPU, de media, solo est\u00e1n aprovechadas al cinco por ciento, el concepto m\u00e1s caro del presupuesto de IA es el tiempo en el que no ocurre nada. En la mayor\u00eda de los casos, esto no se debe a la arquitectura del modelo ni a clusters demasiado peque\u00f1os. El problema reside en la canalizaci\u00f3n 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.<\/p>\n
\n5 %<\/div>\nutilizaci\u00f3n media de las GPU en la empresa; el resto permanece inactivo porque los datos deben prepararse previamente.<\/div>\nFuente: Qumulo, Cloud AI Accelerator Announcement, 26 de mayo de 2026<\/div>\n<\/div>\nEsta observaci\u00f3n coincide con lo que los equipos de plataforma conocen por experiencia. Un cluster que espera tres d\u00edas a sus datos de entrenamiento no es, desde el punto de vista econ\u00f3mico, un cluster, sino un pasivo. El debate sobre la escasez de GPU se desplaza as\u00ed de la compra a la cuesti\u00f3n de c\u00f3mo de r\u00e1pido puede trabajar realmente la capacidad existente. Quien el a\u00f1o pasado consigui\u00f3 presupuesto para aceleradores adicionales deber\u00eda comprobar primero si los antiguos estaban realmente aprovechados.<\/p>\n
2. Conectar en lugar de copiar es la verdadera palanca<\/h2>\n
El requisito t\u00e9cnico 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\u00edficamente AWS Bedrock, Azure AI Foundry y Google Vertex AI como objetivos accesibles sin necesidad de copiar previamente los datos.<\/p>\n
La diferencia no es cosm\u00e9tica. Cada copia implica costes de almacenamiento, riesgos de inconsistencia y tiempo. Quien elimina la copia, elimina tambi\u00e9n las semanas en las que el costoso silicio espera por su \u00abalimento\u00bb. Para los equipos DACH con ubicaciones distribuidas, hay un segundo punto casi m\u00e1s 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\u00f3n arquitect\u00f3nica.<\/p>\n
\n\n\n
\n \nDimensi\u00f3n<\/th>\n Staging cl\u00e1sico<\/th>\n Acelerador de IA en la nube<\/th>\n<\/tr>\n<\/thead>\n \n Movimiento de datos<\/strong><\/td>\n Exportaci\u00f3n, copia, replicaci\u00f3n<\/td>\n Conexi\u00f3n directa sin copia<\/td>\n<\/tr>\n \n Time-to-GPU<\/strong><\/td>\n D\u00edas a semanas<\/td>\n Minutos en lugar de fase de staging<\/td>\n<\/tr>\n \n Costes de inactividad<\/strong><\/td>\n Altos, domina el tiempo muerto<\/td>\n Reducidos por inicio m\u00e1s temprano<\/td>\n<\/tr>\n \n Alcance<\/strong><\/td>\n Por regi\u00f3n, por nube<\/td>\n AWS, Azure, GCP, OCI m\u00e1s UCS<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Conectar en lugar de copiar: conexi\u00f3n directa de datos fuente on-premises a servicios de GPU en tiempo real.<\/figcaption><\/figure>\n 3. Lo que aporta Cisco en el entorno h\u00edbrido<\/h2>\n
La asociaci\u00f3n con Cisco va m\u00e1s all\u00e1 de un logo en una diapositiva. Cisco aporta la capa de red y seguridad necesaria para que los datos fluyan de manera r\u00e1pida y controlada m\u00e1s all\u00e1 de los l\u00edmites de la nube y las ubicaciones. Con UCS, se a\u00f1ade una base de computaci\u00f3n 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.<\/p>\n
El segundo anuncio, CloudBridge, aborda un punto cr\u00edtico relacionado: el llamado \u00abimpuesto flash\u00bb. 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\u00facleo econ\u00f3mico de toda la historia: no m\u00e1s rendimiento, sino menos desperdicio.<\/p>\n
4. Donde la arquitectura alcanza sus l\u00edmites<\/h2>\n
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\u00edtico. La latencia y el ancho de banda entre la fuente de datos y la GPU determinan entonces si la teor\u00eda se traduce en rendimiento real. Es manejable, pero requiere trabajo, y este surge durante la operaci\u00f3n, no en la presentaci\u00f3n comercial.<\/p>\n
\n\nQu\u00e9 queda por verificar<\/p>\n
- \n
- La latencia de la red se convierte en el nuevo cuello de botella<\/li>\n
- Dependencia de la Qumulo-Fabric como base<\/li>\n
- Gobernanza m\u00e1s all\u00e1 de los l\u00edmites de la nube y la ubicaci\u00f3n<\/li>\n<\/ul>\n<\/div>\n\n
Qu\u00e9 aporta claras ventajas<\/p>\n
- \n
- Sin recopiado, menor riesgo de inconsistencia<\/li>\n
- Inicio m\u00e1s r\u00e1pido de las GPU disponibles<\/li>\n
- Multi-nube m\u00e1s opci\u00f3n on-premises a trav\u00e9s de UCS<\/li>\n<\/ul>\n<\/div>\n<\/div>\n
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\u00e1cilmente. Esto no es un argumento en contra de la arquitectura, pero s\u00ed un punto clave para la negociaci\u00f3n contractual y la planificaci\u00f3n de salida. Quien implemente la fabric deber\u00eda documentar desde el principio c\u00f3mo ser\u00eda una salida, mientras la pregunta a\u00fan sea te\u00f3rica.<\/p>\n
Qu\u00e9 deben evaluar ahora los equipos DACH<\/h2>\n
La prueba m\u00e1s 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: \u00bfcu\u00e1nto tiempo transcurre desde el inicio de un workload hasta el primer batch procesado? Si este intervalo se sit\u00faa en el rango de d\u00edas, la palanca es real. Si se reduce a minutos, el acelerador resuelve un problema que no existe.<\/p>\n
El segundo paso es la cuesti\u00f3n de costes sin marketing. Los costes de las GPU inactivas pueden cuantificarse en cuanto se comparan la utilizaci\u00f3n y la tarifa por hora. Solo esta cifra decide si la nueva fabric es una inversi\u00f3n o una capa adicional. Un piloto bien dise\u00f1ado con un workload real, una medici\u00f3n previa de la utilizaci\u00f3n y una condici\u00f3n clara de cancelaci\u00f3n dice m\u00e1s que cualquier arquitectura de referencia. Quien mide ambos aspectos, lleva la discusi\u00f3n con el proveedor a un plano de igualdad, no de presentaciones.<\/p>\n
Preguntas frecuentes<\/h2>\n
\n\u00bfQu\u00e9 significa liquidez de GPU?<\/strong><\/summary>\n
Se refiere a poner en producci\u00f3n m\u00e1s r\u00e1pido la capacidad de GPU existente, asegurando que los datos est\u00e9n disponibles sin largas etapas de preparaci\u00f3n. El cuello de botella pasa de la compra de nuevo hardware a la cuesti\u00f3n de cu\u00e1n pronto pueden trabajar los aceleradores ya disponibles.<\/p>\n<\/details>\n
\n\u00bfTengo que copiar mis datos a la nube?<\/strong><\/summary>\n
Seg\u00fan 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.<\/p>\n<\/details>\n
\n\u00bfQu\u00e9 nubes son compatibles?<\/strong><\/summary>\n
Qumulo menciona AWS, Azure, Google Cloud y Oracle Cloud Infrastructure. A trav\u00e9s de Cisco UCS, se a\u00f1ade una variante on-premises para configuraciones h\u00edbridas.<\/p>\n<\/details>\n
\n\u00bfQu\u00e9 papel juega Cisco?<\/strong><\/summary>\n
Cisco proporciona la red, la seguridad y, con UCS, la base de computaci\u00f3n on-premises. Esta capa determina si los datos llegan con suficiente rapidez a las GPU, superando los l\u00edmites entre la nube y las ubicaciones f\u00edsicas.<\/p>\n<\/details>\n
\n\u00bfPara qui\u00e9n resulta rentable este enfoque?<\/strong><\/summary>\n
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.<\/p>\n<\/details>\n
- Conexi\u00f3n en lugar de copia:<\/strong> Los sistemas locales y en la nube se conectan a AWS Bedrock, Azure AI Foundry y Google Vertex AI sin necesidad de copiar datos.<\/li>\n