Lambda, Kubernetes 서비스용 오픈소스 Run:ai 스케줄러 도입 준비

Lambda는 2026년 10월 13일, 관리형 구성 요소로 제공할 스케줄러 라이브러리의 일부로 오픈소스 Run:ai GPU 스케줄러를 Lambda Kubernetes Service (LKS)에서 정식 관리형 옵션으로 제공하기 위해 NVIDIA와 협력하고 있다고 밝혔다.

이 계획은 2026년 10월 13일 Lambda 블로그 게시물에 소개됐다. 회사는 “NVIDIA가 Run:ai를 오픈소스로 공개하기로 한 결정을 환영하며, Lambda Kubernetes Service (LKS)에서 정식 옵션으로 제공하기 위해 협력하고 있습니다”라고 밝혔다. Lambda는 2022년부터 자사 인프라에서 Run:ai를 지원해 왔다고 설명했으며, LKS를 통해 Run:ai의 기능을 더 쉽게 도입하고 운영할 수 있도록 해 팀들이 GPU 용량을 할당하고 공유하는 방식을 더 폭넓게 제어할 수 있게 하는 것이 목표라고 밝혔다.

NVIDIA, 2025년 스케줄러 오픈소스로 공개

NVIDIA는 2025년 4월 1일, Run:ai 플랫폼에서 처음 개발된 Kubernetes 네이티브 GPU 스케줄링 솔루션인 KAI Scheduler를 Apache 2.0 라이선스로 오픈소스 공개했다고 NVIDIA의 발표에서 밝혔다. NVIDIA는 이 스케줄러가 계속 NVIDIA Run:ai 플랫폼의 일부로 패키징되어 제공된다고 설명했다.

NVIDIA에 따르면 이 스케줄러는 공정 할당량 값을 지속적으로 다시 계산하고 할당량과 한도를 실시간으로 조정하며, 갱 스케줄링, GPU 공유, 계층형 큐잉을 결합한다. 내장된 podgrouper는 Kubeflow, Ray, Argo, Training Operator를 비롯한 프레임워크의 워크로드를 자동으로 연결한다. NVIDIA가 설명하는 스케줄링 주기에서는 먼저 Kubernetes 클러스터의 스냅샷을 생성하고, 정당 할당량 단계와 초과 할당량 단계를 거쳐 각 큐의 공정 할당량을 계산한 다음, 계산된 상태에 현재 할당량을 맞추기 위해 할당, 통합, 회수, 선점 작업을 적용한다.

Run:ai의 GPU 공유 및 할당량 기반 스케줄링

Lambda는 AI 개발 과정에서 GPU에 요구되는 다양한 사용 방식을 설명했다. 디버깅 세션에는 GPU 한 개의 일부만 필요할 수 있고, 평가 작업은 서로 독립적인 다수의 작업으로 확장될 수 있으며, 분산 학습에는 긴밀하게 연결된 대량의 GPU가 한꺼번에 필요할 수 있다. 또한 초기 아이디어를 실험으로 발전시키고 다시 프로덕션 단계로 옮기는 동안 요구 사항도 달라진다. 소규모 작업에 GPU 전체를 할당하면 연구자들은 기다리는 동안 예약된 용량이 유휴 상태로 남게 되고, 다른 팀이 예약해 두고 사용하지 않는 GPU 때문에 팀의 실험이 지연될 수도 있다.

Lambda의 설명에 따르면 Run:ai는 Kubernetes용 GPU 스케줄러로, 기본 Kubernetes 스케줄러의 기능을 두 가지 측면에서 확장한다. 하나는 여러 워크로드가 GPU 한 개에서 실행될 수 있도록 하는 GPU 공유이고, 다른 하나는 할당량 기반 스케줄링이다. 할당량 기반 스케줄링은 각 팀에 보장된 용량을 제공하는 한편, 팀끼리 유휴 용량을 빌려 쓸 수 있게 한다.

NVIDIA의 GPU 분할 기능 문서에 따르면 분할 기능은 GPU 메모리를 여러 워크로드가 공유할 수 있는 작은 단위로 나눈다. 각 워크로드가 요청한 메모리 크기를 강제해 요청량을 초과하거나 다른 워크로드의 메모리를 침범하지 못하게 한다. 각 파드에는 별도의 가상 메모리 주소 공간이 할당되며, 문서에서는 이를 “논리적 GPU”라고 부른다.

문서에 따르면 분할 기능은 기본적으로 NVIDIA의 시분할 방식을 사용해 GPU 연산 자원을 공유한다. 다중 GPU 분할은 단일 노드에 있는 여러 GPU에 동일한 분할 크기를 할당한다. 예를 들어 GPU 8개를 사용하고 GPU당 메모리 40GB가 필요한 모델에는 각 GPU의 전체 메모리 대신 8×40GB를 할당할 수 있으며, 이렇게 하면 해당 노드의 각 GPU에서 40GB를 다른 워크로드가 사용할 수 있다. 문서에서는 같은 노드에서 GPU 분할 기능과 Multi-Instance GPU (MIG) 모드를 함께 사용할 수 없다고 설명한다.

NVIDIA의 스케줄러 개념 문서에 따르면 새로 생성되는 모든 파드는 파드 그룹에 할당되며, 갱 스케줄링은 여러 파드로 구성된 워크로드를 전부 스케줄링하거나 전부 대기 상태로 두는 것을 뜻한다. 노드 풀마다 프로젝트와 부서별 스케줄링 큐가 생성된다. 정당 할당량은 선점할 수 없는 워크로드의 실행 한도를 정하고, 초과 할당량에 해당하는 리소스는 선점 가능한 워크로드만 사용할 수 있다. 스케줄러는 노드 풀마다 프로젝트와 부서별 공정 할당량 값을 계산한다. 한 큐의 사용량이 공정 할당량보다 적고 다른 큐의 사용량은 이를 초과하면, 스케줄러는 균형을 맞추기 위해 큐 사이에서 리소스를 이동하며, 이 과정에서 초과 할당량을 사용하는 선점 가능 워크로드가 선점될 수 있다. 스케줄러는 프로젝트와 부서 사이의 리소스도 회수할 수 있으며, 관리자는 노드 풀마다 빈 패킹 또는 분산 배치 전략을 설정할 수 있다.

LKS의 노드 자동 복구

Lambda는 GPU 공유와 선점이 모두 GPU 하드웨어가 정상적으로 작동한다는 전제에 기반하지만, 대규모 환경에서는 이를 당연하게 볼 수 없다고 지적했다. 가속기에서는 XID 오류가 발생하고, NVLink와 PCIe 링크의 성능이 저하되며, 메모리 행이 재매핑되고, InfiniBand 포트의 전송 속도가 예상 수준 아래로 떨어질 수 있다. 스케줄러는 정상 GPU와 고장 징후가 있는 GPU를 구분하지 못하므로, 작업을 중단시키는 노드에 계속 작업을 보낸다.

Lambda는 자동 복구 기능이 이미 LKS에서 제공되고 있다고 밝혔다. 회사는 이러한 결함이 있는지 모든 노드를 모니터링하고, 각 결함을 표준 Kubernetes 노드 조건으로 표시한다고 설명했다. 조건이 발생하면 해당 노드는 새 작업이 배정되지 않도록 차단되고, 실행 중인 작업은 비워진다. 이어 결함을 자동으로 해결하거나 하드웨어 수리 단계로 에스컬레이션하며, 노드는 재검증을 통과한 뒤에만 서비스에 복귀한다.

Lambda의 관리형 Kubernetes 문서에서는 이 서비스를 GPU와 InfiniBand(RDMA)를 지원하고 1-Click Cluster의 모든 노드에서 공유 영구 스토리지를 제공하는 Kubernetes 환경으로 설명한다. NVIDIA GPU Operator와 NVIDIA Network Operator가 사전 설치되어 있으며, 서비스는 GPU, 네트워킹, 스토리지가 제대로 작동하는지 확인하기 위해 지속적으로 검증하는 동시에 하드웨어 문제를 감지하고 복구하는 자동 노드 복구 기능도 실행한다.

관리형 스케줄러 라이브러리 로드맵

Lambda는 GPU 스케줄링이 의도적으로 개방해 두는 계층이라고 설명했다. 또한 LKS가 다음 단계로 이른바 AI 소프트웨어 라이브러리를 지향한다고 밝혔다. 이 라이브러리에는 Kubernetes, Slurm, Run:ai에서 실행되는 스케줄러 등이 포함되며, 고객이 Helm 차트로 직접 조립하는 대신 Lambda가 자체 하드웨어에서 검증하고 최신 상태로 유지하는 관리형 구성 요소로 제공된다. Run:ai는 이 라이브러리의 핵심 대상이며, Lambda는 이를 실현하기 위해 NVIDIA와 협력하고 있다고 밝혔다.

Lambda에 따르면 오픈소스 공개 덕분에 이러한 접근 방식이 가능해졌다. 회사는 고객에게 통합 지침을 건네는 데 그치지 않고, LKS 안에서 Run:ai를 직접 패키징하고 테스트하며 유지 관리할 수 있다. Lambda는 패키징과 검증, 지속적인 운영을 직접 맡는 즉시 사용 가능한 통합을 목표로 하고 있다고 밝혔다.

자체적으로 공개 연구를 수행하는 Lambda는 의존하는 도구를 살펴보고, 조정하고, 개선할 수 있는 능력을 중요하게 여긴다고 밝혔다. 또한 NVIDIA의 결정으로 이러한 자유가 오케스트레이션 분야까지 확장됐다고 설명했다.