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는 어떻게 제공될까요?

일반적인 흐름을 단순화하면 다음과 같습니다.

요청 → 정책 확인 → 가용 용량 확인 → 자원 할당 → 프로비저닝 → 사용 → 사용량 측정 → 종료 / 회수

요청, 용량 확인, 할당, 프로비저닝, 사용 / 측정, 회수의 6단계가 소프트웨어 운영 및 요청 레이어 아래에서 이어지고, 할당된 자원과 사용 가능한 풀 사이를 GPU 용량 풀이 오가는 구조.
그림 1. 온디맨드 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도 온디맨드 서비스가 될 수 있습니다.

콘솔, API, 정책 / 용량 확인으로 이루어진 On-demand 요청 계층 아래에 전용 베어메탈, GPU VM, 컨테이너 GPU가 같은 비중으로 놓인 구조.
그림 2. 온디맨드는 자원 형태가 아니라 소비 방식입니다. 같은 온디맨드 경험 아래 전용 베어메탈, VM, 컨테이너 기반 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와 함께 운영 아키텍처를 점검해 보세요.

문의하기

참고 자료