Compartir clusters de GPU entre equipos sin que uno se coma los recursos del otro es un problema de diseño, no de compra de hardware. AWS ha publicado una arquitectura de referencia para que varios equipos usen un único cluster de Amazon SageMaker HyperPod con EKS, con aislamiento entre ellos, reparto equitativo de capacidad y coste imputado a quien lo genera. La propuesta combina IAM Identity Center, dominios de SageMaker AI por equipo, namespaces de Kubernetes, HyperPod Task Governance y asignación de costes por namespace.
Qué propone AWS para compartir clusters de GPU entre equipos
La arquitectura parte de un único cluster de SageMaker HyperPod orquestado con EKS y lo divide en capas que cada equipo ve como propias. Para la autenticación se usa AWS IAM Identity Center, de modo que los usuarios entran con su identidad corporativa y no con credenciales de larga duración repartidas a mano. Cada equipo dispone de su propio dominio de SageMaker AI, y dentro de Kubernetes cada uno trabaja en su namespace, que es la frontera de aislamiento sobre la que se apoya el resto del diseño.
Encima de eso entra HyperPod Task Governance, la pieza que asigna recursos a cada equipo y decide cómo se reparte la capacidad de cómputo del cluster. Cierra el esquema la asignación de costes por namespace, que permite saber cuánto gasta cada equipo en GPU. Importa porque, sin un diseño multi-tenant, las empresas se enfrentan a tres problemas muy concretos: consumo de recursos descontrolado, aislamiento débil entre equipos e imposibilidad de imputar el coste de las GPU a quien lo genera.
Es un problema conocido en cualquier organización que ha comprado o alquilado capacidad de GPU: el cluster es caro, escaso y todo el mundo lo quiere a la vez. Cuando no hay reglas, gana quien lanza primero el trabajo más grande, y la factura llega a finanzas sin desglose. Tener un cluster único tiene sentido económico, porque la capacidad ociosa se reparte, pero solo funciona si hay un marco que ordene el acceso. Eso es lo que AWS intenta documentar con esta referencia.
El enfoque también evita la alternativa más simple y más cara: un cluster por equipo. Esa opción da aislamiento total, pero multiplica el coste fijo y deja GPU paradas en un equipo mientras otro espera cola. Compartir exige más diseño al principio y menos desperdicio después.
Cómo se materializa el aislamiento y el reparto en la práctica
El ejemplo de la arquitectura usa dos equipos, A y B, cada uno en su propio namespace. El flujo de acceso por línea de comandos es sencillo: el usuario ejecuta aws sso login, obtiene credenciales temporales asociadas al permission set de su equipo y, con ellas, lanza tareas con kubectl contra el cluster. Las credenciales temporales y el permission set por equipo son lo que impide que alguien del equipo A opere sobre los recursos del equipo B, porque los permisos se derivan de la identidad y no de quién conoce la dirección del cluster.
Esta separación de responsabilidades es la parte más útil del diseño. La identidad se gestiona en un sitio (IAM Identity Center), el aislamiento lógico en otro (namespaces de Kubernetes), la política de reparto en un tercero (Task Governance) y la contabilidad del gasto en el último (asignación de costes por namespace). Cada capa se puede revisar, auditar y modificar sin tocar las demás, lo que simplifica el mantenimiento cuando entra un equipo nuevo o cambian las prioridades.
Los dominios de SageMaker AI por equipo añaden el entorno de trabajo propio para quienes prefieren desarrollar desde SageMaker en lugar de usar solo la línea de comandos. El resultado es que un equipo de ciencia de datos y otro de ingeniería de ML pueden convivir en el mismo hardware con su propio espacio, sus propios permisos y su propia línea en la factura.
Conviene ser realista con el alcance. Es una arquitectura de referencia, no un producto que se activa con un interruptor. Exige conocer Kubernetes, entender los permission sets de IAM Identity Center y definir previamente qué cuota corresponde a cada equipo. La tecnología reparte lo que se le diga que reparta; las decisiones de cuántas GPU recibe cada equipo y con qué prioridad siguen siendo organizativas.
Cómo pueden aplicar esto las empresas hoy
Si tu empresa ya usa o va a usar SageMaker HyperPod con EKS y tiene más de un equipo compitiendo por las mismas GPU, esta referencia es un buen punto de partida para compartir clusters de GPU entre equipos con orden. El primer paso es previo a la técnica: acordar quién son los equipos, qué parte del cluster le corresponde a cada uno y quién paga qué. Sin ese acuerdo, Task Governance solo automatiza una discusión pendiente.
El segundo paso es empezar pequeño, replicando el ejemplo de dos equipos con su namespace y su permission set. Comprobad que el login con aws sso login y el lanzamiento de tareas con kubectl funcionan como se espera, y verificad que un equipo no puede ver ni tocar lo del otro. Después, activad la asignación de costes por namespace y revisad si los informes permiten repercutir el gasto a cada departamento con el nivel de detalle que pide finanzas.
Para evaluar el retorno, comparad el coste de un cluster compartido con el de mantener uno por equipo y medid el tiempo de GPU ocioso actual. Si es alto, el ahorro es tangible. Si solo hay un equipo, o la carga es pequeña y esporádica, esta arquitectura es más complejidad de la que necesitáis: HyperPod está pensado para cómputo de cierta envergadura y una PYME con un único proyecto de IA no va a notar el beneficio. Lo que conviene evitar es montar el multi-tenant antes de tener el segundo equipo, y repartir cuotas a ojo sin datos de uso real.
Análisis Blixel
La parte difícil de una GPU compartida nunca ha sido el hardware, sino el reparto de poder. Quien controla las cuotas decide qué proyectos avanzan, y por eso muchos clusters acaban como terreno de nadie o como feudo de un solo equipo. Que AWS publique una referencia que junta identidad, aislamiento, política de reparto y contabilidad es útil precisamente porque obliga a tratar esas cuatro cosas a la vez, y no como parches sucesivos cuando el problema ya ha estallado.
Dicho esto, no hay que idealizarlo. Es documentación de arquitectura, y su valor depende de que la organización tenga equipos con necesidades reales y un criterio claro de prioridad. Si no lo tiene, el mejor diseño técnico solo hará visible el conflicto. Mi opinión es que el punto más infravalorado es la imputación de costes: cuando cada equipo ve cuánto gasta en GPU, empieza a optimizar sus trabajos sin que nadie se lo pida. Ninguna política de cuotas consigue ese efecto con tanta eficacia.
Para las empresas que ya están en AWS y en Kubernetes, compartir clusters de GPU entre equipos con este patrón es un camino razonable y documentado. Para el resto, la lección sirve igualmente: antes de comprar más GPU, conviene saber quién usa las que ya tiene. Esa pregunta cuesta mucho menos que otro cluster, y la respuesta suele sorprender más de lo que los equipos admiten.
¿Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido común. Hablemos.
Deja una respuesta