Uso de la programación con reconocimiento de 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. Al utilizar UltraServers con Amazon SageMaker HyperPod, SageMaker HyperPod aplica automáticamente etiquetas de topología a los recursos. La programación con reconocimiento de topología ayuda a asignar los recursos para minimizar las sobrecargas de la 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.
La programación con reconocimiento de topología es compatible 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, las sobrecargas de la transferencia de datos suelen proceder de tres orígenes principales:
-
Transferencia de datos de GPU a GPU: las tecnologías modernas, como los conmutadores NVLink y NVLink, permiten transferir datos de alto rendimiento entre las GPU sin involucrar a otros recursos de computación. Esto es extremadamente eficiente, pero suele limitarse a una sola instancia.
-
Transferencia de datos de GPU a CPU: los sistemas de acceso a memoria no uniforme (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 obtener un rendimiento óptimo, los procesos que cargan o leen datos hacia o desde 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.
Arquitectura de UltraServer
SageMaker HyperPod admite la arquitectura de UltraServer con instancias p6e-gb200.36xlarge. Un UltraServer puede contener 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 computación desde un único UltraServer.
Etiqueta de topología de EKS
De acuerdo con la topología de instancias de EC2, HyperPod etiqueta automáticamente los nodos con las siguientes etiquetas:
-
topology.kubernetes.io/region: es la Región de AWS en la que reside el nodo.
-
topology.kubernetes.io/zone: es la zona de disponibilidad en la que reside el nodo.
-
topology.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-2ytopology.k8s.aws/network-node-layer-3. -
topology.k8s.aws/ultraserver-id: es un 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 acerca del uso de UltraServers con SageMaker HyperPod, consulte Uso de UltraServers en Amazon SageMaker HyperPod.
Con estas etiquetas, puede utilizar la programación con reconocimiento de topología en la gobernanza de tareas de HyperPod para aplicar anotaciones y etiquetas de topología a fin de optimizar la eficacia del entrenamiento de sus cargas de trabajo. Para obtener más información, consulte Uso de la programación con reconocimiento de topología en la gobernanza de tareas de Amazon SageMaker HyperPod.
Complementos de topología de red de Slurm
Slurm integra complementos para conocer la topología de la red. La arquitectura UltraServer de SageMaker HyperPod admite el complemento de bloques.
Uso del complemento de topología/bloque
NVIDIA ha desarrollado un complemento de topología/bloque que proporciona una programación jerárquica entre 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.
Configuración
Para la programación con reconocimiento de topología con el complemento de topología/bloque,
-
SageMaker HyperPod configura automáticamente el complemento de topología/bloque. Si desea ajustar el complemento, especifique lo siguiente en el archivo topology.conf 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.confincluya:TopologyPlugin=topology/block
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 un bloque que no contenga ningún trabajo
sbatch -N12 —exclusive=topo
Prácticas recomendadas para la topología de UltraServer
Para obtener un rendimiento óptimo con la arquitectura UltraServer en SageMaker HyperPod debe:
-
Definir los tamaños de bloque adecuados: configure
BlockSizes=18(o 17 si hay un nodo libre) para que coincidan con la arquitectura de UltraServer. -
Utilizar segmentos para mejorar la disponibilidad: utilice
--segment=16,--segment=8o--segment=9con los comandossrunysbatchpara mejorar la flexibilidad de la programación de tareas. -
Tener en cuenta el tamaño del trabajo y el tamaño del segmento:
si
BlockSizes=18, los trabajos con hasta 18 instancias siempre se ejecutarán en un único UltraServer.Si
BlockSizes=16, los trabajos con menos de 16 instancias siempre se ejecutarán en un único UltraServer, mientras que los trabajos con 18 instancias se ejecutarán en uno o dos UltraServer.
Al pensar en segmentar, tenga en cuenta lo siguiente:
Con
--segment=1, cada instancia se puede ejecutar en un UltraServer independiente.Con
-N 18 --segment 9, 9 nodos se colocarán en un UltraServer y otros 9 nodos se pueden colocar en el mismo UltraServer o en otro.Con
-N 24 --segment 8, el trabajo puede ejecutarse en 2 o 3 UltraServer y cada 8 nodos se colocan juntos en el mismo servidor.
Limitaciones de la programación con reconocimiento de topología de SageMaker HyperPod
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 los nodos de UltraServer en una partición diferente.
Cree un clúster independiente con UltraServers solo en la misma VPC y utilice la configuración de varios clústeres de Slurm.
