Usando o agendamento com reconhecimento de topologia na governança de tarefas da Amazon SageMaker HyperPod

O agendamento com reconhecimento de topologia na governança de tarefas SageMaker HyperPod da Amazon otimiza a eficiência do treinamento de cargas de trabalho distribuídas de aprendizado de máquina ao colocar pods com base na topologia de rede física de suas instâncias da Amazon. EC2 Ao considerar a estrutura hierárquica da AWS infraestrutura, incluindo zonas de disponibilidade, blocos de rede e racks físicos, o agendamento com reconhecimento de topologia garante que os pods que exigem comunicação frequente sejam programados em estreita proximidade para minimizar a latência da rede. Esse posicionamento inteligente é particularmente benéfico para trabalhos de treinamento de aprendizado de máquina em grande escala que envolvem pod-to-pod comunicação intensiva, resultando em tempos de treinamento reduzidos e utilização mais eficiente de recursos em todo o cluster.

O agendamento com reconhecimento de topologia é compatível com os seguintes tipos de instância:

O agendamento com reconhecimento de topologia se integra aos seus HyperPod fluxos de trabalho existentes, ao mesmo tempo em que fornece preferências de topologia flexíveis por meio dos arquivos kubectl YAML e da CLI. HyperPod HyperPod a governança de tarefas configura automaticamente os nós do cluster com rótulos de topologia e trabalha com políticas de governança de HyperPod tarefas e mecanismos de empréstimo de recursos, garantindo que o agendamento com reconhecimento de topologia não interrompa seus processos operacionais atuais. Com suporte integrado para as especificações de topologia preferenciais e exigidas, você pode ajustar o posicionamento da carga de trabalho para atender aos seus requisitos específicos de desempenho, mantendo a flexibilidade de voltar ao agendamento padrão quando as restrições de topologia não puderem ser satisfeitas.

Ao aproveitar os rótulos com reconhecimento de topologia HyperPod, você pode aprimorar suas cargas de trabalho de aprendizado de máquina por meio do posicionamento inteligente de pods que considera a infraestrutura física da rede. HyperPod a governança de tarefas otimiza automaticamente o agendamento de pods com base na topologia hierárquica do data center, o que se traduz diretamente em latência de rede reduzida e melhor desempenho de treinamento para tarefas de ML distribuídas. Esse reconhecimento de topologia é particularmente valioso para cargas de trabalho de aprendizado de máquina em grande escala, pois minimiza a sobrecarga de comunicação ao colocar estrategicamente os pods relacionados mais próximos na hierarquia da rede. O resultado é uma latência otimizada da rede de comunicação entre os pods, uma utilização mais eficiente dos recursos e um melhor desempenho geral para AI/ML aplicativos com uso intensivo de computação, tudo isso obtido sem a necessidade de gerenciar manualmente configurações complexas de topologia de rede.

A seguir estão os rótulos das camadas de rede de topologia disponíveis nas quais a governança de HyperPod tarefas pode programar pods:

Para usar o agendamento com reconhecimento de topologia, inclua os seguintes rótulos em seu arquivo YAML:

Se os recursos não compartilharem o mesmo rótulo de topologia, o trabalho será suspenso. O trabalho estará na lista de espera. Quando Kueue perceber que há recursos suficientes, ela admitirá e executará o trabalho.

O exemplo a seguir demonstra como usar os rótulos em seus arquivos YAML:

apiVersion: batch/v1
kind: Job
metadata:
  name: test-tas-job
  namespace: hyperpod-ns-team-name
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
    kueue.x-k8s.io/priority-class: PRIORITY_CLASS-priority
spec:
  parallelism: 10
  completions: 10
  suspend: true
  template:
    metadata:
      labels:
        kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
      annotations:
        kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
        or
        kueue.x-k8s.io/podset-preferred-topology: "topology.k8s.aws/network-node-layer-3"
    spec:
      nodeSelector:
        topology.k8s.aws/network-node-layer-3: TOPOLOGY_LABEL_VALUE
      containers:
        - name: dummy-job
          image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
          args: ["3600s"]
          resources:
            requests:
              cpu: "100"
      restartPolicy: Never

A tabela a seguir explica os novos parâmetros que você pode usar no arquivo kubectl YAML.

Você também pode usar a HyperPod CLI para executar seu trabalho e usar o agendamento com reconhecimento de topologia. Para obter mais informações sobre a HyperPod CLI, consulte. SageMaker HyperPod Comandos CLI

hyp create hyp-pytorch-job \                                            
  --version 1.1 \
  --job-name sample-pytorch-job \
  --image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \
  --pull-policy "Always" \
  --tasks-per-node 1 \
  --max-retry 1 \
  --priority high-priority \
  --namespace hyperpod-ns-team-name \
  --queue-name hyperpod-ns-team-name-localqueue \
  --preferred-topology-label topology.k8s.aws/network-node-layer-1

A seguir está um exemplo de arquivo de configuração que você pode usar para executar um PytorchJob com rótulos de topologia. O arquivo é muito semelhante se você quiser executar trabalhos MPI e Tensorflow. Se você quiser executar esses trabalhos em vez disso, lembre-se de alterar o arquivo de configuração adequadamente, como usar a imagem correta em vez de PyTorchJob. Se você estiver executando um PyTorchJob, poderá atribuir topologias diferentes aos nós mestre e de trabalho. PyTorchJob sempre tem um nó principal, então recomendamos que você use a topologia para dar suporte aos grupos de trabalho.

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  annotations: {}
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
  name: tas-test-pytorch-job
  namespace: hyperpod-ns-team-name
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      restartPolicy: OnFailure
      template:
        metadata:
          labels:
            kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
        spec:
          containers:
          - command:
            - python3
            - /opt/pytorch-mnist/mnist.py
            - --epochs=1
            image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
            imagePullPolicy: Always
            name: pytorch
    Worker:
      replicas: 10
      restartPolicy: OnFailure
      template:
        metadata:
          # annotations:
            # kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
          labels:
            kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
        spec:
          containers:
          - command:
            - python3
            - /opt/pytorch-mnist/mnist.py
            - --epochs=1
            image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
            imagePullPolicy: Always
            name: pytorch
            resources:
              limits:
                cpu: 1
              requests:
                memory: 200Mi
                cpu: 1
          #nodeSelector:
          #  topology.k8s.aws/network-node-layer-3: xxxxxxxxxxx

Para ver as topologias do seu cluster, use a operação da DescribeInstanceTopologyAPI. Por padrão, as topologias estão ocultas no AWS Management Console e no Amazon SageMaker Studio. Siga estas etapas para vê-las na interface que você está usando.

SageMaker Studio

AWS Management Console