View a markdown version of this page

Uso de la programación basada en la topología en Amazon SageMaker HyperPod - Amazon SageMaker AI
UltraServer arquitecturaEtiquetas de topologíaComplementos de topología de SlurmPrácticas recomendadasLimitaciones

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 Amazon SageMaker HyperPod

La eficiencia de la transferencia de datos es un factor fundamental en las cargas de trabajo de computación de alto rendimiento (HPC) y de machine learning. Cuando se utiliza UltraServers con Amazon SageMaker HyperPod, aplica SageMaker HyperPod automáticamente etiquetas topológicas a los recursos. Topology-aware La programación ayuda a asignar los recursos para minimizar los gastos generales de transferencia de datos al considerar tanto la topología de la instancia (cómo se conectan los recursos dentro de una instancia) como la topología de la red (cómo se conectan las instancias entre sí). Para obtener más información sobre la topología de las instancias, consulte Topología de instancias de Amazon EC2.

Topology-aware la programación funciona con los dos clústeres de Slurm y Amazon EKS. Para obtener información general sobre cómo funciona la topología con Slurm, consulte Topology guide in the Slurm documentation.

En Amazon SageMaker HyperPod, los gastos generales de transferencia de datos suelen provenir de tres fuentes principales:

  • GPU-to-GPU transferencia de datos: las tecnologías modernas, como los conmutadores NVLink y NVLink, permiten una transferencia de datos de alto rendimiento entre las GPU sin utilizar otros recursos informáticos. Esto es extremadamente eficiente, pero suele limitarse a una sola instancia.

  • GPU-to-CPU transferencia de datos: los sistemas de acceso a Non-uniform memoria (NUMA) tienen varios buses de sistema en una sola placa base. En una arquitectura de instancia de EC2 típica, como la p5.48xlarge, hay dos buses de sistema diferentes, cada uno con una CPU y 4 GPU. Para un rendimiento óptimo, los procesos que cargan o leen datos en to/from las GPU deben ejecutarse en una CPU conectada al mismo bus del sistema que la GPU.

  • Comunicaciones de red entre instancias: las instancias transfieren datos a través de una cadena de conmutadores de red. La ruta más corta suele corresponder a la latencia más baja.

UltraServer arquitectura

SageMaker HyperPod admite UltraServer la arquitectura con instancias p6e-gb200.36xlarge. An UltraServer contiene hasta 18 instancias p6e-gb200.36xlarge, con 4 GPU en cada instancia. Todas las GPU de todos los nodos están interconectadas mediante conmutadores NVLink, lo que permite transferir los datos entre dos GPU cualesquiera sin utilizar interfaces de red.

Esta arquitectura genera un aumento significativo del rendimiento en comparación con las instancias individuales. Para aprovechar esta arquitectura de forma eficaz, los trabajos deben enviarse a los nodos de cómputo desde un único nodo. UltraServer

Etiqueta de topología de EKS

De acuerdo con la topología de instancias de EC2, etiqueta HyperPod automáticamente los nodos con las siguientes etiquetas:

  • topología.kubernetes. io/region- el lugar en el que reside el nodo Región de AWS .

  • topología.kubernetes. io/zone- la zona de disponibilidad en la que reside el nodo.

  • topología.k8s. aws/network-node-layer: NetworkNodes describe el conjunto de nodos de red de una instancia. En cada conjunto de nodos de red, los nodos de red se enumeran en orden jerárquico de arriba a abajo. El nodo de red que está conectado a la instancia es el último nodo de red de la lista. Hay cuatro capas de nodos de red y a cada nodo se le asigna una etiqueta. Las capas disponibles son topology.k8s.aws/network-node-layer-1, topology.k8s.aws/network-node-layer-2 y topology.k8s.aws/network-node-layer-3.

  • topología.k8s. aws/ultraserver-id: identificador que se utiliza para etiquetar cada una de las instancias que pertenecen al mismo dominio NVLink en un Ultraserver. Para obtener más información sobre el uso UltraServers de with, consulte. SageMaker HyperPod Uso UltraServers en Amazon SageMaker HyperPod

Con estas etiquetas, puede utilizar la programación basada en la topología en el gobierno de HyperPod tareas para aplicar anotaciones y etiquetas topológicas a fin de optimizar la eficiencia del entrenamiento de sus cargas de trabajo. Para obtener más información, consulte Uso de la programación basada en la topología en la gobernanza de tareas de Amazon SageMaker HyperPod.

Complementos de topología de red de Slurm

Slurm proporciona complementos integrados para conocer la topología de la red. SageMaker HyperPod selecciona y configura automáticamente el complemento de topología adecuado en función de los tipos de instancias del clúster.

Selección automática de la topología

Al crear un clúster de HyperPod Slurm, el sistema inspecciona todos los grupos de instancias y sus tipos de instancias asociados, identifica las características de comunicación de la GPU de cada tipo de instancia y configura Slurm con el complemento de topología adecuado. Este proceso se ejecuta automáticamente y no requiere ninguna configuración.

HyperPod administra la topología a través de un topology.conf archivo generado dinámicamente. A medida que el clúster evoluciona mediante operaciones de escalado o sustituciones de nodos, reconcilia HyperPod continuamente la configuración de la topología para reflejar el estado actual del clúster. Para obtener más información, consulte Actualizaciones de topología dinámica.

Uso del complemento topology/tree

El topology/tree complemento modela estructuras de comunicación jerárquicas con múltiples niveles de ancho de banda. La topología de árbol permite a Slurm colocar los trabajos de una manera que minimiza la comunicación entre niveles y maximiza la localidad.

La topología de árbol se utiliza para tipos de ejemplo con interconexiones jerárquicas, en los que las cargas de trabajo de formación distribuidas se benefician de una ubicación adaptada a la localidad. Esto incluye tipos de instancias como, y. ml.p5.48xlarge ml.p5e.48xlarge ml.p5en.48xlarge

SageMaker HyperPod configura automáticamente el topology/tree complemento cuando el clúster usa estos tipos de instancias. El generado topology.conf mapea los nodos en una jerarquía de conmutadores que refleja los niveles de comunicación del hardware.

Asegúrese de que slurm.conf incluya:

TopologyPlugin=topology/tree

Configuración

SageMaker HyperPod configura automáticamente el topology/tree complemento en función de la información proporcionada por Amazon EC2. Para obtener más información sobre la topología de Amazon EC2, consulte Topología de instancias de Amazon EC2.

Cuando se utiliza el topology/tree complemento, el Slurm tiene el siguiente aspectotopology.conf:

SwitchName=nn-6fe9d8a965d34d181 Switches=nn-0b53107754517bf0e

SwitchName=nn-0b53107754517bf0e Switches=nn-424c855d4ad825aa4,nn-95acd7c656329fc30

SwitchName=nn-424c855d4ad825aa4 Nodes=ip-10-1-111-198
SwitchName=nn-95acd7c656329fc30 Nodes=ip-10-1-53-231

De uso

Cuando el topology/tree complemento está configurado, Slurm intenta asignar máquinas que estén cerca unas de otras. Puede obligar a Slurm a asignar las máquinas en un solo conmutador pasando el parámetro de la línea de --switch comandos a o: sbatch srun

sbatch --switch=1 ....

Usando el complemento topology/block

NVIDIA desarrolló un topology/block complemento que proporciona una programación jerárquica en bloques de nodos con las siguientes características:

  • Un bloque es un rango consecutivo de nodos.

  • Los bloques no se pueden superponer entre sí.

  • Todos los nodos de un bloque se asignan a un trabajo antes de utilizar el siguiente bloque.

  • El tamaño del bloque de planificación es el tamaño de bloque más pequeño configurado.

  • Cada tamaño de nivel de bloque superior es una potencia de dos del anterior.

Este complemento asigna los nodos en función de la topología de red definida.

La topología de bloques modela dominios de comunicación uniformes y de gran ancho de banda, en los que todas las GPU participan en un único dominio de alta velocidad con una latencia casi uniforme. La topología de bloques trata a todos los nodos como parte de una única unidad de comunicación cohesiva. UltraServer La arquitectura in SageMaker HyperPod es compatible con el complemento de bloques.

La topología de bloques se utiliza para tipos de instancias como ml.p6e-gb200.NVL72 yml.p6e-gb300.NVL72.

Configuración

SageMaker HyperPod configura automáticamente el topology/block complemento. Si desea configurar el complemento manualmente, especifique lo siguiente en el topology.conf archivo de su directorio de configuración de Slurm:

BlockName=us1 Nodes=ultraserver1-[0-17]
BlockName=us2 Nodes=ultraserver2-[0-17]
BlockSizes=18

Asegúrese de que slurm.conf incluya:

TopologyPlugin=topology/block

De uso

Al enviar trabajos, puede utilizar los siguientes argumentos adicionales con los comandos sbatch y srun:

  • --segment=N: especifique el número de nodos que desea agrupar. El tamaño del segmento debe ser menor o igual que el tamaño del bloque de planificación.

  • --exclusive=topo: pida que no se coloquen otros trabajos en el mismo bloque. Esto es útil para las referencias y las aplicaciones sensibles al rendimiento.

A continuación se muestran escenarios de ejemplo que puede tener en cuenta al pensar en la asignación de bloques.

Asignar un bloque completo de nodos a un sistema vacío

sbatch -N18

Asignar dos bloques de nodos a un sistema vacío

sbatch -N36

Asignar 18 nodos a un bloque más 6 nodos a otro bloque

sbatch -N24

Asignar 12 nodos a un bloque más 12 nodos a otro bloque

sbatch -N24 --segment=12

Con --exclusive=topo, el trabajo debe colocarse en bloque sin ningún otro trabajo

sbatch -N12 --exclusive=topo

Selección de topología para clústeres con tipos de instancias mixtos

HyperPod actualmente usa Slurm 24.11, que solo admite una configuración de topología única por clúster. Esto significa que no se admite la selección de topología por partición, que no pueden coexistir varios modelos de topología en un solo clúster y que todos los nodos deben ajustarse a una única definición de topología.

Si el clúster contiene varios tipos de instancias, HyperPod selecciona una topología que sea compatible con todos ellos. En la siguiente tabla, se muestra un ejemplo de cómo se HyperPod resuelve la topología de un clúster con tipos de instancias mixtos.

Grupo de instancias Tipo de instancia Topología preferida

IG-1

ml.p5.48xlarge

Árbol

IG-2

ML.P6E-GB300.NVL72

Bloque

En este ejemplo, la topología de bloques es óptima para el ML.P6e-GB300.nvl72, pero la topología de árbol es compatible con el ml.p5.48xlarge y el ML.P6e-GB300.nvl72. HyperPod selecciona la topología de árbol como topología de todo el clúster para garantizar que todos los nodos puedan participar correctamente en la programación y que ningún tipo de instancia quede excluido o tergiversado.

importante

Para las cargas de trabajo en las que la programación basada en la topología es fundamental para el rendimiento, recomendamos crear clústeres independientes para cada tipo de instancia en lugar de combinar distintos tipos de instancias en un solo clúster. Esto garantiza que cada clúster utilice la topología óptima para su hardware y ofrezca el mejor rendimiento posible de la carga de trabajo. Por ejemplo, en lugar de combinar las instancias ml.p5.48xlarge y ML.p6e-GB300.nvl72 en un solo clúster en el que se selecciona la topología en árbol como solución de compatibilidad, cree un clúster dedicado para cada tipo de instancia, de modo que cada una utilice su modelo de topología ideal.

Deshabilite o cambie el complemento de topología

Cuando se crea un clúster de Slurm, selecciona HyperPod automáticamente el complemento de topología óptimo. Para cambiar manualmente el complemento de topología, actualice el TopologyPlugin valor slurm.conf en el nodo del controlador.

Ejemplo:

# Set this value to disable topology plugin
TopologyPlugin=topology/flat

Actualizaciones de topología dinámica

Topology-aware la programación mantiene continuamente la corrección de la topología a medida que cambia el clúster. La topología se recalcula automáticamente y el topology.conf archivo se regenera cuando se produce alguno de los siguientes eventos:

  • Scale-up: Se añaden nuevos nodos al clúster.

  • Scale-down: Los nodos se eliminan del clúster.

  • Sustitución de nodos: los nodos defectuosos o en mal estado se sustituyen o los nodos se sustituyen manualmente mediante la BatchReplaceClusterNodesAPI.

Cuando se actualiza la topología, los nuevos nodos se incorporan a la estructura topológica correcta, los nodos eliminados se eliminan y la configuración de Slurm se actualiza sin necesidad de intervención manual. Esto garantiza que la topología siempre refleje el estado real del clúster.

nota

Los usuarios avanzados pueden anular el comportamiento de la topología iniciando sesión en el nodo del controlador Slurm y modificando manualmente y. slurm.conf topology.conf Sin embargo, los cambios manuales pueden sobrescribirse HyperPod durante las actualizaciones posteriores del clúster, incluidas las operaciones de escalado, el reemplazo de nodos y otros eventos del ciclo de vida del clúster. Si modifica estos archivos manualmente, compruebe los cambios después de actualizar el clúster.

Prácticas recomendadas para la UltraServer topología

Para un rendimiento óptimo con una UltraServer arquitectura en SageMaker HyperPod:

  • Defina los tamaños de bloque adecuados: configure BlockSizes=18 (o 17 si hay un nodo libre) para que coincidan con la UltraServer arquitectura.

  • Utilizar segmentos para mejorar la disponibilidad: utilice --segment=16, --segment=8 o --segment=9 con los comandos srun y sbatch para mejorar la flexibilidad de la programación de tareas.

  • Tener en cuenta el tamaño del trabajo y el tamaño del segmento:

    • SiBlockSizes=18, los trabajos con hasta 18 instancias siempre se ejecutarán en una sola UltraServer.

    • SiBlockSizes=16, los trabajos con menos de 16 instancias siempre se ejecutarán en una sola UltraServer, mientras que los trabajos con 18 instancias se ejecutarán en una o dos UltraServers.

Al pensar en segmentar, tenga en cuenta lo siguiente:

  • Con--segment=1, cada instancia se puede ejecutar de forma independiente UltraServer.

  • Con-N 18 --segment 9, se colocarán 9 nodos en una UltraServer y se pueden colocar otros 9 nodos en la misma u otra UltraServer.

  • Con-N 24 --segment 8, el trabajo puede ejecutarse en 2 o 3 UltraServers, con cada 8 nodos colocados juntos en el mismo servidor.

Limitaciones en la programación SageMaker HyperPod basada en la topología

El complemento topology/block tiene limitaciones en el caso de los clústeres heterogéneos (clústeres con distintos tipos de instancia):

  • Slurm solo puede programar los nodos enumerados en bloques.

  • Cada bloque debe tener al menos BlockSizes[0] nodos.

Para clústeres heterogéneos, tenga en cuenta estas alternativas:

  • No utilice el complemento de bloques con clústeres heterogéneos. En su lugar, aísle UltraServer los nodos de una partición diferente.

  • Cree un clúster independiente UltraServers solo en la misma VPC y utilice la configuración de varios clústeres de Slurm.