GPU Provisioning이란? 주문에서 사용 가능 상태까지의 자동화

GPU Provisioning은 사용자나 고객의 GPU 요청을 실제로 접속하고 사용할 수 있는 Compute Environment로 준비하는 과정입니다.

GPU를 “할당했다”는 것만으로는 사용 준비가 끝나지 않습니다. Service Model에 따라 Compute, Network, Storage, Image / OS, Driver / Runtime, Credential과 Access까지 여러 요소가 함께 구성되어야 합니다.

그래서 GPU Cloud에서 Provisioning의 핵심은:

Request / Order를 Ready-to-Use Environment로 바꾸는 것

입니다.

GPU를 주문하면 바로 사용할 수 있을까요?

Cloud Service에서는 그렇게 보여야 합니다.

사용자는 Console이나 API에서 필요한 GPU를 선택하고 요청하면 됩니다.

하지만 Platform 뒤에서는 여러 Step이 연결될 수 있습니다.

예를 들어 Bare Metal GPU Service라면:

• 적합한 Physical Server 선택
• Server 상태 확인
• Image / OS 배포
• Network 구성
• Storage 연결
• GPU Driver / Runtime 준비
• Access Credential 설정
• Health / Readiness 확인

이 필요할 수 있습니다.

VM 기반 GPU Service라면:

• VM 생성
• GPU Passthrough 또는 vGPU Profile 적용
• Network / Storage 연결
• Image / Runtime 구성
• Access 설정

이 필요할 수 있습니다.

Kubernetes 환경에서는 이미 준비된 GPU Node 위에서 Container Workload를 실행할 수도 있고, GPU Operator 같은 Tool을 통해 Driver, Container Toolkit, Device Plugin 등 GPU 사용에 필요한 Software Component를 관리할 수 있습니다.

즉 Provisioning은 하나의 고정된 Script가 아니라 Service Model에 따라 Resource를 사용 가능한 상태로 만드는 Workflow입니다.

GPU Provisioning은 실제로 무엇을 준비할까요?

일반적으로 다음 영역을 함께 봐야 합니다.

Compute / GPU

• Bare Metal Server
• VM
• GPU Type
• GPU Quantity
• GPU Passthrough / vGPU / Partitioning Profile

Network

• IP
• VLAN / Segment
• Routing
• Security Policy
• External / Private Access

Storage

• Boot Disk
• Volume
• Dataset
• Shared Storage
• Object Storage Access

Image / Runtime

• OS Image
• Driver
• CUDA / Runtime
• Container Runtime
• 필요한 Software Stack

Access

• User / Organization
• Credential
• SSH Key
• IAM / Role
• Console / API Permission

이 요소들이 준비되고 검증되어야 사용자는 실제 AI Workload를 실행할 수 있습니다.

Provisioning은 왜 자동화되어야 할까요?

GPU Server를 몇 대만 운영할 때는 수작업도 가능합니다.

하지만 고객이나 Team이 반복적으로 Resource를 요청하면 문제가 달라집니다.

매 요청마다:

• 어떤 Server를 줄지 찾고
• Network를 연결하고
• Storage를 붙이고
• Image를 설치하고
• Access를 설정하고
• 사용이 끝나면 Resource를 다시 정리하는

과정을 사람이 처리한다면 Service Delivery 속도와 일관성이 떨어집니다.

Self-Service·On-demand Cloud에서는 고객이 요청할 때마다 동일한 Policy와 Workflow로 Environment를 만들 수 있어야 합니다.

그래서 Provisioning Automation은 단순한 운영 편의 기능이 아니라 Cloud Service Delivery의 핵심 요소입니다.

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

둘은 자주 함께 사용되지만 역할이 다릅니다.

Provisioning

Resource Environment를 준비합니다.

예:

• GPU VM 생성
• Bare Metal Server Image 배포
• Network / Storage 연결
• Access 준비

Scheduling

준비된 Resource 중에서 Workload를 어디에 실행할지 결정합니다.

예:

• Training Job을 어떤 GPU Node에 배치할지
• 어떤 GPU Type이 적합한지
• Queue / Priority / Quota를 어떻게 적용할지

따라서:

Provisioning = Resource를 사용 가능한 상태로 준비

Scheduling = Workload를 적합한 Resource에 배치

입니다.

Resource Allocation과 Provisioning도 같은 말일까요?

완전히 같지는 않습니다.

Allocation은 특정 Resource를 User / Tenant / Workload에 배정하는 의미로 사용될 수 있습니다.

Provisioning은 Allocation을 포함할 수도 있지만, 실제로 사용 가능한 Environment가 되도록 필요한 Configuration과 Integration을 수행하는 더 넓은 Workflow로 보는 것이 일반적입니다.

예를 들어 GPU Server 한 대를 Tenant A에 “배정”했다고 해도:

• Network가 연결되지 않았거나
• OS가 준비되지 않았거나
• Credential이 없거나
• Storage가 연결되지 않았다면

사용자 관점에서는 아직 Service가 준비되지 않은 것입니다.

Bare Metal Provisioning은 왜 더 복잡할 수 있을까요?

Bare Metal은 Physical Server 자체를 직접 제공하기 때문에 VM Provisioning과 다른 Step이 필요할 수 있습니다.

OpenStack Ironic처럼 Bare Metal Provisioning을 위한 Platform은 Physical Machine을 Cloud Resource처럼 관리하고, Image 배포와 Hardware Lifecycle을 자동화하는 데 사용됩니다.

Bare Metal Service에서는:

• BMC / Remote Management
• PXE / Image Deployment
• Network Boot
• Disk Configuration
• Hardware 상태 확인
• Cleaning / Recovery

같은 Physical Lifecycle이 중요할 수 있습니다.

그래서 Bare Metal GPU Cloud는 단순히 “GPU Server를 빌려주는 것”과 다릅니다.

Kubernetes 환경에서 Provisioning은 어떻게 다를까요?

이미 GPU Node가 Cluster에 준비되어 있다면 매 Workload마다 Physical Server를 새로 설치할 필요는 없습니다.

대신 Platform은:

• GPU Driver
• Container Runtime
• Device Plugin
• Node Label
• Monitoring Component

같은 Software Layer를 준비해 GPU가 Kubernetes Resource로 사용 가능하도록 만들어야 합니다.

Kubernetes는 Device Plugin을 통해 GPU를 Schedulable Resource로 노출할 수 있고, NVIDIA GPU Operator는 GPU Driver, Container Toolkit, Device Plugin과 Monitoring Component의 관리 자동화를 지원합니다.

이 경우 Provisioning은 Physical Server 설치보다 GPU-enabled Cluster Environment를 유지하고 필요한 Resource를 Service 형태로 준비하는 것에 가까울 수 있습니다.

Provisioning이 끝났다는 것은 무엇을 의미할까요?

Operator 관점에서는 단순히 Automation Job이 완료되었다는 것만으로 부족합니다.

사용자 관점에서 실제로 다음이 가능해야 합니다.

• Resource가 보임
• Network 접속 가능
• Storage 사용 가능
• GPU 인식
• Credential 동작
• 필요한 Runtime 사용 가능
• Health Check 통과

즉 Provisioning 완료는:

Infrastructure Task Complete가 아니라 User-ready State

로 보는 것이 중요합니다.

사용이 끝나면 어떻게 될까요?

Cloud Resource는 생성만큼 회수도 중요합니다.

사용이 종료되면:

• Credential 제거
• Network 해제
• Storage 처리
• Tenant Data 정리
• Server Cleaning
• Resource 상태 검증
• Pool로 반환

같은 Deprovisioning / Recovery Process가 필요할 수 있습니다.

이 과정을 자동화해야 Resource를 빠르고 안전하게 다시 사용할 수 있습니다.

따라서 전체 Lifecycle은:

Request → Provision → Use → Deprovision → Recover → Recycle

로 볼 수 있습니다.

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

아닙니다.

Provisioning은 매우 중요한 Capability이지만 GPU Cloud Service에는 일반적으로:

• Service Catalog
• User / Organization
• Multi-Tenancy
• Scheduling
• Network / Storage
• Quota / Policy
• Metering
• Billing
• Observability
• API / Console
• Lifecycle

같은 기능이 함께 필요합니다.

Provisioning은 이 전체 운영 체계에서 주문을 실제 Resource로 바꾸는 핵심 연결 단계입니다.

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

Thaki NeoCloud OS의 Capability Model에는 GPU / Bare Metal Provisioning과 함께 Multi-Tenancy, Scheduling, Quota / Policy, Metering, Billing, Observability와 Lifecycle Automation이 포함됩니다.

Canonical Architecture는:

Customer Infrastructure → Thaki NeoCloud OS → Customer NeoCloud Service

입니다.

이 구조에서 Provisioning은 Customer가 Self-Service로 주문한 Resource를 실제 사용 가능한 Service로 만드는 운영 Workflow의 핵심 부분입니다.

정리하면

GPU Provisioning은 GPU를 단순히 “잡아주는 기능”이 아닙니다.

핵심은:

GPU Request를 실제 사용 가능한 Environment로 자동으로 준비하는 것

입니다.

Service Model에 따라 세부 과정은 달라질 수 있지만 일반적으로 Compute, Network, Storage, Image / Runtime과 Access를 함께 준비해야 합니다.

그리고:

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

이 둘을 구분하면 GPU Cloud의 운영 구조를 훨씬 명확하게 이해할 수 있습니다.

FAQ

GPU Provisioning과 GPU Scheduling은 같은가요?

아닙니다. Provisioning은 Resource Environment를 준비하고, Scheduling은 Workload를 준비된 Resource에 배치합니다.

Provisioning에는 GPU Driver 설치도 항상 포함되나요?

항상 그렇지는 않습니다. 이미 구성된 Cluster에서는 Driver와 Runtime이 사전에 준비되어 있을 수 있습니다. Provisioning Step은 Bare Metal, VM, Kubernetes 등 Service Model에 따라 달라집니다.

Bare Metal GPU도 자동 Provisioning할 수 있나요?

가능합니다. OpenStack Ironic 같은 Bare Metal Provisioning 기술은 Physical Server의 Image 배포와 Lifecycle을 Cloud 방식으로 자동화하는 데 사용될 수 있습니다.

GPU를 Allocation하면 Provisioning이 끝난 것인가요?

아닐 수 있습니다. Network, Storage, Image / Runtime, Access와 Health Check가 준비되어야 사용자 관점에서 실제 사용 가능한 Environment가 됩니다.

Provisioning 이후 Resource 회수도 자동화해야 하나요?

On-demand Service에서는 중요합니다. Deprovisioning, Cleaning, Recovery와 Resource Recycling을 자동화해야 Capacity를 반복적으로 안전하게 사용할 수 있습니다.