NVIDIA Mission Control 2.5, GPU 장애 때 학습을 다시 이어가는 자동 복구

NVIDIA가 10월 26일 Mission Control 2.5의 Kubernetes 자동 복구 기능을 소개했다. Mission Control은 여러 GPU 서버에서 AI 학습 작업을 배정하고 장비 상태를 관리하는 기업용 소프트웨어다. 이번 버전은 기존 Slurm 환경에서 제공하던 복구 엔진을 NVIDIA Run:ai가 관리하는 Kubernetes 작업으로 확장한다. 공식 발표

GPU 한 곳에서 문제가 생기면 학습 작업을 정상 장비에서 다시 시작하는 동안, 문제 장비는 따로 격리하고 진단한다. 작업을 재개하기 위해 장비의 고장 원인을 끝까지 분석할 때까지 기다릴 필요를 줄이는 구조다.

여러 GPU가 함께 학습할 때 생기는 문제

대형 AI 모델은 여러 서버의 GPU가 계산을 나누고 중간 결과를 주고받으며 학습한다. 그중 한 GPU가 멈추거나 통신이 지연되면 함께 실행하던 작업도 영향을 받는다. 수백 대의 서버에서 며칠씩 돌아가는 학습이라면, 경고를 확인하고 문제 장비를 찾은 뒤 작업을 다시 넣는 시간이 누적된다. NVIDIA는 이런 운영 부담을 줄이는 데 이번 기능의 목적을 둔다. 적용 배경

Kubernetes는 컨테이너 형태의 프로그램을 여러 서버에 배치하고 실행 상태를 관리하는 기반이다. Run:ai는 그 위에서 AI 작업의 대기열과 GPU 자원 배정을 담당한다. Slurm 역시 대규모 계산 작업을 배정하는 시스템이지만, 이번 변화는 Kubernetes를 사용하는 팀도 작업 정보와 장비 상태를 연결한 복구 흐름을 쓸 수 있게 했다는 데 있다.

예를 들어 여러 서버에서 학습하던 작업에 통신 시간 초과가 발생했다고 하자. 단순히 같은 장비에서 다시 실행하면 불량 GPU 때문에 같은 실패가 반복될 수 있다. 반대로 모든 오류를 장비 고장으로 취급하면 정상 서버까지 제외해 사용할 GPU가 줄어든다. 복구 엔진은 작업 이력과 실행 위치, 장비 상태를 함께 보고 대응을 나눈다. 작업 맥락을 이용하는 방식

작업 배정·실패 판단·장비 복구를 나눈다

전체 흐름에는 세 가지 역할이 있다. 스케줄러는 어느 자원에서 작업을 실행할지 정한다. 작업 복구 서비스는 실행 중인 작업이 어디에 배치됐는지 추적하고, 실패 이력과 작업 구성을 이용해 재시작·재시도·재대기열 등록 등의 경로를 판단한다. 하드웨어 복구 서비스는 노드와 GPU를 감시하고 문제 자원을 배정 대상에서 빼거나 진단·조치를 수행한다. 노드는 작업을 실행하는 서버 단위다. 세 구성 요소의 역할

하드웨어 고장에서는 두 복구 서비스가 병행해 움직인다. 작업 쪽은 정상 자원을 찾아 재개하고, 장비 쪽은 고장 의심 노드를 격리한 이유를 기록하고 진단을 이어간다. 격리는 다음 작업도 같은 문제 장비를 배정받는 일을 막는다. 한편 잠깐의 소프트웨어 오류라면 정책에 따라 재시도하고, 반복되거나 복구할 수 없는 실패는 별도 대응으로 넘긴다. 장애 유형별 처리

작업이 실패하기 전에도 장비를 제외할 수 있다. GPU 상태 경고나 연결 문제가 반복되면 새 작업을 받지 않도록 하고 진단을 시작한다. 장비가 켜져 있는지뿐 아니라 다음 학습에 투입해도 되는지를 관리하는 셈이다. 진단이 끝난 장비는 준비 상태를 확인한 뒤 다시 사용 가능한 자원으로 돌아온다.

자동 재시작이 학습 진행 상황까지 보존하나?

실패한 프로그램을 다시 실행하는 것과 학습을 멈춘 지점 가까이에서 이어가는 것은 다르다. 후자에는 모델의 중간 상태를 저장한 체크포인트가 필요하다. 공식 소프트웨어 오류 도식도 체크포인트에서의 재시작을 보여준다. 저장 이후에 계산한 부분은 다시 수행할 수 있으므로, 자동 복구 기능이 있다고 해서 작업 손실이 모두 사라지는 것은 아니다. 체크포인트 기반 복구

릴리스 문서는 NVIDIA Resiliency Extensions(NVRx)가 Mission Control과 함께 자동 설치되지 않아 별도로 설치해야 한다고 명시한다. 학습 앱이 처리량·체크포인트·멈춤 감지 정보를 내보내도록 텔레메트리 라이브러리를 연동하는 방법도 안내한다. 텔레메트리는 실행 상태를 전달하는 관측 정보다. 장비 관리 도구를 설치하는 일과 학습 코드가 재개 가능한 상태를 준비하는 일이 함께 필요하다. 설치와 학습 앱 연동 조건

이번 발표에는 Kubernetes 복구 시간을 몇 초 줄였는지 보여주는 동일 조건의 수치 비교가 없다. 따라서 효과는 복구가 시작되기까지 걸린 시간, 재계산한 학습량, 같은 노드에서의 반복 실패, 정상 장비를 잘못 제외한 빈도 등을 실제 환경에서 확인해야 한다. 앞서 소개한 NVIDIA Minerva의 장애 관측과 연결해 보면, 상태를 파악하는 데서 작업 배정과 복구 행동으로 이어지는 단계가 이번 기능의 중심이다.

현재 어떤 환경에서 사용할 수 있나?

Mission Control 2.5는 현재 제공되며, 기존 사용자는 공식 문서에서 업그레이드 절차를 확인할 수 있다. 다만 모든 Kubernetes 프로그램에 같은 복구가 자동 적용되는 것은 아니다. 2.5.0 릴리스 문서는 Run:ai KAI 스케줄러와 Kubeflow PyTorch 학습 오퍼레이터를 사용하는 연동을 명시한다. 오퍼레이터는 분산 학습 작업을 Kubernetes에서 관리하는 구성 요소다. 해당 연동은 실패에 관련된 노드를 다음 실행 대상에서 제외하도록 작업 명세를 갱신한다. 정확한 지원 범위

플랫폼별 조건도 다르다. Vera Rubin NVL72는 이번 버전에서 초기 구동 지원만 제공하며, Run:ai와 자동 복구 엔진은 지원 대상에 들어가지 않는다. 발표에 함께 언급된 AI 기반 네트워크 이상 탐지도 베타 기능이다. 버전 전체의 제공 상태와 개별 기능·장비의 지원 범위를 구분해야 한다. 플랫폼 제한과 베타 구성

도입은 데이터센터 운영팀이 지원 시스템과 소프트웨어 구성을 확인하는 방식이다. 제품 페이지는 기업용 지원과 도입 상담을 안내하며, 확인한 공개 자료에는 단일 정액 요금이 제시돼 있지 않다. 자신의 GPU 서버와 스케줄러, 학습 프레임워크가 지원 조합에 해당하는지 확인한 뒤 복구 정책과 체크포인트 방식을 함께 준비할 수 있다. 제품과 도입 안내