AWS presenta un esquema para compartir un único clúster de HyperPod EKS entre varios equipos

AWS ha publicado una arquitectura de referencia con la que un único clúster de Amazon SageMaker HyperPod, con orquestación a través de EKS, puede cederse de forma segura a varios equipos a la vez. El esquema consta de cinco capas: acceso único mediante AWS IAM Identity Center, SageMaker Domains independientes y espacios de nombres de Kubernetes para el aislamiento, HyperPod Task Governance para repartir los aceleradores de forma equitativa y un control de costes a nivel de namespace para las facturas internas. Es la respuesta a un problema habitual: las GPU son caras y escasas, y asignar un clúster propio a cada equipo resulta un desperdicio.

Por qué compartir un clúster

Cuando cada equipo de ML tiene su propio clúster, aparecen desequilibrios. En unos, los aceleradores quedan ociosos por las noches y entre experimentos; en otros, la cola de entrenamiento se alarga durante días. Además, los ingenieros de plataforma administran varios entornos en lugar de uno. Un clúster común resuelve ambos problemas, pero plantea tres preguntas nuevas. ¿Cómo evitar que un equipo acceda a los datos y las tareas de otro? ¿Cómo impedir que un equipo lo acapare todo? ¿Quién paga qué?

La arquitectura de AWS responde a cada pregunta con un componente distinto.

Cómo funciona el aislamiento

La puerta de entrada es AWS IAM Identity Center. Los usuarios y grupos proceden del directorio corporativo, y cada grupo se corresponde con un equipo. No hace falta crear cuentas independientes en AWS, y los permisos se revocan desde un único lugar.

A partir de ahí opera una doble frontera. Cada equipo recibe su propio SageMaker Domain, es decir, un entorno de trabajo con perfiles de usuario y roles de ejecución. En paralelo, se crea para él un espacio de nombres de Kubernetes en el clúster EKS compartido, donde viven sus tareas. El Domain determina lo que una persona ve y lanza. El namespace determina dónde y con qué restricciones se ejecutan esas tareas sobre el hardware común.

Equidad y dinero

El aislamiento no basta: sin reglas para repartir la capacidad de cómputo, un clúster compartido se convierte en una pugna por los recursos. Aquí entra HyperPod Task Governance. Permite fijar para cada equipo una cuota de recursos de cómputo y prioridades de tareas. La capacidad ociosa de los demás equipos puede ocuparse de forma temporal, y cuando su propietario la reclama, las tareas de menor prioridad le ceden el sitio. Así aumenta el aprovechamiento del clúster y se mantiene la cuota garantizada de cada equipo.

La última capa es la financiera. Los costes se asocian al namespace y, por tanto, a un equipo concreto. Es la base del chargeback: contabilidad y los responsables de cada área ven quién ha consumido cuánto y pueden emitir facturas internas sin hojas de cálculo manuales.

Elementos clave del esquema:

• Clúster: un único Amazon SageMaker HyperPod con orquestación a través de EKS.
• Autenticación: AWS IAM Identity Center, con grupos que se corresponden con equipos.
• Aislamiento: SageMaker Domain y namespace de Kubernetes independientes para cada equipo.
• Equidad: HyperPod Task Governance con cuotas y prioridades.
• Finanzas: reparto de costes a nivel de namespace.

Por dónde empezar la implantación

La fuente describe únicamente la arquitectura, así que lo que sigue son conclusiones prácticas del autor, no datos de AWS.

Empiece por un mapa de los equipos y de su consumo real. Conviene derivar las cuotas del historial de uso y no de los deseos de los responsables; de lo contrario, habrá que redistribuirlas justo después del lanzamiento. Después, acuerde las clases de prioridad: qué se considera entrenamiento productivo, qué experimentos y qué trabajo interactivo. El desalojo de tareas solo es indoloro si hay checkpoints periódicos, de modo que conviene exigir de antemano que se guarde el estado.

Evalúe aparte el nivel de aislamiento. Namespace y Domain separan los equipos de forma lógica, pero físicamente siguen en el mismo clúster. Para datos con requisitos estrictos de los reguladores, puede hacer falta un control adicional o un clúster independiente. Por último, pacte con el departamento financiero el modelo de chargeback antes del lanzamiento: qué se considera exactamente coste del equipo y cómo se reparten los gastos comunes de inactividad y administración. Técnicamente, configurar el seguimiento por namespace es más sencillo que ponerse de acuerdo sobre ello dentro de la empresa.