Crusoe의 자가 치유 AI 학습

Crusoe의 엔지니어 Connor Guerrero에 따르면, 수천 개의 GPU에 걸쳐 학습을 관리할 때 GPU 장애에 대한 수동 해결은 지속 불가능하다고 합니다.

Crusoe 팀은 컴퓨팅, 스토리지, 네트워킹은 물론 플릿 오케스트레이션을 위한 전문 도구를 포함하는 서비스형 인프라 제공에서 견고성과 사용자 친화성을 모두 제공하기 위해 Slurm과 Kubernetes를 결합한 하이브리드 솔루션을 사용합니다.

Crusoe의 플랫폼인 '관리형 Slurm'은 Kubernetes, 즉 CMK 위에 구축되며, Kubernetes에서 Slurm을 실행하기 위한 SchedMD의 오픈 소스 프로젝트인 Slinky를 통합합니다.

이러한 아키텍처 선택을 통해 시스템은 Slurm의 고성능 작업 스케줄링을 달성하는 동시에 'AutoClusters'가 실패한 GPU 노드를 자동으로 감지하고 교체하여 인프라 복원력 및 관찰 가능성 측면에서 Kubernetes의 강점을 활용할 수 있습니다.

갱 스케줄링, 토폴로지 인식, 클러스터 유효성 검사를 위한 프롤로그/에필로그 기능과 같은 주요 기능은 연구원들에게 익숙하며, 연구원들은 확립된 워크플로 및 스크립트 때문에 Slurm을 계속 선호합니다.

Young Jeong은 학습, 학습 후 평가 및 추론을 포함하는 동적인 최신 AI 워크로드가 기존 Slurm 클러스터의 기능을 자주 초과한다고 언급했습니다.

Slurm 파티션의 정적인 특성은 제한된 GPU 용량에 대한 적응을 방해하고, 비정상 노드의 수동 감지 및 비우기와 같은 상당한 운영 부담을 야기합니다.

Slurm은 작업 실패를 식별할 수 있지만, 네트워크 중단이나 성능 저하와 같은 근본 원인을 진단하는 데 있어 관찰 가능성이 부족한 경우가 많습니다.

팀은 학습 및 추론을 위해 두 개의 개별 인프라 스택을 관리할 때 운영 마찰과 비용 증가를 자주 겪는데, Crusoe는 이 문제를 해결하는 것을 목표로 합니다.

Crusoe의 Nikhil Gupta는 Crusoe Slurm 연산자가 Crusoe Managed Kubernetes 플랫폼 및 더 넓은 Crusoe 클라우드와 협력하여 Slurm 작업을 기존 Kubernetes 제어 플레인에 직접 통합한다고 설명했습니다.

Crusoe 플랫폼을 사용하는 연구원은 SSH를 통해 표준 Slurm 인터페이스와 상호 작용하며, Kubernetes가 기본 인프라를 오케스트레이션한다는 사실을 알지 못합니다. 한편 플랫폼 팀은 Slurm을 또 다른 서비스로 취급하여 새로운 온콜 팀이나 전문 실행 설명서의 필요성을 없앱니다.

이러한 통합 접근 방식은 모든 GPU를 단일 클러스터에 배치하여 학습 및 추론 워크로드 간의 원활한 동적 재할당을 가능하게 하고, 추론 수요가 적은 기간에는 하드웨어를 학습 작업으로 전환하여 GPU 활용도를 극대화할 수 있습니다.

Nikhil Gupta가 설명했듯이, AutoClusters 시스템은 GPU를 사용할 수 없게 만드는 XID 79 오류와 같은 중요한 하드웨어 문제를 자율적으로 감지하고 수동 개입 없이 사용자에게 즉시 알립니다.

Slurm 연산자는 영향을 받는 노드를 다운으로 표시하고 작업 종료 신호를 보냅니다. 사용자는 체크포인트 또는 로그 플러싱을 위해 최대 2분까지 허용되며, 그 후 시스템은 교체 자격을 확인하고 비정상 노드를 자동으로 코돈, 드레인 및 교체합니다.

노드가 실패하면 예비 용량에서 가져온 정상 노드로 자동으로 교체되며, 시스템은 사용자에게 복구 경고를 기록합니다.

Connor Guerrero가 설명했듯이, 새 노드가 온라인 상태가 되면 Slurm 작업이 다시 시작되고 애플리케이션 코드는 자동으로 모델과 체크포인트를 로드하여 학습을 재개합니다.

Crusoe는 sbatch를 통해 두 개의 A100 노드에서 PyTorch 학습 스크립트를 실행한 다음, 의도적으로 한 GPU에서 XID 79 오류를 트리거하여 중요한 하드웨어 장애를 시뮬레이션함으로써 시스템의 복원력을 시연했습니다.

AutoClusters 시스템은 약 5분 만에 결함이 있는 노드를 신속하게 교체하여 자율 복구 기능을 선보였습니다.

Connor Guerrero는 애플리케이션 수준 복구를 포함한 총 종단간 다운타임이 15분 미만이었으며, 대부분의 시간이 애플리케이션 수준 코드에 기인한다고 말했습니다.

Connor Guerrero는 Kubernetes 클러스터, 컨트롤러, 로그인 노드 및 스토리지를 동시에 프로비저닝하는 유틸리티인 '원클릭 Slurm'을 소개했습니다.

엔지니어는 추가 단일 명령으로 GPU 노드 풀을 추가할 수 있으며, 기본적으로 AutoClusters를 활성화하여 즉시 작업을 실행할 수 있습니다.

기존 Slurm은 자동 복구 기능이 부족하고 Kubernetes는 고성능 작업 스케줄링 기능이 부족하므로, 실패한 GPU 노드를 자동으로 코돈하고 Slurm 연산자에게 신호를 전파할 수 있도록 이들을 통합하는 것이 유리합니다.

이러한 통합은 ML 연구원들이 컨테이너를 관리하거나 파드에 SSH할 필요 없이 익숙한 Slurm 명령을 계속 사용할 수 있음을 의미하며, GPU 노드는 주로 Kubernetes 노드로 기능하여 학습 작업이 완료된 직후 추론 파드를 실행할 수 있습니다.

통합 시스템은 오류 감지부터 작업 재개 및 체크포인트 설정에 이르는 전체 복구 프로세스를 관리하여 지속적인 작업을 보장합니다.

Connor Guerrero는 Slurm과 Kubernetes를 동기화함으로써 전통적으로 분리된 시스템이 통합되어 실패한 GPU 노드의 자동 코돈 및 Slurm 연산자에게 직접 신호 전파가 가능해진다고 설명했습니다.

이러한 통합을 통해 연구원들은 파드나 컨테이너를 관리할 필요 없이 익숙한 Slurm 명령을 유지할 수 있으며, 플랫폼 팀은 표준 원격 측정 및 관찰 가능성 도구에 대한 모든 액세스를 유지할 수 있습니다.

Connor Guerrero는 Slurm 작업이 끝나면 GPU 노드가 유휴 상태로 있지 않고 Kubernetes를 통해 추론 파드에 즉시 재활용될 수 있으므로, 통합 리소스 풀로서 전체 플랫폼 활용도를 최적화한다고 언급했습니다.

Connor Guerrero는 핵심 아이디어는 엔지니어링 초점을 인프라 유지 관리에서 핵심 애플리케이션 구축으로 전환하여 엔지니어가 혁신에 노력을 집중할 수 있도록 하는 것이라고 강조했습니다.