클러스터에 사용 가능한 GPU가 남아 있는데도 AI 작업이 계속 Pending 상태라면, 정말 GPU가 부족한 걸까요?
AI 인프라에서는 종종 답이 아니오입니다. 문제는 GPU의 절대 개수가 아니라, 해당 작업이 요구하는 조건을 만족하는 형태의 GPU 자원이 없다는 데 있습니다.
기존 Kubernetes autoscaling은 대체로 다음과 같은 방식으로 판단합니다.
Pod가 Pending 상태다
→ 현재 노드에 여유가 없다
→ GPU 노드를 추가한다
CPU와 메모리 중심의 일반적인 서비스에서는 이 모델이 잘 작동합니다. 하지만 대규모 학습, 분산 추론, 멀티 GPU 기반 워크로드에서는 “GPU가 몇 개 있는가”만으로 배치 가능 여부를 판단할 수 없습니다.
예를 들어 작업이 GPU 4개를 요청했다고 해도, 실제 요구사항은 훨씬 복잡할 수 있습니다.
- 동일한 GPU 모델 4개가 필요한가
- GPU 간에 NVLink 같은 고속 연결이 필요한가
- GPU와 NIC가 가까운 NUMA 영역에 있어야 하는가
- 특정 GPU partition 또는 공유 방식이 필요한가
- 여러 Pod가 동시에 준비되어야만 시작할 수 있는가
- 예약된 GPU capacity가 있는 특정 zone에서 실행되어야 하는가
즉, 클러스터 전체에 GPU가 10개 남아 있더라도 작업 관점에서는 사용할 수 있는 GPU가 0개일 수 있습니다.
| 클러스터 상태 | 단순 리소스 관점 | AI 워크로드 관점 |
|---|---|---|
| GPU 8개가 여러 노드에 분산 | GPU 8개 여유 | 8-GPU 분산 학습에는 부적합할 수 있음 |
| GPU는 충분하지만 NIC locality 불일치 | 배치 가능해 보임 | 통신 성능 저하 또는 배치 실패 가능 |
| 일부 GPU만 partition으로 남음 | GPU 사용 가능 | 큰 단위의 작업은 시작 불가 |
| GPU worker 일부만 배치 가능 | 부분 실행 가능 | Gang workload 전체는 시작 불가 |
가령 8개의 GPU worker가 동시에 올라와야 하는 분산 학습 작업을 생각해 보겠습니다. autoscaler가 Pending Pod 하나만 보고 GPU 노드 한 대를 추가하면 일부 worker만 실행될 수 있습니다. 하지만 나머지 worker가 준비되지 않으면 학습은 시작되지 않습니다.
이 상태에서는 GPU가 이미 할당되어 있음에도 실제 업무 성과는 나오지 않습니다. 다른 작업이 쓰기도 어려운 GPU 조각만 남고, 비용은 계속 발생합니다.
GPU worker 8개 필요
↓
worker 2개만 우선 배치
↓
나머지 6개는 Pending
↓
분산 학습 시작 불가
↓
할당된 GPU도 유효한 생산성 없이 점유
이것이 AI 시대의 Software Infra 운영에서 중요한 차이입니다. GPU는 단순히 교환 가능한 숫자 자원이 아닙니다. GPU 모델, 장치 간 연결 구조, 네트워크 경로, 분할 방식, 예약 capacity까지 함께 고려해야 하는 구조화된 자원입니다.
따라서 Pending 상태를 발견했을 때 운영팀은 곧바로 “GPU를 더 늘려야 한다”고 결론 내리기보다 다음을 확인해야 합니다.
- 요청한 GPU 유형과 실제 가용 GPU가 일치하는가?
- 필요한 GPU들이 동일 노드 또는 적절한 고속 fabric 안에 있는가?
- GPU와 네트워크 장치의 topology 조건이 충족되는가?
- 여러 Pod가 동시에 확보되어야 하는 gang workload인가?
- GPU partition 또는 공유 정책 때문에 연속된 capacity가 부족한가?
- 예약된 capacity와 실제 workload 요구사항이 서로 맞는가?
결국 AI 워크로드의 autoscaling은 노드를 추가하는 문제가 아닙니다. 작업이 실제로 실행될 수 있는 하드웨어 조합을 확보하는 문제입니다. GPU가 남아 있는데도 작업이 시작되지 않는다면, 부족한 것은 GPU 수량이 아니라 workload가 요구하는 topology와 capacity 조건을 이해하는 autoscaling 능력일 가능성이 큽니다.
GPU를 숫자가 아닌 구조로 표현하다: DRA와 Software Infra
“GPU 4개”라는 요청만으로 대규모 학습을 제대로 배치할 수 있을까요?
겉으로는 충분해 보입니다. 하지만 GPU가 어떤 모델인지, 서로 얼마나 빠르게 연결되어 있는지, 네트워크 인터페이스와 어떤 경로로 이어지는지 모른다면 GPU 4개라는 숫자는 중요한 정보를 놓칩니다. AI 워크로드가 복잡해질수록 Software Infra는 단순한 자원 수량이 아니라 자원의 구조와 관계를 이해해야 합니다.
숫자 기반 GPU 요청의 한계
기존 Kubernetes 환경에서는 GPU를 대개 확장 리소스의 개수로 요청합니다.
resources:
limits:
nvidia.com/gpu: 4
이 요청은 “GPU 4개가 필요하다”는 사실은 전달합니다. 그러나 실제 분산 학습과 고성능 추론에 필요한 조건까지 표현하지는 못합니다.
예를 들어 다음 질문에는 답할 수 없습니다.
- 필요한 GPU가 특정 세대 또는 특정 모델인가?
- 4개의 GPU가 같은 서버에 있어야 하는가?
- GPU끼리 NVLink 같은 고속 인터커넥트로 연결되어야 하는가?
- GPU와 NIC가 동일한 NUMA 영역에 있어야 하는가?
- GPU 일부만 분할해 사용할 수 있는가?
- 특정 GPU와 특정 네트워크 장치를 함께 할당해야 하는가?
즉, GPU 4개를 보유한 두 노드는 Kubernetes의 단순 리소스 모델에서는 동일해 보일 수 있습니다. 하지만 한 노드는 GPU 간 고속 통신이 가능하고, 다른 노드는 느린 PCIe 또는 네트워크 경로에 의존할 수 있습니다. 대규모 모델 학습에서는 이 차이가 성능 저하를 넘어 작업 실패나 긴 대기 시간으로 이어질 수 있습니다.
DRA란 무엇인가
DRA(Dynamic Resource Allocation)는 GPU와 같은 특수 하드웨어를 단순한 정수형 리소스가 아니라, 속성·연결 관계·배치 조건을 가진 구조화된 자원으로 다루기 위한 Kubernetes의 접근 방식입니다.
핵심은 “GPU가 몇 개인가?”에서 다음 질문으로 전환하는 것입니다.
이 워크로드가 요구하는 GPU, 네트워크, 토폴로지 조건을 동시에 만족하는 장치 집합을 확보할 수 있는가?
DRA 환경에서는 워크로드가 ResourceClaim을 통해 필요한 accelerator의 특성을 더 구체적으로 표현할 수 있습니다. 구현과 지원 수준은 환경마다 다르지만, 개념적으로 다음과 같은 요구를 다룰 수 있습니다.
- 특정 GPU 모델 또는 accelerator 클래스
- 동일한 고속 fabric에 연결된 GPU 집합
- GPU와 NIC의 locality 조건
- NUMA 또는 PCIe 토폴로지 제약
- GPU partition 또는 공유 capacity 조건
- 특정 장치 간 함께 배치되어야 하는 관계
이제 scheduler는 단순히 GPU 수량이 남은 노드를 찾는 것이 아니라, 워크로드의 실행 조건을 만족하는 장치 조합을 찾을 수 있습니다.
토폴로지가 AI 성능을 좌우하는 이유
분산 학습에서는 여러 GPU가 지속적으로 gradient, parameter, activation 데이터를 교환합니다. 이때 GPU 간 통신 경로가 느리면, GPU 자체의 연산 성능이 높아도 전체 학습 속도는 크게 떨어질 수 있습니다.
다음 두 구성을 비교해 보겠습니다.
| 구성 | GPU 수 | 연결 구조 | 예상 결과 |
|---|---|---|---|
| 노드 A | 8개 | GPU 간 고속 링크, NIC locality 우수 | 대규모 학습에 적합 |
| 노드 B | 8개 | GPU 간 통신 경로가 느리고 NIC와 멀리 떨어짐 | 통신 병목 및 성능 저하 가능 |
기존 방식에서는 두 노드 모두 GPU 8개로 판단됩니다. 반면 DRA는 GPU 종류와 연결 구조, 네트워크 관계를 포함해 자원을 평가할 수 있도록 설계됩니다.
이 차이는 특히 다음 워크로드에서 중요합니다.
- 대규모 LLM 사전 학습 및 파인튜닝
- 멀티 노드 분산 학습
- 고대역폭 통신이 필요한 모델 병렬화
- 낮은 지연 시간이 중요한 분산 추론
- GPU와 RDMA NIC의 근접성이 필요한 데이터 처리 작업
DRA-aware Autoscaling이 필요한 이유
DRA의 가치는 scheduler에만 머물지 않습니다. autoscaler 역시 같은 하드웨어 의미를 이해해야 합니다.
기존 autoscaling은 대체로 다음처럼 동작합니다.
Pod가 Pending 상태
→ GPU 노드가 부족하다고 판단
→ GPU 노드 추가
하지만 Pending의 원인이 단순한 GPU 부족이 아닐 수 있습니다. 필요한 것은 GPU 4개가 아니라, 같은 fabric에 연결된 특정 GPU 4개와 적절한 NIC locality일 수 있습니다.
DRA-aware autoscaler는 이 차이를 반영합니다.
Workload의 ResourceClaim 분석
→ GPU 모델·토폴로지·공유 조건 확인
→ 조건을 만족하는 노드 유형 선택
→ 적절한 capacity provision
→ Scheduler가 실제 장치 집합 할당
반대로 autoscaler가 DRA 정보를 이해하지 못하면 문제가 발생합니다. GPU 수량은 충분해도 워크로드 조건에 맞지 않는 노드를 생성할 수 있기 때문입니다. 결과적으로 GPU 비용은 증가하지만, Pod는 계속 Pending 상태에 남을 수 있습니다.
GPU 공유에서도 중요한 자원 의미
DRA는 GPU 전체를 독점하는 환경뿐 아니라 GPU partitioning, time-slicing, consumable capacity 같은 공유 모델에서도 중요합니다.
예를 들어 하나의 GPU를 다음처럼 나눠 사용한다고 가정해 보겠습니다.
GPU 전체 capacity: 100
추론 서비스 A: 30
배치 작업 B: 40
잔여 capacity: 30
이때 Software Infra는 단순히 “GPU가 사용 중인가?”만 판단해서는 안 됩니다. 남은 30의 capacity가 어떤 워크로드에 실제로 할당 가능한지, 성능 격리가 유지되는지, 큰 작업을 위한 연속된 capacity가 남아 있는지까지 고려해야 합니다.
따라서 GPU sharing은 단순한 비용 절감 기능이 아닙니다. scheduler, device plugin, autoscaler, cloud provider가 동일한 자원 의미를 공유해야 하는 운영 문제입니다.
운영 관점에서 확인할 질문
DRA 도입 또는 AI 클러스터 확장을 검토한다면 다음 질문부터 점검해야 합니다.
- 사용 중인 Kubernetes와 autoscaler가 DRA ResourceClaim을 지원하는가?
- GPU 모델, NVLink, PCIe, NUMA, NIC locality 정보를 수집할 수 있는가?
- autoscaler가 단순 GPU 개수가 아닌 노드 토폴로지까지 고려하는가?
- GPU partition 및 공유 모델을 scheduler와 autoscaler가 동일하게 해석하는가?
- 예약된 GPU capacity가 워크로드의 topology 요구와 실제로 호환되는가?
DRA는 단순히 GPU 요청 문법을 고도화하는 기능이 아닙니다. AI 시대의 Software Infra가 하드웨어를 숫자로 추상화하던 방식에서 벗어나, 성능과 배치 가능성을 함께 결정하는 구조화된 자원 모델로 이동하고 있음을 보여주는 핵심 변화입니다.
Software Infra: Pod 하나가 아닌 작업 전체를 움직여라
GPU worker 8개가 모두 준비되어야 시작할 수 있는 분산 학습 작업을 생각해 보겠습니다. 기존 autoscaler가 Pending 상태의 Pod를 보고 노드를 한 대씩 추가하면, worker 몇 개만 먼저 실행되고 나머지는 계속 대기하는 상황이 생길 수 있습니다.
문제는 일부 worker가 실행 중이어도 학습 작업 전체는 시작할 수 없다는 점입니다. 준비된 GPU는 실제 연산을 하지 못한 채 점유되고, 다른 작업도 그 자원을 활용하기 어려워집니다. 노드를 추가했는데도 처리량은 늘지 않고 비용만 발생하는 전형적인 AI 인프라 낭비입니다.
Pod 단위 확장의 한계
일반적인 Kubernetes autoscaling은 대개 개별 Pod의 Pending 상태를 신호로 사용합니다.
Pod 하나 Pending
→ 노드 한 대 추가
→ 일부 Pod 배치
→ 다른 Pod는 계속 Pending
하지만 분산 학습, 대규모 배치 추론, 파라미터 서버 구조처럼 여러 컴포넌트가 함께 시작되어야 하는 작업에서는 이 방식이 맞지 않습니다.
예를 들어 다음과 같은 작업이 있다고 가정해 보겠습니다.
GPU worker 8개
Parameter server 2개
고속 네트워크 연결
동시 시작 필요
이 작업에 worker 3개만 먼저 배치되면 어떤 일이 벌어질까요?
- 작업 전체는 시작되지 못한다.
- 먼저 확보된 GPU 3개는 유휴 상태가 된다.
- 남은 worker를 위한 GPU와 네트워크 topology가 보장되지 않을 수 있다.
- 다른 workload는 이미 묶인 capacity를 활용하지 못한다.
- autoscaler는 Pod별 Pending을 보고 추가 확장을 반복할 수 있다.
즉, GPU가 부족해서가 아니라 작업 전체를 수용할 수 있는 형태의 capacity를 한 번에 확보하지 못해서 작업이 멈춥니다.
Gang Scheduling: 모두 준비되거나, 아무도 시작하지 않거나
이 문제를 해결하는 핵심 개념이 Gang Scheduling입니다. 여러 Pod를 독립적인 배치 단위가 아니라 하나의 논리적 workload로 묶어 처리합니다.
Gang Scheduling의 원칙은 간단합니다.
필요한 Pod가 모두 배치될 수 있을 때만 작업을 시작한다.
이를 통해 일부 Pod만 실행된 채 GPU를 점유하는 상황을 방지할 수 있습니다.
기존 방식
worker 3개 실행 + worker 5개 대기
→ 작업 미시작
→ GPU 3개 유휴 점유
Gang Scheduling 방식
worker 8개 + 부가 컴포넌트 전체 수용 가능 여부 확인
→ 가능: 전체 작업 admit 및 배치
→ 불가능: 전체 작업 대기
겉으로 보면 “대기”가 비효율적으로 보일 수 있습니다. 그러나 실제로는 실행할 수 없는 일부 Pod가 GPU를 잡아두는 일을 막기 때문에, 클러스터 전체 관점에서는 훨씬 효율적입니다.
Workload와 PodGroup이 필요한 이유
이러한 실행 단위를 Kubernetes에 전달하려면 Pod들을 하나의 그룹으로 표현해야 합니다. 여기서 활용되는 개념이 Workload와 PodGroup입니다.
PodGroup은 다음과 같은 정보를 담을 수 있습니다.
- 함께 시작해야 하는 Pod의 수
- 최소 실행 가능 replica 수
- 필요한 GPU와 CPU·메모리 용량
- 우선순위와 queue 정보
- 특정 topology 또는 네트워크 조건
- 전체 작업의 admission 조건
이제 scheduler는 “이 Pod 하나를 어디에 놓을까?”가 아니라 다음과 같이 판단할 수 있습니다.
이 작업 전체가
GPU 8개,
필요한 네트워크 연결,
동일 zone 또는 fabric 조건,
필수 보조 Pod까지
동시에 충족될 수 있는가?
이 관점은 Software Infra 운영에서 매우 중요합니다. AI workload의 실제 실행 단위는 Pod 하나가 아니라, 여러 Pod와 GPU·네트워크 자원이 결합된 작업 전체이기 때문입니다.
Autoscaler도 작업 전체를 이해해야 한다
다만 scheduler가 Workload 또는 PodGroup을 이해한다고 해서 문제가 자동으로 해결되지는 않습니다. autoscaler가 여전히 Pod 하나의 Pending 신호만 본다면, 필요한 capacity를 잘못 계산할 수 있습니다.
Scheduler:
"GPU worker 8개가 모두 필요합니다."
Autoscaler:
"Pending Pod 하나가 보이니 GPU 노드 한 대를 추가하겠습니다."
이 간극을 줄이기 위해 필요한 것이 provisioning request입니다. Workload가 전체 capacity 요구를 명시적으로 전달하면, autoscaler와 cloud provider는 개별 Pod가 아닌 작업 단위로 인프라를 준비할 수 있습니다.
Workload 정의
→ 전체 GPU·CPU·네트워크 요구량 계산
→ provisioning request 생성
→ 필요한 노드 capacity 확보
→ 준비 완료 확인
→ workload 전체 admission
→ gang scheduling으로 동시 배치
이 흐름은 “Pod가 막히면 노드를 추가한다”는 사후 대응형 확장보다 훨씬 예측 가능하고 비용 효율적입니다.
Kueue가 맡는 역할
여러 팀과 여러 AI 작업이 하나의 GPU 클러스터를 공유한다면, 단순히 capacity를 늘리는 것만으로는 충분하지 않습니다. 어떤 작업을 먼저 실행할지, quota를 초과하지 않는지, 대규모 작업이 필요한 자원을 확보할 수 있는지를 함께 관리해야 합니다.
이때 Kueue는 workload admission과 quota 관리를 담당합니다.
- 팀 또는 프로젝트별 GPU quota 관리
- queue 기반 작업 우선순위 제어
- 전체 capacity가 준비된 workload만 admission
- 대규모 gang workload의 공정한 대기 처리
- 불완전한 resource allocation 방지
Kueue와 provisioning request를 함께 사용하면, 클러스터는 단순한 Pod 실행 환경을 넘어 GPU capacity를 작업 단위로 조율하는 제어 시스템에 가까워집니다.
운영 관점에서 얻는 효과
Workload-aware autoscaling을 적용하면 다음과 같은 효과를 기대할 수 있습니다.
| 운영 문제 | 작업 단위 autoscaling의 대응 |
|---|---|
| 일부 worker만 실행되어 GPU가 유휴 상태가 됨 | 전체 작업이 가능한 경우에만 admission |
| Pod별 scale-up으로 노드가 단편적으로 늘어남 | 전체 workload 기준으로 capacity 산정 |
| 대규모 학습 작업이 queue에서 오래 멈춤 | quota·우선순위·capacity 준비 상태를 함께 관리 |
| GPU 비용은 증가하지만 실제 학습은 시작되지 않음 | 실행 가능성을 확인한 뒤 자원 할당 |
| 여러 팀의 GPU 경합이 심함 | Kueue 기반 queue와 quota 정책 적용 |
결론적으로 AI 환경의 autoscaling은 Pod 수를 세는 문제가 아닙니다. 이 작업이 지금, 전체 조건을 만족한 상태로 실행 가능한가를 판단하는 문제입니다. Software Infra가 workload 단위의 admission과 provisioning을 지원할 때, GPU는 부분적으로 묶인 비용이 아니라 실제 성능과 처리량으로 이어지는 자원이 됩니다.
Software Infra 관점의 Kueue와 Provisioning Request: 필요한 Capacity를 먼저 확보하는 방식
작업이 필요한 GPU 수와 조건을 미리 알릴 수 있다면, 왜 Pod가 하나씩 Pending 상태가 된 뒤에야 노드를 늘려야 할까요?
기존 Kubernetes autoscaling은 대체로 배치 실패 이후 반응하는 구조입니다. Scheduler가 Pod를 배치하지 못하고, Pending Pod가 쌓이면 Autoscaler가 이를 감지해 노드를 추가합니다. CPU·메모리 중심 서비스에서는 충분히 실용적이지만, 여러 GPU와 고속 네트워크를 동시에 요구하는 AI 워크로드에는 늦고 부정확할 수 있습니다.
Kueue와 Provisioning Request는 이 순서를 바꾸려는 시도입니다. Pod가 실패한 결과를 보고 대응하는 대신, 워크로드가 실행되기 전에 필요한 전체 capacity를 선언하고 확보하도록 만듭니다.
Pod 단위 반응형 Autoscaling의 한계
예를 들어 분산 학습 작업이 다음과 같은 조건을 요구한다고 가정해 보겠습니다.
- GPU worker 8개
- 각 worker에 GPU 1개 이상
- 동일 zone 또는 동일 고속 네트워크 fabric
- parameter server 2개
- 모든 구성 요소의 동시 시작
기존 방식에서는 worker Pod 일부가 먼저 스케줄링되고, 나머지 Pod는 Pending 상태가 될 수 있습니다. Autoscaler는 Pending Pod를 기준으로 노드를 추가하지만, 새 노드가 필요한 GPU 모델·토폴로지·네트워크 조건을 정확히 만족한다는 보장은 없습니다.
그 결과 다음과 같은 비효율이 발생합니다.
- 일부 GPU만 할당된 채 작업 전체가 시작하지 못함
- 부분 배치된 Pod가 다른 워크로드의 배치를 방해함
- 필요한 수보다 적은 GPU 노드가 순차적으로 추가됨
- GPU는 증가했지만 gang workload 전체를 수용하지 못함
- 예약된 capacity 대신 비용이 높은 on-demand 노드가 생성됨
즉, 문제는 단순히 GPU 개수가 부족한 것이 아니라 워크로드 전체 요구사항이 capacity provisioning 과정에 전달되지 않는 것입니다.
Kueue: 실행 전 Admission을 관리하는 계층
Kueue는 Kubernetes 환경에서 batch 및 AI 워크로드의 quota, queue, admission을 관리하는 컴포넌트입니다. 핵심 역할은 “이 작업을 지금 실행해도 되는가?”를 Pod 단위가 아니라 workload 단위로 판단하는 것입니다.
Kueue는 다음 정보를 기준으로 admission을 결정할 수 있습니다.
- 조직 또는 팀별 GPU quota
- 우선순위와 대기열 정책
- 필요한 CPU·메모리·GPU 규모
- 여러 Pod가 동시에 준비되어야 하는 gang scheduling 조건
- 예약 capacity와 사용 가능한 클러스터 자원
- 특정 accelerator 또는 topology 요구사항
중요한 점은 Kueue가 단순한 대기열 도구가 아니라는 것입니다. AI 작업이 실제로 실행 가능한 자원을 확보하기 전까지 admission을 지연함으로써, 일부 Pod만 시작되는 불완전한 상태를 줄이는 역할을 합니다.
기존 흐름
Pod 생성
→ Scheduler 배치 시도
→ 일부 Pod Pending
→ Autoscaler 노드 추가
→ 다시 배치 시도
Kueue 기반 흐름
Workload 제출
→ Quota 및 우선순위 확인
→ 전체 capacity 확보 요청
→ 필요한 노드 준비
→ Workload 전체 admission
→ Scheduler가 Pod들을 배치
이 구조는 Software Infra 운영 관점에서 특히 중요합니다. GPU는 단가가 높고 준비 시간이 길기 때문에, 실행 가능성이 불확실한 Pod를 먼저 배치하는 방식보다 capacity 확보와 admission을 연결하는 방식이 훨씬 예측 가능하기 때문입니다.
Provisioning Request: 전체 요구사항을 Autoscaler에 전달하는 연결고리
Provisioning Request는 workload가 필요한 capacity를 Autoscaler 또는 클라우드 provider에 명시적으로 전달하기 위한 메커니즘입니다.
핵심은 “Pending Pod가 몇 개인가?”가 아니라 “이 작업을 실행하려면 어떤 형태의 인프라가 얼마나 필요한가?”를 요청하는 데 있습니다.
예를 들어 요청에는 다음과 같은 의미가 담길 수 있습니다.
GPU 8개가 장착된 노드 또는 동등한 capacity 필요
동일 zone 배치 필요
특정 GPU 모델 필요
GPU 간 고속 fabric 필요
고성능 NIC와의 locality 필요
예약된 GPU capacity 우선 사용
전체 workload가 준비될 때까지 admission 보류
이 정보가 Autoscaler에 전달되면, Autoscaler는 단순히 가장 저렴하거나 즉시 생성 가능한 노드를 찾는 대신, 워크로드 실행 조건을 만족하는 노드 형태를 provision할 수 있습니다.
전체 흐름은 다음과 같이 이해할 수 있습니다.
Workload 요구사항 정의
↓
Kueue가 quota·우선순위·admission 조건 검토
↓
Provisioning Request 생성
↓
Autoscaler 또는 Cloud Provider가 필요한 capacity 확보
↓
준비 상태 반환
↓
Kueue가 workload 전체를 admit
↓
Scheduler가 PodGroup 또는 gang 단위로 배치
이 방식은 Scheduler와 Autoscaler가 서로의 판단을 추측하던 기존 구조를 개선합니다. Scheduler는 배치 가능한 환경을 기다리고, Autoscaler는 워크로드의 실제 요구조건을 바탕으로 capacity를 준비할 수 있습니다.
“한 번에 확보”가 항상 Atomic을 의미하지는 않는다
다만 Provisioning Request가 있다고 해서 모든 GPU와 노드가 반드시 원자적으로, 즉 완벽하게 한 번에 확보되는 것은 아닙니다.
현실의 클라우드 환경에서는 다음 변수가 존재합니다.
- 특정 GPU 모델의 지역별 재고 부족
- 예약 capacity의 topology 불일치
- 노드 생성 시간 차이
- provider별 Provisioning Request 지원 범위 차이
- Autoscaler 구현체별 DRA 및 topology 인식 수준 차이
- quota는 통과했지만 실제 인프라 공급이 지연되는 상황
따라서 현재의 흐름은 완전한 단일 control loop라기보다, 분리되어 있던 control loop를 더 긴밀하게 연결하는 best-effort 통합 모델에 가깝습니다.
그럼에도 의미는 분명합니다. 기존 방식이 실패한 Pod를 관찰한 뒤 capacity를 늘리는 구조였다면, Kueue와 Provisioning Request는 실행 계획을 먼저 만들고 capacity를 준비한 뒤 workload를 시작하는 구조로 Kubernetes를 이동시키고 있습니다.
운영팀이 설계해야 할 정책
Kueue와 Provisioning Request를 도입할 때는 기술 기능만 활성화하는 것으로 충분하지 않습니다. 다음 정책을 함께 정의해야 합니다.
| 정책 영역 | 확인할 사항 |
|---|---|
| Quota | 팀·프로젝트·환경별 GPU 사용 한도를 어떻게 나눌 것인가 |
| Priority | 긴급 inference 작업과 장시간 학습 작업 중 무엇을 우선할 것인가 |
| Admission | 전체 capacity가 확보될 때까지 작업을 대기시킬 수 있는가 |
| Reservation | 예약 GPU를 어떤 workload에 우선 배정할 것인가 |
| Topology | 동일 노드, 동일 rack, 동일 zone 조건을 어디까지 강제할 것인가 |
| Timeout | capacity 확보가 장시간 지연될 때 작업을 취소·재시도할 것인가 |
| Observability | 대기 원인이 quota, topology, 공급 부족 중 무엇인지 확인할 수 있는가 |
특히 운영 대시보드에서는 단순한 Pending Pod 수보다 다음 상태를 구분해서 보여주는 것이 좋습니다.
- quota 부족으로 admission 대기 중인지
- GPU capacity provisioning 중인지
- topology 조건을 만족하는 노드를 찾지 못했는지
- reservation capacity와 요구사항이 맞지 않는지
- gang 전체 capacity가 아직 준비되지 않았는지
이 구분이 없다면 운영팀은 GPU가 부족하다고 판단하기 쉽습니다. 하지만 실제 원인은 GPU 총량이 아니라 admission 정책, 잘못된 topology 조건, 또는 예약 capacity의 배치 불일치일 수 있습니다.
Kueue와 Provisioning Request는 Kubernetes를 단순한 Pod 실행 플랫폼에서 한 단계 더 발전시킵니다. AI Software Infra에서는 “Pod가 실패하면 노드를 늘리는 방식”보다 “워크로드가 실행되기 전에 필요한 자원을 계획하고 확보하는 방식”이 비용, 안정성, GPU 활용률 측면에서 훨씬 중요한 운영 모델이 되고 있습니다.
GPU 개수에서 AI 인프라 최적화로: Software Infra의 비용·성능 판단
GPU 노드를 더 추가하는 것이 언제나 정답일까요? 이미 예약한 GPU가 놀고 있는 동안 비싼 온디맨드 인스턴스를 새로 구매하거나, 분산 학습의 통신 조건에 맞지 않는 노드를 늘린다면 autoscaling은 성능 문제를 해결하기보다 비용과 지연을 키울 수 있습니다.
AI 환경의 autoscaling은 이제 단순히 GPU 부족 → 노드 추가로 판단할 수 없습니다. 중요한 것은 GPU의 개수가 아니라, 해당 workload가 실제로 실행될 수 있는 적합한 capacity를 확보하는 것입니다.
예를 들어 8개의 GPU가 필요한 분산 학습 작업은 GPU 8개가 존재한다는 사실만으로 실행되지 않습니다. GPU 간 고속 연결, GPU와 NIC의 locality, 동일 zone 배치, 충분한 네트워크 대역폭이 함께 충족되어야 합니다. 통신 경로가 느린 GPU 노드를 여러 대 추가하면 작업은 시작되더라도 all-reduce 같은 분산 통신 단계에서 성능이 크게 저하될 수 있습니다.
또한 비용 측면에서는 reservation-aware 전략이 중요합니다. 운영팀은 다음 순서로 capacity를 판단해야 합니다.
- 이미 구매하거나 예약한 GPU capacity가 남아 있는지 확인합니다.
- 해당 예약 capacity가 workload의 GPU 모델·토폴로지·zone 조건을 만족하는지 검증합니다.
- 예약 자원으로 충족할 수 없다면, 필요한 형태의 온디맨드 capacity를 최소 범위로 확보합니다.
- 작업 종료 후에는 scale-in 정책을 적용해 불필요한 GPU 비용이 지속되지 않도록 합니다.
이때 문제가 되는 대표적인 상황은 다음과 같습니다.
| 상황 | 단순 autoscaling의 결과 | 최적화된 판단 |
|---|---|---|
| 예약 GPU는 남았지만 다른 zone에 있음 | 온디맨드 GPU를 즉시 추가 | 지연 요구사항과 전송 비용을 비교해 예약 자원 활용 여부 결정 |
| GPU는 충분하지만 NVLink·NIC 조건이 맞지 않음 | GPU 노드를 더 증설 | topology 조건을 만족하는 노드 타입만 provision |
| 작은 추론 작업이 GPU 전체를 점유 | GPU utilization 저하, 불필요한 scale-out | partitioning 또는 공유 capacity 활용 |
| 분산 학습 Pod 일부만 배치 가능 | 일부 GPU만 묶여 전체 작업 지연 | workload 단위로 capacity를 확보한 뒤 동시 admission |
이러한 판단은 Kubernetes autoscaler 하나만의 역할이 아닙니다. Scheduler, DRA 기반 resource claim, Kueue의 quota·admission 정책, 클라우드 provider의 예약 capacity 정보가 함께 연결되어야 합니다. 즉, Software Infra 관점에서 AI autoscaling은 노드 수를 조절하는 기능이 아니라 하드웨어 구조·워크로드 요구·비용 정책을 함께 최적화하는 제어 체계에 가깝습니다.
결국 운영팀이 봐야 할 지표도 달라집니다. GPU utilization만 확인하는 것으로는 부족합니다. 예약 GPU 활용률, topology mismatch로 인한 Pending 비율, workload별 provisioning 시간, gang scheduling 대기 시간, scale-in 이후의 비용 절감 효과까지 함께 추적해야 합니다.
좋은 autoscaling의 목표는 GPU를 가장 많이 추가하는 것이 아닙니다. 필요한 순간에, 올바른 연결 구조와 비용 조건을 갖춘 GPU capacity를 확보하고, 작업이 끝나면 빠르게 회수하는 것입니다.
