GPU Died. Training Didn't: Self-Healing Training at Scale — Crusoe

한 줄 핵심

대규모 GPU 학습에서는 GPU 장애가 피할 수 없으므로, Slurm의 고성능 스케줄링과 Kubernetes의 복원력·관측성을 결합해 실패를 자동 복구하는 인프라가 필요하다는 점을 보여주는 영상이다.

시간별 요약

1. 0:00
   소개 Crusoe에서 구축한 인프라가 치명적 하드웨어 오류를 어떻게 처리하는지 설명하며, 수천 개 GPU 규모의 학습에서는 수동 복구가 지속 가능하지 않다는 문제의식을 제시한다.
2. 0:12
   GPU 장애는 피할 수 없다 대규모 학습 환경에서는 GPU 장애가 필연적이므로 자동화된 복구가 필요하며, Slurm과 Kubernetes를 함께 써서 학습 엔지니어와 플랫폼 팀 모두가 쓰기 쉬운 복원성 높은 플랫폼을 만든다는 점을 강조한다.
3. 0:56
   Crusoe Cloud란 무엇인가 Crusoe Cloud는 컴퓨트·스토리지·네트워킹과 Nvidia, AMD 최신 GPU를 제공하는 IaaS이며, 그 위에 CMK와 managed slurm, 그리고 장애 GPU 노드를 자동 감지·교체하는 autoclusters 같은 운영 도구를 얹어 대규모 GPU 플릿을 관리한다.
4. 1:56
   이 아키텍처를 선택한 이유 전통적인 Slurm의 장점과 한계를 함께 이해해야 현재의 아키텍처가 자연스럽게 설명되며, 특히 현대 AI 학습의 동적 요구와 장애 대응에는 추가적인 복원력 계층이 필요하다.
5. 2:13
   Slurm이 강한 부분 Slurm은 HPC에서 출발해 멀티 노드 학습에 필요한 타이트한 집단 통신, gang scheduling, topology awareness, prologue/epilog 같은 기능을 제공하므로 연구자들에게 익숙한 방식으로 고성능 학습 작업을 잘 지원한다.
6. 3:31
   Slurm의 한계 현대 AI 워크로드는 학습만이 아니라 post-training, eval, inference까지 포함해 훨씬 동적이지만, Slurm은 파티션 중심으로 비교적 정적이어서 GPU 자원 활용과 운영 유연성에서 한계가 드러난다.
7. 4:21
   노드 상태 검사 GPU 장애 노드를 감지하고 drain하며 작업을 재큐잉하는 기능은 가능하지만, 이를 직접 운영하려면 수동 처리나 별도 자동화·스크립팅이 필요해 운영 부담이 커진다.
8. 5:04
   관측성의 공백 Slurm은 작업 실패 자체는 알 수 있지만 네트워크 문제나 성능 저하처럼 왜 실패했는지까지 충분히 설명하지 못하므로, 장애 원인 분석과 운영 가시성을 위해 Kubernetes 수준의 관측성이 중요해진다.
9. 5:51
   왜 Kubernetes인가 Kubernetes는 클라우드의 표준 운영 체계처럼 널리 쓰이고 생태계가 성숙해 있으며, 내장된 self-healing, 로드밸런싱, 오토스케일링과 함께 관측성·네트워킹·보안 확장성을 제공해 복원력 있는 서비스 운영에 유리하다.
10. 6:45
    두 개의 스택, 두 배의 부담 Inference는 Kubernetes, training은 Slurm처럼 팀이 익숙한 도구를 따로 쓰면 결국 인프라 스택이 분리되어 운영 부담과 비용이 늘어나므로, 둘을 하나의 구조로 묶는 접근이 필요하다.
11. 7:35
    Kubernetes 위의 managed Slurm Crusoe는 Slurm을 Kubernetes 위에 올려 하나의 명령으로 클러스터를 만들고, 사용자·파티션·설정·스토리지를 함께 관리하게 하여 Slurm 사용자는 기존처럼 쓰고 플랫폼 팀은 기존 인프라 안에서 운영하도록 만든다.
12. 8:09
    연구자와 플랫폼 팀이 보는 모습 연구자에게는 평범한 Slurm 클러스터처럼 보이지만, 플랫폼 팀에게는 기존 서비스에 붙는 하나의 서비스일 뿐이라 새로운 관측 도구나 온콜 체계를 따로 만들 필요가 없고, 같은 인프라에서 일관되게 운영할 수 있다.
13. 8:58
    학습과 추론 사이의 GPU 공유 모든 GPU가 하나의 클러스터에 있으면 수요가 높은 시점에 inference에 자원을 더 주거나, 유휴 시점에 training을 크게 돌리는 식으로 자원을 유연하게 재배치할 수 있어 하드웨어 활용도가 높아진다.
14. 9:43
    자동 복구: AutoClusters managed slurm은 autoclusters와 결합해 하드웨어 오류를 자동 복구할 수 있으며, 치명적 장애가 감지되면 노드를 교체하는 전체 절차가 별도 수동 개입 없이 진행된다.
15. 10:03
    XID 79 오류가 발생하면 XID 79 같은 치명적 GPU 오류가 나면 사용자에게 알림을 보내되 조치는 요구하지 않고, Slurm이 노드를 down 처리하고 작업을 재큐잉한 뒤 Kubernetes가 cordon·drain·교체를 수행하며 체크포인트 저장 시간을 확보한 뒤 새 노드로 재개한다.
16. 11:27
    학습 도중 GPU가 실패하는 데모 PyTorch 학습 작업 중 XID79를 인위적으로 발생시키면 GPU 사용률이 즉시 떨어지고 노드 교체가 시작되며, 장애 감지부터 건강한 노드 복귀까지 약 5분, 전체적으로는 15분 미만에 학습이 다시 이어진다.
17. 12:56
    15분 안에 학습 재개 자동 복구 후 GPU 사용률이 정상으로 돌아오고 전체 다운타임이 15분 미만으로 유지되어, 야간에 엔지니어가 직접 들어가 수 시간씩 디버깅하는 방식보다 훨씬 효율적이라는 점을 보여준다.
18. 13:16
    원클릭 Slurm 이전에는 Slurm과 Kubernetes를 함께 구성하는 일이 어려웠지만, 이제는 단일 명령으로 Kubernetes 클러스터, Slurm 컨트롤러, 로그인 노드, 스토리지를 프로비저닝하고 GPU 노드 풀만 추가하면 바로 사용할 수 있다.
19. 14:01
    요약 전통적인 Slurm은 고성능 스케줄링에는 강하지만 자동 치유는 약하며, Kubernetes 위에 올리면 두 팀의 워크플로를 바꾸지 않고도 장애 복구와 관측성을 갖춘 통합 환경을 만들 수 있다는 점을 정리한다.
20. 15:55
    실패를 전제로 설계하기 핵심은 장애가 반드시 발생한다는 사실을 전제로 인프라를 설계해, 치명적 오류가 나도 필요한 조치가 자동으로 수행되도록 만들고 엔지니어는 애플리케이션 개발에 집중하게 하는 것이다.

실무 인사이트

• GPU 학습 인프라는 성능만이 아니라 장애 감지·격리·교체·재개까지 포함한 복구 경로를 처음부터 설계해야 운영 비용이 급격히 줄어든다.
• 학습과 추론을 분리된 스택으로 운영하기보다 같은 GPU 풀을 공유하면 유휴 자원을 줄이고 수요 변동에 더 유연하게 대응할 수 있다.
• 연구자 경험을 유지하면서 플랫폼 팀의 관측성과 자동화를 확보하려면, 사용자 인터페이스는 Slurm처럼 익숙하게 두고 내부 실행 계층은 Kubernetes처럼 복원력 있게 구성하는 접근이 효과적이다.