Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Uso de la programación basada en la topología en la gobernanza de tareas de Amazon SageMaker HyperPod
La programación basada en la topología en la gobernanza de SageMaker HyperPod tareas de Amazon optimiza la eficiencia del entrenamiento de las cargas de trabajo de aprendizaje automático distribuidas al colocar los pods en función de la topología de red física de sus instancias de Amazon. EC2 Al tener en cuenta la estructura jerárquica de la AWS infraestructura, incluidas las zonas de disponibilidad, los bloques de red y los racks físicos, la programación basada en la 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 resulta especialmente beneficiosa para los trabajos de formación en aprendizaje automático a gran escala que requieren una pod-to-pod comunicación intensiva, lo que se traduce en una reducción de los tiempos de formación y en una utilización más eficiente de los recursos en todo el clúster.
nota
Para utilizar una programación basada en la topología, asegúrate de que tu versión de la gobernanza de HyperPod tareas sea la 1.2.2-eksbuild.1 o superior.
La programación basada en la topología admite los siguientes tipos de instancias:
-
ml.p3dn.24xlarge
-
ml.p4d.24xlarge
-
ml.p4de.24xlarge
-
ml.p5.48xlarge
-
ml.p5e.48xlarge
-
ml.p5en.48 x grande
-
ml.p6e-gb200.36xlarge
-
ml.trn 1.2 x large
-
ml.trn1.32xlarge
-
ml.trn1n.32xlarge
-
ml.trn 2,48 x grande
-
ml.trn2u.48 x grande
La programación compatible con la topología se integra con sus HyperPod flujos de trabajo existentes y, al mismo tiempo, proporciona preferencias de topología flexibles a través de los archivos YAML de kubectl y la CLI. HyperPod HyperPod La gobernanza de tareas configura automáticamente los nodos del clúster con etiquetas topológicas y funciona con las políticas de gestión de HyperPod tareas y los mecanismos de préstamo de recursos, lo que garantiza que la programación basada en la topología no interrumpa los procesos operativos actuales. Gracias a la compatibilidad integrada con las especificaciones topológicas preferidas y obligatorias, puede ajustar la ubicación de la carga 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 restricciones topológicas.
Al utilizar etiquetas que tienen en cuenta la topología HyperPod, puede mejorar sus cargas de trabajo de aprendizaje automático mediante una colocación inteligente de los módulos que tenga en cuenta la infraestructura física de la red. HyperPod La gestión de tareas optimiza automáticamente la programación de los módulos 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 aprendizaje automático distribuidas. Este conocimiento de la topología es especialmente valioso para las cargas de trabajo de aprendizaje automático a gran escala, ya que minimiza la sobrecarga de comunicación al colocar estratégicamente los módulos 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 módulos, una utilización más eficiente de los recursos y un mejor rendimiento general para AI/ML las aplicaciones con un uso intensivo de recursos informáticos, todo ello sin necesidad de gestionar manualmente complejas configuraciones de topología de red.
Las siguientes son etiquetas para las capas de red topológicas disponibles en las que el gobierno de HyperPod tareas puede programar los pods:
-
topology.k8s.aws/ -1 network-node-layer
-
network-node-layertopology.k8s.aws/ -2
-
network-node-layertopology.k8s.aws/ -3
Para utilizar la programación basada en la topología, incluye las siguientes etiquetas en el archivo YAML:
-
kueue.x-k8s.io/podset-required-topology : indica que este trabajo debe tener los pods necesarios y que todos los pods de los nodos deben programarse dentro de la misma capa de topología.
-
kueue.x-k8s.io/podset-preferred-topology : indica que este trabajo debe tener los pods, pero que se prefiere programar los pods dentro de la misma capa de topología, aunque no es obligatorio. HyperPod el gobierno de tareas intentará programar los módulos dentro de una capa antes de probar con la siguiente capa de topología.
Si los recursos no comparten la misma etiqueta de topología, el trabajo se suspenderá. El trabajo estará en la lista de espera. Una vez que Kueue vea que hay suficientes recursos, admitirá y ejecutará el trabajo.
En el siguiente ejemplo, se muestra cómo utilizar las etiquetas de 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 puedes usar en el archivo YAML kubectl.
Parámetro | Descripción |
---|---|
kueue.x-k8s.io/queue-name | El nombre de la cola que se va a utilizar para ejecutar el trabajo. El formato del nombre de esta cola debe ser. hyperpod-ns- |
kueue.x-k8s.io/priority-class | Permite especificar una prioridad para la programación de los pods. Esta especificación es opcional. |
annotations | Contiene la anotación de topología que se adjunta al trabajo. Las topologías disponibles son kueue.x-k8s.io/ y podset-required-topologykueue.x-k8s.io/. podset-preferred-topology Puede usar una anotación o un NodeSelector, pero no ambos al mismo tiempo. |
nodeSelector | Especifica la capa de red que representa la capa de ubicación de EC2 instancias de Amazon. Utilice este campo o una anotación, pero no ambos al mismo tiempo. En tu archivo YAML, también puedes usar el parámetro NodeSelector para elegir la capa exacta para tus pods. Para obtener el valor de la etiqueta, usa la operación de API. DescribeInstanceTopology |
También puede usar la HyperPod CLI para ejecutar su trabajo y usar la programación compatible con la topología. Para obtener más información acerca de la HyperPod CLI, consulteSageMaker 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
El siguiente es un ejemplo de archivo de configuración que puede utilizar para ejecutar un archivo PytorchJob con etiquetas topológicas. El archivo es muy similar si quieres ejecutar trabajos de MPI y Tensorflow. Si, en vez de eso, quieres ejecutar esos trabajos, recuerda cambiar el archivo de configuración en consecuencia, por ejemplo, usar la imagen correcta en su lugar. PyTorchJob Si está ejecutando un PyTorchJob, puede asignar topologías diferentes a los nodos maestro y trabajador. PyTorchJob siempre tiene un nodo maestro, por lo que le recomendamos que utilice la topología para admitir los módulos de trabajo en su lugar.
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 tu clúster, usa la operación DescribeInstanceTopologyAPI. De forma predeterminada, las topologías están ocultas en Amazon Studio AWS Management Console y Amazon SageMaker Studio. Siga estos pasos para verlas en la interfaz que está utilizando.
SageMaker Estudio
-
En SageMaker Studio, navega hasta tu clúster.
-
En la vista de tareas, selecciona el menú de opciones de la columna Nombre y, a continuación, selecciona Administrar columnas.
-
Seleccione Topología solicitada y Restricción topológica para añadir las columnas y ver la información de topología en la lista de pods de Kubernetes.
AWS Management Console
-
Abre la consola Amazon SageMaker AI en https://console.aws.amazon.com/sagemaker/
. -
En HyperPod clústeres, selecciona Gestión de clústeres.
-
Selecciona la pestaña Tareas y, a continuación, selecciona el icono con forma de engranaje.
-
En los atributos de la instancia, selecciona Topología solicitada y Restricción topológica.
-
Seleccione Confirmar para ver la información de topología en la tabla.