GPU Multi-Tenancy란? 여러 고객이 GPU 인프라를 안전하게 사용하는 구조

GPU Multi-Tenancy는 하나의 GPU Infrastructure를 여러 고객, Organization 또는 Team이 사용하면서 각 Tenant의 Resource, Access, Network, Storage, Policy와 Usage를 서로 분리하고 통제하는 운영 구조입니다.

가장 흔한 오해는 이것입니다.

Multi-Tenancy = 여러 사용자가 하나의 Physical GPU를 나눠 쓰는 것

이라고 생각하기 쉽지만, 꼭 그렇지는 않습니다.

Tenant별로 Dedicated GPU나 Dedicated Node를 할당할 수도 있고, GPU VM, vGPU, MIG 같은 방식으로 Resource를 Virtualize하거나 Partitioning할 수도 있습니다.

핵심은 “GPU를 공유하는가?”보다:

Tenant 간 Isolation과 Policy를 얼마나 명확하게 보장할 수 있는가

입니다.

Tenant란 무엇일까요?

Cloud나 Platform에서 Tenant는 독립적으로 관리되는 Customer, Organization, Business Unit 또는 Project를 의미할 수 있습니다.

예를 들어 GPU Cloud에서:

• 고객사 A
• 고객사 B
• 고객사 C

가 같은 Physical Infrastructure를 사용하더라도 각 고객은 서로의:

• User
• Workload
• Network
• Storage
• Credential
• Usage

에 접근할 수 없어야 합니다.

Enterprise 내부 환경에서도:

• Research Team
• Product Team
• Data Team

을 서로 다른 Tenant 또는 Organizational Boundary처럼 운영할 수 있습니다.

즉 Multi-Tenancy는 Public Cloud에만 필요한 개념은 아닙니다.

GPU Multi-Tenancy에서는 무엇을 분리해야 할까요?

GPU만 나누면 Multi-Tenancy가 완성되는 것은 아닙니다.

실제 환경에서는 여러 Layer를 함께 봐야 합니다.

1. Identity / Access

Tenant별로:

• User
• Organization
• Role
• Service Account
• Credential

이 분리되어야 합니다.

Kubernetes 환경에서는 Namespace와 RBAC가 중요한 Building Block이 될 수 있습니다.

하지만 Namespace만 만든다고 완전한 Isolation이 자동으로 생기는 것은 아닙니다.

2. Compute / GPU

Tenant에게 어떤 Compute Resource를 제공할지 결정해야 합니다.

예:

• Dedicated Bare Metal GPU
• Dedicated GPU VM
• vGPU
• MIG Instance
• Shared Kubernetes GPU Pool

Isolation Requirement와 Workload에 따라 방식이 달라질 수 있습니다.

3. Scheduling / Quota

한 Tenant가 모든 GPU를 점유하면 다른 Tenant의 Service가 영향을 받을 수 있습니다.

그래서:

• GPU Quota
• Priority
• Reservation
• Scheduling Policy
• Resource Limit

가 필요할 수 있습니다.

Kubernetes ResourceQuota는 Namespace 단위 Resource Usage를 제한하는 데 사용할 수 있고, Multi-Tenant Cluster에서는 한 Tenant의 Resource 독점을 줄이는 데 도움이 됩니다.

4. Network

Tenant A의 Workload가 Tenant B의 Service에 자유롭게 접근할 수 있다면 Compute Isolation만으로는 충분하지 않습니다.

Network Policy나 Network Segmentation을 통해 Tenant 간 Traffic Boundary를 설계해야 합니다.

5. Storage / Data

각 Tenant의:

• Volume
• Object Storage
• Dataset
• Model
• Checkpoint
• Secret

도 분리되어야 합니다.

Compute를 분리했어도 Storage Credential이나 Dataset Permission이 잘못 구성되면 Data Isolation이 깨질 수 있습니다.

6. Usage / Metering

각 Tenant가:

• GPU를 얼마나 사용했는지
• 어떤 Resource를 할당받았는지
• 얼마나 오래 사용했는지

를 확인할 수 있어야 합니다.

Internal Environment에서는 Showback / Capacity Planning에 사용할 수 있고, Customer-facing Cloud에서는 Billing / Settlement와 연결될 수 있습니다.

Multi-Tenancy는 반드시 GPU Sharing을 의미할까요?

아닙니다.

Multi-Tenancy와 GPU Sharing은 별개의 개념입니다.

Dedicated GPU / Node

Tenant마다 Physical GPU 또는 Node를 전용으로 할당할 수 있습니다.

이 경우 Physical Resource를 공유하지 않아도 전체 Platform은 Multi-Tenant일 수 있습니다.

예를 들어:

• Tenant A → GPU Node 1
• Tenant B → GPU Node 2
• Tenant C → GPU Node 3

처럼 운영하면서 User, Network, Storage, Quota와 Usage를 Tenant별로 분리할 수 있습니다.

GPU VM / vGPU

Virtualization Layer를 통해 VM별로 GPU Resource를 제공할 수 있습니다.

vGPU는 하나의 Physical GPU Resource를 여러 VM에 제공하는 방식에 활용될 수 있습니다.

VM은 Tenant Boundary로 사용될 수 있지만, IAM, Network, Storage와 Policy는 별도로 설계해야 합니다.

MIG

NVIDIA MIG는 지원 GPU를 여러 독립 GPU Instance로 Partitioning할 수 있는 기술입니다.

각 Instance는 Compute와 Memory Resource의 일부를 독립적으로 사용할 수 있습니다.

이런 Hardware Partitioning은 여러 Workload를 하나의 Physical GPU에서 실행할 때 Resource Isolation과 Predictability를 높이는 데 도움이 될 수 있습니다.

다만:

MIG 하나만으로 전체 Multi-Tenant Cloud가 완성되는 것은 아닙니다.

User, VM / Container, Network, Storage, IAM, Quota와 Usage Policy가 함께 필요합니다.

Multi-User와 Multi-Tenant는 무엇이 다를까요?

여러 사람이 같은 System을 사용한다고 해서 항상 Multi-Tenant인 것은 아닙니다.

Multi-User

하나의 Organization이나 Trust Boundary 안에서 여러 사용자가 같은 Platform을 사용하는 상황입니다.

Multi-Tenant

서로 다른 Customer / Organization / Security Boundary를 Platform이 명확히 분리해서 운영하는 상황입니다.

Multi-Tenant Environment에서는 일반적으로 더 강한:

• Identity Separation
• Policy
• Network Isolation
• Data Isolation
• Resource Governance
• Audit

이 필요합니다.

Kubernetes Namespace만 있으면 충분할까요?

보통 충분하지 않습니다.

Kubernetes Namespace는 API Resource를 논리적으로 분리하고 RBAC, ResourceQuota, NetworkPolicy 같은 Policy를 적용하는 중요한 기본 단위입니다.

하지만 Kubernetes 공식 Multi-Tenancy Guidance도 Namespace Isolation 외에:

• Access Control
• Quota
• Network Isolation
• Node Isolation
• Security Policy

등을 함께 고려합니다.

즉:

Namespace는 Multi-Tenancy의 시작점일 수 있지만 완성된 Security Boundary라고 가정하면 안 됩니다.

특히 서로 신뢰하지 않는 외부 Tenant를 하나의 Cluster에 배치한다면 Isolation Requirement를 더 엄격하게 평가해야 합니다.

Noisy Neighbor 문제는 무엇인가요?

여러 Tenant가 같은 Physical Infrastructure를 사용하면 한 Tenant의 Workload가 다른 Tenant의 Performance에 영향을 줄 수 있습니다.

예:

• GPU Resource 과점유
• CPU / Memory 사용 증가
• Storage I/O
• Network Traffic
• Shared Cache / Device Contention

이런 현상을 흔히 Noisy Neighbor Problem이라고 합니다.

이를 줄이기 위해:

• Dedicated Resource
• Quota
• Limit
• Scheduling
• Hardware Partitioning
• Network / Storage Policy

를 조합할 수 있습니다.

하지만 완전한 Performance Isolation이 필요한 Workload라면 Resource Sharing 자체를 줄이고 Dedicated GPU / Node를 선택하는 것이 더 적합할 수도 있습니다.

GPU Scheduling과 Multi-Tenancy는 어떤 관계인가요?

Scheduling은 Multi-Tenant Environment에서 매우 중요합니다.

Scheduler는 단순히 Free GPU를 찾는 것이 아니라:

• Tenant Quota
• Priority
• Reservation
• GPU Type
• Available Capacity
• Topology

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

예를 들어 Tenant A가 Quota를 모두 사용했다면 Free GPU가 있어도 추가 Allocation을 제한할 수 있습니다.

그래서:

Multi-Tenancy는 Isolation 문제이면서 동시에 Resource Governance 문제입니다.

Metering은 왜 필요할까요?

Multi-Tenant Service에서는 “누가 무엇을 얼마나 사용했는가?”를 확인할 수 있어야 합니다.

Metering은 다음에 활용될 수 있습니다.

Internal Environment

• Team별 Usage
• Showback
• Capacity Planning
• Quota 조정

Customer-facing Cloud

• Billing
• Settlement
• Usage Report
• SLA / Contract 확인

즉 Metering은 단순 비용 계산 기능이 아니라 Tenant별 Resource Accountability를 만드는 운영 기능입니다.

GPU Multi-Tenancy를 설계할 때 무엇을 확인해야 할까요?

Tenant Boundary

• Customer?
• Organization?
• Project?
• Team?

먼저 무엇을 Tenant로 정의할지 명확해야 합니다.

Identity

• IAM
• RBAC
• Service Account
• Credential

Compute / GPU

• Dedicated GPU?
• Dedicated Node?
• GPU VM?
• vGPU?
• MIG?

Network

• Tenant 간 Communication 차단
• Private Network
• Network Policy
• External Access

Storage / Data

• Volume
• Dataset
• Model
• Secret
• Backup

Policy

• Quota
• Priority
• Reservation
• Scheduling

Operations

• Provisioning
• Metering
• Monitoring / Observability
• Audit
• Lifecycle
• Recovery

GPU Multi-Tenancy만 있으면 GPU Cloud가 될까요?

아닙니다.

Multi-Tenancy는 Cloud Service의 중요한 Capability 중 하나입니다.

하지만 고객이 실제 GPU Cloud를 사용하려면:

• Service Catalog
• Ordering
• Provisioning
• Scheduling
• Network / Storage
• Metering
• Billing
• SLA
• API / Console
• Lifecycle Management

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

그래서 Multi-Tenancy는 전체 GPU Cloud Operating Model의 한 부분으로 봐야 합니다.

Thaki Cloud는 GPU Multi-Tenancy를 어떻게 볼까요?

Thaki NeoCloud OS의 Capability Model에는:

• User / Organization Management
• Multi-Tenancy
• IAM / Access Control
• GPU / Bare Metal Provisioning
• GPU Scheduling
• Quota / Policy
• Metering
• Billing
• SLA
• Observability
• Lifecycle Automation

이 포함됩니다.

Canonical Architecture는:

Customer Infrastructure → Thaki NeoCloud OS → Customer NeoCloud Service

입니다.

여기서 Multi-Tenancy는 여러 고객이나 Organization이 같은 Cloud Platform을 사용하면서도 각자의 Resource와 Policy를 독립적으로 운영할 수 있게 만드는 핵심 운영 Capability입니다.

정리하면

GPU Multi-Tenancy는 하나의 GPU를 여러 사용자가 나눠 쓰는 기능만을 의미하지 않습니다.

핵심은:

여러 Tenant가 하나의 Infrastructure를 사용하면서도 서로의 Resource, Access, Network, Storage, Policy와 Usage가 올바르게 분리되는 것

입니다.

이를 위해:

• Dedicated GPU / Node
• GPU VM / vGPU
• MIG
• Namespace / RBAC
• Quota
• Scheduling
• Network Policy
• Storage Isolation
• Metering

같은 여러 Building Block을 조합할 수 있습니다.

가장 중요한 한 문장은:

Multi-Tenancy의 핵심은 Resource Sharing이 아니라 Tenant Isolation과 Policy Enforcement입니다.

FAQ

GPU Multi-Tenancy는 반드시 한 GPU를 여러 고객이 공유하는 것인가요?

아닙니다. Tenant별 Dedicated GPU나 Dedicated Node를 제공해도 전체 Platform은 Multi-Tenant일 수 있습니다.

MIG가 있으면 GPU Multi-Tenancy가 완성되나요?

아닙니다. MIG는 GPU Resource Partitioning과 Isolation에 도움이 되는 Building Block입니다. User, Network, Storage, IAM, Quota, VM / Container Boundary와 Policy가 함께 필요합니다.

Kubernetes Namespace만으로 Tenant Isolation이 충분한가요?

보통 아닙니다. Namespace는 중요한 논리적 경계지만 RBAC, ResourceQuota, NetworkPolicy, Node / Workload Isolation과 Security Policy를 함께 고려해야 합니다.

Multi-Tenancy와 Multi-User는 같은가요?

아닙니다. Multi-User는 같은 Trust Boundary 안의 여러 사용자일 수 있지만 Multi-Tenant는 서로 다른 Customer / Organization Boundary를 분리해서 운영하는 의미가 더 강합니다.

GPU Multi-Tenancy에서 Metering이 왜 필요한가요?

Tenant별 Usage를 추적해야 Fairness, Capacity Planning, Showback 또는 Billing을 운영할 수 있기 때문입니다.