Seonglae Cho- 도입
- 결과
- 문제해결
- 한계
Script
Hello we are team tpcxai and Im Alan. lets get started
- I or it instead of We
Introduction
- We aimed to reproduce the TPCxAI original paper’s results which compared single node and multi-node benchmark
- Issues 때문에 use case 2에서 use case 10으로 교체했고 여러가지 faced issue어떻게 해결했는지는 results 먼저 공유한 이후 설명하겠다
- 이 결과로 우리는 multi node environment에서 를 sf 100까지 scaling할 수 있었고 원본 그래프와 유사한 결과와 insight를 얻을 수 있었다
- milestone 2 figure 사용 등등
- 위 테이블이랑 비교하게 동일한 형태로 테이블도 하나그리기
Results
실험한 cpu, memory 먼저 보여주고 aws에서 vessl outputperform 할 수 있을지? 물어보기
Use case 에 비례하고 실행한 시간 4개 곱한거에 4제곱근한거라 use case와는 독립적이라고 볼 수 있다. 다만 kind of average from multiplication geometric mean
SF에만 의존적인 지수라고 보면 되고 가장 높은 SF에서 일단 처음 Single node(Vessl)이랑 multi node (AWS)비교
성능차이 심한데도 architecture 차이를 극복하고 SF15에서 역전한거 대단
I guess TPCxAI utilized devide and conquer algorithm so that might be the reasons
일단 50 에서 AIUCmp 보여주기
Vessl
CPU 30
MEMORY 120Gi
SF1
DATAGEN: 68.39
TLOAD: 7.431
TLD: 7.431
TPTT: 66.74
TPST1: 11.938
TPST2: 10.096
TPST: 11.938
TTT: 7.317
AIUCpm@1.0=4.159
SF 5
DATAGEN: 78.392
TLOAD: 20.451
TLD: 20.451
TPTT: 164.928
TPST1: 23.966
TPST2: 20.959
TPST: 23.966
TTT: 10.809
AIUCpm@5.0=9.812
SF 10
DATAGEN: 107.701
TLOAD: 38.376
TLD: 38.376
TPTT: 447.263
TPST1: 49.953
TPST2: 44.93
TPST: 49.953
TTT: 24.238
AIUCpm@10.0=8.887
SF 15
DATAGEN: 126.186
TLOAD: 54.904
TLD: 54.904
TPTT: 749.194
TPST1: 70.477
TPST2: 60.659
TPST: 70.477
TTT: 30.969
AIUCpm@15.0=9.246
SF 50
DATAGEN: 248.326
TLOAD: 249.869
TLD: 249.869
TPTT: 3623.764
TPST1: 217.992
TPST2: 198.214
TPST: 217.992
TTT: 100.626
AIUCpm@50.0=7.991
SF 100
30gb memory was not enough so with segmentation fault because it doesn’t divide tasks
AWS
CPU 4
Memory 16Gi
Node 2
단순비교로도 8 32 로 적지만 더 높은 성능 만들었다
AWS Multinode (2-nodes) SF=1
DATAGEN: 131.788
TLOAD: 28.014
TLD: 28.014
TPTT: 97.567
TPST1: 45.895
TPST2: 46.12
TPST: 46.12
TTT: 34.831
AIUCpm@1.0=1.311
AWS Multinode (2-nodes) SF=5
DATAGEN: 183.126
TLOAD: 28.751
TLD: 28.751
TPTT: 126.066
TPST1: 46.864
TPST2: 45.112
TPST: 46.864
TTT: 29.069
AIUCpm@5.0=6.364
AWS Multinode (2-nodes) SF=10
DATAGEN: 314.458
TLOAD: 39.025
TLD: 39.025
TPTT: 234.247
TPST1: 50.481
TPST2: 50.358
TPST: 50.481
TTT: 30.863
39.024861097335815 234.247 50.481 30.86337399482727 10.0
61.432287721837255 600.0
AIUCpm@10.0=9.767
AWS Multinode (2-nodes) SF=15
DATAGEN: 380.166
TLOAD: 49.841
TLD: 49.841
TPTT: 309.634
TPST1: 54.569
TPST2: 53.777
TPST: 54.569
TTT: 33.425
AIUCpm@15.0=12.356
AWS Multinode (2-nodes) SF=50
DATAGEN: 1058.961
TLOAD: 111.113
TLD: 111.113
TPTT: 983.195
TPST1: 80.553
TPST2: 78.268
TPST: 80.553
TTT: 49.251
111.11266207695007 983.195 80.553 49.25120532512665 50.0
144.28641709330068 3000.0
AIUCpm@50.0=20.792
AWS Multinode (2-nodes) SF=100
DATAGEN: 1775.698
TLOAD: 181.266
TLD: 181.266
TPTT: 1641.541
TPST1: 109.187
TPST2: 109.12
TPST: 109.187
TTT: 64.691
AIUCpm@100.0=28.022
200
DATAGEN: 3510.667
TLOAD: 354.442
TLD: 354.442
TPTT: 3437.691
TPST1: 182.072
TPST2: 182.268
TPST: 182.268
TTT: 101.487
AIUCpm@200.0=30.97
AWS Multinode AIUCpm@1.0 (1-node) SF=1
DATAGEN: 150.881
TLOAD: 17.886
TLD: 17.886
TPTT: 141.313
TPST1: 53.532
TPST2: 53.075
TPST: 53.532
TTT: 41.678
AIUCpm@15.0=1.231
t2-xlarge 16GB memory 4 cores instance 2개이고 original paper 는 3개 사용했다
Load time
- y axis exponential scale
- actually linear
- You must focus on gradient difference between multi and single
Power Training time
- linear since 15 and 50 is big
Power Serving
- interestingly independent of node, single was similar and multi was similar if we consider it was 2 and 3
Throughput
- The difference with serving thorughput and serving is it considers
Score
- single node 1때 좀 낮은 거는 operation overhead 때문인듯 하지만 중요한건 scale factor independent 해진다는 것
- However score in multi node linearly under scale with SF increase due to the overhead
Implementation details
Issues
- dependency issues
- TPCxAI issues
- Resource issues
- 강제종료되는거 메모리 계속 늘려서 해결하려고 했는데 그게 아니라 메모리 줄여서 노드에 과도 메모리 로드되지 않아야 했다
Minor Issues
- pssh에서 hdfs 작동하기 위해 bashrc interactive 이전에 사용 zsh 같은 경우 zshenv
- Hadoop and spark configuration as you all experienced
Limitation
- 실제 ai bottleneck은 training이고 따로 pytorch distributed training이나 deepspeed 사용하는데, 이렇게 hadoop ecosystem에서 복잡한 dependency로 어려운 세팅을 가지고 하는 게 설득력이 부족하다
- to distribute the node, main script in main node is not effieicnet so better to run in worker node
- usecase에 따라 많이 다르긴 하다
- AWS node 성능과 개수 couldnt do enough scale out
- AWS EMR migration api 요청 끝나고 나서도 크레딧 유지시켜주면 해보겠다
- 시스템에 변화를 주고 싶었지만 실행에 직면한 여러 오류들을 해결하느라 새로운 더 효율적인 big data을 구축하지는 못했다
.zshenv.bashrcTuff project
Maybe hundreds of experiment and runs for each phases
thank you for listening and hope you guys enjoy this week’s 대동제 and Yonsei festival week
