SageMaker 분산 데이터 병렬화 라이브러리의 구성 팁 - 아마존 SageMaker

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

SageMaker 분산 데이터 병렬화 라이브러리의 구성 팁

SageMaker 분산 데이터 병렬화 (SMDDP) 라이브러리를 사용하기 전에 다음 팁을 검토하십시오. 이 목록에는 모든 프레임워크에 적용할 수 있는 팁이 포함되어 있습니다.

데이터 사전 처리

CPU를 사용하는 외부 라이브러리를 사용하여 훈련 중에 데이터를 전처리하는 경우 분산 SageMaker 데이터 병렬이 작업에 CPU를 사용하기 때문에 CPU 병목 현상이 발생할 수 있습니다. AllReduce 전처리 단계를 GPU를 사용할 라이브러리로 이동시키거나 훈련 전에 모든 전처리를 완료하여 훈련 시간을 개선할 수 있습니다.

단일 노드와 다중 노드 비교

이 라이브러리는 여러 개의 노드와 함께 사용하는 것이 좋습니다. 이 라이브러리는 단일 호스트 및 다중 디바이스 설정(예: 여러 개의 GPU를 갖춘 단일 ML 컴퓨팅 인스턴스)과 함께 사용할 수 있습니다. 다만 노드를 2개 이상 사용하면 라이브러리의 AllReduce 연산을 통해 성능이 크게 향상됩니다. NVLink는 이미 단일 호스트에서도 노드 내 AllReduce 효율에 기여하고 있습니다.

디버거를 통한 디버그 스케일링 효율성

Amazon SageMaker Debugger를 사용하여 교육 중에 CPU 및 GPU 사용률과 기타 관심 지표를 모니터링하고 시각화할 수 있습니다. Debugger 기본 제공 규칙을 사용하여 컴퓨팅 성능 문제(예: CPUBottleneck, LoadBalancing, LowGPUUtilization)를 모니터링할 수 있습니다. Amazon SageMaker Python SDK 추정기를 정의할 때 디버거 구성으로 이러한 규칙을 지정할 수 있습니다. 를 AWS CLI 사용하고 AWS SDK for Python (Boto3) 교육하는 경우 Amazon SageMaker API를 SageMaker 사용하여 디버거 구성에 나와 있는 대로 SageMaker 디버거를 활성화할 수 있습니다.

SageMaker 교육 작업에서 디버거를 사용하는 예제를 보려면 노트북 예제 리포지토리에 있는 노트북 예제 중 하나를 참조할 수 있습니다. SageMaker GitHub 디버거에 대해 자세히 알아보려면 Amazon SageMaker 디버거를 참조하십시오.

배치 크기

분산 훈련에서는 노드가 많이 추가될수록 배치 크기도 그에 비례하여 증가해야 합니다. 훈련 작업에 노드를 더 추가하고 전역 배치 크기를 늘리는 동시에 수렴 속도를 향상시키려면 학습률을 높이세요.

이를 달성할 방법은 훈련 작업이 진행됨에 따라 학습률을 작은 값에서 큰 값으로 높이는 점진적 학습률 워밍업을 이용하는 것입니다. 이와 같은 상승은 학습률의 급격한 증가를 방지함으로써 훈련 시작 시 수렴이 원활해지게 합니다. 그 예로 선형적 확장 규칙(소규모 배치 크기에 k를 곱할 때마다 학습률에도 k를 곱함)을 사용할 수 있습니다. 이 기술에 대한 자세한 내용은 연구 논문, 정확하고 큰 미니배치 SGD: 1시간 교육 ImageNet , 섹션 2 및 3을 참조하십시오.

사용자 지정 MPI 옵션

SageMaker 분산 데이터 병렬 라이브러리는 고성능 클러스터의 노드 간 통신을 관리하는 데 널리 사용되는 표준인 MPI (Message Passing Interface) 를 사용하며 GPU 수준 통신에는 NVIDIA의 NCCL 라이브러리를 사용합니다. TensorFlow 또는 Estimator Pytorch와 함께 data parallel 라이브러리를 사용하면 각 컨테이너가 MPI 환경을 설정하고 mpirun 명령을 실행하여 클러스터 노드에서 작업을 시작합니다.

Estimatorcustom_mpi_options 파라미터를 사용하여 사용자 지정 MPI 연산을 설정할 수 있습니다. 이 필드에 전달된 모든 mpirun 플래그는 mpirun 명령에 추가되고 for training에서 실행됩니다. SageMaker 그 예로 다음을 사용하여 Estimatordistribution 파라미터를 정의하면, 프로그램 시작 시 NCCL_DEBUG 변수를 사용하여 NCCL 버전을 인쇄할 수 있습니다.

distribution = {'smdistributed':{'dataparallel':{'enabled': True, "custom_mpi_options": "-verbose -x NCCL_DEBUG=VERSION"}}}

Amazon FSx 사용과 최적의 스토리지 및 처리량 설정

분산 데이터 병렬 처리를 이용하여 다중 노드로 모델을 훈련시킬 때는 FSx for Lustre를 사용하는 것이 가장 좋습니다. Amazon FSx는 더 빠른 처리량으로 공유 파일 스토리지를 지원하는 확장형 고성능 스토리지 서비스입니다. Amazon FSx 스토리지를 대규모로 사용하면 모든 컴퓨팅 노드에서 더 빠른 데이터 로드 속도를 달성할 수 있습니다.

일반적으로는 분산 데이터 병렬 처리를 사용할 경우, 총 훈련 처리량이 GPU 수에 따라 거의 선형적으로 확장될 것으로 예상됩니다. 그러나 최적이 아닌 Amazon FSx 스토리지를 사용한다면 Amazon FSx 처리량이 적어져 훈련 성능이 저하될 수 있습니다.

그 예로 스토리지 용량이 최소 1.2TiB인 SCRATCH_2 배포 유형의 Amazon FSx 파일 시스템을 사용할 경우, I/O 처리량은 240MB/s입니다. Amazon FSx 스토리지는 사용자가 물리적 스토리지 디바이스를 할당할 수 있도록 작동합니다. 할당되는 디바이스가 많을수록 사용자가 얻는 처리량도 큽니다. SRATCH_2 유형의 최소 스토리지 증분은 1.2TiB이며, 이에 해당하는 처리량 증분은 240MB/s입니다.

100GB 이상의 데이터 세트를 4노드 클러스터로 훈련시킬 모델이 있다고 가정해 봅시다. 제공된 배치 크기가 클러스터에 최적화되어 있을 경우, 해당 모델이 약 30초 내에 한 에포크를 완료할 수 있다고 가정해 봅시다. 이 경우 필요한 최소 I/O 속도는 약 3GB/s(100GB/30s)입니다. 이러한 속도는 240MB/s보다 훨씬 높은 처리량 요건으로 보입니다. 이처럼 제한된 Amazon FSx 용량을 이용하여 분산 훈련 작업을 대규모 클러스터로 확장하면 I/O 병목 현상 문제가 악화될 수 있습니다. 캐시가 누적되면 이후의 에포크에서 모델 훈련 처리량이 향상될 수 있으나, Amazon FSx 처리량에 병목 현상이 남아 있을 수 있습니다.

이러한 I/O 병목 현상 문제를 완화하려면 처리량이 증가할 수 있도록 Amazon FSx 스토리지 크기를 늘려야 합니다. 일반적으로 최적의 I/O 처리량을 구하기 위해서는, I/O 병목 현상 문제 해결에 충분하다고 판단될 때까지 다양한 Amazon FSx 처리량을 실험하여 추정치와 같거나 그보다 조금 적은 처리량을 할당하면 됩니다. 앞서 언급한 예제의 경우에는 처리량이 2.4GB/s이고 RAM 캐시가 67GB인 Amazon FSx 스토리지가 충분합니다. 파일 시스템의 처리량이 최적인 경우에는 모델 훈련 처리량이 즉시 또는 캐시가 누적된 첫 번째 에포크 이후 최대치에 도달해야 합니다.

Amazon FSx 스토리지 및 배포 유형을 늘리는 방법은 Amazon FSx for Lustre 설명서의 다음 페이지를 참조하세요.