GPU Scheduling이란? AI Cloud에서 GPU 자원을 배분하는 방법

게시일 ·

이 글 공유하기

GPU Scheduling은 여러 사용자와 AI Workload가 GPU를 요청할 때 어떤 Workload를 언제, 어느 GPU에서 실행할지 결정하는 운영 기능입니다.

단순히 “빈 GPU를 찾아주는 기능”만을 뜻하지 않습니다.

실제 AI Cloud에서는 Workload마다 필요한 GPU Type과 수량이 다르고, Multi-GPU Job은 여러 GPU를 동시에 확보해야 하며, 조직별 Quota와 Queue Priority도 고려해야 할 수 있습니다.

따라서 GPU Scheduling의 핵심은:

Workload 요구사항과 운영 Policy를 현재 GPU Resource 상태에 맞추는 것

입니다.

GPU가 많아질수록 이 문제는 단순 배치가 아니라 Capacity, Utilization, Fairness, Topology를 함께 다루는 운영 문제로 바뀝니다.

GPU Scheduling이 왜 필요할까요?

하나의 Team이 GPU 몇 장을 직접 사용하는 환경에서는 사람이 어떤 GPU가 비어 있는지 확인하고 Job을 실행할 수도 있습니다.

하지만 GPU Cluster가 커지고 사용자가 늘어나면 상황이 달라집니다.

예를 들어 동시에 다음 요청이 들어올 수 있습니다.

  • Research Team: H100 8개로 Training
  • Inference Team: L40S 2개로 Long-running Service
  • 개발자 A: GPU 1개로 Fine-tuning
  • 개발자 B: GPU 1개로 Evaluation
  • 긴급 Production Job: 높은 Priority로 GPU 4개 요청

이때 단순히 먼저 들어온 Job부터 실행하면 중요한 Production Workload가 오래 기다릴 수 있고, 큰 Training Job이 필요한 GPU를 한 번에 확보하지 못할 수도 있습니다.

GPU Scheduling은 이런 충돌을 운영 Policy에 맞게 조정합니다.

GPU Scheduler는 무엇을 보고 결정할까요?

Scheduling Platform마다 구현은 다르지만 일반적으로 다음 요소가 중요합니다.

GPU Type

모든 GPU가 같은 것은 아닙니다.

Workload가 특정 GPU Architecture, Model 또는 Capability를 필요로 한다면 Scheduler는 해당 조건을 만족하는 Node를 찾아야 합니다.

Kubernetes에서는 GPU를 Device Plugin을 통해 Schedulable Resource로 노출하고, 서로 다른 GPU Type을 가진 Node는 Label / Selector 같은 방식으로 구분할 수 있습니다.

GPU 수량

Single-GPU Job과 8-GPU Distributed Training Job은 Scheduling 조건이 완전히 다릅니다.

큰 Job은 여러 GPU를 동시에 확보해야 할 수 있습니다.

Queue

여러 Team이나 Project가 하나의 Cluster를 사용한다면 Job을 Queue로 관리할 수 있습니다.

Queue를 사용하면:

  • 기다리는 Job을 관리하고
  • Team별 Resource를 구분하고
  • Resource가 확보될 때 순서대로 실행

할 수 있습니다.

Priority

모든 Workload의 중요도가 같지는 않습니다.

Production Inference, 긴급 Fine-tuning, Experiment 같은 Workload에 서로 다른 Priority를 적용할 수 있습니다.

Quota

특정 Team이나 Project가 전체 GPU를 독점하지 않도록 Resource Limit을 둘 수 있습니다.

Quota는 Resource Fairness와 Capacity Planning에 중요한 역할을 합니다.

Reservation

중요한 Job이나 정해진 시간대에 필요한 Capacity를 미리 확보해야 하는 경우 Reservation 개념이 필요할 수 있습니다.

Topology

Multi-GPU Training에서는 단순히 GPU 수량만 맞으면 되는 것이 아닐 수 있습니다.

같은 Node 안의 GPU인지, GPU Interconnect가 어떻게 구성되어 있는지, Multi-node Network가 어떤 구조인지가 Performance에 영향을 줄 수 있습니다.

그래서 Scheduler가 Hardware Topology를 고려해야 하는 환경도 있습니다.

GPU Scheduling은 ‘빈 GPU 찾기’가 아니라 Workload 요구와 운영 Policy를 Resource 상태에 맞추는 과정입니다.

그림 1. GPU Scheduling은 어떻게 결정될까요?

Multi-GPU Job은 왜 Scheduling이 더 어렵나요?

Single-GPU Job은 GPU 한 개가 Free라면 실행할 수 있는 경우가 많습니다.

하지만 Distributed Training처럼 여러 Worker가 동시에 시작해야 하는 Job은 다릅니다.

예를 들어 GPU 8개가 필요한 Job인데 6개만 먼저 배정된다면 나머지 2개를 기다리는 동안 이미 잡아 둔 Resource가 제대로 활용되지 않을 수 있습니다.

이런 종류의 Workload에서는 Gang Scheduling이 사용될 수 있습니다.

Gang Scheduling은 필요한 최소 Resource가 동시에 준비될 때 Job을 Scheduling하는 방식입니다.

즉:

여러 Resource가 함께 있어야 실행 가능한 Job은 일부만 먼저 배정하는 것이 오히려 낭비가 될 수 있습니다.

Free GPU가 있는데도 Job이 실행되지 않을 수 있습니다

GPU 운영에서 자주 발생하는 문제 중 하나가 Resource Fragmentation입니다.

예를 들어:

  • Node A에 Free GPU 2개
  • Node B에 Free GPU 2개

가 있다면 Cluster 전체로는 GPU 4개가 비어 있습니다.

하지만 새로운 Job이 같은 Node에 GPU 4개를 요구한다면 실행할 수 없습니다.

총 Free Capacity는 4개지만 Workload 조건을 만족하는 Schedulable Capacity는 0인 셈입니다.

그림 2. GPU가 4개 남아 있는데도 Job이 실행되지 않는 이유

그래서 GPU Utilization을 볼 때 단순히 “몇 개가 사용 중인가?”만 확인하면 부족합니다.

Free Capacity와 실제로 배치 가능한 Capacity는 다를 수 있습니다.

GPU Scheduling과 Provisioning은 무엇이 다를까요?

두 용어는 자주 함께 나오지만 역할은 다릅니다.

Provisioning

GPU Resource를 사용할 수 있는 상태로 준비하는 과정입니다.

예:

  • Bare Metal Server 할당
  • VM 생성
  • OS / Driver 준비
  • Network 연결
  • Storage 연결
  • Access 정보 생성

Scheduling

이미 사용 가능한 Resource Pool 안에서 어떤 Workload를 어떤 GPU에 배치할지 결정하는 과정입니다.

간단히 말하면:

Provisioning = Resource를 준비

Scheduling = Workload를 Resource에 배치

입니다.

실제 GPU Cloud에서는 두 과정이 연결되어야 합니다.

고객이 Resource를 주문하면 필요한 Infrastructure가 Provisioning되고, Workload 실행 단계에서는 Scheduler가 적합한 GPU에 Job을 배치할 수 있습니다.

Scheduling과 Orchestration도 같은 말은 아닙니다

Scheduling은 “어디에서 실행할 것인가?”에 초점이 있습니다.

Orchestration은 더 넓게:

  • Workload 생성
  • Dependency
  • Retry
  • Scaling
  • Lifecycle
  • Service 연결

등 여러 운영 단계를 조정할 수 있습니다.

따라서 Scheduler는 Orchestration System의 일부일 수 있지만 두 용어를 동일하게 사용하는 것은 정확하지 않습니다.

GPU Scheduling이 Utilization을 높이나요?

좋은 Scheduling은 GPU Resource를 더 효과적으로 배치하는 데 도움이 됩니다.

예를 들어:

  • 작은 Job을 적절히 배치하고
  • 큰 Job을 위해 필요한 Capacity를 확보하고
  • Queue를 통해 Idle Time을 줄이고
  • Fragmentation을 줄이는

운영을 할 수 있습니다.

하지만 Scheduling만으로 높은 Utilization이 자동으로 만들어지는 것은 아닙니다.

GPU Utilization에는:

  • Workload 자체의 GPU 사용 효율
  • Data Pipeline
  • CPU / Memory
  • Storage
  • Network
  • Model Architecture
  • Batch Size
  • Software Optimization

도 영향을 줍니다.

그래서 Cluster Level Resource Utilization과 실제 GPU Compute Utilization을 구분해서 봐야 합니다.

Kubernetes에서는 GPU를 어떻게 Scheduling할까요?

Kubernetes는 Device Plugin Framework를 통해 GPU 같은 Specialized Hardware를 Schedulable Resource로 노출할 수 있습니다.

예를 들어 NVIDIA GPU가 Node에 등록되면 Workload가 필요한 GPU 수량을 요청할 수 있습니다.

GPU Type이 여러 종류라면 Node Label과 Selector를 이용해 특정 Accelerator가 있는 Node로 Workload를 배치할 수 있습니다.

하지만 AI Workload가 복잡해지면 기본 Resource 요청 외에도:

  • Queue
  • Priority
  • Quota
  • Gang Scheduling
  • Topology
  • Reservation

같은 추가 Scheduling 기능이 필요할 수 있습니다.

그래서 Kubernetes 환경에서도 Workload 특성에 따라 별도의 Batch Scheduler, Queue Manager 또는 GPU-aware Scheduling Layer를 함께 사용하기도 합니다.

운영자는 무엇을 봐야 할까요?

GPU Scheduling Platform을 평가할 때는 단순히 “GPU를 배정할 수 있는가?”보다 다음을 확인해야 합니다.

Resource Awareness

  • GPU Type 구분
  • GPU 수량
  • Node / Topology Awareness
  • Multi-GPU / Multi-Node 지원

Policy

  • Queue
  • Priority
  • Quota
  • Reservation
  • Fairness

Workload

  • Training
  • Fine-tuning
  • Inference
  • Batch Job
  • Long-running Service

Operations

  • Provisioning 연동
  • Monitoring / Observability
  • Capacity Management
  • API
  • Lifecycle Automation

Efficiency

  • Fragmentation 관리
  • Idle Resource 확인
  • Waiting Job 분석
  • 실제 GPU Compute Utilization 확인

GPU Scheduling만 있으면 GPU Cloud가 될까요?

아닙니다.

GPU Scheduling은 GPU Cloud의 중요한 기능이지만 전체 Cloud Service 중 하나의 운영 기능입니다.

고객이 실제 Cloud Service를 사용하려면 Scheduling 외에도:

  • Service Catalog
  • Ordering
  • User / Organization Management
  • Multi-Tenancy
  • Provisioning
  • Network / Storage
  • Metering
  • Billing
  • SLA
  • Observability
  • Lifecycle Management
  • API / Console

같은 기능이 필요할 수 있습니다.

따라서:

GPU Scheduling은 GPU를 배분하는 기능이고, GPU Cloud는 그 Resource를 고객이 Service로 사용할 수 있게 만드는 전체 Operating Model입니다.

Thaki Cloud는 GPU Scheduling을 어떻게 볼까요?

Thaki NeoCloud OS의 Capability Model에서 GPU Scheduling은 중요한 구성 요소입니다.

하지만 Thaki Cloud는 Scheduling을 독립적인 기능 하나로만 보지 않습니다.

Canonical Architecture는:

Customer Infrastructure → Thaki NeoCloud OS → Customer NeoCloud Service

입니다.

이 가운데 Thaki NeoCloud OS는:

  • Provisioning
  • Multi-Tenancy
  • GPU Scheduling
  • Metering
  • Billing
  • SLA
  • Observability
  • Lifecycle Automation

등을 연결해 Infrastructure를 실제 Cloud Service로 운영하는 Software Layer 역할을 합니다.

즉 Scheduling의 가치는 다른 Cloud Operation 기능과 연결될 때 더 커집니다.

정리하면

GPU Scheduling은 여러 사용자와 Workload 사이에서 GPU Resource를 배분하는 운영 기능입니다.

좋은 Scheduler는 단순히 빈 GPU를 찾는 것이 아니라:

  • GPU Type
  • GPU 수량
  • Queue
  • Priority
  • Quota
  • Reservation
  • Topology
  • Multi-GPU Requirement
  • Resource Fragmentation

을 고려해야 할 수 있습니다.

그리고 가장 중요한 구분은:

Provisioning은 Resource를 준비하고, Scheduling은 Workload를 그 Resource에 배치합니다.

GPU Scheduling은 GPU Cloud 운영에서 중요한 기능이지만, Scheduling 하나만으로 GPU Cloud가 완성되는 것은 아닙니다.

FAQ

GPU Scheduling은 GPU Utilization과 같은 의미인가요?

아닙니다. Scheduling은 Resource 배치 의사결정이고, Utilization은 Resource가 실제로 얼마나 사용되는지를 나타냅니다. Scheduling은 Utilization 개선에 도움을 줄 수 있지만 동일한 개념은 아닙니다.

Kubernetes 기본 Scheduler만으로 GPU Scheduling이 가능한가요?

기본적인 GPU Resource 요청과 Node 선택은 가능합니다. 다만 Queue, Quota, Gang Scheduling, Advanced Topology 같은 요구는 별도의 Scheduling / Queue Layer가 필요할 수 있습니다.

GPU가 비어 있는데도 Job이 기다릴 수 있나요?

그럴 수 있습니다. 필요한 GPU Type, 수량, Node Topology, Quota, Priority 또는 Multi-GPU 조건을 만족하지 못하면 Free GPU가 있어도 Job이 대기할 수 있습니다.

Gang Scheduling이란 무엇인가요?

여러 Worker나 Resource가 함께 준비되어야 실행 가능한 Job에서 필요한 최소 Resource를 동시에 확보한 뒤 Scheduling하는 방식입니다.

Scheduling과 Provisioning은 무엇이 다른가요?

Provisioning은 Infrastructure Resource를 사용 가능한 상태로 준비하고, Scheduling은 실행할 Workload를 준비된 Resource에 배치합니다.

이 글 공유하기

GPU Capacity를 더 효율적으로 운영하고 계신가요?

GPU Resource를 여러 사용자와 Workload에 배분하려면 Scheduling뿐 아니라 Provisioning, Policy, Metering, Observability와 Lifecycle Management가 함께 연결되어야 합니다. Thaki Cloud와 함께 Service-ready GPU Operations Architecture를 검토해 보세요.

문의하기

참고 자료