GPU 한 장을 바꾸는데 전체 작업을 다시 세울 필요는 없다

대규모 학습은 GPU 고장 외에도 여러 이유로 멈춘다. scheduler가 장비를 회수하고, 운영자가 rack을 비우고, 느려진 node를 옮기거나 자원 배치를 다시 맞출 수 있다. checkpoint 재시작은 어떤 경우에도 쓸 수 있지만 그만큼 많은 비용을 낸다. 작업을 끝내고, 자원을 다시 잡고, 통신 group을 만들고, 모델 상태를 읽고, software stack을 다시 준비한다[3]. 실행 중 구성을 바꾸는 elastic runtime도 전체 collective 상태를 재구성하는 동안 모든 rank를 세울 수 있다.

Alibaba Group과 대학 연구진의 TrainMover는 장비 한 대의 교체를 대부분 그대로인 분산 작업의 작은 변경으로 다룬다[1]. GPU 1,024장에서 계획된 중단은 20초 미만이고, 사전 준비가 불가능한 갑작스러운 장애도 30초 미만이다. 활성 worker에는 모델을 위한 추가 memory를 요구하지 않는다고 보고한다. 핵심은 재시작 코드를 조금 빠르게 만든 것이 아니라, 중단 시간에 하던 일을 그 전에 끝내는 데 있다.

전체 작업에서 달라지는 부분만 찾는다

collective communication library는 보통 group을 한 단위로 만든다. 구성원 한 명이 바뀌면 모든 rank가 group을 다시 만드는 것이 안전하다. TrainMover는 이 설정을 두 단계로 나눈다. 중단 전에 그대로 유지될 통신 상태를 준비하고, 나갈 장비와 대체 장비가 정해지면 해당 장비와 peer 사이의 차이만 설치한다. 나머지 worker는 기존 연결과 모델 상태를 유지한다.

대체 장비도 실제 실행 준비를 해야 한다. 일반적인 warmup은 분산 프로그램 안으로 들어가 memory를 할당하고 kernel을 준비하며 collective를 호출할 수 있다. 아직 정식 구성원이 아닌 장비가 이 통신에 들어오면 실행 중인 group과 충돌한다. TrainMover는 통신 없는 격리 warmup을 사용한다. local 연산과 memory 경로는 실제로 실행하되 분산 통신은 가로막는다. 따라서 대체 장비는 작업 구성원이 되기 전에 준비를 마칠 수 있다.

세 번째 요소는 특정 rank 역할에 고정되지 않은 범용 standby다. tensor, pipeline, data, expert parallel 중 어느 역할의 worker가 나가도 runtime이 필요한 역할을 구성하고 살아 있는 인접 장비에서 상태를 전달한다. 여러 교체가 있으면 상태 전송은 장비 쌍별로 병렬 실행하며 고대역폭 RDMA를 사용한다. GPU memory의 크기가 제한돼 있으므로 전송도 목표 복구 시간 안에 들어온다는 것이 논문의 설명이다.

TrainMover가 전역 재시작을 국소 교체로 바꾸는 방식. a, 기존 재시작은 장비 한 대가 나가도 모든 rank의 상태를 내린다. b, 2단계 group 설정은 유지되는 연결을 남기고 바뀐 통신만 추가한다. c, 대체 장비는 통신 없는 warmup 뒤에 역할과 상태를 받아 전환 시점에 합류한다. 이 글을 위해 새로 만든 도판.

GPU 1,024장에서 실제로 측정한 것

평가는 GPU 32장부터 1,024장까지 확장하며, 규모에 맞춰 175B dense 모델에서 5.12T MoE까지 구성을 바꾼다. GPU 1,024장에서 계획된 이동은 20초 아래를 유지했다. 나가는 쪽을 미리 준비할 수 없는 갑작스러운 장애도 30초 이내였다. GPU 수를 32장에서 1,024장으로 늘렸을 때 추가된 중단 시간은 10초 이하였는데, 통신 차이 적용과 장비 쌍별 상태 전송이 대부분 병렬로 진행되기 때문이다.

10분마다 자원을 재배치하는 실험도 있다. GPU 1,024장에서 유효 학습 효율 97%를 유지해 처리량 손실이 3% 미만이었다. 드물게 발생하는 장애 복구와는 목적이 다르다. 이동 비용이 충분히 작아 scheduling 수단으로 쓸 수 있는지 확인한 것이다. cloud 운영자는 scheduler가 더 나은 위치를 찾을 수 있다면, 장비가 완전히 고장 나기 전에 상태가 나쁜 pool이나 불균형한 배치에서 작업을 옮길 수 있다.

비교 결과는 중단 시간을 어디에서 쓰는지로 읽는 편이 정확하다. checkpoint 재시작은 자원 할당, 초기화, 데이터 재적재 비용을 낸다. 기존 elastic system은 일부 단계를 줄여도 넓은 범위의 통신 상태를 다시 만들 수 있다. TrainMover가 멈춘 상태에서 하는 일은 장애 확인과 조정, 작은 통신 변경, 상태 전달이다. 전체 작업은 커지지만 바뀐 구성원 수는 적으므로 규모가 클수록 전역 재시작과 차이가 벌어진다.

실측 복구 시간과 fleet 투영치는 다른 종류의 근거다. a, GPU 1,024장에서 계획된 사건은 20초 미만, 예기치 않은 장애는 30초 미만이다. b, 10분 간격 재배치에서는 학습 효율 97%를 유지한다. c, GPU 6만4천 장에서 낭비 시간을 55% 줄이고 주당 140만 GPU-hour를 아낀다는 값은 논문의 사건 모델에 따른 투영치이며 실측 deployment가 아니다. 이 글을 위해 새로 만든 도판.

GPU 6만4천 장 수치에는 표지가 필요하다

TrainMover는 GPU 6만4천 장 fleet에서 최선의 비교 대상보다 낭비되는 GPU-hour를 55% 줄이고, 주당 140만 GPU-hour를 절약할 수 있다고 추정한다. 경제적 의미가 가장 큰 숫자지만 가장 잘못 전달되기 쉽다. 시스템을 직접 측정한 범위는 GPU 1,024장이다. GPU 6만4천 장 결과는 장애 발생 모델과 관측한 확장 특성을 적용한 외삽이다. 대규모 fleet에서 기대할 수 있는 효과의 근거이지, GPU 6만4천 장을 일주일간 운영한 계측값은 아니다.

그렇다고 투영치가 의미 없지는 않다. 논문은 GPU 3만2천 장에서 복구 시간을 4.45분에서 20초로 줄이면, 이상적인 선형 확장을 가정할 때 GPU 약 2,400장을 더 넣은 것과 비슷한 처리량 효과가 난다고 계산한다. 소수의 standby를 두는 편이 모든 활성 GPU를 전역 복구 동안 기다리게 하는 것보다 저렴할 수 있음을 보여 주는 비교다. 다만 적정 standby 수는 장애가 함께 발생하는 정도, 자원 가격, 대기 장비에 낮은 우선순위 작업을 넣을 수 있는지에 따라 달라진다.

줄이지 못하는 장애도 있다

빠른 교체에는 정상적인 모델 상태를 가진 source, 동작하는 RDMA 경로, 나갈 장비나 고장 난 장비를 아는 control plane이 필요하다. rack이나 fabric이 함께 고장 나면 worker와 상태를 줄 이웃을 동시에 잃을 수 있다. TrainMover는 장비 교체 구간을 줄이는 시스템이기도 하다. 수치가 조용히 틀리는 SDC를 찾아내거나 사용자 코드가 divergence를 만들었는지 판단하지는 않는다. 이 문제는 ByteRobust가 다루는 더 넓은 복구 stack처럼 검출과 debugging system의 영역이다[2].

elasticity에는 두 뜻이 있다. API상 작업 구성원을 바꿀 수 있어도 실제 구현이 그 변경을 안전하게 만들려고 수천 rank를 세운다면 운영 비용은 여전히 전역적이다. TrainMover의 목표는 교체 비용이 전체 작업 크기가 아니라 바뀐 장비 수를 따르게 하는 것이다. 공급자의 모델과 network에서도 이 성질이 유지된다면, 장비 이동은 마지막 수단이 아니라 일상적인 유지보수 방법이 될 수 있다.

신뢰성도 용량 배분 문제다

TrainMover는 복구 단위를 전체 작업에서 바뀐 구성원으로 줄인다. 구현상의 차이처럼 보이지만 전체 장비의 비용 구조가 달라진다. 체크포인트 재시작은 사건이 난 뒤 스토리지 대역폭과 다시 계산할 시간을 쓴다. TrainMover는 사건이 나기 전에 대기 장비와 제어 계층의 복잡성을 지불한다. 따라서 비교할 값은 중단 시간 하나가 아니다. 예약한 예비 GPU시간, 상태 전송 트래픽, 이전 중단, 인계가 늦었을 때 되돌려야 하는 작업량을 함께 계산해야 한다.

이 장부를 사용하면 GPU 6만4천 장 투영치의 의미도 정확해진다. 큰 장비군에서는 중단 사건이 더 자주 생겨 전역 재시작의 고정비가 빠르게 누적된다. 그러나 절감률은 사건 유형의 구성, 체크포인트 간격, 예비 장비 배치 정책, 같은 네트워크 구역에 호환 장비가 있는지에 따라 달라진다. 도입을 검토하는 운영자는 자신의 장애 기록을 논문의 모델에 넣고 각 입력값에 따른 민감도를 공개해야 한다. 55%를 어디서나 적용되는 상수로 가져오면 안 된다.

운영 목표도 프로세스가 다시 살아난 시간이 아니라 유효한 다음 스텝이 나온 시간이어야 한다. 대체 장비가 실행 중이어도 통신 그룹, 최적화기 상태, 캐시, 데이터 로더 위치가 준비되지 않으면 학습은 진행되지 않는다. 텔레메트리는 검출, 대체 장비 선택, 격리 환경 준비, 변경분 설치, 상태 복사, 인계 뒤 첫 스텝을 나눠 기록해야 한다. 검출이 길면 상태 신호를 개선하고, 상태 복사가 길면 배치나 체크포인트 구성을 바꾸며, 호환 예비 장비가 부족하면 신뢰성을 스케줄러의 예약 문제로 다뤄야 한다. TrainMover의 더 큰 의미는 신뢰성 용량도 학습 용량처럼 미리 계획해야 한다는 데 있다.

논문의 전체 장비 투영치를 쓰지 않고도 손익분기점을 계산할 수 있다. 예비 장비가 실제로 처리할 수 있는 중단에서 잃을 것으로 예상되는 GPU시간이 예비 장비의 기회비용보다 크면 예약할 가치가 있다. 양쪽 값은 역할과 토폴로지에 따라 달라진다. 데이터 병렬 대체 장비는 배치하기 쉬울 수 있지만 파이프라인이나 전문가 랭크는 특정 네트워크 구역과 상태 원본이 필요할 수 있다. 전체 예비 비율 하나로는 이 차이가 사라진다. 호스트, 랙, 패브릭 구역, 가속기 종류, 학습 역할별 대응 범위를 따로 보고해야 한다.

상관된 장애는 더 어려운 경계다. 전력 사건, 랙 상단 스위치 장애, 잘못된 소프트웨어 배포, 손상된 체크포인트는 이탈 장비와 대기 장비, 상태 원본을 함께 잃게 할 수 있다. 변경분 재구성은 국소 변경을 빠르게 하지만 이 의존성을 독립적으로 만들지는 않는다. 평가는 장비 한 대 교체뿐 아니라 공통 원인 사건과 성능이 낮아진 네트워크 경로도 포함해야 한다. TrainMover가 기존 복원력 기법을 없애지 않는 지점이 여기다. 자주 발생하는 좁은 사건은 국소 인계가 처리하고, 넓은 사건에는 체크포인트 다양성, 장애 영역을 고려한 배치, 되돌리기가 여전히 필요하다.