AWS mostra arquitetura para dividir um único cluster HyperPod EKS entre equipes

A AWS publicou uma arquitetura de referência que permite entregar com segurança um único cluster Amazon SageMaker HyperPod, com orquestração via EKS, a várias equipes ao mesmo tempo. O desenho tem cinco camadas: acesso unificado pelo AWS IAM Identity Center, SageMaker Domains separados e namespaces do Kubernetes para isolamento, HyperPod Task Governance para a distribuição justa dos aceleradores e contabilização de custos no nível do namespace para cobranças internas. A proposta responde a um problema comum: GPUs são caras e escassas, e dar a cada equipe um cluster próprio é um desperdício.

Por que dividir um único cluster

Quando cada equipe de ML tem seu próprio cluster, surge um desequilíbrio. Em algumas, os aceleradores ficam ociosos à noite e nos intervalos entre experimentos; em outras, a fila de treinamento se estende por dias. Enquanto isso, os engenheiros de plataforma administram vários ambientes em vez de um. O cluster compartilhado resolve os dois problemas, mas cria três novas perguntas. Como impedir que uma equipe acesse os dados e as tarefas de outra? Como evitar que uma equipe ocupe tudo? Quem paga o quê?

A arquitetura da AWS responde a cada pergunta com um componente específico.

Como funciona o isolamento

O ponto de entrada é o AWS IAM Identity Center. Usuários e grupos vêm do diretório corporativo, e cada grupo corresponde a uma equipe. Não é preciso criar contas separadas na AWS, e as permissões são revogadas em um só lugar.

Em seguida, entra em ação uma barreira dupla. Cada equipe recebe seu próprio SageMaker Domain, ou seja, um ambiente de trabalho com perfis de usuário e funções de execução. Em paralelo, é criado para ela um namespace do Kubernetes no cluster EKS compartilhado, onde ficam suas tarefas. O Domain define o que a pessoa vê e executa. O namespace define onde e com quais restrições essas tarefas rodam no hardware compartilhado.

Justiça e dinheiro

Isolamento não basta: sem regras de distribuição de recursos computacionais, um cluster compartilhado vira uma disputa por recursos. É aí que entra o HyperPod Task Governance. Ele permite definir para cada equipe uma cota de recursos computacionais e prioridades de tarefas. A capacidade ociosa dos vizinhos pode ser usada temporariamente e, quando o dono a requisita de volta, as tarefas de menor prioridade cedem lugar. Assim, a utilização do cluster aumenta, e a fatia garantida de cada equipe é preservada.

A última camada é a financeira. Os custos são vinculados ao namespace e, portanto, a uma equipe específica. Essa é a base do chargeback: a contabilidade e os gestores das áreas veem quem consumiu quanto e podem emitir cobranças internas sem planilhas manuais.

Elementos-chave do desenho:

• Cluster: um único Amazon SageMaker HyperPod com orquestração via EKS.
• Autenticação: AWS IAM Identity Center, com grupos correspondentes às equipes.
• Isolamento: SageMaker Domain e namespace do Kubernetes separados para cada equipe.
• Justiça: HyperPod Task Governance com cotas e prioridades.
• Finanças: distribuição de custos no nível do namespace.

Por onde começar a implantação

A fonte descreve apenas a arquitetura, então o que vem a seguir são conclusões práticas minhas, e não dados da AWS.

Comece mapeando as equipes e o consumo real de cada uma. As cotas devem partir do histórico de utilização, e não dos desejos dos gestores; caso contrário, será preciso redistribuí-las logo após o lançamento. Depois, defina as classes de prioridade: o que conta como treinamento em produção, o que é experimento, o que é trabalho interativo. A preempção de tarefas só é indolor com checkpoints regulares, então vale exigir o salvamento de estado desde o início.

Avalie o nível de isolamento separadamente. Namespace e Domain separam as equipes de forma lógica, mas fisicamente elas continuam no mesmo cluster. Para dados sujeitos a exigências rígidas de reguladores, pode ser necessário um controle adicional ou um cluster dedicado. Por fim, alinhe com o financeiro o modelo de chargeback antes do lançamento: o que exatamente conta como custo da equipe e como se dividem as despesas comuns com ociosidade e administração. Tecnicamente, configurar a contabilização por namespace é mais fácil do que chegar a um acordo sobre isso dentro da empresa.