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 aprendizaje automático. Cuando se utiliza UltraServers con Amazon SageMaker HyperPod, aplica SageMaker HyperPod automáticamente etiquetas topológicas a los recursos. La programación basada en la topología 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 instancias, consulta Topología de EC2 instancias de Amazon.
La programación basada en la topología 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 la guía de topología en la documentación de Slurm.
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 NVLink los NVLink conmutadores, permiten la transferencia de datos de alto rendimiento entre ellas GPUs sin la participación de otros recursos informáticos. Esto es extremadamente eficiente, pero por lo general se limita a una sola instancia.
-
GPU-to-CPU transferencia de datos: los sistemas de acceso a memoria no uniforme (NUMA) tienen varios buses de sistema en una sola placa base. En una arquitectura de EC2 instancia típica, como la p5.48xlarge, hay dos buses de sistema diferentes, cada uno con una CPU y 4. GPUs Para obtener un rendimiento óptimo, los procesos que cargan o leen datos to/from GPUs 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 en cada instancia. GPUs Todos los nodos están interconectados GPUs a través de NVLink conmutadores, lo que permite la transferencia de datos entre dos nodos sin utilizar interfaces de red. GPUs
Esta arquitectura proporciona 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 EKS
De acuerdo con la topología de la EC2 instancia, etiqueta HyperPod automáticamente los nodos con las siguientes etiquetas:
-
topology.kubernetes.io/region: la región en la que reside el nodo. Región de AWS
-
topology.kubernetes.io/zone: la zona de disponibilidad en la que reside el nodo.
-
topology.k8s.aws/ network-node-layer: describe el conjunto de nodos de red de una instancia. NetworkNodes En cada conjunto de nodos de red, los nodos de red se muestran 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 hasta cuatro capas de nodos de red y cada nodo está etiquetado con una etiqueta. Las capas disponibles son
topology.k8s.aws/network-node-layer-1,topology.k8s.aws/network-node-layer-2,topology.k8s.aws/network-node-layer-3. -
topology.k8s.aws/ultraserver-id: identificador que se utiliza para etiquetar cada una de las instancias que pertenecen al mismo dominio en un Ultraserver. NVLink UltraServers Para obtener más información sobre el uso SageMaker HyperPod Uso UltraServers en Amazon SageMaker HyperPod de with, consulte.
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 .
Plugins de topología de red Slurm
Slurm proporciona complementos integrados para el reconocimiento de la topología de la red. UltraServer architecture in SageMaker HyperPod es compatible con el complemento de bloques.
Uso del topology/block complemento
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 una tarea 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 que el anterior
Este complemento asigna los nodos en función de la topología de red definida.
Configuración
Para configurar la programación basada en la topología con el complemento, topology/block
-
SageMaker HyperPod configura automáticamente el complemento. topology/block Si desea configurar 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 incluir:
slurm.confTopologyPlugin=topology/block
Uso
Al enviar trabajos, puede utilizar los siguientes argumentos adicionales con sbatch y srun comandos:
--segment=N: especifique el número de nodos que desea agrupar. El tamaño del segmento debe ser inferior o igual al tamaño del bloque de planificación.--exclusive=topo: Solicite que no se coloquen otros trabajos en el mismo bloque. Esto es útil para la evaluación comparativa y las aplicaciones sensibles al rendimiento.
Los siguientes son ejemplos de escenarios que puede tener en cuenta al pensar en la asignación de bloques.
Asigne un bloque completo de nodos a un sistema vacío
sbatch -N18
Asigne dos bloques de nodos en un sistema vacío
sbatch -N36
Asigne 18 nodos en un bloque más 6 nodos en otro bloque
sbatch -N24
Asigne 12 nodos en un bloque y 12 nodos en otro bloque
sbatch -N24 —segment=12
Con —exclusive=topo, el trabajo debe colocarse en un bloque sin ningún otro trabajo
sbatch -N12 —exclusive=topo
Mejores prácticas de topología UltraServer
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. -
Utilice segmentos para mejorar la disponibilidad: utilice
--segment=16comandos o--segment=9consbatchcomandossruny para mejorar la flexibilidad de la programación de tareas.--segment=8 -
Tenga 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 una sola UltraServer.Si
BlockSizes=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.
Cuando piense en segmentar, tenga en cuenta lo siguiente
Con
--segment=1, cada instancia se puede ejecutar de forma independiente. UltraServerCon
-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 topology/block complemento tiene limitaciones en el caso de los clústeres heterogéneos (clústeres con diferentes tipos de instancias):
Slurm solo puede programar los nodos listados en bloques
Cada bloque debe tener al menos nodos
BlockSizes[0]
En el caso de clústeres heterogéneos, considere 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.
