GPU가 죽어도 학습은 멈추지 않는다: 대규모 자기 복구 학습

URL: https://www.youtube.com/watch?v=bRGyYaE0lxI 날짜: 2026-10-04 채널: aiDotEngineer

📌 핵심 질문 / GPU 장애가 발생해도 대규모 분산 학습을 중단하지 않는 방법은 무엇인가

==수천 개의 GPU를 사용하는 환경에서는 장애를 전제로 Slurm의 고성능 스케줄링과 Kubernetes의 자기 복구·관찰 가능성을 한 스택으로 결합해야 한다.==

• GPU 고장은 대규모 클러스터에서 불가피하며, 장애 노드를 사람이 새벽에 고치는 방식은 확장되지 않는다.
• Slurm은 gang scheduling, topology awareness, 익숙한 sbatch 워크플로우를 제공하지만 동적 리소스 관리·노드 상태 관리·관찰 가능성은 별도로 보강해야 한다.
• Crusoe Managed Slurm on Kubernetes와 AutoClusters는 알림 → 노드 down 처리 → 작업 취소와 재큐 → 노드 cordon/drain → 예비 노드 교체 → checkpoint 기반 학습 재개를 자동으로 수행한다.

연구자는 기존 Slurm 명령을 그대로 사용하고 Kubernetes를 알 필요가 없다. 플랫폼 팀은 기존 Kubernetes 서비스·관찰 도구·온콜 체계 안에서 GPU 노드를 관리한다. XID 79 같은 치명적 GPU 오류가 발생해도 AutoClusters의 노드 교체 자체는 약 5분, 애플리케이션이 checkpoint를 읽고 재개하는 전체 중단 시간은 15분 미만으로 유지한다.

1. 문제의 성격과 Crusoe의 인프라

대규모 AI 학습의 운영 문제는 모델 코드보다 GPU 플릿의 장애와 복구에서 발생한다.

1.1. 발표의 출발점: 장애를 예외가 아니라 정상 상태로 보기

1. 발표자와 문제 정의

   1. 발표자: Crusoe의 Developer Advocate Connor Guerrero가 동료 Nikhil Gupta, Young Jeong과 함께 발표한다.
   2. 핵심 상황: 수천 개의 GPU에서 매우 큰 학습 작업을 돌리면 GPU 장애는 필연적으로 발생한다.
   3. 운영 한계: 규모가 커질수록 장애 때마다 사람이 개입해 원인을 찾고 노드를 교체하는 방식은 완전히 지속 불가능하다.

2. 해결 목표

   1. 자동 복구 플랫폼: Slurm과 Kubernetes를 함께 사용해 치명적인 하드웨어 오류를 자동으로 처리한다.
   2. 두 사용자 집단의 사용성 보존: 머신러닝 엔지니어는 익숙한 방식으로 작업을 제출하고, 플랫폼 팀은 클러스터를 관리하는 기존 운영 방식을 유지한다.
   3. 발표의 범위: 전통적 Slurm의 강점과 한계, Kubernetes를 결합한 아키텍처, XID 79 복구 흐름, 학습 중 GPU 장애 데모, one-click Slurm을 차례로 다룬다.

1.2. Crusoe Cloud와 관리 도구의 위치

1. 기본 클라우드 인프라

   1. Infrastructure as a Service: Crusoe Cloud는 compute, storage, networking과 NVIDIA·AMD 최신 세대 GPU를 제공한다.
   2. 발표의 초점: 원시 인프라보다 대규모 GPU 플릿을 오케스트레이션하는 상위 tooling에 초점을 둔다.

2. 두 핵심 서비스

   1. Crusoe Managed Kubernetes(CMK): 클라우드의 Kubernetes 관리형 서비스다.
   2. Managed Slurm: CMK 위에 구축되며 Slinky를 기반으로 한다. Slinky는 Kubernetes 위에서 Slurm을 실행하기 위한 SCALABLE COMPUTING 계열의 공식 오픈소스 프로젝트다.
   3. 결합 효과: Slurm의 고성능 job scheduling에 Kubernetes의 인프라 복원력과 observability를 더한다.
   4. AutoClusters: GPU 노드의 실패를 자동으로 탐지하고 교체하는 Crusoe 시스템이다.

2. Slurm이 잘하는 일과 현대 AI 워크로드의 간극

Slurm은 분산 학습에 적합한 연구자 중심 스케줄러지만, AI 워크로드의 동적성과 하드웨어 운영까지 혼자 책임지도록 설계되지는 않았다.

2.1. Slurm이 학습에 강한 이유

1. HPC에서 출발한 연구자 중심 설계

   1. 기원: Slurm은 약 20년 전 대학과 연구소 연구자들이 연구자를 위해 고성능 컴퓨팅(HPC)용으로 만들었다.
   2. 현대 AI와의 적합성: Crusoe 고객과 다른 사용자들이 관찰한 결과, 이 설계가 오늘날의 AI training workload에도 잘 맞는다.

2. 분산 학습 핵심 기능

   1. Tight collective communication: 여러 노드의 여러 rank가 긴밀하게 집단 통신해야 하는 multi-node training을 전제로 한다.
   2. Training 전용 네트워크: 학습 workload에 맞춘 특수 네트워크 사용을 고려한다.
   3. Gang scheduling: 분산 작업에 필요한 자원을 한꺼번에 배치해 일부 rank만 실행되는 상태를 피한다.
   4. Topology awareness: GPU와 네트워크 토폴로지를 고려해 통신 효율이 높은 배치를 선택한다.
   5. Prologue·epilogue: 작업 전후에 클러스터 검증과 정리 절차를 실행할 수 있다.
   6. 익숙한 인터페이스: 연구자는 기존 script와 클러스터 환경에서 사용하던 Slurm 도구를 그대로 쓴다.

2.2. AI workload의 동적성

1. 학습만으로 끝나지 않는 AI 플랫폼

   1. 워크로드 구성: training뿐 아니라 post-training, evaluation, inference가 함께 실행된다.
   2. 배치 위치의 다양성: 이 작업들이 모두 같은 Slurm 클러스터에 올라가는 것은 아니다.

2. 정적 파티셔닝의 한계

   1. GPU capacity constraint: GPU가 부족한 상황에서는 사용 가능한 자원을 workload 사이에서 더 동적으로 움직여야 한다.
   2. 전통적 Slurm의 성격: 파티션과 기타 기능이 비교적 정적이어서 수요 변화에 즉시 대응하기 어렵다.
   3. 운영 결론: AI 플랫폼은 고정된 학습 큐만 관리하는 것이 아니라, 변화하는 학습·평가·추론 자원을 함께 조정해야 한다.

2.3. 노드 상태와 관찰 가능성의 부족

1. Health check 운영 부담

   1. 문제: GPU는 실제로 고장 나므로 노드가 healthy인지 계속 판별해야 한다.
   2. Slurm의 관련 기능: 작업 재큐(requeue), 불량 노드 탐지, prologue와 공개 도구를 조합해 대응할 수 있다.
   3. 숨은 비용: 불량 노드를 찾고, drain하고, 우회하는 절차를 수동으로 하거나 별도 automation·script로 만들어야 한다.

2. Job 실패와 degraded performance

   1. 실패 원인의 다양성: GPU 고장 외에도 network flap과 스위치 문제로 성능이 저하되거나 작업이 실패할 수 있다.
   2. Slurm의 시야: Slurm은 job이 실패했다는 사실은 알지만, 왜 실패했는지의 모든 맥락을 알려주지는 않는다.
   3. 관찰 가능성의 역할: 하드웨어·네트워크·노드 상태와 작업 이벤트를 연결해 원인을 설명하는 observability가 필요하다.

3. Kubernetes 위의 Managed Slurm을 선택한 이유

두 개의 독립 인프라 스택을 병렬 운영하는 대신 Kubernetes를 공통 기반으로 삼아 Slurm 사용자 경험과 플랫폼 운영 경험을 동시에 보존한다.

3.1. Kubernetes가 보완하는 운영 기능

1. 클라우드의 운영체제

   1. 확산과 친숙함: Kubernetes는 널리 사용되며 팀들이 이미 익숙한 플랫폼이다.
   2. 성숙한 생태계: observability, networking, security에 필요한 도구·extension·plugin이 풍부하다.

2. 서비스 복원력

   1. Self-healing: 내장된 자기 복구 기능으로 서비스가 계속 동작하도록 유지한다.
   2. Load balancing·autoscaling: 트래픽과 수요에 따라 서비스를 안정적으로 유지하고 확장한다.
   3. 운영 통합: Slurm을 기존 Kubernetes 서비스와 같은 운영·관찰·보안 체계 안에 넣을 수 있다.

3.2. 두 스택을 따로 둘 때의 비용

1. 서로 다른 출발점

   1. Inference에서 training으로 확장: Kubernetes에 inference를 운영하던 팀은 Slurm 클러스터 배포와 관리가 낯설 수 있다.
   2. Training에서 inference로 확장: Slurm에 익숙한 연구팀은 기존 Kubernetes framework를 몰라 추가 마찰을 겪는다.

2. 팀 속도 저하

   1. 중복 운영: 두 스택을 두면 별도의 인프라, observability 도구, on-call 팀, runbook이 필요하다.
   2. 비용과 마찰: 다음 모델과 제품을 빠르게 내놓으려는 팀에게 이중 스택은 추가 비용과 설정 시간을 만든다.
   3. 아키텍처 결정: Crusoe는 Managed Slurm을 Kubernetes 위에 구축해 공통 플랫폼을 만들었다.

3.3. Crusoe Slurm Operator의 역할

1. 통합 배포와 관리

   1. 연결 범위: Crusoe Slurm Operator는 CMK 및 Crusoe Cloud의 storage·networking과 연동한다.
   2. 관리 대상: Slurm users, partitions, configurations, storage를 한꺼번에 관리한다.
   3. 선언적 생성: Slurm cluster 하나를 만드는 명령 한 번으로 Kubernetes cluster 안에 사용할 환경을 생성한다.

2. 사용자별 추상화

   1. 연구자: IP 주소로 SSH한 뒤 일반 Slurm cluster처럼 sbatch와 다른 Slurm 기능을 사용한다.
   2. 플랫폼 팀: Slurm을 기존 인프라에 붙는 또 하나의 service로 보고 같은 관찰 도구·온콜·리소스 풀을 사용한다.
   3. 경계 유지: 연구자는 Kubernetes가 아래에서 실행된다는 사실을 알 필요가 없고, 플랫폼 팀은 Kubernetes 수준의 관리 권한과 telemetry를 유지한다.

4. 하나의 GPU 풀에서 학습·추론·복구를 연결하기

GPU 노드를 Kubernetes 우선 자원으로 관리하면 학습과 추론의 수요가 바뀔 때 자원을 재할당하고, 장애가 생겨도 같은 제어면에서 복구할 수 있다.

4.1. Training과 inference 사이의 자원 재배치

1. 수요가 올라갈 때

   1. Inference burst: 사용자 수가 늘어 inference 서비스가 급증하면 training 클러스터의 일부 GPU를 inference 서비스에 재할당한다.
   2. 단일 스택의 이점: 모든 GPU와 하드웨어가 하나의 클러스터에 있으므로 별도 마이그레이션 없이 자원을 움직인다.

2. 수요가 내려갈 때

   1. 유휴 GPU 활용: 사용자 부하가 낮아 GPU가 놀면 그 자원으로 training job을 키운다.
   2. 대형 실험: 더 많은 GPU를 사용하는 큰 규모의 학습 실행을 시작할 수 있다.
   3. 조건: 이런 동적 가용성은 training과 inference가 한 인프라 스택의 노드 풀을 공유할 때 가능하다.

4.2. AutoClusters의 XID 79 복구 흐름

1. 장애 감지와 사용자 알림

   1. 오류 사례: GPU 하나를 완전히 사용할 수 없게 만드는 NVIDIA XID 79 같은 critical hardware error를 감지한다.
   2. 알림: 사용자에게 장애와 복구 이벤트를 알리지만, 사용자에게 요구되는 조치는 없다.

2. Slurm 작업의 안전한 종료

   1. 노드 차단: Slurm Operator가 해당 노드를 down 상태로 만들고 실행 중인 작업을 취소한다.
   2. SIGTERM 유예: 프로세스는 종료 전에 SIGTERM을 받으며, checkpoint를 저장하거나 log를 flush할 수 있는 시간이 최대 2분 주어진다.
   3. 재큐: 취소된 job은 자동으로 requeue된다.

3. Kubernetes 노드 교체

   1. 교체 예외 확인: AutoClusters는 해당 노드의 pod에 automatic replacement를 비활성화하는 label이 있는지 먼저 확인한다.
   2. 격리: 교체 가능한 노드라면 Kubernetes node를 cordon하고 drain한다.
   3. 대체: unhealthy node를 node pool에서 제거하고 spare capacity의 새 healthy node로 교체한다.
   4. 감사 기록: alert와 remediation 내역을 사용자가 확인할 수 있도록 기록한다.

4. 학습 재개

   1. Slurm 복귀: healthy node가 online으로 돌아오면 Slurm job이 다시 시작된다.
   2. 애플리케이션 책임: application code가 model과 checkpoint를 불러온다.
   3. 상태 보존: 마지막 checkpoint에서 학습을 이어가므로 장애 전 진행 상황을 처음부터 반복하지 않는다.

5. GPU 중단 데모와 성능 수치

데모는 학습 중 발생한 XID 79를 내부 모니터링 신호로 주입해, 사람의 개입 없이 노드 교체와 checkpoint 복귀가 이어지는 과정을 보여준다.

5.1. 데모 구성

1. 양쪽 화면의 역할

   1. 왼쪽: sbatch로 PyTorch training script를 실행한다.
   2. 오른쪽: Crusoe Cloud console에서 A100 GPU 노드 2개로 구성된 GPU node pool을 확인한다.
   3. 시작: 평소처럼 작업을 제출한 뒤 학습을 진행한다.

2. 장애 주입과 감지

   1. XID 79 주입: 내부 monitoring backend에 GPU 하나에서 XID 79가 발생했다고 알리는 script를 실행한다.
   2. 즉시 변화: 해당 GPU utilization이 즉시 떨어져 GPU가 offline이 되었음을 확인한다.
   3. 자동 시작: AutoClusters가 노드 교체를 바로 시작하고, 사용자에게 critical hardware error 알림을 보낸다.

5.2. 복구 시간과 사용자 경험

1. 시간 분해

   1. 인프라 복구: critical hardware error 감지부터 healthy node가 node pool에 돌아오기까지 약 5분이 걸린다.
   2. 애플리케이션 시간: 나머지 시간은 application-level code가 model·checkpoint를 로드하는 데 사용된다.
   3. 전체 결과: end-to-end로는 15분보다 조금 짧다.

2. 학습 결과

   1. 자동 재시작: Slurm job이 자동으로 재시작한다.
   2. Checkpoint 복구: 작업이 checkpoint를 로드하고 중단된 지점부터 학습을 계속한다.
   3. 다운타임: GPU utilization이 정상으로 돌아오고 총 downtime은 15분 미만이다.
   4. 운영 대비: 엔지니어가 한밤중에 로그인해 몇 시간 동안 원인을 디버깅하는 상황을 플랫폼이 대신 처리한다.

6. One-click Slurm과 최종 설계 원칙

복잡한 Slurm·Kubernetes 결합 환경을 한 명령으로 만들고, 장애가 당연히 발생한다는 전제에서 자율 복구를 기본값으로 삼는다.

6.1. One-click Slurm

1. 한 명령으로 만드는 환경
   1. 자동 프로비저닝: underlying Kubernetes cluster, Slurm controller, login node, storage를 한 번에 만든다.
   2. GPU 확장: GPU node pool 추가는 그 다음 명령 하나로 처리한다.
   3. 즉시 사용: 엔지니어는 곧바로 SSH해 job을 실행할 수 있다.
   4. 기본 복구: AutoClusters가 기본으로 활성화되어 별도 복구 시스템을 조립할 필요가 없다.

6.2. 전체 설계의 요약

1. 전통적 Slurm의 위치

   1. 장점: 고성능 job scheduling을 제공한다.
   2. 부족한 점: 현대 AI 인프라에 필요한 자동 healing과 인프라 수준의 관찰 가능성을 단독으로 제공하지 않는다.

2. 두 시스템의 동기화

   1. 공통 기반: Kubernetes 위에 Slurm을 두면 두 시스템이 같은 인프라 상태를 바라본다.
   2. 장애 신호 전파: 실패한 GPU node가 Kubernetes에서 자동으로 cordon되면 그 신호가 Slurm Operator로 직접 전파된다.
   3. 워크플로우 보존: 플랫폼 팀과 머신러닝 팀 모두 작업 방식을 바꿀 필요가 없다.

3. GPU node를 Kubernetes 우선으로 보기

   1. Slurm은 workload: GPU node는 Kubernetes node가 먼저이고 Slurm은 그 위에서 실행되는 workload다.
   2. 작업 종료 후 재사용: Slurm job이 끝나도 GPU node가 다음 Slurm job만 기다리며 유휴 상태로 남지 않는다.
   3. 즉시 추론 배치: 플랫폼 관점에서는 여전히 pool의 Kubernetes node이므로 inference pod를 바로 스케줄링할 수 있다.

6.3. Q&A와 마무리

1. 현장에서의 질문 유도

   1. 질문 방식: 발표자는 참석자에게 질문이 있으면 연결해 달라고 안내한다.
   2. 접점: San Francisco AI Engineer World's Fair 2026 현장의 booth UG12 또는 소셜 채널 crusadev에서 Crusoe 팀을 만날 수 있다고 말한다.

2. 최종 원칙

   1. 실패의 불가피성: AI 시대의 대규모 인프라에서는 critical error를 피할 수 없다고 전제한다.
   2. 자율 처리: 오류가 나면 알림·격리·교체·재큐·재개가 올바른 순서로 자동 수행되도록 아키텍처를 설계한다.
   3. 엔지니어의 집중: 엔지니어는 인프라 장애를 걱정하는 대신 애플리케이션 구축에 집중해야 한다.

주요 발언 모음

"GPU failures are inevitable. And so at scale, manual remediation is completely unsustainable."

"By using both Slurm and Kubernetes, we can provide a robust platform with automated remediation that maintains ease of use for both machine learning engineers and the platform teams managing the underlying clusters."

"The total downtime is less than 15 minutes."

"GPU nodes are Kubernetes nodes first. Slurm is just a workload running on top."

"Failures are inevitable. The architecture of infrastructure should be designed so that when there is a critical error, all the right actions are handled autonomously."

핵심 데이터 & 수치

• 수천 개의 GPU: 대규모 학습에서는 GPU 장애가 통계적 예외가 아니라 운영상 필연이다.
• 최대 2분: SIGTERM 이후 checkpoint 저장과 log flush에 사용할 수 있는 유예 시간이다.
• 약 5분: AutoClusters가 critical hardware error를 감지한 뒤 healthy node를 node pool에 되돌리는 인프라 복구 시간이다.
• 15분 미만: 모델·checkpoint 로딩을 포함한 end-to-end downtime이다.
• 2개 A100 노드: GPU 장애 데모에서 사용한 node pool 규모다.
• 20년 이상: Slurm이 대학·연구소의 HPC용으로 발전해 온 시간의 규모다.
• 2026년 AI Engineer World's Fair: 발표가 녹화된 행사와 장소는 San Francisco다.

결론 및 시사점

1. 장애를 전제로 설계: GPU·네트워크·노드 고장은 제거할 수 없으므로 수동 복구 절차를 자동화된 기본 경로로 바꿔야 한다.
2. 역할 분리와 통합: Slurm은 분산 학습의 gang scheduling과 topology awareness를 담당하고, Kubernetes는 노드 수명주기·self-healing·observability를 담당한다.
3. 한 스택의 운영 효율: training과 inference가 같은 Kubernetes 노드 풀을 공유하면 수요에 따라 GPU를 재배치하고 유휴 자원을 줄일 수 있다.
4. Checkpoint가 복구의 경계: SIGTERM 유예 시간 안에 상태를 저장하고, 새 노드에서 애플리케이션이 checkpoint를 읽게 하면 GPU 교체가 학습 손실로 이어지지 않는다.
5. 사용자 경험 보존: 연구자는 sbatch와 SSH를 계속 사용하고, 플랫폼 팀은 Kubernetes의 기존 telemetry와 runbook을 유지해야 한다.
6. 자율 복구의 기준: 성공적인 시스템은 장애를 알리는 데서 끝나지 않고 cordon, drain, 교체, requeue, resume까지 연결해야 한다.
7. 운영자의 시간 보호: 15분 미만의 자동 downtime은 새벽에 사람이 몇 시간 동안 장애를 분석하는 비용보다 훨씬 낫다.