최근 IBM Blog에 Sam Matzek 이란 엔지니어가 Tensorflow + LMS (Large Model Support)를 사용하여 그 효과를 테스트한 결과가 포스팅되었습니다. (2018/07/27)
GPU 메모리 사이즈의 제약으로 인한 성능 병목을 해결하기 위하여, 시스템 메모리 영역을 사용할 수 있는 기능으로 소개했던 LMS를 실제로 적용하여 테스트한 내용인데, 쉽게 참조해보실 수 있도록 한글로 번역해보았습니다.
참고로, LMS에 대한 개략적인 소개글은 아래 IBM 유부선 상무님 블로그에 잘 정리되어있습니다.
* Inference 시스템을 위한 GPU 용량 sizing, 그리고 IBM caffe의 Large Model Support (LMS) 옵션 (
원문은 아래 링크를 참조하세요. (
1. Introduction
딥러닝은 일반적으로 신경 네트워크를 학습하는 데 GPU를 사용합니다. 이것이 잘 작동하는 동안, GPU의 메모리 양은 훈련 될 수있는 신경망의 깊이, 복잡성, 데이터의 크기를 제한합니다. GPU 메모리가 16 또는 32GB 인 반면, 다수의 GPU가 장착된 서버의 시스템 메모리는 이것의 몇배를 더 제공할 수 있습니다. GPU에서 신경망을 훈련 및 추론하는 동안 해당 시스템 메모리를 사용할 수 있다면 더 큰 데이터와 복잡한 모델을 사용할 수 있습니다.
2. TensorFlow Large Model Support 개요
TensorFlow Large Model Support (TFLMS)는 일반적으로 GPU 메모리에 맞지 않는 대형 모델 및 데이터를 교육하는 방법을 제공하는 Python 모듈입니다. 사용자가 정의한 계산 그래프를 사용하고 GPU에서 호스트로 또는 그 반대로 텐서를 전송하기 위한 Swap-in, Swap-out 노드를 자동으로 추가합니다. 훈련 및 추론을 수행하는 동안, TFLMS는 그래프 실행이 마치 OS의 메모리 페이징처럼 작동하도록 만듭니다. 시스템 메모리는 GPU 메모리의 페이징 캐시로 효과적으로 사용되고, 텐서는 GPU 메모리와 CPU 메모리간에 앞뒤로 Swap됩니다. TFLMS 알고리즘에 대한 자세한 내용은 [1]을 참조하십시오.
2.1 하드웨어 개요(Hardware overview)
아래 테스트에서는 모델 학습 및 평가를 위해 IBM Power AC922 서버를 활용합니다. AC922 서버는 NVIDIA Tesla V100 GPU와 POWER9 CPU 간에 고속의 NVLink 2.0 연결을 제공합니다. 이 NVLink가 CPU와 시스템 메모리 사이의 고속 메모리 버스와 결합되면, TFLMS를 이용하여 GPU와 시스템 메모리간에 텐서를 교환하는 것이 가능해집니다. AC922 서버에서는 NVLink 2.0 연결을 통해 CPU와 GPU간에 각 방향으로 150GB/s 통신이 가능합니다. 이를 기존의 32GB/s PCI Gen3 기반으로 연결된 GPU 통신 환경과 비교하면, 낮은 대역폭(PCI Gen3)으로 연결된 GPU를 사용하는 Tensor swapping이 어떻게 모델의 훈련 성능을 극단적으로 저하시키는 지 쉽게 이해할 수 있습니다.
2.2 3DUnet 이미지 분할 (3DUnet Image Segmentation)
이미지 분할(Image Segmentation)을 위한 3DUnet 모델 훈련은 일반적으로 교육에 사용될 수있는 3D 이미지의 크기를 제한 할 수있는 높은 메모리 사용 요구 사항을 가지고 있습니다. TFLMS는 필요에 따라 GPU에서 텐서를 스왑 할 수 있게함으로써 더 큰 모델과 이미지를 사용할 수 있도록 합니다. 이 기능을 GPU, CPU 및 AC922의 시스템 메모리 사이의 고 대역폭 인터커넥트와 결합하면, 더이상 GPU에 데이터를 공급하는게 어렵지 않게 되므로 대형 모델과 데이터를 사용할 수있게됩니다.
실제 사용 사례에서 TFLMS를 시연하기 위해 David G. Ellis가 쓴 Keras 모델[6]을 사용합니다. 이 모델은 lsensee 외 기타 연구자들이 2017 BraTS Preceeding의 100[7]페이지에서 묘사한 모델 구조에 따라 다중 모드 MRI 스캔을 처리하기 위해 작성된 것입니다.
Keras 모델은 TCGA[4,5]와 MICCAI Bra TS 2017 데이터셋[6,7]을 처리하기 위해 작성되었으며, 더욱이 Keras의 Theano 백엔드를 기대하며 작성되었습니다. 다음 테스트에서는 tf.keras 모듈의 TensorFlow 1.8 및 PowerAI 1.5.2에 포함된 Keras API와 함께 작동하도록, Keras.json을 사용하여 백엔드 옵션을 설정하도록 모델 코드를 수정하였습니다. 그 다음, TFLMS Keras 콜백은 콜백 리스트에 추가되는데, 이 콜백 리스트는 텐서 스와핑에 맞게 변경된 모델을 허용하도록 Keras model을 맞추는 동안 사용됩니다.
3. Overview of case study
Ellis의 Git repository [5] 에서 제공되는 모델 코드는 배치 사이즈 1, 전체 이미지 사이즈 128^3로 훈련하도록 설정되었습니다. 해당 코드는 전체 이미지 보다는 패치들로 훈련을 지원하도록 작성되었습니다. 아래 테스트에서는 전체 이미지들로 훈련하였고, 실제로는 144^3 사이즈, 배치 사이즈 1의 경우가 16GB GPU 상에서 Out of memory 에러가 발생하기 전에 TFLMS 없이 훈련될 수 있는 최대 배치 사이즈 및 데이터 해상도임을 확인했습니다.
모델에서 TFLMS를 활성화하면 배치 사이즈 1로 192 ^ 3 해상도의 이미지를 학습 할 수 있습니다. TFLMS로 학습되는 192 ^ 3 해상도의 이미지는 144 ^ 3 해상도의 이미지보다 ~ 2.4 배 더 해상도가 좋습니다 .
이 모델은 "전체 종양(Whole tumor)", "종양 코어(Tumor core)"및 "종양 강화(Enhancing tumor)"라고하는 3 개의 하위 영역에 대한 이미지 분할 레이블을 생성합니다. git 저장소의 평가 코드는 실측 자료의 레이블과 비교하여 모델에 의해 생성 된 분할에 대한 다이스 계수(Dice coefficients)를 계산합니다. 이러한 다이스 계수는 상자 수염 그림(Box and whisker plots)을 사용하여보다 쉽게 시각적으로 비교할 수 있습니다.
4. 192^3 image resolution result comparison
4.1 Test methodology
이 모델은 해상도가 각 144^3, 192^3인 이미지를 사용해서 배치 사이즈 1로 훈련되었고, 검증을 위한 배치 사이즈는 2입니다. 해상도가 144 ^ 3 인 이미지의 훈련 실행은 TFLMS없이 수행되었지만, 해상도 192 ^ 3 의 이미지 훈련은 TFLMS를 활용합니다. 그런 다음 모델을 사용하여 일련의 유효성 검사 데이터를 예측하거나 추론하며, 이미지 분할 예측은 다이스 계수를 사용하여 세 개의 다른 하위 영역에서 채점됩니다.
모델과 데이터셋은 어떠한 특정 대상이 훈련 또는 검증 분할 중인지, 또한 이미지의 순열에 따라서도 평가 중에 다른 주사위 계수를 얻을 수 있습니다. 이러한 차이를 최소화하기 위해서 동일한 훈련/검증 대상 분할이 모든 모델의 훈련 수행 중에 사용되었습니다. 6 가지 모델들이 144 ^ 3 해상도로 학습되었고, 각 모델의 세분화 예측(segmentation predictions)이 평가되었습니다. 가장 높은 점수를 받은 훈련/검증 대상은 모든 비교 모델 훈련에 사용되었습니다.
8 개의 모델이 훈련되었고, 4개의 모델은 각 해상도에서 훈련되었습니다. 192 ^ 3 해상도 이미지에 대한 예측은 동일 해상도의 실측 세분화(true segmentations)에 대해 평가되었습니다. 144 ^ 3 예측 세분화는 원래의 데이터셋을 대상 해상도로 크기를 조정하는 데 사용 된 것과 동일한 크기 조정 함수를 사용하여 192 ^ 3으로 크기가 조정되었습니다. 크기가 조정 된 144 ^ 3 예측은 192 ^ 3 모델 예측과 동일한 192 ^ 3 실측 세분화에 대해 평가되었습니다.
그런 다음 각 하위 영역의 각 유효성 검사 대상에 대한 평균 다이스 계수를 각 해상도에 대해 평균화했습니다.
4.2 Test results
BraTS 2017 데이터셋의 차원들은 Y 축에서 가장 큰 차이를 갖는 144^3에 매우 근접합니다.
Table 1.
|
X
|
Y
|
Z
|
Average
|
140
|
171
|
140
|
Median
|
140
|
171
|
140
|
Minimum
|
124
|
151
|
121
|
Maximum
|
159
|
191
|
150
|
144 ^ 3 해상도가 데이터셋 대상(subjects)의 해상도 대부분을 다루고 스케일링으로 인한 정보 손실이 일반적으로 Y 축에서만 발생한다는 것을 감안할 때, 192 ^ 3 해상도는 144^3 사이즈 이상의 다이스 계수에서 큰 이득을 갖지 않을 것으로 예상했습니다. 144 ^ 3 및 192 ^ 3 해상도로 훈련 된 모델 간에 "전체 종양", "종양 코어" 및 "종양 강화" 하위 영역에 대한 다이스 계수를 상자 수염 그림을 사용하여 나타내면, 다음과 같은 차이를 볼수 있습니다. :
192 ^ 3 해상도는 전체 종양의 경우 약간 더 높은 값을 가지며, 종양의 핵심 경우에서 거의 동일합니다. 또한 강화 종양의 양상은 144 ^ 3과 192 ^ 3 사이에서 매우 유사하며, 4분위수의 3과 4 사분위에서 약간 더 좋은 값을 갖는 192 ^ 3 해상도를가집니다.
5. Effects of 2x image resolution on Dice coefficients
TFLMS는 이 모델을 사용하여 192 ^ 3 이미지 해상도를 학습 할 수 있고, 이것은 TFLMS 없이도 학습 할 수있는 144 ^ 3 해상도보다 약 2.4 배 더 큽니다. 데이터셋의 해상도가 144 ^ 3에 가깝기 때문에 다이스 계수는 실제로 이미지 해상도의 2 배를 사용하는 이점을 나타내지 않습니다. 다이스 계수에서 2 배의 이미지 해상도를 더 잘 시각화하기 위해, 위에서 설명한 동일한 테스트 방법이 112 ^ 3과 144 ^ 3 사이의 비교에 적용되었습니다. 144 ^ 3이 112 ^ 3보다 2.1 배 더 크기 때문에, 144 ^ 3과 192 ^ 3의 2.4x 차이와 비슷한 112 ^ 3 해상도가 선택되었습니다.
144 ^ 3 계수로 평가 된 112 ^ 3 예측과 144 ^ 3 계수 간의 다이스 계수를 비교하면 고해상도 이미지를 사용할 때 매우 큰 이점이 있습니다.
Figure 3:
고해상도 데이터셋이 주어지면, 우리는 TFLMS로 훈련된 144^3 모델과 192^3 모델 간의 2.4배 해상도 차이를 사용하여 계수에 대한 유사한 추측을 할수 있습니다.
6. TFLMS training overhead
모델 교육에서 TFLMS의 오버 헤드를 측정하기 위해, 144 ^ 3와 192 ^ 3 사이의 해상도는 16GB NVIDIA Tesla V100 GPU가 있는 AC922 서버에서 최적의 TFLMS 매개 변수 설정으로 튜닝되었고, 훈련되었습니다. 그 다음, 모델 해상도는 32GB NVIDIA Tesla V100 GPU가 장착 된 AC922에서 TFLMS를 사용하지 않고 훈련 되었습니다. 이를 통해 TFLMS의 오버 헤드를 더 큰 데이터 해상도를 처리하는 오버 헤드와 별도로 측정 할 수 있습니다. 그런 다음 오버 헤드 비율은 144 ^ 3 이상의 해상도 인수를 통해 그래프로 표시됩니다.
7. TFLMS를 사용하는 PCIe Gen3 기반 x86 서버(Intel CPU 2개) 및 NVLink로 연결된 8 GPU (TFLMS with PCIe Gen3 on an x86 server with 2x Intel CPUs and 8 GPUs connected via NVLink)
TFLMS와 함께 대형 모델 및 데이터를 사용하는 훈련에서의 NVLink 2.0 영향을 측정하기 위해, 2x Intel CPU가 장착 된 x86 서버와 16GB의 NVIDIA Tesla V100 GPU 8 개를 사용하여 epoch 시간을 측정했습니다. Multi-GPU epoch 시간의 경우, 개별 모델이 여러 GPU에서 동시에 훈련되었고, 이 모델은 Multi-GPU 훈련을 위해 분산되지 않았습니다. Multi-GPU 모델 분산 메커니즘(distribution mechanism)을 사용할 때 CPU와 GPU 통신 속도의 영향은 동일합니다. 분산된 모델(Distributed model) 훈련은 이 문서 뒷부분에서 다룹니다.
7.1 Scaling 1 to 4 GPUs
먼저 TFLMS를 사용하지 않을 경우 144^3 해상도의 훈련을 위한 Epoch 시간이 측정되었고, epoch 시간은 AC922 과 x86 간에 유사하게 관찰되었습니다.
Table 2.
System GPU ID / Epoch time in seconds
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
Average
|
x86, 1 GPU 144^3
| |
216
| | | | | | |
216
|
AC922, 1 GPU 144^3
|
197
| | | | | | | |
197
|
x86, 4 GPU 144^3
| |
219
|
219
| |
218
| |
218
| |
219
|
AC922, 4 GPU 144^3
|
195
|
198
|
198
|
209
| | | | |
200
|
x86 서버에는 8 GPU가 장착되어 있고, GPU들은 4 Pair로 시스템에 연결되어 있습니다. 각각의 Pair는 single PCI bus 를 공유합니다. PCI 버스 경합을 피하기 위해서, 동시에 4개의 모델 훈련 수행할 때에는 GPU들이 하나의 bus를 공유하지 않도록 했습니다. 따라서 x86서버에서 사용된 일련의 GPU ID는 연속적이지 않습니다. 또한 epoch time이 1~4개의 GPU 간에 획기적으로 줄어들지 않는데, 이건 개별 모델 훈련을 동시에 수행하고, 하나의 모델 훈련을 여러개의 GPU 간에 분산하지 않기 때문입니다.
다음으로 TFLMS를 사용하여 192^3 해상도로 모델을 훈련할때 걸리는 epoch time을 측정했습니다. PCI로 연결된 GPU들과, NVlink로 연결된 GPU 간의 차이는 다음과 같이 나타납니다.
Table 3:
System / GPU ID Epoch time in seconds
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
Average
|
x86, 1 GPU 192^3
| |
1467
| | | | | | |
1467
|
AC922, 1 GPU 192^3
|
590
| | | | | | | |
590
|
x86, 4 GPU 192^3
| |
1520
|
1508
| |
1496
| |
1498
| |
1506
|
AC922, 4 GPU 192^3
|
594
|
602
|
598
|
605
| | | | |
600
|
PCI로 연결된 GPU 들의 Epoch time은 NVLink 2.0 으로 연결된 GPU 의 것보다 2.5배가 더 걸립니다.
어디서 이런 차이가 오는지를 확인하기 위해서, NVIDIA profiler인 nvprof를 사용하여, 2번재 epoch 중에 20부터 50 Step 까지를 분석했습니다. (훈련 중 첫번째 epoch은 warm up 단계이므로 두번째 epoch을 분석했습니다.) 또한 이 단계는 epoch의 시작과 끝을 피하기 위해서 선택되었습니다. 배치 사이즈 1로 훈련하는 동안, 각각의 Step은 각 하나의 주제가 됩니다.
nvprof data를 통해 x86 서버는 GPU가 유휴 상태이고 메모리 copy가 발생하지 않는 배치들 간에 큰 차이가 있음을 알수 있습니다. 이러한 결과는 AC922보다 epoch 당 44초의 오버헤드를 보여줍니다. inter-bach 오버헤드를 고려할때, NVLink 2.0 + Volta V100 의 조합은 여전히 PCIe Gen3 + Volta V100 조합보다 동일 해상도에서 2.4배 빠릅니다. nvprof 데이터는 tensor swapping을 위해 발생하는 CPU와 GPU간의 메모리 Copy가 더 느린 PCI bus에서는 더 오랜시간이 걸리고, GPU들을 유휴상태로 만든다는 것을 보여줍니다.
아래는 x86, AC922 각각에서 1 배치에 대해 보여줍니다.
맨 아래의 시간 막대는 GPU Compute 사용량을 보여 주며 그 위에 있는 세 개의 시간 막대는 메모리 Copy을 보여줍니다. 빨간색 선은 두 타임 라인에서 동등한 텐서의 상대적 위치를 보여줍니다.
GPU 사용 시간대의 공백은 이미지 처리 중에 GPU가 사용되지 않을 때를 나타내는데, 이때 GPU는 다음 텐서가 수행되도록 Swap in/out 하는 메모리 Copy과정이 끝날때까지 기다립니다. NVLink 2.0 전송 속도의 영향은 AC922의 GPU 사용량 라인에서 볼 수 있습니다. 텐서 스와핑으로 인한 GPU 사용량의 격차가 크게 줄어 듭니다.
또한 NVIDIA Visual Profiler는 프로파일링 된 30 개 배치에 대한 메모리 Copy 및 GPU 활용량에 대한 다음 통계를 보여줍니다.
Table 4:
|
GPU utilization
|
Host to GPU memory copy throughput
|
GPU to Host memory copy throughput
|
x86
|
29.1%
|
10.9 GB/s
|
11.7 GB/s
|
AC922
|
73.5%
|
64.4 GB/s
|
60.4 GB/s
|
위에서도 Memory copy 처리량(throughput)이 더 높아질수록, AC922에서 GPU 사용량이 더 많아진다는 것을 알수 있습니다.
7.2 Scaling beyond 4 GPUs
이전에 언급했듯이 x86 서버의 GPU는 쌍으로 PCI 버스에 연결됩니다. 이를 통해 PCI 버스에서 경합하지 않고 4 개의 GPU를 사용할 수 있습니다. TFLMS가 동일한 PCI 버스에서 2 개의 GPU와 함께 사용될 때 어떤 일이 발생할까요? 이를 측정하기 위해, 동시 모델 훈련을 6회, 8회 실행했습니다. 또한 이 테스트를 위해 GPU 6개짜리 AC922를 활용했습니다.
Table 5:
|
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
Average
|
x86, 6 GPU 192^3
| |
1514
|
2067
|
2081
|
1991
|
1991
|
1506
| |
1858
|
AC922, 6 GPU 192^3
|
674
|
674
|
681
|
675
|
672
|
682
| | |
676
|
x86, 8 GPU 192^3
|
2110
|
2108
|
2146
|
2116
|
2025
|
2025
|
2038
|
2038
|
2076
|
x86 서버에서 GPU ID 쌍은 (0, 1), (2, 3), (4, 5), (6, 7)입니다. 위 표에서 볼 수 있듯이, GPU가 PCI 버스를 공유 할 때 epoch 시간이 약 38 % 증가합니다(4 GPU의 평균 epoch 시간과 8 GPU의 평균 시간을 비교했을 때). 6 GPU에서 x86 서버의 평균 epoch 시간은 AC922의 평균 epoch 시간의 2.75 배가 걸립니다. 8 GPU에서 평균 epoch 시간은 4 GPU 짜리 AC922의 epoch time의 3.5 배가 걸립니다. AC922의 epoch 시간도 GPU 1 번과 4 번에서 증가한 것을 알 수 있습니다. 이것은 6 GPU AC922가 CPU와 GPU 사이에 GPU 당 100GB/s NVLink 2.0 링크를 가지고 있는 반면, 4 GPU AC922는 GPU 당 150GB/s 링크를 가지고 있기 때문입니다.
x86서버에서 GPU가 PCI 버스를 독점 사용하고 서로 경쟁 할 때와 비교해서, 4 및 6 GPU 구성에서 AC922의 epoch 시간을 그래프로 나타내면, 급격한 증가를 볼수 있습니다.
TFLMS로 훈련을 수행 할 때 PCI 버스를 공유하는 두 GPU의 영향을 조사하기 위해서, nvprof를 다시한번 사용하여 Epoch 2의 30 Step에 대한 훈련을 프로파일했습니다. 다음은 x86 서버의 GPU가 독점적으로 PCI bus를 사용할 때와 PCI bus를 공유하여 사용하는 2개 GPU 환경에서 배치 1회 수행했을때, 각각에 대한 비교입니다. 두 타임 라인 사이의 해당 텐서는 빨간색 선으로 연결됩니다.
2개 GPU가 동일 PCI bus를 공유하면 GPU들은 각각 Bandwidth를 차지하기 위해 경합하고, 메모리 Copy 시간을 길어지며 GPU 사용률은 감소, 훈련 시간은 증가하게 됩니다.
NVIDIA Visual Profiler는 프로파일링 된 30개의 배치에 대한 메모리 Copy, GPU 사용률에 대해 다음 통계를 보여줍니다.
|
GPU utilization
|
Host to GPU memory copy throughput
|
GPU to Host memory copy throughput
|
x86, 1 GPU per PCI bus
|
29.1%
|
10.9 GB/s
|
11.7 GB/s
|
x86, 2 GPUs per PCI bus
|
22.6%
|
7.6 GB/s
|
8.2 GB/s
|
AC922 6 GPU system
|
66.3%
|
45.8 GB/s
|
43.5 GB/s
|
동일한 PCI 버스를 공유하는 두 개의 GPU를 TFLMS와 함께 사용하면, 경합으로 인해 메모리 Copy 처리량이 30 % 감소합니다. AC922는 이러한 경합 문제가 발생하지 않는데, CPU와 GPU 간의 NVLink 2.0 연결이 각각의 GPU마다 전용으로 할당되고, GPU가 사용 가능한 대역폭을 놓고 경쟁 할 필요가 없기 때문입니다.
8. Distributed Deep Learning Results
8.1 DDL Overview
이미지 해상도가 높아짐에 따라 훈련 시간은 크게 늘어났습니다. 훈련 시간이 늘어나는 것을 통해, IBM PowerAI DDL (Distributed Deep Learning) 라이브러리를 사용하여 3DUnet 모델을 분산 학습(distributed training) 할 때의 영향을 확인할 수 있습니다.
DDL 라이브러리는 단순한 파이선 인터페이스를 제공하는데, 기존의 모델에 software-hardware에 최적화된 분산형 훈련을 추가하기 위한 것입니다 [8]. DDL MPI를 사용하여 각 GPU에 모델 복사본을 만든 다음, 토폴로지 인식 AllReduce operation을 사용하여 각 단계 이후의 모든 모델을 동기화합니다. 대부분의 경우 선형 속도가 가깝습니다.
8.2 DDL Integration into Model
To enable the use of DDL the primary changes that were required were splitting the data, scaling the learning rate, limiting certain steps to only running on a single node, and adding a callback to synchronize the Keras metrics.
8.2.1.1 Splitting the Data
또한 검증(validation) 데이터를 나누어 즉석 검증으로 배포합니다. 표준 파이썬 slice은 노드의 순위와 전체 GPU 수에 따라 훈련 및 유효성 검사 데이터를 분할하는 데 사용됩니다.
training_lists = [training_list[i::ddl.size()] for i in range(ddl.size())] training_list = training_lists[ddl.rank()]
validation_lists = [validation_list[i::ddl.size()] for i in range(ddl.size())] validation_list = validation_lists[ddl.rank()]
8.2.1.2 Scaling the Learning Rate
데이터가 GPU 간에 분할되었으므로, learning late는 전체 GPU 개수로 조정되어야 합니다.
# Before:
# config["initial_learning_rate"] = 5e-4
# After:
config["initial_learning_rate"] = 5e-4 * ddl.size()
8.2.1.3 Rank 0 Restrictions
순위 0에서 실행되도록 제한되어야하는 2 가지 기본 작업은 모델 검사 점 및 로깅입니다. Rank 0에서 이러한 콜백 만 추가하여 수행됩니다.
# Only do these callbacks on the rank 0 node.
if ddl.rank() == 0:
callbacks.append(ModelCheckpoint(model_file, save_best_only=True))
callbacks.append(CSVLogger(logging_file, append=True))
8.2.1.4 Early Stop Callback
마지막으로 모든 노드에서 모든 메트릭을 동기화 상태로 유지하려면 추가 콜백이 필요합니다. 이렇게하면 조기 정지 및 학습 속도(Learning rate) 스케줄링이 모두 동기화 된 상태로 유지됩니다.
callbacks = list()
callbacks.append(ddl.DDLCallback())
8.3 DDL Test Results
4개의 AC922서버에서 훈련시 DDL 적용을 테스트하기 위해, 위에서 설명한대로 100Gb/s Mellanox SB7700 InfiniBand 스위치를 통해 연결된 100Gb / s Mellanox CX5 InfiniBand 어댑터를 사용했습니다. DDL의 적용은 정확성에 영향을 미치지 않았습니다.
192^3 해상도 이미지는 단일 GPU에서 epoch 당 590 초의 훈련 시간이 걸립니다. DDL을 사용하면, 이 훈련 시간은 4 GPU 짜리 단일 노드에서 epoch 당 150 초, 2 노드 및 총 8 GPU 환경에서 76 초, 4 노드 및 총 16개 GPU에서 40 초가 걸립니다. DDL을 사용할 때 모델의 총 epoch 수가 수렴하고, 초기에 중지 된 Keras 콜백에 의해 중지 될 훈련은 변경되지 않습니다. DDL로 훈련 된 모델의 손실, 검증 손실(Validation loss) 및 다이스 계수는 DDL없이 훈련 된 모델과 동일합니다.
Table 7:
Number of GPUs
|
Epoch time
|
Speedup
|
Efficiency
|
1 (without DDL)
|
590s
|
|
|
4
|
150s
|
3.93
|
98.33%
|
8
|
76s
|
7.76
|
97.04%
|
16
|
40s
|
14.75
|
92.19%
|
여기서 스케일링은 이상적인 것보다 약간 적습니다. 이 중 일부는 일련의 계산으로 설명됩니다. 그러나 이 예제에서 이미지 수는 스케일링에 더 큰 영향을줍니다. 훈련에 사용된 총 이미지 수는 228개인데 16으로 나눠서 분배 할 수는 없으므로, 일부 노드에 14개의 이미지와 15 개의 이미지를 제공합니다. 따라서 싱크를 유지하기 위해, 모든 노드는 15 개의 훈련 단계(step)를 수행해야하며, 이는 총 작업량이 약간 증가하는 효과가 있습니다.
9. Conclusion
TFLMS 모듈을 사용하면 시스템 메모리와 GPU 메모리간에 텐서 스와핑 (tensor swapping)을 허용함으로써, GPU 메모리에 맞지 않는 큰 해상도의 큰 데이터를 가진 대형 모델을 고해상도로 학습 할 수 있습니다. Swapping이 훈련시에 오버헤드를 증가시키기는 하지만, GPU가 NVLink 2.0 고속 연결로 CPU에 연결되어 있을때는 GPU가 PCI 버스로 GPU를 연결한 것보다 2.5-3.5 배 빠른 속도로 모델링 할 수 있습니다. PowerAI Distributed Deep Learning을 사용하여 여러 GPU에 모델 훈련을 배포(distribute)하면 epoch 시간을 훨씬 더 줄일 수 있습니다.
TFLMS와 AC922 서버 및 NVLink 2.0에 연결된 GPU를 함께 사용하면, 각 기업의 Data scientist들이 큰 모델과 데이터로 훈련하는 것을 신속하게 반복할 수 있도록 해줍니다.
10. Acknowledgments
Thanks to Bryant Nelson for enabling the 3DUnet model with DDL, doing the DDL test runs, and authoring that section of the blog. Thanks to Tung D. Le for authoring the TFLMS module and working with me on its refactoring and performance analysis.
11. References / Citations
[1]
https://arxiv.org/abs/1807.02037
[2] Menze BH, Jakab A, Bauer S, Kalpathy-Cramer J, Farahani K, Kirby J, Burren Y, Porz N, Slotboom J, Wiest R, Lanczi L, Gerstner E, Weber MA, Arbel T, Avants BB, Ayache N, Buendia P, Collins DL, Cordier N, Corso JJ, Criminisi A, Das T, Delingette H, Demiralp Γ‡, Durst CR, Dojat M, Doyle S, Festa J, Forbes F, Geremia E, Glocker B, Golland P, Guo X, Hamamci A, Iftekharuddin KM, Jena R, John NM, Konukoglu E, Lashkari D, Mariz JA, Meier R, Pereira S, Precup D, Price SJ, Raviv TR, Reza SM, Ryan M, Sarikaya D, Schwartz L, Shin HC, Shotton J, Silva CA, Sousa N, Subbanna NK, Szekely G, Taylor TJ, Thomas OM, Tustison NJ, Unal G, Vasseur F, Wintermark M, Ye DH, Zhao L, Zhao B, Zikic D, Prastawa M, Reyes M, Van Leemput K. “The Multimodal Brain Tumor Image Segmentation Benchmark (BRATS)”, IEEE Transactions on Medical Imaging 34(10), 1993-2024 (2015) DOI: 10.1109/TMI.2014.2377694
[3] Bakas S, Akbari H, Sotiras A, Bilello M, Rozycki M, Kirby JS, Freymann JB, Farahani K, Davatzikos C. “Advancing The Cancer Genome Atlas glioma MRI collections with expert segmentation labels and radiomic features”, Nature Scientific Data, 4:170117 (2017) DOI: 10.1038/sdata.2017.117
[4] Bakas S, Akbari H, Sotiras A, Bilello M, Rozycki M, Kirby J, Freymann J, Farahani K, Davatzikos C. “Segmentation Labels and Radiomic Features for the Pre-operative Scans of the TCGA-GBM collection”, The Cancer Imaging Archive, 2017. DOI: 10.7937/K9/TCIA.2017.KLXWJJ1Q
[5] Bakas S, Akbari H, Sotiras A, Bilello M, Rozycki M, Kirby J, Freymann J, Farahani K, Davatzikos C. “Segmentation Labels and Radiomic Features for the Pre-operative Scans of the TCGA-LGG collection”, The Cancer Imaging Archive, 2017. DOI: 10.7937/K9/TCIA.2017.GJQ7R0EF
[6]
https://github.com/ellisdg/3DUnetCNN
[7]
https://www.cbica.upenn.edu/sbia/Spyridon.Bakas/MICCAI_BraTS/MICCAI_BraTS_2017_proceedings_shortPapers.pdf
[8] Minsik Cho, Ulrich Finkler, Sameer Kumar, David Kung, Vaibhav Saxena, Dheeraj Sreedhar. “PowerAI DDL”, August 8, 2017
