NVIDIA DSX OS는 GPU 클러스터의 구성 기준을 재현하고, 실제 작업으로 준비 상태를 검증하며, 운영 중 결함을 감시하는 도구군이다. 클러스터 운영팀은 기존 배포 도구를 유지하면서 신규 용량과 수리된 노드를 검사하고, 설정에 따라 격리와 복구를 자동화할 수 있다.
1. 구성 기준을 파일로 고정하고 기존 배포 도구에 연결
구성 기준을 맡는 NVIDIA AI Cluster Runtime(AICR)은 네트워크·스토리지·드라이버 등 구성요소의 버전을 고정한 레시피를 만든다. 레시피는 클러스터에 어떤 소프트웨어를 어떤 순서로 설치할지 담은 구성 설계도다.
AICR은 이 설계도를 기존 배포 도구가 적용할 수 있는 산출물, 도구가 만들어 내는 배포용 파일로 변환한다. 실제 배포와 상태 조정은 기존 도구가 맡으므로 운영팀은 현재 파이프라인, 작업 단계를 이어 실행하는 흐름을 활용할 수 있다.
레시피에는 구성요소 간 의존 관계, 먼저 갖춰야 할 구성요소 간 관계와 설치 뒤 상태를 확인하는 검사도 담긴다. 이에 따라 기준을 버전 관리하고 코드 검토할 수 있으며, 수동 변경으로 기준에서 벗어난 상태도 탐지할 수 있다. 쿠버네티스가 비정상 컨테이너를 포함한 파드를 실행 중으로 표시할 수 있어, 파드 상태만 확인하는 검사보다 구성요소별 상태 확인이 중요하다.
아래 명령은 실시간 클러스터를 레시피 기준과 대조하고, 기준에서 벗어나면 0이 아닌 종료 코드, 명령 실행 결과를 나타내는 숫자를 내도록 한다.
# Check a live cluster against the recipe's constraints
aicr validate --recipe recipe.yaml
# Compare a golden baseline against the live cluster, non-zero exit on drift
aicr diff --baseline ./golden.yaml --target cm://default/aicr-snapshot --fail-on-drift2. 실제 작업을 돌려 느린 노드와 실패 원인을 확인
기본 상태 검사가 서비스의 작동 여부를 확인한다면, NVIDIA Cluster Readiness Engine(NVCRE)은 여러 노드가 함께 실제 작업을 감당하는지 시험한다. 학습 작업과 GPU 간 통신 테스트를 실행하고 결과와 실패 원인을 기록한다.
인증 명세, 검사 대상과 합격 기준을 적은 문서에서는 검사 노드와 테스트 종류, 통과 임계값, 통과 여부를 가르는 기준 수치를 정한다. 예시 설정은 통신·학습 테스트를 선택하고 버스 대역폭, 데이터 전송 통로의 처리 용량의 통과 기준을 초당 300GB 이상으로 둔다. 이는 측정 결과가 아니라 운영팀이 정하는 합격선의 예다.
검사 목록에는 GPU 관리 도구인 DCGM의 레벨 4 진단과 NVIDIA NeMo Framework 기반 사전 학습, 본격 작업 전에 모델을 미리 훈련하는 작업도 포함된다. 자체 컨테이너 테스트를 인증 검사로 추가할 수도 있다.
64개 노드의 통신 시험에서 대역폭이 낮게 나오면 NVCRE는 실패 그룹을 반복해 나누고 최소 그룹 크기까지 시험해 의심 노드와 이유를 보고한다. 한 노드의 성능 저하가 분산 학습, 여러 GPU가 나눠 수행하는 학습 전체를 늦출 수 있어, 단순 상태 지표에 드러나지 않는 병목, 전체 처리 속도를 늦추는 지점을 찾는 데 의미가 있다.
3. 결함 감시를 격리와 복구 뒤 재검증으로 연결
NVSentinel은 GPU 진단과 오류 신호, 네트워크 인터페이스, 네트워크 연결을 담당하는 장치의 상태, 클라우드 유지보수 이벤트를 감시한다. NVIDIA 설명에 따르면 감시에는 GPU 시간을 쓰지 않아 진행 중인 작업에 쓸 자원을 남긴다.
기본값은 결함을 노드 상태로 보고하는 감시 모드다. 운영팀은 보고를 평가한 뒤 자동 격리·작업 비우기, 노드에서 실행 작업을 비우는 절차·복구를 활성화할 수 있다. 일정 시간 안에 격리할 노드 수를 제한하는 안전장치도 제공한다.
새 노드가 합류하거나 복구된 노드가 돌아올 때 재검증을 요청하도록 설정할 수 있다. 검증 중에는 새 작업 배정을 차단하고, 검사를 통과해 다른 검사의 차단 사유도 없어지면 해제한다. 재시도 뒤에도 실패한 노드는 차단 상태를 유지한다.
NVCRE는 어떤 노드가 왜 실패했는지 판별하고, NVSentinel은 격리와 복구를 담당한다. 이 역할 분리는 두 시스템이 한 노드를 중복 차단해 정리 상태가 어긋나는 일을 줄인다. 플랫폼팀은 인증 결과를 자체 노드 생명주기, 노드의 생성부터 폐기까지 관리하는 도구에 전달해 운영을 맡길 수도 있다.
4. 감시부터 도입하되 합격선과 복구 규칙은 팀이 결정
세 도구는 Apache 2.0 라이선스 오픈소스이며 외부 기여를 받는다. 도입하려면 각 도구와 테스트 실행 환경을 설치·구성해야 한다. 운영 중인 클러스터에서는 감시 보고를 살피며 시작하고, 신뢰할 수 있는 신호에 격리·복구 규칙을 연결할 수 있다.
자동 복구와 재검증을 설정하면 노드를 수리하고 검사한 뒤 가용 자원으로 돌려놓는 수작업 인수인계를 줄일 수 있다. 대신 운영팀은 클러스터에 맞는 테스트와 임계값, 격리 규칙, 복구 한도와 담당자 대응 절차를 설계하고 유지해야 한다.
성능 임계값은 기본으로 설정되지 않아, 이를 지정하지 않으면 목표보다 느린 노드도 통과할 수 있다. 드라이버·관리 구성요소 업그레이드나 연결망 변경 뒤 검증은 자동으로 시작되지 않으므로 운영팀이 요청해야 한다.
DSX OS의 가치는 GPU 클러스터의 기준·검증·복구를 이어 붙이는 데 있고, 그 자동화의 범위는 운영팀이 정한 검사와 규칙에 달려 있다.
