기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# SageMaker AI 분산 데이터 병렬화 라이브러리의 구성에 관한 팁
SageMaker AI의 분산 데이터 병렬화(SMDDP) 라이브러리를 사용하기 전에 다음 팁을 검토합니다. 이 목록에는 모든 프레임워크에 적용할 수 있는 팁이 포함되어 있습니다.
**Topics**
+ [데이터 사전 처리](#data-parallel-config-dataprep)
+ [단일 노드 및 다중 노드 비교](#data-parallel-config-multi-node)
+ [Debugger를 이용한 디버깅 확장 효율](#data-parallel-config-debug)
+ [배치 크기](#data-parallel-config-batch-size)
+ [사용자 지정 MPI 옵션](#data-parallel-config-mpi-custom)
+ [Amazon FSx 사용과 최적의 스토리지 및 처리량 설정](#data-parallel-config-fxs)
## 데이터 사전 처리
CPU를 사용하는 외부 라이브러리를 이용하여 훈련 중에 데이터를 전처리할 경우, SageMaker AI 분산 데이터 병렬이 `AllReduce` 연산에 CPU를 사용하기 때문에 CPU 병목 현상이 발생할 수 있습니다. 전처리 단계를 GPU를 사용할 라이브러리로 이동시키거나 훈련 전에 모든 전처리를 완료하여 훈련 시간을 개선할 수 있습니다.
## 단일 노드 및 다중 노드 비교
이 라이브러리는 여러 개의 노드와 함께 사용하는 것이 좋습니다. 이 라이브러리는 단일 호스트 및 다중 디바이스 설정(예: 여러 개의 GPU를 갖춘 단일 ML 컴퓨팅 인스턴스)과 함께 사용할 수 있습니다. 다만 노드를 2개 이상 사용하면 라이브러리의 `AllReduce` 연산을 통해 성능이 크게 향상됩니다. NVLink는 이미 단일 호스트에서도 노드 내 `AllReduce` 효율에 기여하고 있습니다.
## Debugger를 이용한 디버깅 확장 효율
Amazon SageMaker Debugger를 사용하여 훈련 중에 CPU 및 GPU 사용률과 기타 관심 대상 지표를 모니터링하고 시각화할 수 있습니다. Debugger [기본 제공 규칙](https://docs.aws.amazon.com/sagemaker/latest/dg/debugger-built-in-rules.html)을 사용하여 컴퓨팅 성능 문제(예: `CPUBottleneck`, `LoadBalancing`, `LowGPUUtilization`)를 모니터링할 수 있습니다. Amazon SageMaker Python SDK 예측기를 정의하면 [Debugger 구성](https://docs.aws.amazon.com/sagemaker/latest/dg/debugger-configuration-for-debugging.html)으로 이 규칙을 지정할 수 있습니다. SageMaker AI 훈련에 AWS CLI 및 AWS SDK for Python (Boto3) 를 사용하는 경우 [ Amazon SageMaker API를 사용하여 SageMaker 디버거 구성에 표시된 대로 디버거를](https://docs.aws.amazon.com/sagemaker/latest/dg/debugger-createtrainingjob-api.html) 활성화할 수 있습니다.
SageMaker 훈련 작업에서 Debugger를 사용하는 예제를 확인하려면 [SageMaker Notebook Examples GitHub 리포지토리](https://github.com/aws/amazon-sagemaker-examples/tree/master/sagemaker-debugger)에 있는 노트북 예제 중 하나를 참조하면 됩니다. Debugger에 대한 자세한 정보는 [Amazon SageMaker Debugger](https://docs.aws.amazon.com/sagemaker/latest/dg/train-debugger.html)를 참조하세요.
## 배치 크기
분산 훈련에서는 노드가 많이 추가될수록 배치 크기도 그에 비례하여 증가해야 합니다. 훈련 작업에 노드를 더 추가하고 전역 배치 크기를 늘리는 동시에 수렴 속도를 향상시키려면 학습률을 높이세요.
이를 달성할 방법은 훈련 작업이 진행됨에 따라 학습률을 작은 값에서 큰 값으로 높이는 점진적 학습률 워밍업을 이용하는 것입니다. 이와 같은 상승은 학습률의 급격한 증가를 방지함으로써 훈련 시작 시 수렴이 원활해지게 합니다. 그 예로 *선형적 확장 규칙*(소규모 배치 크기에 k를 곱할 때마다 학습률에도 k를 곱함)을 사용할 수 있습니다. 이 기법에 대한 자세한 내용은 연구 논문 [Accurate, Large Minibatch SGD: Training ImageNet in 1 Hour](https://arxiv.org/pdf/1706.02677.pdf)의 2항과 3항을 참조하세요.
## 사용자 지정 MPI 옵션
SageMaker AI 분산 데이터 병렬 라이브러리는 고성능 클러스터의 노드 간 통신 관리에 널리 사용되는 표준인 Message Passing Interface(MPI)를 사용하며, GPU 수준의 통신에 NVIDIA의 NCCL 라이브러리를 사용합니다. TensorFlow 또는 Pytorch `Estimator`와 함께 데이터 병렬 라이브러리를 사용하면 각 컨테이너가 MPI 환경을 설정하고 `mpirun` 명령을 실행하여 클러스터 노드로 작업을 시작합니다.
`Estimator`의 `custom_mpi_options` 파라미터를 사용하여 사용자 지정 MPI 연산을 설정할 수 있습니다. 이 필드에 전달된 모든 `mpirun` 플래그는 `mpirun` 명령에 추가되며 훈련 목적으로 SageMaker AI에서 실행됩니다. 그 예로 다음을 사용하여 `Estimator`의 `distribution` 파라미터를 정의하면, 프로그램 시작 시 [https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/env.html#nccl-debug](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/env.html#nccl-debug) 변수를 사용하여 NCCL 버전을 인쇄할 수 있습니다.
```
distribution = {'smdistributed':{'dataparallel':{'enabled': True, "custom_mpi_options": "-verbose -x NCCL_DEBUG=VERSION"}}}
```
## Amazon FSx 사용과 최적의 스토리지 및 처리량 설정
분산 데이터 병렬 처리를 이용하여 다중 노드로 모델을 훈련시킬 때는 [FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)를 사용하는 것이 가장 좋습니다. Amazon FSx는 더 빠른 처리량으로 공유 파일 스토리지를 지원하는 확장형 고성능 스토리지 서비스입니다. Amazon FSx 스토리지를 대규모로 사용하면 모든 컴퓨팅 노드에서 더 빠른 데이터 로드 속도를 달성할 수 있습니다.
일반적으로는 분산 데이터 병렬 처리를 사용할 경우, 총 훈련 처리량이 GPU 수에 따라 거의 선형적으로 확장될 것으로 예상됩니다. 그러나 최적이 아닌 Amazon FSx 스토리지를 사용한다면 Amazon FSx 처리량이 적어져 훈련 성능이 저하될 수 있습니다.
그 예로 스토리지 용량이 최소 1.2TiB인 [**SCRATCH\$12** 배포 유형의 Amazon FSx 파일 시스템](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html#fsx-aggregate-perf)을 사용할 경우, I/O 처리량은 240MB/s입니다. Amazon FSx 스토리지는 사용자가 물리적 스토리지 디바이스를 할당할 수 있도록 작동합니다. 할당되는 디바이스가 많을수록 사용자가 얻는 처리량도 큽니다. SRATCH\$12 유형의 최소 스토리지 증분은 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 설명서*의 다음 페이지를 참조하세요.
+ [스토리지 용량을 늘리는 방법](https://docs.aws.amazon.com/fsx/latest/LustreGuide/managing-storage-capacity.html#increase-storage-capacity)
+ [집계 파일 시스템 성능](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html#fsx-aggregate-perf)