Uso de la programación con reconocimiento de topología en la gobernanza de tareas de Amazon SageMaker HyperPod

La programación con reconocimiento de topología en la gobernanza de tareas de Amazon SageMaker HyperPod optimiza la eficacia del entrenamiento de las cargas de trabajo de machine learning distribuidas al colocar los pods en función de la topología de red física de las instancias de Amazon EC2. Al tener en cuenta la estructura jerárquica de la infraestructura de AWS, incluidas las zonas de disponibilidad, los bloques de red y los racks físicos, la programación con reconocimiento de topología garantiza que los pods que requieren una comunicación frecuente se programen muy cerca para minimizar la latencia de la red. Esta ubicación inteligente es especialmente beneficiosa para los trabajos de entrenamiento de machine learning de gran tamaño que requieren una comunicación intensiva de un pod a otro, lo que se traduce en una reducción de los tiempos de entrenamiento y en un uso más eficiente de los recursos en todo el clúster.

La programación con reconocimiento de topología admite los siguientes tipos de instancia:

La programación con reconocimiento de topología se integra con los flujos de trabajo de HyperPod existentes y, al mismo tiempo, proporciona preferencias topológicas flexibles a través de los archivos YAML de kubectl y la CLI de HyperPod. La gobernanza de tareas de HyperPod configura automáticamente los nodos del clúster con etiquetas topológicas y funciona con las políticas de gobernanza de tareas y los mecanismos de préstamo de recursos de HyperPod, lo que garantiza que la programación con reconocimiento de topología no interrumpa los procesos operativos actuales. Gracias a la compatibilidad integrada con las especificaciones topológicas preferidas y obligatorias, puede refinar la ubicación de las cargas de trabajo para adaptarla a sus requisitos de rendimiento específicos y, al mismo tiempo, mantener la flexibilidad necesaria para recurrir a la programación estándar cuando no se puedan cumplir las limitaciones topológicas.

Al utilizar las etiquetas que consideran la topología en HyperPod, puede mejorar sus cargas de trabajo de machine learning a través de la colocación inteligente de los pod que considera la infraestructura física de la red. La gobernanza de tareas de HyperPod optimiza automáticamente la programación de los pods en función de la topología jerárquica del centro de datos, lo que se traduce directamente en una reducción de la latencia de la red y en un mejor rendimiento de entrenamiento para las tareas de machine learning distribuidas. Este conocimiento de la topología es especialmente valioso para las cargas de trabajo de machine learning de gran tamaño, ya que minimiza la sobrecarga de comunicación al colocar estratégicamente los pods relacionados más cerca unos de otros en la jerarquía de la red. El resultado es una latencia optimizada de la red de comunicación entre los pods, una utilización más eficiente de los recursos y un mejor rendimiento general para las aplicaciones de IA/ML con un uso intensivo de la computación, todo ello sin necesidad de administrar manualmente complejas configuraciones de topología de red.

A continuación se muestran las etiquetas para las capas de topología de red disponibles en las que la gobernanza de tareas de HyperPod puede programar los pods:

Para usar la programación con reconocimiento de topología, debe incluir las siguientes etiquetas en su archivo YAML:

Si los recursos no comparten la misma etiqueta de topología, el trabajo se suspenderá. El trabajo estará en la lista de espera. Cuando Kueue vea que hay suficientes recursos, admitirá el trabajo y lo ejecutará.

En el siguiente ejemplo, se muestra cómo utilizar las etiquetas en los archivos 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

En la siguiente tabla se explican los nuevos parámetros que puede usar en el archivo YAML de kubectl.

También puede usar la CLI de HyperPod para ejecutar su trabajo y usar la programación con reconocimiento de topología. Para obtener más información acerca de la CLI de HyperPod, consulte Comandos de la CLI de SageMaker HyperPod.

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

El siguiente es un ejemplo de archivo de configuración que puede utilizar para ejecutar un PytorchJob con etiquetas de topología. El archivo es muy similar si desea ejecutar trabajos MPI y Tensorflow. Si prefiere ejecutar esos trabajos, recuerde cambiar el archivo de configuración en consecuencia, por ejemplo, use la imagen correcta en lugar de PyTorchJob. Si está ejecutando un PyTorchJob, puede asignar diferentes topologías a los nodos maestro y de trabajo. PyTorchJob siempre tiene un nodo maestro, por lo que le recomendamos que utilice la topología para admitir los pods de trabajo.

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 las topologías de su clúster, utilice la operación de la API DescribeInstanceTopology. De forma predeterminada, las topologías están ocultas en la Consola de administración de AWS y en Amazon SageMaker Studio. Siga estos pasos para verlas en la interfaz que está utilizando.

SageMaker Studio

Consola de administración de AWS