부분 admission은 왜 분산 학습 잡을 멈추게 하나?
원인은 스케줄러의 성능이 아니라 admission 시점의 단위다. GPU를 pod 단위로 하나씩 배정하면 일부 worker만 자원을 잡은 채 나머지를 기다리는 상태가 생기고, 이 상태 자체가 데드락이다. gang 단위로 "전부 아니면 전무"를 확인한 뒤 admission하면 이 실패 경로가 원천적으로 막힌다.
- 분산 학습 잡은 worker 전체가 동시에 뜰 때만 진행되므로, 개별 pod 스케줄링은 구조적으로 부분 할당을 허용한다.
- gang admission은 잡 전체가 요구하는 GPU 총량(combined demand)을 만족할 수 있을 때만 자원을 내주므로, 자원을 쥔 채 멈추는 상태를 만들지 않는다. ZenML 자료가 이 구조를 이런 식으로 설명한다.
- utilization을 올리려는 스케줄링 정책과 gang의 동시성 요구는 자주 충돌하며, 이 충돌이 데드락과 대기시간 증가의 공통 뿌리다.
- 2026년 기준 실무 스택은 이 문제를 "큐잉·quota"와 "동시 시작 보장"을 서로 다른 계층에 맡겨 분리하는 방향으로 정리되고 있다.
Kubernetes 기본 스케줄러가 pod를 개별 단위로 배치하는 방식과, Kueue+Volcano 조합이 워크로드를 gang 단위로 admission하는 방식을 나란히 놓고 보면, 같은 클러스터·같은 GPU 수에서도 데드락 발생 조건이 갈린다.
admission 단위를 pod로 볼 때와 gang으로 볼 때, 무엇이 달라지나?
pod 단위 admission은 스케줄러가 "지금 빈 자원에 이 pod가 들어갈 수 있는가"만 본다. worker A, B, C 중 A, B만 자원이 있으면 그 둘만 우선 배치되고 C는 대기열에 남는다. 이 상태에서 A, B는 GPU를 점유했지만 job은 시작되지 못하므로, 그 GPU는 진척을 만들지 못하면서 다른 잡의 접근도 막는다.
gang 단위 admission은 이 판단을 잡 전체로 끌어올린다. A, B, C 세 worker의 요구를 합쳐 "지금 클러스터가 이 총량을 감당할 수 있는가"를 먼저 확인하고, 그렇지 않으면 셋 다 대기열에 남긴다. Volcano가 담당하는 부분이 이 동시 시작(all-or-nothing) 판단이고, Kueue는 그 앞단에서 워크로드 큐잉과 quota를 관리한다.
자원을 먼저 잡아두는 쪽과 조건이 맞을 때까지 기다리는 쪽, 대기시간은 어떻게 움직이나?
먼저 잡아두는 방식(pod 단위)은 초기 점유가 빠르지만, 조건 미충족 상태가 길어질수록 대기시간과 자원 낭비가 함께 늘어난다. 조건이 맞을 때까지 기다리는 방식(gang 단위)은 admission 자체가 늦어질 수 있어도, 일단 admit된 이후에는 멈출 이유가 없다.
이 상충은 "utilization을 극대화하려는 정책"과 "동시성 요구가 있는 잡"이 같은 클러스터에 있을 때 드러난다. multi-tenant GPU 클러스터의 admission control을 대기시간 상한으로 formal하게 다룬 arXiv 계열 논문("Queue-Theoretic Admission Control for Multi-Tenant GPU Clusters")은, utilization을 무리하게 끌어올리는 정책이 대기시간과 starvation을 함께 키운다는 문제의식을 이론적으로 정리한 사례로 언급된다.
스케줄러 계층을 나누면 실패 지점은 어디로 옮겨가나?
계층을 나누면 실패 지점은 "자원 부족"에서 "admission 조건 미충족"으로 옮겨간다. 실무에서 자주 제시되는 조합은 큐잉·quota는 Kueue, gang의 원자성은 Volcano, 노드 공급·확장은 Karpenter로 나누는 3계층 구조다. 핵심은 admit하기 전에 gang 전체가 성립 가능한지 검증하는 지점을 하나로 고정한다는 데 있다.
계층을 나누지 않으면 이 검증이 스케줄러 내부 어딘가에서 암묵적으로만 이루어져 원인 추적이 어렵다. 계층을 나누면 실패는 "admission layer가 거절했다"는 형태로 명확히 드러난다.
실측 수치로 보면 무엇이 확인되고 무엇이 안 되나?
| 항목 | pod 단위 admission | gang 단위 admission |
|---|---|---|
| 부분 할당 발생 가능성 | 있음 | 구조적으로 배제 |
| admission 판단 시점 | 개별 pod마다 | 잡의 combined demand 확인 후 |
| 담당 컴포넌트(대표 예) | 기본 kube-scheduler | Kueue(큐잉·quota) + Volcano(동시 시작) |
| 대기시간 특성 | 초기 점유는 빠르나 멈춤 위험 | admission은 늦어질 수 있으나 시작 후 안정 |
| 정량 실측 공개 여부 | 사례 위주, 수치 제한적 | 벤치마크 논문 존재하나 세부 수치는 원문 확인 필요 |
"정량 실측 공개 여부" 행은 신중히 읽어야 한다. 2026년 arXiv에 올라온 "Characterizing the Scalability and Performance of Large-Scale AI Training Under Multi-Tenancy"는 DLNetBench라는 벤치마크로 분산 학습의 통신·동기화 패턴을 재현한다고 설명하지만, 공개된 스니펫만으로는 구체적인 utilization·대기시간 수치가 드러나지 않는다. 구조적 우위는 여러 출처에서 반복 확인되지만, "몇 % 개선"류 숫자는 원문 표를 직접 확인하기 전까지 본문 근거로 쓰기 어렵다.
기본 스케줄러에서 gang admission 계층으로 옮길 때 실제로 드는 것은?
가장 먼저 드는 것은 워크로드 정의를 바꾸는 작업이다. pod 단위로 작성된 매니페스트를 gang 단위 워크로드(PodGroup 또는 이에 준하는 리소스)로 재정의해야 하고, gang size·quota·admission timeout을 잡별로 다시 산정해야 한다. 두 번째는 큐잉·quota 정책과 gang 판단 로직이 서로 다른 컴포넌트에 걸치면서 생기는 운영 복잡도다. 실패 원인이 "quota 부족"인지 "gang 조건 미충족"인지 구분해야 하므로 모니터링 지표도 계층별로 다시 설계해야 한다. 세 번째는 노드 공급 계층과의 정합성 확인이다. gang이 admit되었더라도 실제 노드가 그 시점에 공급되지 않으면 대기시간이 admission layer가 아니라 인프라 계층에서 늘어난다.
그럼 언제 gang admission이 필요하고 언제 필요 없나?
판단 기준은 "잡이 부분적으로 시작돼도 의미가 있는가"다. worker 일부만으로도 진행 가능한 배치 잡이나 단일 GPU로 끝나는 워크로드라면 pod 단위 admission으로 충분하고, gang 계층 추가는 복잡도만 늘린다. 반대로 all-reduce 같은 동기화 구조에 의존하는 분산 학습 잡, 그리고 여러 팀이 같은 GPU 풀을 나눠 쓰는 멀티테넌시 환경이라면 gang admission 없이는 부분 할당 데드락과 그로 인한 실질 utilization 저하를 감수해야 한다.
핵심 정리
- 데드락의 원인은 스케줄러 성능이 아니라 admission 단위다. pod 단위는 부분 할당을 구조적으로 허용하고, gang 단위는 combined demand 검증으로 이를 배제한다.
- 실무에서는 큐잉·quota(Kueue), gang 원자성(Volcano), 노드 공급(Karpenter)을 계층으로 분리해 admission 실패 지점을 명확히 하는 구성이 반복적으로 제시된다.
- utilization을 극대화하려는 정책과 gang의 동시성 요구는 상충하며, 이 상충이 대기시간·starvation 증가로 이어진다는 점은 이론 연구에서도 formal하게 다뤄진다.
- DLNetBench 같은 벤치마크 논문이 존재하지만, 공개된 스니펫만으로는 구체 수치가 확인되지 않아 정량 비교는 원문 확인 전까지 보류해야 한다.
- 판단 기준은 "부분 시작이 잡에 의미가 있는가"이며, 동기화 의존이 높은 분산 학습·멀티테넌시 환경일수록 gang admission의 필요성이 커진다.
더 알아보기
GPU 스케줄링과 학습 오케스트레이션: 희소 자원을 어떻게 분배할 것인가 — 이 주제의 종합 가이드