On-demand GPU Service란? 필요한 GPU를 필요할 때 제공받는 방식
“On-demand GPU”라는 말을 들으면 무엇이 먼저 떠오르시나요?
필요할 때 GPU VM을 바로 생성하는 서비스일 수도 있고, 사용한 시간만큼 비용을 내는 요금제를 떠올릴 수도 있습니다.
어떤 사람은 Shared GPU를, 어떤 사람은 Spot GPU를 생각하기도 합니다.
하지만 온디맨드 GPU의 핵심은 특정 가상화 방식이나 할인 요금제가 아닙니다.
가장 단순하게 정의하면:
필요한 GPU 자원을 필요할 때 요청하고, 제공받아 사용한 뒤, 사용이 끝나면 반환할 수 있는 소비·운영 방식
입니다.
이 정의에서 중요한 것은 GPU가 VM인지, 베어메탈인지보다 요청과 제공의 방식입니다.
온디맨드는 Shared GPU와 같은 말이 아닙니다
GPU를 온디맨드로 제공한다고 해서 여러 고객이 하나의 GPU를 반드시 나눠 써야 하는 것은 아닙니다.
온디맨드 서비스는 다음과 같은 여러 형태로 제공될 수 있습니다.
- 전용 베어메탈 GPU 서버
- GPU VM
- vGPU 같은 가상화 GPU
- 컨테이너 기반 GPU 워크로드
- 특정 기간 동안 할당되는 GPU 자원
각 방식은 성능, 격리, 운영 방식과 상품 구조가 다를 수 있습니다.
온디맨드라는 표현은 그 위에 있는 소비 경험을 설명합니다.
고객이 필요한 자원을 요청하고, 정책과 가용 용량을 확인한 뒤, 실제 사용할 수 있는 환경을 제공받는 구조입니다.
온디맨드 GPU는 어떻게 제공될까요?
일반적인 흐름을 단순화하면 다음과 같습니다.
요청 → 정책 확인 → 가용 용량 확인 → 자원 할당 → 프로비저닝 → 사용 → 사용량 측정 → 종료 / 회수

1. 요청
고객은 포털이나 API에서 필요한 GPU 상품을 선택합니다.
예:
- GPU 서버 1대
- GPU 4개가 포함된 VM
- 특정 GPU 수량이 필요한 AI 워크로드 환경
2. 정책 확인
고객이 해당 상품을 사용할 수 있는지 확인합니다.
조직별 할당량, 계약, 권한, 최대 사용 기간 같은 정책이 적용될 수 있습니다.
3. 가용 용량 확인
카탈로그에 상품이 존재하는 것과 실제로 지금 제공할 수 있는 것은 다릅니다.
GPU 모델, 서버 구성, 데이터센터 위치, 네트워크, 스토리지, 기존 예약 등에 따라 가용 용량이 달라질 수 있습니다.
4. 자원 할당
조건이 맞으면 실제 GPU 자원을 고객 요청에 연결합니다.
5. 프로비저닝
할당된 자원을 고객이 사용할 수 있는 상태로 만듭니다.
베어메탈 서버라면 이미지 배포, 네트워크 연결, 스토리지 구성, 인증 정보 발급 같은 과정이 포함될 수 있습니다.
6. 사용 / 측정
고객이 GPU 자원을 사용하고, 서비스는 사용 기간이나 계약상 과금 기준에 필요한 기록을 남깁니다.
7. 종료 / 회수
사용이 끝나면 자원을 정리하고 다시 가용 자원 풀로 되돌립니다.
이 전체 흐름이 반복 가능해야 “필요할 때 요청하고 반환하는” 온디맨드 서비스가 됩니다.
온디맨드는 “즉시 무조건 제공”을 뜻하지 않습니다
온디맨드라는 표현 때문에 모든 GPU 요청이 즉시 처리될 것처럼 느껴질 수 있습니다.
하지만 실제 클라우드에서도 온디맨드 자원은 가용 용량의 영향을 받습니다.
GPU는 일반적인 CPU 인스턴스보다 특정 하드웨어 종류와 서버 구성이 중요한 경우가 많습니다.
예를 들어 고객이 원하는 조건이:
- 특정 GPU 종류
- 8-GPU 서버
- 특정 데이터센터
- 고속 네트워크
- 특정 스토리지
라면 이 조건을 모두 만족하는 가용 자원이 있어야 합니다.
따라서:
온디맨드는 요청 방식이지, 무한한 재고 보장이 아닙니다.
가용 용량이 없다면 요청이 실패하거나, 대기하거나, 다른 상품을 선택해야 할 수 있습니다.
On-demand와 Spot은 같은 개념일까요?
아닙니다.
일반적인 클라우드 시장에서 On-demand와 Spot / Preemptible은 서로 다른 소비 옵션으로 구분되는 경우가 많습니다.
On-demand는 보통 장기 약정 없이 필요할 때 자원을 요청해 사용하는 유연한 방식입니다.
Spot / Preemptible은 남는 용량을 활용하는 대신 서비스 제공자가 자원을 중단할 수 있는 조건이 붙는 경우가 많습니다.
예를 들어 AWS도 On-Demand Instances와 Spot Instances를 별도 구매 옵션으로 구분합니다.
따라서 “온디맨드 GPU”라고 했다고 해서 자동으로 중단 가능한 GPU라는 뜻은 아닙니다.
Reserved와 On-demand는 반대말일까요?
항상 그렇지는 않습니다.
예약형 상품은 특정 기간의 용량을 미리 확보하는 방식입니다.
온디맨드는 필요 시 자원을 요청하는 방식입니다.
하나의 GPU 클라우드 사업자가 둘을 함께 운영할 수도 있습니다.
예를 들어:
- 기본 고객은 온디맨드로 가용 용량을 요청
- 대규모 고객은 미리 용량 예약
- 예약되지 않은 일부 용량은 온디맨드 풀로 운영
하는 구조가 가능합니다.
중요한 것은 사업자가 어떤 용량을 어느 상품에 할당할지 정책을 명확히 관리하는 것입니다.
전용 베어메탈도 온디맨드가 될 수 있습니다
온디맨드를 VM과 동일하게 생각할 필요는 없습니다.
물리 서버도 자동화된 프로비저닝 구조를 통해 클라우드 방식으로 제공할 수 있습니다.
OpenStack Ironic은 물리 베어메탈 서버를 API 기반으로 프로비저닝하고 관리하는 대표적인 예입니다.
고객이 전용 GPU 서버를 요청하고 시스템이:
- 가용 서버 확인
- 예약 / 할당
- 이미지 배포
- 네트워크 연결
- 접근 권한 생성
- 사용 종료 후 정리
를 일관되게 처리한다면 전용 물리 GPU도 온디맨드 서비스가 될 수 있습니다.

즉:
온디맨드는 자원의 물리적 형태가 아니라 서비스 소비 방식입니다.
GPU에서는 프로비저닝 시간이 더 중요할 수 있습니다
“요청 가능”과 “즉시 사용 가능”도 같은 말이 아닙니다.
VM은 이미 준비된 이미지와 자원 풀에서 비교적 빠르게 생성될 수 있습니다.
반면 베어메탈 서버는 환경에 따라:
- 장비 상태 확인
- 이미지 배포
- 펌웨어 / 설정
- 네트워크 구성
- 스토리지 연결
- 초기화
같은 단계가 더 필요할 수 있습니다.
따라서 온디맨드 서비스의 품질은 단순히 “주문 버튼이 있는가?”보다:
- 예상 프로비저닝 시간을 고객에게 어떻게 보여주는가?
- 실패 상태를 어떻게 처리하는가?
- 자원 회수 후 언제 다시 가용 상태가 되는가?
까지 포함해서 봐야 합니다.
사용량 측정과 과금은 어떻게 연결될까요?
온디맨드 서비스는 사용 기간과 자원 상태가 매출 계산에 직접 연결될 수 있습니다.
하지만 GPU 사용률 자체를 그대로 과금 데이터로 사용한다고 가정해서는 안 됩니다.
상품에 따라 과금 기준은 달라질 수 있습니다.
예:
- 서버가 고객에게 할당된 시간
- VM 실행 시간
- 예약 기간
- 특정 워크로드 실행 시간
따라서 기술 모니터링, 자원 할당 기록, 서비스 상태, 계약 조건을 구분해서 관리해야 합니다.
온디맨드 GPU 사업자가 운영해야 하는 것은 무엇일까요?
온디맨드 경험을 만들려면 단순 프로비저닝 자동화만으로는 부족할 수 있습니다.
다음이 연결되어야 합니다.
- 주문 가능한 상품
- 고객 / 조직 / 권한
- 할당량 / 정책
- 실제 가용 용량
- 자원 예약 / 할당
- 프로비저닝
- 서비스 상태
- 사용량 측정
- 과금 연동
- 종료 / 회수
- 장애 / 재시도
즉 온디맨드 GPU는 결국 클라우드 운영 문제입니다.
Thaki Cloud는 이 문제를 어떻게 볼까요?
Thaki Cloud의 Canonical Architecture는 다음과 같습니다.
Customer Infrastructure → Thaki NeoCloud OS → Customer NeoCloud Service
Thaki NeoCloud OS는 GPU 및 AI 인프라를 보유한 사업자가 자체 브랜드의 Self-Service·On-demand NeoCloud 서비스를 구축하고 운영할 수 있도록 지원하는 클라우드 플랫폼입니다.
지원되는 환경에서는 서비스 카탈로그, 프로비저닝, 테넌시, 자원 할당 / 스케줄링, 사용량 측정, 과금 연동, 관측과 자원 라이프사이클 같은 영역을 연결할 수 있습니다.
실제 지원 범위, 하드웨어 연동과 상용 조건은 프로젝트별 확인이 필요합니다.
정리하면
On-demand GPU는 특정 GPU 기술이나 가격제를 뜻하지 않습니다.
핵심은:
필요할 때 요청 → 실제 가용 용량 확인 → 할당 / 프로비저닝 → 사용 → 측정 → 반환
입니다.
전용 베어메탈도 온디맨드가 될 수 있고, 공유 GPU도 온디맨드가 될 수 있습니다.
또한 온디맨드라고 해서 GPU 용량이 무한하거나 항상 즉시 제공되는 것은 아닙니다.
GPU 클라우드 사업자는 자원 형태보다 먼저 요청부터 반환까지의 운영 구조를 설계해야 합니다.
FAQ
On-demand GPU는 Shared GPU를 뜻하나요?
아닙니다. 전용 베어메탈, VM, 가상화 GPU, 컨테이너 기반 GPU 모두 온디맨드 방식으로 제공될 수 있습니다.
On-demand GPU와 Spot GPU는 같은가요?
아닙니다. Spot / Preemptible은 중단 가능성과 가격 조건을 포함하는 별도의 소비 옵션으로 운영되는 경우가 많습니다.
On-demand이면 GPU가 항상 즉시 제공되나요?
아닙니다. 실제 가용 용량, GPU 종류, 서버 구성, 위치와 정책에 따라 제공 가능 여부가 달라질 수 있습니다.
예약형 GPU와 온디맨드를 함께 운영할 수 있나요?
가능합니다. 일부 용량은 예약형으로, 일부는 온디맨드 풀로 운영할 수 있습니다.
전용 베어메탈 GPU도 온디맨드가 가능한가요?
가능합니다. API / 포털 요청과 자동화된 프로비저닝·회수 흐름이 연결되면 물리 서버도 클라우드 방식으로 제공할 수 있습니다.
온디맨드 GPU 서비스를 설계하고 계신가요?
GPU 용량을 고객이 필요할 때 요청하고 사용할 수 있는 서비스로 만들기 위해 상품, 가용 용량, 프로비저닝, 사용량 측정과 자원 회수 구조를 검토하고 있다면 Thaki Cloud와 함께 운영 아키텍처를 점검해 보세요.
문의하기참고 자료
관련 아티클
- GPU Cloud란 무엇인가? 개념, 작동 방식, GPUaaS와의 차이GPU Cloud는 데이터센터의 GPU를 네트워크를 통해 필요할 때 사용하는 클라우드 컴퓨팅 방식입니다. GPUaaS와의 차이, 작동 방식, Bare Metal·Virtual GPU 유형, 활용 사례와 운영 구조를 설명합니다.
- AI Factory란 무엇인가? AI 데이터센터와 무엇이 다른가?AI Factory는 AI 워크로드를 반복적으로 개발·학습·배포·운영하기 위한 통합 인프라와 운영 환경입니다. AI 데이터센터와의 차이, 핵심 구성 요소, AI Lifecycle, GPU Cloud와의 관계를 설명합니다.
- GPUaaS란 무엇인가? GPU as a Service의 구조와 핵심 기능GPUaaS는 GPU 연산 자원을 직접 구매하지 않고 서비스 형태로 사용하는 방식입니다. GPU Cloud와의 차이, 작동 방식, Bare Metal·Virtual GPU 제공 형태, 운영 기능과 선택 기준을 설명합니다.
- Private AI Cloud란 무엇인가?Private AI Cloud는 단일 조직 전용의 Private Cloud 운영 모델에 GPU·AI 플랫폼·데이터·보안·거버넌스를 결합한 AI 환경입니다. Public AI Cloud, On-Prem AI, Sovereign AI, Air-Gapped AI와의 차이와 구축 고려사항을 설명합니다.
- GPU 서버가 있다고 GPU Cloud가 되는 것은 아닙니다GPU 서버를 보유하거나 호스팅한다고 자동으로 GPU Cloud가 되는 것은 아닙니다. GPU Hosting과 GPU Cloud의 차이, Self-Service·Provisioning·Scheduling·Metering 등 Cloud 운영에 필요한 핵심 기능을 설명합니다.
- NeoCloud란 무엇인가? AI 시대의 GPU 중심 클라우드NeoCloud는 GPU와 AI Workload에 특화된 Cloud Infrastructure Provider를 설명할 때 사용되는 산업 용어입니다. 기존 Hyperscaler, GPU Cloud, GPUaaS와의 관계와 Thaki Cloud의 NeoCloud Enablement 관점을 설명합니다.
- AI Factory의 다음 단계는 Cloud Service입니다AI Factory를 구축하는 것과 고객이 실제로 사용할 수 있는 Cloud Service를 운영하는 것은 다릅니다. Provisioning, Multi-Tenancy, GPU Scheduling, Metering, Billing, SLA 등 서비스화에 필요한 운영 계층을 설명합니다.
- AI 인프라를 Cloud Business로 전환한다는 것은 무엇인가?GPU와 AI 인프라를 보유하는 것과 실제 Cloud Business를 운영하는 것은 다릅니다. Infrastructure → Product → On-demand Cloud Service 전환 과정과 Service Catalog, Provisioning, Metering, Billing, SLA 등 사업화에 필요한 운영 구조를 설명합니다.
- Bare Metal GPU란? 가상화 GPU와의 차이와 활용 방식Bare Metal GPU의 개념과 GPU VM, vGPU, GPU Passthrough의 차이를 알아보세요. 전용성, 성능 일관성, 유연성, 자원 효율, Provisioning 관점에서 어떤 방식이 적합한지 설명합니다.
- Private AI Cloud와 Public AI Cloud의 차이Private AI Cloud와 Public AI Cloud를 전용성, 통제 범위, 확장성, Managed Service, 운영 책임, 비용 구조 관점에서 비교합니다. 어떤 AI Workload에 각각 적합한지 알아보세요.
- GPU Scheduling이란? AI Cloud에서 GPU 자원을 배분하는 방법GPU Scheduling의 개념과 Queue, Priority, Quota, GPU Type, Topology, Multi-GPU Job, Resource Fragmentation을 알아보세요. GPU Cloud에서 Scheduling과 Provisioning이 어떻게 다른지도 설명합니다.
- AI Factory 구축 이후에 필요한 운영 플랫폼은 무엇인가?AI Factory 구축 이후 실제 운영 단계에서 필요한 Provisioning, GPU Scheduling, 사용자·Policy 관리, Observability, Capacity Management, Metering과 Lifecycle Automation을 알아보세요.
- On-Prem AI란? 기업이 자체 환경에서 AI를 운영하는 이유On-Prem AI의 개념과 Private AI Cloud와의 차이, 기업이 데이터·모델·네트워크·지연시간·운영 통제를 이유로 자체 환경에서 AI를 운영하는 경우와 Trade-off를 알아보세요.
- GPU Multi-Tenancy란? 여러 고객이 GPU 인프라를 안전하게 사용하는 구조GPU Multi-Tenancy의 개념과 Tenant Isolation, Dedicated GPU, vGPU, MIG, Kubernetes Namespace, Quota, Scheduling, Network·Storage 분리와 Usage 관리 구조를 알아보세요.
- GPU Provisioning이란? 주문에서 사용 가능 상태까지의 자동화GPU Provisioning의 개념과 GPU 요청 이후 Compute, Network, Storage, Image, Runtime, Access를 준비해 실제 사용 가능한 환경으로 만드는 자동화 과정을 알아보세요.
- AI Factory를 Multi-Customer Cloud Service로 전환하려면AI Factory를 여러 고객이 사용하는 Cloud Service로 전환할 때 필요한 Service Catalog, Multi-Tenancy, Provisioning, Scheduling, Metering, Billing, SLA와 Lifecycle을 알아보세요.
- GPU 클라우드 사업화 준비도 체크리스트: 무엇을 점검해야 할까?GPU 서버를 보유했다고 바로 GPU 클라우드 서비스를 판매할 수 있는 것은 아닙니다. 서비스 상품화, 멀티테넌시, 프로비저닝, 사용량 측정, 과금, SLA와 자원 라이프사이클을 12개 실무 항목으로 점검합니다.
- GPU 클라우드 수익성 분석: 가동률보다 중요한 것은 무엇일까?GPU 사용률과 과금 가능 시간은 같은 지표가 아닙니다. 가상의 32-GPU 계산 예시를 통해 판매 가능 용량, 과금 가능 GPU 시간, 실현 단가, 고정비·변동비와 손익분기점을 설명합니다.
- GPU 클라우드 직접 구축 vs. 통합 운영 플랫폼: 무엇이 더 합리적일까?OpenStack, Kubernetes, Prometheus 같은 오픈소스로 GPU 클라우드를 구축할 수 있습니다. 직접 통합과 운영 플랫폼 도입을 연동, 실패 처리, 과금, 확장성과 3–5년 총소유비용 관점에서 비교합니다.
- Self-Service Cloud란? 고객이 직접 주문하고 사용하는 클라우드 서비스셀프서비스 클라우드는 단순한 포털이 아닙니다. 서비스 카탈로그, IAM, 정책·할당량, 가용 용량, 프로비저닝, 사용량 측정과 자원 회수가 어떻게 연결되어야 하는지 설명합니다.
- Cloud Service Catalog란? GPU 인프라를 서비스 상품으로 만드는 첫 단계클라우드 서비스 카탈로그는 GPU 재고 목록이나 가격표가 아닙니다. GPU·네트워크·스토리지를 고객이 주문할 수 있는 상품으로 정의하고 정책, 프로비저닝, 과금과 연결하는 구조를 설명합니다.
- 데이터센터가 GPU Hosting에서 GPU Cloud로 전환하려면GPU Hosting에서 GPU Cloud로의 전환은 하드웨어 교체보다 운영 모델 변화에 가깝습니다. 서비스 카탈로그, 셀프서비스, 프로비저닝, 고객 분리, 사용량 측정·과금과 자원 회수를 어떻게 추가해야 하는지 설명합니다.