NVIDIA Run:ai 오픈소스 분석: GPU 공유·할당량·배치를 나눠 보기

전체 공개로 달라진 선택지

NVIDIA는 2026년 10월 13일 Run:ai 전체 플랫폼의 오픈소스 공개를 발표했다. 통합 플랫폼 외에 KAI Scheduler, GPU Fractioning Operator, KAI Resource Management, Workload Map을 개별적으로 채택할 수 있다는 설명이다. NGC의 통합 Community Product는 유료 Run:ai 구독 없이 이용할 수 있지만, 내려받을 때 적용 약관에 동의해야 하며 NVIDIA 기업 지원은 포함되지 않는다. NVIDIA 공식 발표

선택의 폭이 넓어진 지점은 “GPU를 공짜로 쓴다”는 데 있지 않다. 이미 자체 플랫폼을 가진 팀이 부족한 부분만 검토하거나, 통합 플랫폼의 코드를 확인하며 운영할 수 있다는 데 있다. 하드웨어·클라우드 사용료, 장애 대응과 업그레이드 인력은 여전히 도입 비용이다. 이 글은 10월 19일의 공식 자료를 바탕으로 그 선택을 나눈 문헌 분석이다. 설치 후기나 성능 벤치마크는 아니다.

Run:ai 저장소는 구조를 제어 영역과 클러스터 서비스로 설명한다. 제어 영역은 작업·조직 자원·정책을 관리하고, 각 Kubernetes 클러스터의 서비스는 실제 작업 배치와 상태 전달을 맡는다. Kubernetes나 컨테이너 런타임을 대체하는 제품은 아니다. Run:ai 구조 · 커밋 67e8211

따라서 첫 질문은 “전체를 설치할까”보다 현재 어떤 결정이 잘못되고 있는가다. 작은 작업이 큰 GPU를 오래 독점하는지, 팀 사이에 자원 배분 규칙이 없는지, 분산 작업이 필요한 자원을 함께 받지 못하는지에 따라 출발점이 다르다.

네 구성요소가 답하는 네 질문

아래의 ‘먼저 볼 증상’과 ‘남는 문제’는 공식 역할을 업무에 연결한 편집 판단이다. 구성요소를 서로 경쟁하는 대체 제품으로 비교한 표가 아니다.

구성요소	맡는 질문	먼저 볼 증상 / 남는 문제
KAI Scheduler	어느 작업을 어디에 배치할까?	작업 대기·빈자리 조각화 / 배치 후 모델 자체의 느린 연산은 별도
GPU Fractioning Operator	정해진 GPU 메모리 몫을 노드에서 어떻게 적용할까?	작은 작업이 GPU를 통째로 점유 / 연산 속도·지연 보장은 별도
KAI Resource Management	어느 부서·프로젝트가 어떤 자원 풀을 사용할까?	팀별 권리와 조직 구조 관리 / 실제 배치 가능성은 별도
Workload Map	이 작업의 구성요소·복제 수·상태는 어디에 있나?	작업 종류마다 별도 연동 코드 증가 / 스케줄러 자체는 아님

KAI Scheduler는 여러 Pod가 함께 자원을 받아야 하는 gang scheduling, 자원을 모아 배치하는 bin-packing, 계층형 큐와 공정 배분 등을 제공한다. Pod는 여기서 Kubernetes가 실행·배치하는 기본 단위로 이해하면 된다. 분산 학습처럼 여러 Pod가 협력하는 작업은 한 개만 시작해도 일을 끝내지 못할 수 있다. KAI Scheduler 기능 · 커밋 e2bba44

GPU Fractioning Operator는 배치 결정을 노드의 메모리 경계로 이어 준다. 확인한 README는 컨테이너 시작 전에 NRI 플러그인이 GPU 메모리 한도를 넣고, 드라이버가 상한을 강제하는 구조를 설명한다. KAI가 어느 GPU의 몫을 줄지 정하는 일과, 실행 중 그 한도를 적용하는 일이 분리된다. GPU Fractioning 구조 · 커밋 90690e9

KAI Resource Management는 프로젝트·부서·노드 풀·큐를 조직 구조에 연결한다. Workload Map 저장소의 현재 README는 이를 Karta라고도 부르며, 서로 다른 작업 형식에서 Pod 명세·복제 수·상태를 공통 방식으로 읽고 수정하는 구조를 설명한다. 예컨대 RayCluster와 PyTorchJob을 다루는 관리 도구가 각 형식의 내부 경로를 매번 새로 구현하는 부담을 줄이는 방향이다. Resource Management 범위, Workload Map/Karta 설명

이 구분을 기억하면 장애를 다른 계층에 떠넘기는 일을 줄일 수 있다. 메모리 상한이 정확해도 팀 배분 규칙이 없을 수 있고, 조직 할당량이 있어도 작업을 놓을 만한 GPU 묶음이 없을 수 있다.

GPU 네 장이 비었는데 네 장짜리 작업이 기다리는 이유

다음은 노드 두 대, 노드마다 GPU 네 장인 가상 클러스터다. GPU는 동일하고, 정수 장치 단위로만 할당하며, 기존 작업은 이동시키지 않는다고 가정한다. 새 작업 J는 통신 조건 때문에 같은 노드 안의 GPU 네 장을 한꺼번에 요구한다. 실제 Run:ai 설정이나 실행 결과가 아니라 배치 조건을 설명하는 사례다.

배치 상태	노드 A의 빈 GPU	노드 B의 빈 GPU	전체 여유	J를 놓을 수 있나?
기존 작업이 양쪽에 두 장씩 점유	2	2	4	불가. 어느 노드에도 네 장이 없음
기존 작업 네 장이 A에 모여 있음	0	4	4	가능. 다른 조건이 모두 맞는다는 가정
J가 노드 사이 분산을 허용함	2	2	4	GPU 개수 조건상 가능. 통신·CPU 등은 별도

첫째 행과 둘째 행의 차이는 자원의 총량이 아니라 요청이 요구하는 모양이다. 이 경우 bin-packing을 검토할 이유가 있다. 반대로 서비스 복제본을 여러 노드에 나누어 장애 영향을 줄이는 일이 더 중요하면, 한 노드로 모으는 정책이 적절하지 않을 수 있다. 무엇을 최적화할지 먼저 정해야 한다.

Gang scheduling은 이와 연결되지만 같은 기능은 아니다. 이는 함께 시작해야 하는 작업 묶음을 일부만 배치하지 않도록 다루는 문제다. 묶음을 인식했다고 빈 GPU가 생기거나, 같은 노드 조건이 저절로 충족되지는 않는다. 원래 요청이 불가능하면 모두 대기하는 것이 맞다. “일부 Pod가 떴으니 진행 중”이라는 착시를 줄이는 것이 먼저일 수 있다.

이미 실행 중인 작업을 모으는 일에는 종료·재시작 비용이 붙을 수 있다. 위 둘째 행은 더 유리한 초기 배치를 보여줄 뿐, 첫째 행에서 무손실로 이동하는 기능을 증명하지 않는다. 이 글의 배치 계산 자료는 개수와 조건만 확인한다.

팀별 보장량은 빈 GPU를 계속 비워 두라는 뜻일까

같은 가상 클러스터에서 연구팀과 서비스팀의 기준 몫을 각각 네 장으로 정했다고 하자. 서비스팀이 두 장만 쓰는 동안 연구팀이 여섯 장을 쓰게 허용할 수 있다. 이때 운영자가 정해야 하는 것은 남는 몫을 빌리는 조건과 돌려주는 조건이다.

KAI의 공정 배분 문서는 큐의 deserved quota와 초과 몫을 구분하고, 초과 배분에서 우선순위·가중치를 사용한다고 설명한다. 자원이 부족한 큐를 위해 다른 큐의 초과 자원을 회수하는 전략도 있다. 확인한 커밋에서는 기본적으로 보장량 안의 자원을 보호하지만, 별도의 alpha 옵션을 켜면 더 높은 우선순위 큐가 낮은 우선순위 큐의 보장량 안에서도 회수할 수 있다. 고정 커밋의 fairness·reclaim 문서

그러므로 “네 장 보장”이라는 회의 문구만으로 실제 동작을 확정하면 안 된다. 큐 설정과 작업의 중단 가능 여부, 배치 제약이 함께 맞아야 한다. 위의 6:2 배분도 공식 알고리즘을 실행한 결과가 아니라, 두 장을 빌려 쓰는 상황을 설명하기 위한 숫자다.

서비스팀이 네 장을 다시 필요로 할 때 연구 작업을 중단할 수 있다면 체크포인트가 얼마나 최근인지 확인해야 한다. 체크포인트는 중단 뒤 작업을 이어갈 저장 상태다. 마지막 저장 이후의 계산을 잃는다면 GPU 이용률을 높인 대신 재계산 시간을 늘린 셈이 된다. 중단할 수 없는 긴 작업이라면 처음부터 빌려줄 수 있는 범위나 대기 정책을 다르게 정해야 한다.

운영 검토에서는 다음 세 시각을 나누어 기록할 수 있다. 이는 제품이 제공하는 특정 지표 이름이 아니라 이 글의 측정 제안이다.

1. 서비스팀이 추가 자원을 요청한 시각.
2. 빌려 쓴 자원이 반환되고 새 작업이 실제 시작한 시각.
3. 중단됐던 연구 작업이 복구되어 유효한 결과를 낸 시각.

첫째와 둘째 차이는 자원 회수까지 포함한 대기다. 셋째는 연구팀이 부담한 손실을 드러낸다. 한쪽의 빠른 시작만 보고 다른 쪽의 재시작 비용을 지우면 배분 정책을 잘못 평가하게 된다.

GPU 메모리를 네 몫으로 나누면 처리량도 네 배일까

가상의 GPU 메모리 80GiB를 네 작업에 20GiB씩 배정하면 명목 합계는 20 × 4 = 80GiB다. 그러나 이것은 메모리 예산 계산일 뿐 네 작업이 동시에 원하는 속도로 끝난다는 결론은 아니다. 실제로 할당할 수 있는 용량과 여유분은 장치·런타임에서 확인해야 하며, 모델 가중치 외 임시 메모리와 요청 증가 때의 점유량도 고려해야 한다.

노트북 작업 네 개가 대부분 입력을 기다린다면 공유가 유용할 수 있다. 반면 네 작업이 같은 순간에 긴 계산을 시작하면 연산 자원을 두고 경쟁할 수 있다. 추론 요청의 지연 목표가 엄격한 팀은 평균 이용률 상승보다 느린 응답 구간이 어떻게 변하는지 먼저 봐야 한다. 이는 공유 자원에 대한 분석이며 이번에 측정한 결과가 아니다.

메모리 강제 기능에는 설치 전제가 있다. 확인한 GPU Fractioning README는 r615 이상 드라이버/CUDA 13.4, NRI를 지원하는 컨테이너 런타임, GPU Operator 및 관련 구성요소 버전 조건을 명시한다. GPU Operator의 기본 설치가 원하는 드라이버를 자동 선택한다고 가정해서도 안 된다. 사전 조건과 드라이버 선택

이 글은 설치 명령을 그대로 복사해 실행하는 가이드가 아니다. 고정 커밋 문서로 원리를 확인했으며, 실제 도입 때는 선택한 릴리스의 지원 조합을 다시 맞춰야 한다. 메모리 한도라는 한 경계의 존재를 모든 작업 간 성능·보안 격리 보증으로 확대하지 않는다.

공개 소스·배포 패키지·지원 계약을 따로 확인한다

전체 플랫폼 발표에서 가장 놓치기 쉬운 부분은 자료마다 설명하는 대상이 다르다는 점이다.

확인한 대상	10월 19일 확인 범위	도입 전에 남길 질문
전체 Run:ai	저장소 공개, 통합 NGC Community Product 안내	자체 운영 담당·업그레이드·지원 경로는?
KAI Scheduler	별도 설치·릴리스 선택 안내	어떤 릴리스와 정책을 고정할까?
GPU Fractioning	노드 강제 구조와 구체적인 런타임 전제	현재 노드 조합이 메모리 상한을 실제 적용하나?
KAI Resource Management	README상 아직 별도 published release 없음	소스 chart 패키징과 호환 controller image를 누가 관리하나?
Workload Map/Karta	pre-1.0, minor 버전 사이 API 변경 가능	기존 관리 도구의 연동·변경 비용을 감당할까?

특히 KAI Resource Management의 현재 README는 chart 소스가 있어도 관리자가 직접 패키징하고 호환 이미지를 제공해야 한다고 적는다. 이를 통합 NGC 패키지가 없다는 뜻으로 읽어서도, 독립 모듈까지 안정된 설치 경로가 모두 준비됐다는 뜻으로 읽어서도 안 된다. 프로젝트 상태

Workload Map의 pre-1.0 상태는 운영 도구를 만드는 팀에 특히 중요하다. 추상화 덕분에 여러 작업 종류를 통합하기 쉬워져도 SDK 변화에 대응할 책임이 사라지지는 않는다. 특정 작업 종류 하나만 안정적으로 처리하면 되는 팀에는 기존 연동을 유지하는 편이 나을 수도 있다. Workload Map 상태

작은 도입 실험을 설계하는 방법

먼저 한 문제와 한 작업군을 고른다. 전체 플랫폼 교체와 메모리 분할, 큐 정책 변경을 동시에 하면 무엇이 효과를 냈는지 알기 어렵다. 아래는 실행 전 채울 평가 양식이다. 이번 글에서는 이 실험을 수행하지 않았다.

현재 문제: 작업 대기 / 메모리 낭비 / 팀 배분 / 작업 형식 연동
대상 작업: 입력·모델·동시성·GPU·노드 구성·버전
바꿀 계층과 구성요소:
유지할 조건: 팀 몫·우선순위·중단 정책·지연 목표
관측: 제출→시작 / 시작→완료 / 유효한 완료 건수
실패 관측: 메모리 초과 / 회수·재시작 / 잃은 계산 / 응답 지연
채택 조건과 중단 조건:
운영 담당·복구 절차·다음 평가일:

예를 들어 대기가 문제라면, 같은 작업 요청으로 대기시간과 유효한 완료 건수를 먼저 비교한다. GPU 이용률이 높아져도 중단·실패가 늘고 완료가 늦어졌다면 그 정책을 그대로 채택할 이유가 약하다. 메모리 공유가 문제라면 여유가 있는 작은 작업군으로 시작해 상한 적용과 동시 실행 때의 지연을 함께 확인한다.

소규모 단일 팀이 전용 GPU를 쓰고 현재 대기가 거의 없다면 통합 플랫폼의 운영 부담이 이익보다 클 수 있다. 반대로 여러 팀이 같은 Kubernetes GPU 풀을 공유하면서 자원 배분과 작업 인계로 시간을 쓰고 있다면, Run:ai의 공개는 직접 검토할 선택지를 넓힌다. 채택 범위는 제품 이름보다 현재 반복되는 운영 결정을 기준으로 정하는 편이 낫다.

GPU 한 장 안에서 용량·대역폭·연산 병목을 구분하려면 HBM과 Roofline, 대기와 병렬 작업의 시간을 나눠 보려면 지연 추적과 임계 경로를 이어 읽을 수 있다. 평가 양식이 필요할 때 다시 찾도록 글 위의 저장 기능을 이용하고, 인프라 주제 모음과 RSS에서 후속 분석을 확인할 수 있다.