De comprar GPUs a venderlas como servicio: el reto ahora es la plataforma
El debate sobre las nubes de GPU ha dejado atras la escasez de tarjetas y se ha mudado a como montar la plataforma que las convierte en un servicio multiusuario, seguro y elastico
El problema de las nubes de GPU ha cambiado de sitio. Durante un par de anos la pregunta era si conseguías las tarjetas; ahora que muchos operadores las tienen en el rack o de camino, el reto es otro: convertirlas en un servicio que los clientes puedan comprar. Red Hat lo llama el reto de las neoclouds y sostiene que el hardware era solo el principio.
El contexto lo dibujan los acuerdos recientes. Nebius cerro un contrato de 17.400 millones de dolares con Microsoft y CoreWeave ha firmado infraestructura con Microsoft y OpenAI. La lectura que hace el fabricante es que los grandes usan estas nubes como proxy de capacidad ajena para tapar huecos, no como plataforma nativa. Eso las obliga a ofrecer infraestructura multiusuario, elastica y consumible por API.
Lo dificil esta debajo
Integrar aceleradores en un Kubernetes basico no basta. En entrenamiento distribuido, el interes se ha ido a la red: RDMA, GPUDirect y tejidos de alto ancho de banda que saltan la CPU del host para que esta no se convierta en el cuello de botella. El planificador tiene que saber de topologia, porque colocar un job multi-GPU sin mirar las conexiones NVLink y el tejido NVSwitch deja rendimiento en la mesa.
Los fallos ademas cuestan distinto que en una nube de proposito general. Un entrenamiento de varios dias que se cae quema horas de GPU y desgasta la confianza del cliente. Y la multitenencia va mas alla de los namespaces: el aislamiento tiene que llegar a la memoria de GPU, a los dominios NVLink y a la salud de la tarjeta. Encima, el comprador empresarial o publico trae sus normativas, ya sean FIPS y FedRAMP en Estados Unidos o ISO 27001, BSI C5 y GDPR fuera, y esa inversión en cumplimiento suele llevar mas tiempo del que el operador calcula. Todo esto sin que el trabajo se detenga: el firmware de las GPUs se actualiza en una flota viva y las arquitecturas nuevas piden cambios de driver y de planificador. Cuando eso esta resuelto, los clientes empiezan a pedir GPUs fraccionadas, confidential computing y endpoints Model-as-a-Service. La plataforma nunca esta terminada.
Construir o comprar es una pregunta sobre tiempo
Cada mes de desarrollo es un mes de GPUs generando coste sin ingresos. Construir en casa tiene sentido para quien maneja flotas grandes y un equipo de ingenieria a la altura; los proveedores consolidados han invertido en distribuciones propias de Kubernetes, planificadores a medida y planos de control hechos a mano. Pero un operador regional, uno soberano o un centro de datos que anade GPU-as-a-Service necesita pasar de bare metal a facturar rapido, y ahi aparece un camino intermedio que suele pasarse por alto: adoptar plataforma para las capas de infraestructura y orquestacion y construir encima lo que diferencia. NxtGen Cloud Technologies lo hizo para su oferta SpeedCloud, segun el fabricante, y se ahorro los meses de montar un plano de control propio.
La referencia para validar todo esto es la guia de software para partners cloud de NVIDIA, que lista requisitos sin prescribir productos: gestion de infraestructura, orquestacion con planificacion consciente de GPU y particionado MIG, red RDMA y GPUDirect, servicios de inferencia y gestion de modelos, observabilidad hasta el XID y seguridad multiusuario con cumplimiento.
Cumplir esa lista con un stack casero es posible. Cumplirla antes de que se acabe el dinero, no tanto. Conviene recordar quien firma el argumento: sale del marketing de producto de Red Hat, que vende justo la plataforma que propone. La cifra del contrato de Nebius, en cambio, viene de fuera.
