UltraServer 아키텍처 토폴로지 레이블 Slurm 토폴로지 플러그인 모범 사례 제한 사항

Amazon SageMaker HyperPod에서 토폴로지 인식 스케줄링 사용

데이터 전송 효율성은 고성능 컴퓨팅(HPC) 및 기계 학습 워크로드에서 중요한 요소입니다. Amazon SageMaker HyperPod와 함께 UltraServers를 사용하는 경우 SageMaker HyperPod는 토폴로지 레이블을 리소스에 자동으로 적용합니다. 토폴로지 인식 스케줄링은 인스턴스 토폴로지(인스턴스 내에서 리소스가 연결되는 방식)와 네트워크 토폴로지(인스턴스가 서로 연결되는 방식)를 모두 고려하여 리소스를 할당함으로써 데이터 전송 오버헤드를 최소화하는 데 도움이 됩니다. 인스턴스 토폴로지에 대한 자세한 내용은 Amazon EC2 인스턴스 토폴로지를 참조하세요.

토폴로지 인식 스케줄링은 Slurm 및 Amazon EKS의 클러스터에서 작동합니다. 토폴로지가 Slurm과 작동하는 방식에 대한 일반적인 정보는 Slurm 설명서의 Topology guide를 참조하세요.

Amazon SageMaker HyperPod에서 데이터 전송 오버헤드는 일반적으로 세 가지 주요 소스에서 발생합니다.

GPU 간 데이터 전송: NVLink 및 NVLink 스위치와 같은 현대적 기술을 사용하면 다른 컴퓨팅 리소스를 사용하지 않고도 GPU 간에 처리량이 많은 데이터를 전송할 수 있습니다. 이는 매우 효율적이지만 일반적으로 단일 인스턴스로 제한됩니다.
GPU와 CPU 간 데이터 전송: Non-uniform Memory Access(NUMA) 시스템에는 단일 마더보드에 여러 시스템 버스가 있습니다. p5.48xlarge와 같은 일반적인 EC2 인스턴스 아키텍처에는 각각 CPU 1개와 GPU 4개가 있는 2개의 서로 다른 시스템이 있습니다. 최적의 성능을 위해 GPU로 데이터를 로드하거나 GPU에서 데이터를 읽는 프로세스는 GPU와 동일한 시스템 버스에 연결된 CPU에서 실행해야 합니다.
인스턴스 간 네트워크 통신: 인스턴스는 네트워크 스위치 체인을 통해 데이터를 전송합니다. 가장 짧은 경로가 일반적으로 지연 시간이 가장 짧습니다.

UltraServer 아키텍처

SageMaker HyperPod는 p6e-gb200.36xlarge 인스턴스를 사용하는 UltraServer 아키텍처를 지원합니다. UltraServer에는 최대 18개의 p6e-gb200.36xlarge 인스턴스가 포함되며 각 인스턴스에는 4개의 GPU가 있습니다. 모든 노드의 모든 GPU는 NVLink 스위치를 통해 상호 연결되므로 네트워크 인터페이스를 사용하지 않고도 두 GPU 간에 데이터를 전송할 수 있습니다.

이 아키텍처는 개별 인스턴스에 비해 상당한 성능 향상을 제공합니다. 이 아키텍처를 효과적으로 활용하려면 작업을 단일 UltraServer에서 컴퓨팅 노드로 제출해야 합니다.

EKS 토폴로지 레이블

EC2 인스턴스 토폴로지에 따라 HyperPod는 노드에 다음 레이블을 자동으로 지정합니다.

topology.kubernetes.io/region - 노드 AWS 리전 가 있는 입니다.
topology.kubernetes.io/zone - 노드가 있는 가용 영역입니다.
topology.k8s.aws/network-node-layer - NetworkNodes는 인스턴스의 네트워크 노드 세트를 설명합니다. 각 네트워크 노드 세트에서 네트워크 노드는 위에서 아래까지 계층적 순서로 나열됩니다. 인스턴스에 연결된 네트워크 노드는 목록의 마지막 네트워크 노드입니다. 네트워크 노드 계층은 최대 4개이며 각 노드에는 레이블이 지정됩니다. 사용 가능한 계층은 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 - Ultraserver에서 동일한 NVLink 도메인에 속하는 각 인스턴스에 레이블을 지정하는 데 사용되는 식별자입니다. SageMaker HyperPod에서 UltraServers를 사용하는 방법에 대한 자세한 내용은 Amazon SageMaker HyperPod에서 UltraServers 사용 섹션을 참조하세요.

이러한 레이블을 사용하면 HyperPod 태스크 거버넌스에서 토폴로지 인식 스케줄링을 사용하여 토폴로지 레이블과 주석을 적용하여 워크로드의 훈련 효율성을 최적화할 수 있습니다. 자세한 내용은 Amazon SageMaker HyperPod 태스크 거버넌스에서 토폴로지 인식 스케줄링 사용 단원을 참조하십시오.

Slurm 네트워크 토폴로지 플러그인

Slurm은 네트워크 토폴로지 인식을 위한 내장 플러그인을 제공합니다. SageMaker HyperPod는 클러스터의 인스턴스 유형에 따라 적절한 토폴로지 플러그인을 자동으로 선택하고 구성합니다.

자동 토폴로지 선택

HyperPod Slurm 클러스터를 생성할 때 시스템은 모든 인스턴스 그룹 및 관련 인스턴스 유형을 검사하고, 각 인스턴스 유형의 GPU 통신 특성을 식별하고, 적절한 토폴로지 플러그인으로 Slurm을 구성합니다. 이 프로세스는 자동으로 실행되며 구성이 필요하지 않습니다.

HyperPod는 동적으로 생성된 topology.conf 파일을 통해 토폴로지를 관리합니다. 클러스터가 조정 작업 또는 노드 교체를 통해 발전함에 따라 HyperPod는 토폴로지 구성을 지속적으로 조정하여 현재 클러스터 상태를 반영합니다. 자세한 내용은 동적 토폴로지 업데이트 단원을 참조하십시오.

토폴로지/트리 플러그인 사용

topology/tree 플러그인은 여러 대역폭 계층으로 계층적 통신 구조를 모델링합니다. 트리 토폴로지를 사용하면 Slurm이 교차 계층 통신을 최소화하고 현지성을 극대화하는 방식으로 작업을 배치할 수 있습니다.

트리 토폴로지는 분산 훈련 워크로드가 로컬리티 인식 배치의 이점을 활용하는 계층적 인터커넥트가 있는 인스턴스 유형에 사용됩니다. 여기에는 ml.p5.48xlarge, ml.p5e.48xlarge및와 같은 인스턴스 유형이 포함됩니다ml.p5en.48xlarge.

SageMaker HyperPod는 클러스터가 이러한 인스턴스 유형을 사용할 때 topology/tree 플러그인을 자동으로 구성합니다. 생성된는 하드웨어의 통신 계층을 반영하는 스위치 계층 구조에 노드를 topology.conf 매핑합니다.

slurm.conf에 다음이 포함되어야 합니다.


TopologyPlugin=topology/tree

구성

SageMaker HyperPod는 Amazon EC2에서 제공하는 정보를 기반으로 topology/tree 플러그인을 자동으로 구성합니다. Amazon EC2 토폴로지에 대한 자세한 내용은 Amazon EC2 인스턴스 토폴로지를 참조하세요.

topology/tree 플러그인을 사용할 때 Slurm은 다음과 topology.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

용도

topology/tree 플러그인이 구성되면 Slurm은 서로 가까운 시스템을 할당하려고 시도합니다. --switch 명령줄 파라미터를 sbatch 또는에 전달하여 Slurm이 단일 스위치에 시스템을 할당하도록 할 수 있습니다srun.


sbatch --switch=1 ....

토폴로지/블록 플러그인 사용

NVIDIA는 다음과 같은 특성을 가진 노드 블록 간 계층적 일정을 제공하는 topology/block 플러그인을 개발했습니다.

블록은 노드의 연속적인 범위입니다.
블록은 서로 겹칠 수 없습니다.
블록의 모든 노드는 다음 블록이 사용되기 전에 작업에 할당됩니다.
계획 블록 크기는 구성된 가장 작은 블록 크기입니다.
더 높은 블록 수준 크기는 이전 블록 수준보다 2의 거듭제곱으로 커집니다.

이 플러그인은 정의된 네트워크 토폴로지를 기반으로 노드를 할당합니다.

블록 토폴로지 모델은 모든 GPUs 참여하는 균일한 고대역폭 통신 도메인을 모델링합니다. 블록 토폴로지는 모든 노드를 단일 응집 통신 단위의 일부로 취급합니다. SageMaker HyperPod의 UltraServer 아키텍처는 블록 플러그인을 지원합니다.

블록 토폴로지는 ml.p6e-gb200.NVL72 및와 같은 인스턴스 유형에 사용됩니다ml.p6e-gb300.NVL72.

구성

SageMaker HyperPod는 topology/block 플러그인을 자동으로 구성합니다. 플러그인을 수동으로 구성하려면 Slurm 구성 디렉터리의 topology.conf 파일에 다음을 지정합니다.


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

slurm.conf에 다음이 포함되어야 합니다.


TopologyPlugin=topology/block

용도

작업을 제출할 때 sbatch 및 srun 명령과 함께 다음 추가 인수를 사용할 수 있습니다.

--segment=N: 그룹화할 노드 수를 지정합니다. 세그먼트의 크기는 계획 블록 크기보다 작거나 같아야 합니다.
--exclusive=topo: 동일한 블록에 다른 작업을 배치하지 않도록 요청합니다. 벤치마킹 및 성능에 민감한 애플리케이션에 유용합니다.

다음은 블록 할당을 생각할 때 고려할 수 있는 샘플 시나리오입니다.

빈 시스템에 전체 노드 블록 할당


sbatch -N18

빈 시스템에 노드 블록 2개 할당


sbatch -N36

한 블록에 노드 18개 + 다른 블록에 노드 6개 할당


sbatch -N24

한 블록에 노드 12개 할당 + 다른 블록에 노드 12개 할당


sbatch -N24 --segment=12

--exclusive=topo를 사용하면 다른 작업 없이 작업을 블록에 배치해야 합니다.


sbatch -N12 --exclusive=topo

혼합 인스턴스 유형이 있는 클러스터의 토폴로지 선택

HyperPod는 현재 클러스터당 단일 토폴로지 구성만 지원하는 Slurm 24.11을 사용합니다. 즉, 파티션별 토폴로지 선택이 지원되지 않고, 여러 토폴로지 모델이 단일 클러스터 내에 공존할 수 없으며, 모든 노드가 단일 토폴로지 정의를 준수해야 합니다.

클러스터에 여러 인스턴스 유형이 포함된 경우 HyperPod는 모든 인스턴스 유형에서 호환되는 토폴로지를 선택합니다. 다음 표는 HyperPod가 혼합 인스턴스 유형이 있는 클러스터의 토폴로지를 해결하는 방법의 예를 보여줍니다.

인스턴스 그룹	인스턴스 유형	기본 토폴로지
IG-1	ml.p5.48xlarge	트리
IG-2	ml.p6e-gb300.NVL72	차단

이 예제에서 블록 토폴로지는 ml.p6e-gb300.NVL72에 최적이지만 트리 토폴로지는 ml.p5.48xlarge 및 ml.p6e-gb300.NVL72와 호환됩니다. HyperPod는 트리 토폴로지를 클러스터 전반의 토폴로지로 선택하여 모든 노드가 예약에 올바르게 참여할 수 있고 인스턴스 유형이 제외되거나 잘못 표현되지 않도록 합니다.

중요

토폴로지 인식 예약이 성능에 중요한 워크로드의 경우 단일 클러스터에서 서로 다른 인스턴스 유형을 결합하는 대신 각 인스턴스 유형에 대해 별도의 클러스터를 생성하는 것이 좋습니다. 이렇게 하면 각 클러스터가 하드웨어에 최적의 토폴로지를 사용하여 가능한 최상의 워크로드 성능을 제공할 수 있습니다. 예를 들어 트리 토폴로지가 호환되는 손상으로 선택된 단일 클러스터에서 ml.p5.48xlarge와 ml.p6e-gb300.NVL72 인스턴스를 결합하는 대신 각 인스턴스 유형에 대한 전용 클러스터를 생성하여 각 인스턴스가 이상적인 토폴로지 모델을 사용하도록 합니다.

토폴로지 플러그인 비활성화 또는 변경

Slurm 클러스터가 생성되면 HyperPod는 최적의 토폴로지 플러그인을 자동으로 선택합니다. 토폴로지 플러그인을 수동으로 변경하려면 컨트롤러 노드에서의 TopologyPlugin 값을 업데이트slurm.conf합니다.

예제:


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

동적 토폴로지 업데이트

토폴로지 인식 예약은 클러스터가 변경될 때 토폴로지 정확성을 지속적으로 유지합니다. 다음 이벤트 중 하나가 발생하면 토폴로지가 자동으로 다시 계산되고 topology.conf 파일이 다시 생성됩니다.

스케일 업: 클러스터에 새 노드가 추가됩니다.
스케일 다운: 클러스터에서 노드가 제거됩니다.
노드 교체: 실패하거나 비정상인 노드가 교체되거나 BatchReplaceClusterNodes API를 사용하여 노드가 수동으로 교체됩니다.

토폴로지가 업데이트되면 새 노드가 올바른 토폴로지 구조에 통합되고 제거된 노드가 정리되며 수동 개입 없이 Slurm 구성이 업데이트됩니다. 이렇게 하면 토폴로지가 항상 실제 클러스터 상태를 반영합니다.

참고

고급 사용자는 Slurm 컨트롤러 노드에 로그인하고 slurm.conf 및를 수동으로 수정하여 토폴로지 동작을 재정의할 수 있습니다topology.conf. 그러나 조정 작업, 노드 교체 및 기타 클러스터 수명 주기 이벤트를 포함하여 후속 클러스터 업데이트 중에 HyperPod에서 수동 변경 사항을 덮어쓸 수 있습니다. 이러한 파일을 수동으로 수정하는 경우 클러스터 업데이트 후 변경 사항을 확인합니다.

UltraServer 토폴로지 모범 사례

SageMaker HyperPod의 UltraServer 아키텍처로 최적의 성능을 얻는 방법:

적절한 블록 크기 설정: UltraServer 아키텍처와 일치하도록 BlockSizes=18(또는 노드 하나가 예비 노드인 경우 17)을 구성합니다.
가용성을 높이기 위해 세그먼트 사용: srun 및 sbatch 명령과 함께 --segment=16, --segment=8 또는 --segment=9를 사용하여 작업 예약 유연성을 개선합니다.
작업 크기와 세그먼트 크기 고려:
- BlockSizes=18인 경우 인스턴스가 최대 18개인 작업은 항상 단일 UltraServer에서 실행됩니다.
- BlockSizes=16인 경우 인스턴스가 16개 미만인 작업은 항상 단일 UltraServer에서 실행되고, 인스턴스가 18개인 작업은 하나 또는 두 개의 UltraServer에서 실행될 수 있습니다.

분할을 고려할 때 다음 사항을 고려하세요.

--segment=1인 경우 각 인스턴스를 별도의 UltraServer에서 실행할 수 있습니다.
-N 18 --segment 9인 경우 한 UltraServer에 9개의 노드가 배치되고, 다른 9개의 노드는 동일한 UltraServer 또는 다른 UltraServer에 배치될 수 있습니다.
-N 24 --segment 8인 경우 2개 또는 3개의 UltraServers에서 작업을 실행할 수 있으며, 노드가 8개씩 동일한 서버에 함께 배치됩니다.

SageMaker HyperPod 토폴로지 인식 스케줄링의 제한 사항

topology/block 플러그인에는 이종 클러스터(인스턴스 유형이 다른 클러스터)에 대한 제한 사항이 있습니다.

블록에 나열된 노드만 Slurm에서 예약할 수 있습니다.
블록마다 최소 BlockSizes[0]개의 노드가 있어야 합니다.

이종 클러스터의 경우 다음 대안을 고려하세요.

블록 플러그인을 이종 클러스터와 함께 사용하지 마세요. 대신 다른 파티션에 UltraServer 노드를 격리하세요.
동일한 VPC에서만 UltraServers를 사용하여 별도의 클러스터를 생성하고 Slurm의 멀티클러스터 설정을 사용합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

워크로드 배포

HyperPod에 모델 배포