엔비디아, 쿠버네티스 GPU 클러스터 운영을 위한 오픈소스 DSX OS 공개

오픈소스 기반 클러스터 통합 운영

엔비디아가 쿠버네티스 기반 인공지능 공장 플랫폼의 오픈소스 소프트웨어 계층인 엔비디아 DSX OS를 공개했다. 이는 그래픽 처리 장치(GPU) 클러스터의 환경 구성, 운영 준비 상태 검증, 상시 장애 감지 및 복구를 표준화하기 위한 도구 모음이다. 아파치 2.0 라이선스로 배포되는 이 소프트웨어 계층은 인공지능 클러스터 런타임, 클러스터 준비 상태 엔진, 엔비디아 센티넬 등 상호 보완적인 세 가지 오픈소스 프로젝트로 구성된다.

이번 발표는 대규모 분산 학습 환경에서 단 하나의 저성능 가속기 노드가 전체 작업 속도를 지연시키는 문제를 해결하려는 맥락에서 나왔다. 기존 클러스터 운영에서는 기본 상태 확인을 통과하고 단순 자원 사용률이 정상이어도 실제 연산 성능이 떨어지는 노드를 사전에 걸러내기 어려웠다. 하드웨어 교체, 드라이버 패치, 노드 증설이 반복되는 운영 수명주기 전반에서 단순 사용률 지표 대신 실제 유효 작업량을 의미하는 굿풋을 유지하려면 지속적인 검증 체계가 필수적이다.

형상 고정과 대규모 성능 검증

인공지능 클러스터 런타임은 드라이버, 네트워크, 스토리지 등 인프라 소프트웨어의 기준선을 선언형 레시피로 고정하여 재현성을 보장한다. 부동 태그 대신 특정 버전을 고정하고 구성요소 간 설치 선행 관계를 의존성 그래프로 정리하여 배포 순서를 자동으로 결정한다. 생성된 설정은 아르고 씨디, 플럭스, 헬름 같은 기존 배포 도구용 산출물로 변환되며, 실제 실행 중인 클러스터와 기준선 사이의 설정을 비교하여 차이가 발생하면 지속적 통합 파이프라인을 차단하는 드리프트 감지 기능도 제공한다.

클러스터 준비 상태 엔진은 단순히 컨테이너 서비스가 구동되는지를 넘어 대규모 분산 워크로드를 처리할 수 있는지 실증적으로 검증한다. 엔비디아 집합 통신 라이브러리 기반 통신 시험, 데이터센터 지피유 매니저 4단계 진단, 80억 및 560억 매개변수 규모의 네모트론 사전 학습 작업을 직접 구동하여 상태를 측정한다. 대역폭 수치 같은 성능 임계값을 설정 파일에 지정해 기준 미달 노드를 사전에 차단하며, 다중 노드 통신 시험에서 성능 저하가 발생하면 문제 그룹을 단계적으로 절반씩 분할 테스트하여 원인이 되는 의심 노드를 자동으로 찾아낸다.

상시 모니터링과 자동 격리 복원

엔비디아 센티넬은 별도의 연산 자원을 소모하지 않으면서 워크로드와 나란히 상시 동작하여 클러스터 건강 상태를 감시한다. 칩셋 오류 신호, 하드웨어 진단 결과, 네트워크 인터페이스 카드 상태, 클라우드 서비스 제공자의 점검 이벤트를 종합해 노드 상태로 발행한다. 초기에는 노드 격리나 작업 퇴출 없이 모니터링 모드로 안전하게 도입할 수 있으며, 신호 신뢰성이 검증되면 공통 표현식 언어 기반의 격리 규칙을 활성화하여 결함 노드에 스케줄링 차단 표식을 지정하고 워크로드를 안전하게 비워낸다.

시스템은 장애 발생부터 복구 후 재투입까지 이어지는 운영 수명주기를 사람의 개입 없이 유기적으로 연결한다. 신규 노드가 클러스터에 합류하거나 장애 조치 후 복귀할 때 수명주기 관리 컨트롤러가 자동으로 검증 요청을 생성하고 해당 노드에 스케줄링 차단 격리를 설정한다. 이후 클러스터 준비 상태 엔진이 실제 워크로드 테스트를 통과시켰을 때만 격리 표식을 해제하여 불완전하게 수리된 노드가 서비스 풀에 무단으로 복귀하는 사고를 원천 차단한다.

운영 분리와 자동화 적용의 한계

엔비디아는 결함 격리와 복구를 전담하는 컨트롤러와 성능 원인 분석 및 시험 기록을 전담하는 검증 엔진의 역할을 명확히 분리했다. 두 시스템이 동일한 노드에 중복으로 격리 조치를 적용하여 상태가 어긋나는 혼선을 방지하고, 플랫폼 운영팀이 자체 운영 도구를 유지하면서 검증 엔진의 결과 리소스만 활용할 수 있도록 유연성을 부여했다. 이를 통해 수작업으로 진행되던 노드 점검과 수명주기 인수인계 과정이 대폭 줄어들고 전체 클러스터의 운영 안정성이 향상된다.

그러나 모든 운영 작업이 완전 자동화되는 것은 아니며 운영자가 직접 관리해야 하는 제약과 한계도 분명하다. 기존 드라이버나 오퍼레이터의 인플레이스 업그레이드, 네트워크 패브릭 변경 작업은 자동으로 재검증이 촉발되지 않으므로 운영자가 직접 검증 요청을 생성하거나 배포 파이프라인의 드리프트 검사를 통해 연동해야 한다. 또한 슬라이딩 윈도우 기반 서킷 브레이커로 동시 격리 노드 수를 제한하고 누적 실패 패턴을 분석하더라도, 기술 지원팀 문의가 권고되는 치명적 하드웨어 결함은 사람의 수동 개입과 조사가 필수적이다.