Amazon EKS NVRx Training, GPU 장애 복구 시간을 분 단위에서 초 단위로 단축
Amazon EKS는 NVIDIA NVRx를 재현 가능한 학습 스택에 통합해 주입된 GPU 장애를 약 10~17초 만에 복구했다. Amazon EKS NVRx training 설계는 16~64개의 H100 GPU를 아우르는 일부 테스트에서 체크포인트 효율도 99% 이상으로 유지했다. 이 결과는 신뢰할 수 있는 복구를 위해 컨테이너를 재시작하거나 전체 Kubernetes 작업을 다시 구축해야 한다는 비용 높은 통념에 도전한다.
이 시스템은 PyTorch Fully Sharded Data Parallel(FSDP)과 세 가지 개별 NVRx 기능을 결합한다. 비동기 체크포인팅은 스토리지 쓰기를 학습 루프 밖으로 이동시킨다. 프로세스 내 재시작은 Python 프로세스를 교체하지 않고 분산 상태를 재구축한다. ft_launcher 구성 요소는 더 심각한 장애 이후 기존 작업 내부에서 새 워커를 시작한다.
따라서 중요한 경쟁 구도는 AWS와 다른 클라우드 제공업체 간의 대결이 아니다. 애플리케이션 인지형 복구와 인프라 전용 복구 간의 대결이다. Kubernetes는 계속해서 스케줄링과 노드 수준 장애를 담당하지만, NVRx는 학습 프로세스에 더 가까운 지점에서 장애를 처리한다. AWS는 이러한 분리가 장애가 발생하지 않은 고가의 GPU가 실패한 동료를 기다리며 보내는 시간을 크게 줄인다고 말한다.
Amazon EKS NVRx Training, 작업 내부로 복구 이동
핵심 변화는 워커 장애가 더 이상 전체 컨테이너 수명 주기 이벤트로 이어질 필요가 없다는 점이다.
AWS와 NVIDIA는 Amazon EKS, 자체 관리 GPU 노드 그룹, PyTorch FSDP를 중심으로 레퍼런스 환경을 구축했다. 이들의 공개 벤치마크는 각각 80GB 메모리를 갖춘 NVIDIA H100 GPU 8개를 포함하는 p5.48xlarge 인스턴스를 사용했다.
테스트 클러스터는 2~8개 노드, 즉 16~64개 GPU로 확장됐다. 각 인스턴스는 고대역폭 통신을 위해 32개의 Elastic Fabric Adapter 인터페이스도 제공했다. Amazon FSx for Lustre는 학습 포드 전반에 걸쳐 공유 체크포인트 스토리지를 제공했다.
NVIDIA Resiliency Extension의 약자인 NVRx는 PyTorch 워크로드에 복구 및 체크포인팅 구성 요소를 추가하는 Python 패키지다. PyTorch 포크, 맞춤형 커널 또는 재컴파일이 필요하지 않다. 팀은 전체 학습 프레임워크를 교체하지 않고도 기능을 개별적으로 추가할 수 있다.
이러한 모듈형 설계는 체크포인트 성능과 장애 복구가 서로 다른 문제이기 때문에 중요하다. 어떤 워크로드는 프로세스 복구 없이 더 빠른 저장만 필요할 수 있다. 다른 워크로드는 기존 체크포인트 구현을 유지하면서 프로세스 충돌 방지가 필요할 수 있다.
레퍼런스 아키텍처는 각 계층을 장애 범위에 따라 처리한다. 프로세스 내 재시작은 Python 인터프리터가 살아 있는 상태에서 발생하는 예외와 통신 중단을 처리한다. ft_launcher는 SIGKILL, 메모리 부족 종료, 일부 운영체제 수준 중단 같은 이벤트를 처리한다.
Kubernetes는 전체 노드가 사라지는 장애에 대한 최외곽 계층으로 남는다. 이 접근 방식은 중첩된 복구 영역의 집합과 유사하다. 각 메커니즘은 장애가 그 아래 계층의 경계를 넘을 때만 개입한다.
학습 포드는 피어 탐색을 위해 헤드리스 Kubernetes Services를 사용한다. 워커는 고정 IP 주소가 아닌 DNS를 통해 서로를 찾는다. 이 구성은 운영자가 작업 구성을 다시 작성하지 않아도 교체 워커가 복귀하는 데 도움이 된다.
AWS는 이전에 PyTorch 도구를 사용한 EKS 기반 탄력적 분산 학습을 설명한 바 있다. NVRx 작업은 복구 루프를 한층 더 좁힌다. 개별 rank가 실패하거나 멈추거나 사라질 때 활성 작업의 생산성을 유지하는 데 초점을 맞춘다.
이러한 차이는 이 글의 중심 긴장을 만든다. Kubernetes는 인프라를 복원할 수 있지만, 인프라 복구에는 모델 상태, 프로세스 그룹, 체크포인트 타이밍에 대한 상세한 지식이 부족하다. NVRx는 이러한 결정을 학습 애플리케이션 내부로 가져온다.
블로킹 체크포인트가 전체 경과 시간의 약 40%를 소비했다
첫 번째 성능 문제는 GPU 연산이 아니었다. 모든 rank가 체크포인트 데이터가 스토리지에 도달하기를 기다리며 보낸 시간이었다.
동기식 체크포인트는 필요한 모델 및 옵티마이저 상태가 기록될 때까지 학습을 일시 중지한다. 분산 FSDP 작업에서는 이 중단이 모든 참여 rank에 영향을 미친다. 정상 GPU는 계속 할당돼 있지만, 쓰기 동안 순전파나 역전파 연산을 수행하지 않는다.
AWS는 동기식 체크포인팅이 확장성 테스트에서 57%~61%의 학습 효율만 냈다고 보고했다. 스토리지 쓰기는 약 275초가 걸렸으며, 이 시간은 16개와 64개 GPU 사이에서 대체로 일정하게 유지됐다. 따라서 컴퓨팅을 추가해도 스토리지 병목으로 인한 중단은 사라지지 않았다.
NVRx 비동기 체크포인팅은 쓰기 경로를 바꾼다. 학습 프로세스는 CPU에 상태를 스테이징한 뒤 작업을 지속 실행되는 백그라운드 프로세스에 넘긴다. 이후 메인 프로세스는 스토리지 I/O가 계속되는 동안 다음 학습 단계로 돌아간다.
구현은 TorchAsyncCheckpoint와 해당 async_save() 메서드를 사용한다. 또 다른 저장을 시작하기 전 또는 종료 전에는 애플리케이션이 진행 중인 작업을 완료한다. 이 조정은 완료되지 않은 체크포인트가 다음 체크포인트와 조용히 충돌하는 일을 방지한다.
FSDP 로컬 상태 딕셔너리는 설계를 강화한다. 각 rank가 자체 샤드를 기록하므로 all-gather 작업과 단일 rank-zero 쓰기 병목을 피할 수 있다. PyTorch의 FSDP 문서는 참여 워커 전반에 파라미터를 분산하는 더 광범위한 샤딩 모델을 설명한다.
체크포인트 간격을 1,000단계로 설정했을 때 AWS는 NVRx 비동기 체크포인팅이 2개 노드에서 99.2%의 학습 효율을 달성했다고 밝혔다. 8개 노드에서는 효율이 99.8%에 도달했다. 동기식 비교 결과는 8개 노드에서 60.3%였다.
이 수치는 모든 모델이나 스토리지 구성에 대한 보장이 아니라 공급업체가 보고한 벤치마크 결과다. 그럼에도 이를 뒷받침하는 메커니즘은 단순하다. 연산 시간이 스토리지 쓰기보다 길면 백그라운드 작업은 유용한 학습 작업 뒤에 거의 완전히 숨을 수 있다.
AWS가 체크포인트 빈도를 높이자 한계가 분명해졌다. 8개 노드에서 100단계마다 체크포인트를 수행할 경우 동기식 효율은 14.7%로 떨어졌다. 비동기 효율도 하락했지만 29.6%로 더 높게 유지됐다.
이유는 타이밍이었다. 100개 학습 단계는 약 280초가 걸렸고, 체크포인트 쓰기는 약 275초가 걸렸다. 다음 스토리지 작업을 숨길 수 있는 여유 연산 창은 거의 없었다.
이것이 NVRx 비동기 체크포인팅의 실제 한계다. 비동기 I/O는 연산 뒤에 쓰기를 숨길 수 있지만, 스토리지를 무한히 빠르게 만들 수는 없다. 저장 요청이 파일시스템의 완료 속도만큼 빠르게 도착하면 대기열은 결국 압력을 가하게 된다.
이 제약이 있더라도 이 기능은 팀이 체크포인트 간격을 선택하는 방식을 바꾼다. 동기식 시스템은 모든 저장이 눈에 보이는 유휴 시간을 발생시키므로 체크포인트 수를 줄이도록 유도한다. 저장 빈도가 낮아지면 장애 후 손실되는 학습량은 늘어난다.
비동기 체크포인팅은 이러한 상충 관계를 완화한다. 쓰기 사이에 충분한 연산이 존재한다면 팀은 더 자주 저장할 수 있다. 더 짧은 간격은 롤백 거리를 줄이고, 중첩된 I/O는 GPU 투자분을 더 많이 보존한다.
결과는 단순히 더 빠른 체크포인트 API가 아니다. 정상 상태 효율과 복구 가능한 진행도 간의 다른 균형이다. 이 균형은 작업이 길어지고 장애 가능성이 있는 구성 요소가 늘어날수록 더 가치 있어진다.
프로세스 내 재시작, Kubernetes 전용 복구 모델에 도전
가장 빠른 복구 경로는 Python 프로세스를 유지하고 장애로 손상된 분산 리소스만 재구축한다.
레퍼런스 구현에서 NVRx는 메인 학습 함수를 프로세스 내 재시작 컨트롤러로 감싼다. 지원되는 예외가 발생하면 래퍼는 활성 시도를 중단하고 다음 호출을 준비한다. 외부 Python 프로세스는 이 과정 전체에서 계속 살아 있다.
NVRx는 먼저 손상된 PyTorch 분산 프로세스 그룹을 중단한다. 플라이트 레코더 추적을 수집하고, NCCL 백엔드를 중지하며, 유효하지 않은 그룹을 제거할 수 있다. NCCL은 GPU 간 집합 연산을 위한 NVIDIA의 통신 라이브러리다.
그런 다음 상태 검사는 각 rank와 연결된 리소스를 검사한다. 이러한 검사는 GPU, NVLink 연결, 네트워크 인터페이스, 반복적인 rank 장애를 포괄할 수 있다. 재시도 컨트롤러는 재시작 횟수를 제한하고, 얼마나 많은 활성 rank가 살아남아야 하는지 결정한다.
시스템은 살아남은 rank를 연속된 그룹으로 재할당하고 새로운 rendezvous를 시작한다. 감싼 학습 함수는 FSDP 모델을 다시 만들고, 최신 체크포인트를 로드한 뒤 작업을 재개한다. Python 인터프리터와 감싼 함수 외부의 객체는 계속 사용할 수 있다.
이 기법은 소프트 장애를 겨냥한다. 처리되지 않은 애플리케이션 예외와 워치독이 감지할 수 있는 NCCL 중단이 그 예다. 모든 차단된 네이티브 호출에서 Python 예외가 안정적으로 발생한다고 가정하지는 않는다.
대신 진행 워치독은 Python 바이트코드 작업 사이의 활동을 기록한다. 별도의 모니터링 스레드는 공유 상태를 확인하며, 하나의 rank가 진행을 멈추면 재시작을 요청할 수 있다. 이후 시스템은 참여 워커 전반에서 중단을 조정한다.
AWS는 이 접근 방식을 ft_launcher 및 기본 Kubernetes 복구와 비교했다. 실험에는 p5.48xlarge 노드 2개, H100 GPU 16개, FSDP 기반 Llama 3.1 8B가 사용됐다. 작업은 2,000단계 동안 실행됐으며 500단계마다 저장했다.
연구진은 동일한 일정에 따라 각 실행에 결정론적 장애 5개를 주입했다. NVRx 프로세스 내 재시작은 컨테이너를 재시작하지 않고 장애당 약 10초 만에 복구됐다. AWS는 학습 goodput 31%, 인프라 goodput 87%를 측정했다.
학습 goodput은 유효한 학습 진행을 만들어 내는 시간을 측정한다. 인프라 goodput은 할당된 인프라가 정상 작동하고 사용 가능한 시간을 측정한다. 둘 사이의 차이에는 롤백과 체크포인트 로딩을 비롯해 모델을 전진시키지 않는 작업이 포함된다.
기본 Kubernetes 복구는 주입된 장애당 약 270초가 걸렸다. 보고된 실험에서 학습 goodput은 11.5%, 인프라 goodput은 35.8%였다. 따라서 이 비교는 컨테이너 시작 최적화 이상의 의미를 갖는다.
AWS에 따르면 하나의 실패한 rank는 살아남은 rank에서 통신 타임아웃을 유발했다. 이후 포드가 동기화되지 않은 상태로 재시작되면서 반복적인 타임아웃 주기와 CrashLoopBackOff 동작이 발생했다. 오케스트레이터는 분산 학습 그룹이 함께 복구되어야 하는 방식을 이해하지 못한 채 컨테이너를 복원했다.
애플리케이션 인지형 복구는 이처럼 누락된 컨텍스트에 접근할 수 있다. 진행이 언제 멈췄는지, 어떤 프로세스 그룹이 무효화됐는지, 어떤 체크포인트로 학습을 재시작할 수 있는지를 안다. Kubernetes는 포드 상태와 노드 상태를 보지만 FSDP 학습 단계의 완전한 의미론은 보지 못한다.
그렇다고 Kubernetes 복구가 불필요해지는 것은 아니다. 죽은 노드는 인터프리터, CUDA 상태 또는 로컬 프로세스를 보존할 수 없다. 노드 교체는 여전히 클러스터 계층의 역할이며, 복구된 워커는 계속해서 영속적인 체크포인트 데이터가 필요하다.
압박은 포드 재시작을 유일한 내결함성 정책으로 사용하는 팀에 가해진다. 이 접근 방식은 여전히 단순하지만, 복구 시간 창에서 상당한 가속기 시간을 낭비할 수 있다. 하나의 장애가 정상 워커 다수를 유휴 상태로 만들 수 있으므로 클러스터가 커질수록 비용도 증폭된다.
NVRx Fault Tolerance, 소프트 장애와 하드 장애를 분리
단일 재시작 메커니즘으로는 모든 장애를 처리할 수 없으므로, NVRx fault tolerance는 프로세스 보존형 복구와 워커 교체를 분리한다.
ft_launcher 구성 요소는 프로세스 내 재시작으로는 살아남을 수 없는 장애를 처리합니다. 여기에는 SIGKILL, 메모리 부족(OOM) 종료, 사용 가능한 Python 인터프리터를 남기지 않는 실패가 포함됩니다. 익숙한 rendezvous 개념을 유지하면서 torchrun을 대체합니다.
각 훈련 rank는 분산 초기화 후 RankMonitorClient를 생성합니다. 클라이언트는 훈련 중 heartbeat를 전송합니다. rank별 모니터 서버는 이러한 신호를 일반 실행 및 초기 시작 조건에 맞춰 구성된 timeout과 비교합니다.
AWS 구성에서는 rank heartbeat timeout을 900초로 사용했습니다. 초기 heartbeat timeout은 1,200초로 설정해 최초 모델 로딩에 더 많은 시간을 허용했습니다. 5초 monitor interval은 launcher가 worker 상태를 확인하는 빈도를 제어했습니다.
이 값들은 보편적인 권고안이 아니라 구성 예시입니다. heartbeat timeout은 신호 사이에 발생할 수 있는 가장 긴 정상 지연보다 길어야 합니다. 너무 짧으면 느린 checkpoint 또는 모델 초기화가 worker 실패처럼 보일 수 있습니다.
worker가 종료되거나 응답을 멈추면 ft_launcher는 남은 worker를 종료합니다. GPU 메모리를 회수하고, 다시 rendezvous를 수행한 뒤, 동일한 job 내부에서 새 프로세스를 시작합니다. 새 worker는 가장 최근 checkpoint에서 상태를 복원합니다.
launcher guide는 NVIDIA의 NeMo RL 스택에서도 같은 일반적 패턴을 보여 줍니다. 이처럼 더 광범위한 통합은 NVRx가 EKS 전용 유틸리티가 아니라 재사용 가능한 복원력 계층으로 설계됐음을 시사합니다.
AWS는 ft_launcher에서 주입된 장애당 약 17초의 복구 시간을 측정했습니다. 보고된 실행은 25.5%의 훈련 goodput과 85.9%의 인프라 goodput을 달성했습니다. 이는 프로세스 내 복구보다 느렸지만, 270초인 Kubernetes 기준선보다는 훨씬 빨랐습니다.
이 차이는 각 방식이 보존하는 상태의 양을 반영합니다. 프로세스 내 재시작은 인터프리터와 외부 프로세스를 유지합니다. ft_launcher는 새 worker를 생성하고, 분산 상태를 초기화하며, 모델을 다시 구성하고, checkpoint를 다시 로드해야 합니다.
더 큰 규모에서는 checkpoint 로딩이 복구 시간의 대부분을 차지할 수 있습니다. 프로세스 생성이 빨라져도 모델 및 optimizer shard를 읽어야 한다는 점은 변하지 않습니다. 따라서 공유 filesystem 처리량은 여전히 fault-tolerance 설계의 일부입니다.
Amazon EKS NVRx 훈련 아키텍처는 GPU node와 동일한 Availability Zone에 있는 FSx for Lustre SCRATCH_2 filesystem을 사용했습니다. 이 배치는 checkpoint 읽기 지연을 줄이기 위한 것이었습니다. 복구 후 모든 worker가 동일하게 지속 저장된 상태에 접근할 수 있었습니다.
NVRx async checkpointing은 두 재시작 경로 모두와 독립적입니다. 이는 쓰기 관련 유휴 시간을 줄이고 위험에 노출되는 진행량을 제어합니다. 재시작 계층은 장애 후 worker가 얼마나 빨리 복귀하는지를 결정합니다.
이러한 분리는 운영자에게 더 많은 선택지를 주지만, 동시에 정책 작업도 추가합니다. 어떤 예외가 프로세스 내 복구를 촉발할 수 있는지, 몇 번의 재시도가 안전한지, 어떤 health check가 rank를 제거해야 하는지를 결정해야 합니다. heartbeat 및 rendezvous timeout도 설정해야 합니다.
NVIDIA는 NVRx project를 실험적이며 활발히 개발 중인 프로젝트로 분류합니다. 문서에서는 기능과 인터페이스가 변경될 수 있다고 경고합니다. 프로덕션 팀은 버전 선택과 업그레이드 테스트를 복원력 계획의 일부로 다뤄야 합니다.
AWS는 benchmark를 재현하기 위해 NVRx 0.4.1을 사용했습니다. 이 게시물은 현재 배포를 위해 업데이트된 launcher 구성과 함께 버전 0.6.0을 권장합니다. fault-tolerance 시스템은 핵심 시작 및 복구 경로에 직접 위치하므로 이러한 버전 차이는 중요합니다.
복구 불가능한 job을 반복적으로 재시작한다면, 실패한 복구 메커니즘은 자동화가 전혀 없는 것보다 더 나쁠 수 있습니다. 재시도 제한, 최소 world size, fault counter는 무제한 루프를 방지합니다. 운영자에게는 성공적인 복구와 반복되는 실패를 구분하는 알림도 여전히 필요합니다.
99% 결과에는 중요한 경계가 있습니다
이 benchmark는 강력한 메커니즘을 뒷받침하지만, 모든 분산 훈련 workload에서 99% 효율을 입증하는 것은 아닙니다.
AWS는 H100 기반 p5 instance에서 PyTorch FSDP와 함께 Llama 3.1 8B라는 하나의 주요 모델 구성을 테스트했습니다. EFA 네트워킹과 FSx for Lustre 스토리지를 사용했습니다. 모델 크기, 스토리지 경로, checkpoint 형식, step 시간은 달라질 경우 overlap window도 달라집니다.
99% 수치는 선택된 interval에서의 async checkpoint 효율에 적용됩니다. 반복적인 장애 상황에서의 종단 간 goodput을 설명하지는 않습니다. 장애 주입 테스트에서 훈련 goodput은 프로세스 내 복구의 경우 31%, ft_launcher의 경우 25.5%에 머물렀습니다.
이처럼 낮은 결과는 checkpoint 측정치와 모순되지 않습니다. 서로 다른 질문에 답하기 때문입니다. async 효율은 정상 훈련 중 checkpoint overhead를 측정하는 반면, goodput에는 장애 주입, rollback, 로딩 및 기타 복구 작업이 포함됩니다.
Checkpoint 빈도에도 피할 수 없는 한계가 있습니다. 100 step마다 한 번 checkpoint를 생성했을 때 async 훈련은 99%가 아니라 29.6% 효율에 도달했습니다. 연산 시간과 쓰기 시간이 비슷했기 때문에 스토리지 시스템은 거의 지속적으로 사용됐습니다.
메모리 압박 역시 주의할 필요가 있습니다. Async checkpointing은 즉각적인 GPU 작업 외부에서 데이터를 staging하고, 백그라운드 프로세스에 쓰기 책임을 부여합니다. 팀은 실제 state dictionary에서 CPU 메모리, queue depth, 스토리지 backlog를 측정해야 합니다.
복구 범위도 또 다른 경계입니다. 운영체제가 worker를 종료하거나 node가 사라지는 경우 프로세스 내 재시작은 도움이 되지 않습니다. ft_launcher는 종료된 프로세스를 대체할 수 있지만, 여전히 job, 클러스터 네트워크, rendezvous 서비스, checkpoint store에 의존합니다.
Node 손실은 여전히 Kubernetes의 과제입니다. 리전 스토리지 중단이나 손상된 checkpoint는 모든 복구 계층을 동시에 무력화할 수 있습니다. 이 아키텍처는 여러 일반적인 장애 비용을 줄이지만, 공유 의존성을 없애지는 않습니다.
장애 탐지는 false positive를 만들 수도 있습니다. 긴 컴파일 단계, 데이터 로딩 중단 또는 filesystem 정체가 지나치게 공격적인 heartbeat timeout을 초과할 수 있습니다. 그러면 launcher는 정상 worker를 재시작하고 유효한 진행 상황을 버리게 됩니다.
자동 복구를 활성화하기 전에 팀에는 workload별 timeout 데이터가 필요합니다. 가장 긴 모델 초기화, checkpoint, validation, 데이터 입력 interval을 기록해야 합니다. 테스트에는 정규 훈련 step 내부의 실패뿐 아니라 이러한 단계에서 발생하는 실패도 포함해야 합니다.
AWS benchmark는 결정론적으로 주입된 장애를 사용했습니다. 이 접근법은 반복 가능한 비교를 지원하지만, 프로덕션 장애는 덜 정돈돼 있습니다. 실제 클러스터에서는 네트워크 성능 저하, 스토리지 감속, 열 문제, 프로세스 충돌이 동시에 발생할 수 있습니다.
reference implementation은 팀이 이 구성을 재현하는 데 유용한 출발점을 제공합니다. 서로 다른 instance family와 모델 규모에서의 재현은 보고된 이점이 얼마나 이식 가능한지를 결정할 것입니다.
운영 복잡성은 마지막 tradeoff입니다. 이 스택에는 Kubernetes Jobs, DNS 기반 peer discovery, EFA 리소스, 공유 스토리지, NVRx wrapper, monitor client, 여러 timeout 계층이 포함됩니다. 각 구성 요소는 또 하나의 구성 표면을 만듭니다.
큰 GPU fleet이 하나의 rank 실패 후 수분 동안 유휴 상태가 된다면 이러한 복잡성은 여전히 정당화될 수 있습니다. 그러나 더 작은 job은 더 단순한 pod 재시작 전략을 수용할 수 있습니다. 관련 계산은 benchmark의 명성이 아니라 복구 비용에 장애 빈도를 곱한 값입니다.
이 설계를 평가하는 팀은 훈련 goodput과 인프라 goodput을 모두 추적해야 합니다. GPU utilization만으로는 모델이 오래된 checkpoint를 반복적으로 다시 로드하는 동안에도 정상적으로 보일 수 있습니다. 유용한 dashboard는 완료된 step, rollback 거리, checkpoint 최신성, 재시작 원인을 보여줘야 합니다.
엔지니어링 조직에는 이러한 실험의 지속 가능한 기록도 필요합니다. 검색 가능한 engineering knowledge base는 timeout 변경, fault trace, benchmark 결과를 연결할 수 있습니다. 이러한 맥락은 팀이 실패한 복구 구성을 반복하지 않도록 돕습니다.
Amazon EKS NVRx Benchmark 이후 주시할 점
다음 증거는 이 설계가 더 큰 모델, 실제 장애, 변화하는 NVRx release 전반에서도 이점을 유지하는지 보여줘야 합니다.
첫 번째 신호는 64개 H100 GPU를 넘어선 독립적인 재현입니다. AWS는 2개에서 8개 node까지의 확장을 테스트했지만, 클러스터 크기가 커질수록 장애 빈도와 조정 비용도 증가합니다. 수백 개 accelerator에 걸친 결과는 rendezvous와 checkpoint 로딩의 한계를 더 잘 드러낼 것입니다.
더 큰 테스트는 평균 복구 시간 이상을 보고해야 합니다. 드물게 발생하는 5분 복구가 장기 실행의 경제성을 좌우할 수 있으므로 분포가 중요합니다. 보고서에는 tail latency, 재시작 실패 시도, incident당 손실된 진행량이 포함돼야 합니다.
두 번째 신호는 주요 훈련 framework 내부에서의 채택입니다. NVRx는 이미 PyTorch 기반 workload와 연결되며 NVIDIA의 더 광범위한 소프트웨어 스택에 등장합니다. 더 많은 native integration은 팀이 유지해야 하는 custom wrapper 및 launcher 코드의 양을 줄일 것입니다.
Framework 채택은 NVRx fault tolerance가 표준 application layer가 될 수 있다는 근거를 강화할 것입니다. 특히 framework마다 서로 다른 timeout, checkpoint, rendezvous 로직이 필요하다면 분절된 integration은 이 주장을 약화할 것입니다.
세 번째 신호는 통제되지 않은 프로덕션 장애의 증거입니다. 결정론적 장애 주입은 비교에 필요하지만, 현장 incident는 실험실에서 거의 재현하지 못하는 조합을 시험합니다. 운영자는 GPU 오류, NCCL 정체, OOM 종료, node 손실에 대한 복구율을 각각 공개해야 합니다.
성공적인 복구는 단순히 프로세스를 재시작하는 것 이상을 의미해야 합니다. Job은 유효한 상태를 복원하고, 올바른 update를 계속 생성하며, 조용한 checkpoint 손상을 피해야 합니다. 반복 복구 후의 모델 수렴은 복구 속도와 동일한 수준으로 면밀히 검토할 가치가 있습니다.
현재 Amazon EKS NVRx 훈련을 고려하는 팀의 실용적인 첫 단계는 통제된 shadow benchmark입니다. 실제 모델, checkpoint 크기, filesystem, step 시간을 사용하세요. 하나의 장애 일정 아래에서 동기 저장, async 저장, launcher 복구, Kubernetes 전용 복구를 비교하세요.
그런 다음 관찰된 연산 및 스토리지 시간을 사용해 checkpoint interval을 조정하세요. Checkpoint가 저장 간 interval만큼 오래 걸린다면 async overlap은 계속 불완전할 것입니다. 연산이 더 넓은 window를 제공한다면, 보고된 99% 효율은 더 그럴듯해집니다.
복구 정책은 보수적인 재시도 제한으로 시작해야 합니다. 모든 재시작 원인을 기록하고 진단 trace를 보존하세요. 동일한 rank 또는 checkpoint에서 반복적으로 실패하는 job에는 끝없는 복구 루프가 아니라 escalation이 필요합니다.
AWS와 NVIDIA의 작업은 한 가지 결론을 무시하기 어렵게 만듭니다. 분산 훈련의 신뢰성은 더 이상 인프라만의 관심사로 남을 수 없습니다. 애플리케이션은 orchestrator가 알지 못하는 방식으로 진행 상황, checkpoint 유효성, process-group 상태를 이해합니다.
Amazon EKS는 여전히 필수적인 scheduling 및 node 대체 기반을 제공합니다. NVRx는 그 경계 내부에서 더 빠른 대응을 더합니다. 두 기술을 함께 사용하면 여러 중요한 장애 유형에서 4분 복구 주기에서 초 단위 재시작으로 나아갈 신뢰할 만한 경로를 제공합니다.
이제 열린 질문은 개념적 문제가 아니라 운영상의 문제입니다. 팀은 자체 모델, 스토리지 시스템, 실제 장애 패턴으로 이러한 이득을 재현할 수 있을까요? 이것이 다음 Amazon EKS NVRx 훈련 배포를 이끌어야 할 시험입니다.
