NVIDIA, 오픈소스 Workload Map 소개: Kubernetes 워크로드를 공통 정의로 기술해 검사, 갱 스케줄링, 플랫폼 보기에 활용

2026년 11월 2일 NVIDIA 개발자 블로그는 Kubernetes 워크로드를 위한 오픈소스 기술 계층인 NVIDIA Workload Map을 소개했다. 이 도구가 겨냥하는 문제는 AI 클러스터용 스케줄러, 컨트롤러, 대시보드, 비용 도구를 만드는 사람에게 익숙하다. 실제 작업이 파드 하나로 끝나는 경우는 드물다. 분산 학습이나 다중 노드 추론 서버는 작은 리소스 트리이며, JobSet이나 LeaderWorkerSet 같은 프레임워크마다 역할, 복제본 수, 파드 템플릿, 상태를 서로 다른 커스텀 리소스에 담는다. 그래서 도구는 프레임워크마다 별도의 어댑터가 필요하다.

Workload Map은 프레임워크별 코드의 상당 부분을 데이터로 바꾼다. Kubernetes 커스텀 리소스 정의와 Go 라이브러리로 배포되며, 각 정의는 한 워크로드 유형의 파드 템플릿, 복제본 수, 상태 필드가 어디에 있는지 알려 준다. 글에 따르면 리소스의 kind는 프로젝트의 옛 이름인 Karta 그대로이다. 정의가 있으면 사용하는 쪽은 파드 템플릿, 복제본 수, 상태, 메타데이터를 꺼내고, 모든 인스턴스에서 파드 사양, 레이블, 어노테이션을 갱신하며, JobSet의 복제된 Job과 그 파드 같은 계층도 이해할 수 있다. 상태 매핑은 기본 조건을 공통 어휘로 번역한다. JobSet에는 단순한 실행 중 조건이 없어서 정의가 복제된 Job의 상태에 대한 식으로 이를 도출하고, 기본의 완료와 실패 조건은 그대로 대응시킨다.

예시는 리더 Job 하나와 워커 Job 둘로 이루어진 JobSet이며, 각 파드가 GPU 4개를 요청한다. kubectl로 나열하면 JobSet 하나, Job 셋, 파드 셋이고 합계는 나오지 않는다. 정의를 등록하기 전 NVIDIA Run:ai에서는 세 Job이 GPU 4개씩 쓰는 세 개의 독립된 워크로드로 보인다. 같은 카탈로그 정의를 API 호출 한 번으로 등록하면 Run:ai는 GPU 12개를 쓰는 하나의 워크로드로 보여 주고 리더와 워커의 구조 보기를 제공한다. Workload Map 명령줄 도구는 실행 중인 객체를 같은 트리로 해석하며, kubeconfig를 사용하고, 기본 정의를 내장하고 있고, 글에 따르면 클러스터에 Workload Map을 설치할 필요가 없다. 출력에는 리더와 워커 역할, 그리고 GPU 12개라는 합계가 나온다.

두 번째 용도는 스케줄링이다. 정의에는 선택적으로 갱 스케줄링 지침을 넣을 수 있다. 글은 역할 분담을 분명히 적는다. 정의는 그룹화 정보를 제공하고, 갱 단위 승인과 배치 결정은 KAI Scheduler가 한다. KAI Scheduler는 네이티브 플러그인이 없는 워크로드 유형을 위해 파드 그룹화 도구의 대체 수단으로 Workload Map을 사용하며, 네이티브 플러그인이 우선한다. 이 점이 중요한 이유는 Workload Map이 기존 연동을 덮어쓰지 않고 빈틈을 메우는 역할이라는 뜻이기 때문이다.

프로젝트에는 테스트를 거친 기성 정의의 카탈로그가 들어 있고 JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet, NVIDIA Dynamo를 다룬다. 다른 유형은 YAML 정의를 작성해 추가할 수 있다. NVIDIA는 이 소프트웨어가 Apache 2.0 라이선스이고 NVIDIA Run:ai 내부에서 프로덕션으로 쓰이며, Elotl의 Nova가 분산 워크로드를 위한 클러스터를 고를 때 구조와 자원 요구를 해석하는 데 쓴다고 말한다. 저장소 스스로는 모든 Kubernetes 프레임워크의 커스텀 리소스를 표준화된 일반 구조로 옮기는 변환 계층이라고 설명한다.

글이 보여 주지 않는 것은 측정된 이점이다. 절약된 시간, 스케줄러 부담, 오류율, 상태 식의 정확도에 대한 수치가 없고, 도입에 관한 설명은 NVIDIA와 한 협력사에서 나온 것이다. 또한 정의는 데이터의 모습을 한 코드이기도 하다. 상태 식이나 파드 템플릿 경로가 틀리면 플랫폼이 상태를 잘못 보고하거나 작업을 잘못 배치할 수 있으므로, 정의도 다른 매니페스트처럼 검토와 테스트가 필요하다. 팀이 시험하는 합리적 방법은 이미 쓰는 프레임워크 하나를 골라 카탈로그 정의를 적용하고, 명령줄 도구가 보여 주는 트리와 GPU 합계를 kubectl 결과와 비교한 뒤에 스케줄러나 플랫폼에 등록하는 것이다. 프로젝트가 구성 요소 이름을 바꾸는 중이므로 설치하는 CRD와 라이브러리 버전도 확인해야 한다.

플랫폼 팀에게 이런 기술 계층의 진짜 가치는 새 프레임워크를 지원하는 비용을 릴리스 주기에서 떼어 낼 수 있다는 데 있다. 새 커스텀 리소스가 나와도 지금까지는 스케줄러나 플랫폼의 다음 버전을 기다려야 했다. 정의를 매니페스트처럼 작성하고 검토하고 적용할 수 있다면 팀이 스스로 지원을 채울 수 있다. 대가는 정의를 유지 보수하고, 상위 프레임워크가 상태 필드를 바꿀 때마다 갱신해야 한다는 점이다. 그러지 않으면 매핑이 조용히 깨진다.