[MLOps] Kubernetes GPU 구성요소와 MIG 운영 구조 정리

1. GPU 연산이 실행되는 흐름

PyTorch 같은 애플리케이션이 GPU를 사용하는 기본 흐름은 다음과 같습니다.

PyTorch
→ CUDA Runtime·라이브러리
→ NVIDIA Driver
→ 물리 GPU

컨테이너 안에 GPU가 들어가지는 않습니다. 호스트 GPU를 컨테이너에서 사용하도록 장치와 드라이버 라이브러리를 연결합니다.

컨테이너 시작
→ NVIDIA Container Toolkit이 GPU 접근 경로 구성
→ 컨테이너 실행
→ CUDA 요청이 NVIDIA Driver를 거쳐 GPU로 전달

Container Toolkit은 실행 중인 연산을 매번 전달하는 프록시가 아닙니다. 컨테이너가 시작될 때 GPU 장치, 드라이버 라이브러리, 환경 변수, CDI 설정 등을 준비합니다.

주요 구성요소

nvidia-smi에 표시되는 CUDA Version은 설치된 CUDA Toolkit 버전이 아닙니다. 현재 Driver가 지원하는 최대 CUDA 버전을 뜻합니다.

호스트에서 nvidia-smi 성공
→ 호스트 Driver와 GPU 연결 확인

컨테이너에서 nvidia-smi 성공
→ GPU 장치와 Driver가 컨테이너에 노출됐는지 확인

torch.cuda.is_available() == True
→ PyTorch가 현재 CUDA 장치를 사용할 수 있다고 판단하는지 확인

CUDA Tensor 연산 성공
→ 메모리 할당과 CUDA Kernel 실행 경로까지 확인

torch.cuda.is_available()만으로 실제 CUDA Kernel 실행이나 NCCL 같은 개별 라이브러리까지 검증할 수는 없습니다. 간단한 Tensor 연산을 실행해 봐야 연산 경로까지 확인됩니다.

2. Kubernetes가 GPU를 발견하고 할당하는 과정

Scheduler가 GPU 노드에 접속해 nvidia-smi를 실행하지는 않습니다. NVIDIA Device Plugin이 GPU를 발견해 kubelet에 등록합니다.

NVIDIA Device Plugin
→ GPU 장치와 상태를 kubelet에 보고
→ kubelet이 Node Capacity·Allocatable 갱신
→ Scheduler가 API Server의 자원 정보를 보고 노드 선택

Pod에서는 GPU를 확장 자원으로 요청합니다.

resources:
  limits:
    nvidia.com/gpu: 1

기본 방식에서 nvidia.com/gpu: 1은 VRAM 1GB가 아니라 GPU 장치 한 개를 의미합니다. Pod가 A100 80GB의 VRAM을 2GB만 사용하더라도 Kubernetes가 남은 78GB를 다른 Pod에 자동으로 할당하지 않습니다.

실제 할당 과정

Scheduler
→ GPU가 남아 있는 노드 선택

kubelet Device Manager
→ 노드 안에서 사용할 실제 GPU를 최종 선택

NVIDIA Device Plugin
→ 선택된 장치를 컨테이너에 노출할 설정 반환

containerd·Container Toolkit
→ 설정을 적용해 컨테이너 실행

Scheduler는 일반적으로 개별 GPU UUID까지 선택하지 않고 노드만 선택합니다. 실제 장치 ID는 kubelet Device Manager가 최종 선택합니다. Device Plugin은 선호 장치 목록(선택 사항)을 제안하고 선택이 끝나면 컨테이너에 필요한 장치 노드와 환경 변수, 마운트, CDI 장치 이름 등을 반환합니다.

3. NVIDIA GPU Operator

GPU Operator는 Kubernetes GPU 노드에 필요한 NVIDIA 소프트웨어 스택을 배포하고 관리합니다. 아래 그림은 실제 Kubernetes 객체의 소유 관계가 아니라 Operator가 관리하는 구성요소를 묶어 나타낸 것입니다.

NVIDIA GPU Operator
└─ ClusterPolicy
   ├─ NVIDIA Driver
   ├─ NVIDIA Container Toolkit
   ├─ NVIDIA Device Plugin
   ├─ GPU Feature Discovery
   ├─ MIG Manager
   ├─ DCGM·DCGM Exporter
   └─ Validator

GPU Operator 자체는 Helm Chart로 설치할 수 있습니다. Helm이 각 구성요소의 기능을 직접 수행하지는 않습니다.

Helm
→ GPU Operator 설치·업그레이드

GPU Operator
→ ClusterPolicy에 따라 NVIDIA 구성요소 배포·관리

각 NVIDIA 구성요소
→ Driver 설치, 장치 등록, MIG 구성, 모니터링 수행

호스트에 Driver가 이미 설치되어 있다면 Operator의 Driver 관리를 끄고 기존 Driver를 사용할 수도 있습니다.

4. MIG Manager와 Device Plugin

MIG는 하나의 물리 GPU를 독립적으로 할당할 수 있는 여러 인스턴스로 나눕니다. Time-slicing과 달리 SM, 메모리 용량, 캐시, 메모리 대역폭 등을 하드웨어 수준에서 격리하지만 물리 GPU 자체는 공유합니다.

NVIDIA GPU Operator 구성에서는 Kubernetes Scheduler나 Device Plugin이 MIG 인스턴스를 직접 생성하지 않습니다.

Node cordon·사용자 GPU 워크로드 종료
→ 필요한 경우 MIG Mode 활성화와 Node 재부팅
→ Node label·MIG ConfigMap에 원하는 구성 선언
→ MIG Manager가 구성 확인
→ NVIDIA Driver를 통해 실제 GPU 재구성
→ Device Plugin이 생성된 MIG 장치 발견
→ Device Plugin이 변경된 장치 목록을 kubelet에 보고
→ kubelet이 Node Capacity·Allocatable 갱신
→ Scheduler가 해당 자원을 요청한 Pod 배치

MIG 재구성은 실행 중인 인스턴스를 더 작은 프로파일로 바로 쪼개는 작업이 아닙니다. 사용자 GPU 워크로드를 먼저 종료하거나 노드를 drain해야 하며 처음 MIG Mode를 활성화할 때는 환경에 따라 재부팅이 필요할 수 있습니다.

GPU Operator 환경에서는 보통 MIG Manager의 코드를 직접 수정하지 않습니다. Node label과 ConfigMap으로 원하는 상태를 선언합니다.

Device Plugin의 MIG_STRATEGY는 GPU를 물리적으로 분할하는 옵션이 아닙니다. 이미 존재하는 MIG 장치를 Kubernetes에 어떻게 노출할지 결정합니다.

• single: Node 안의 GPU가 동일한 MIG 프로파일로 구성됐다는 전제에서 모든 MIG 장치를 nvidia.com/gpu로 노출
• mixed: nvidia.com/mig-1g.10gb처럼 각 MIG 프로파일을 서로 다른 확장 자원으로 노출

5. A100 80GB의 MIG 프로파일

A100에는 108개의 물리 SM이 있지만 MIG에서는 최대 7개의 GPU slice를 사용합니다. 프로파일 이름의 g는 SM 개수가 아니라 GPU slice 개수를 뜻합니다.

+me는 media extension을 뜻합니다. 1g.10gb+me는 같은 크기의 1g.10gb에 NVDEC, JPEG, OFA를 더한 프로파일이며 GPU 한 장에 하나만 만들 수 있습니다. 1g.10gb+me는 R470 계열부터, 1g.20gb는 R525 계열부터 지원됩니다.

GPU slice의 합이 맞더라도 프로파일을 자유롭게 조합할 수는 없습니다. Memory slice와 하드웨어 배치 조건도 만족해야 합니다.

가능(R510 이상): 4g.40gb + 3g.40gb
GPU slice:    4 + 3 = 7/7
Memory slice: 4 + 4 = 8/8

불가능: 3g.40gb + 3g.40gb + 1g.10gb
GPU slice:    3 + 3 + 1 = 7/7
Memory slice: 4 + 4 + 1 = 9/8

작은 추론 모델이 많다면 1g.10gb 인스턴스 7개를 구성할 수 있습니다. 이때 프로파일 이름을 기준으로 한 명목 메모리의 합은 70GB이고 노출되는 SM은 98개이므로 일부 물리 자원이 남습니다.

워크로드 크기가 다양하다면 아래 구성도 검토할 수 있습니다.

3g.40gb × 1
2g.20gb × 1
1g.10gb × 2
──────────────
총 4개 인스턴스
GPU slice 7/7
VRAM 80GB

6. GPU가 비어 있는데도 Pod가 Pending되는 이유

이 절의 예시는 각 프로파일이 별도 자원 이름으로 노출되는 mixed 전략을 기준으로 합니다. kubectl describe node의 내용을 단순화하면 아래와 같습니다.

nvidia.com/mig-3g.40gb
Capacity:    2
Allocatable: 2
Pod requests: 0

여기서 Allocatable: 2는 현재 남은 장치가 두 개라는 뜻이 아니라 일반 Pod에 할당할 수 있는 총량입니다. Pod requests: 0도 종료되지 않은 Pod가 이 자원을 요청한 합계가 0이라는 뜻이며 GPU의 실제 사용률까지 보여주지는 않습니다.

resources:
  limits:
    nvidia.com/mig-1g.10gb: 1

현재 노드에는 3g.40gb를 요청하는 Pod를 두 개까지 배치할 수 있습니다. 그러나 다음 Pod가 요청한 자원은 1g.10gb입니다. 3g.40gb와 1g.10gb는 Kubernetes에서 서로 다른 확장 자원이므로, 비어 있는 3g.40gb가 있어도 Pod는 Pending됩니다. Scheduler는 비어 있는 3g.40gb를 자동으로 나누어 1g.10gb로 만들지 않습니다.

비어 있는 3g.40gb 장치
≠
사용 가능한 1g.10gb 장치

Priority와 Preemption도 없는 자원 종류를 만들어내지는 못합니다. 낮은 우선순위 Pod를 제거해도 1g.10gb가 새로 생기지 않습니다.

필요한 프로파일이 없다면 노드를 cordon하고 GPU 워크로드를 정리한 뒤 MIG 구성을 변경해야 합니다. Device Plugin은 변경된 장치 목록을 ListAndWatch로 kubelet에 다시 보고합니다. Device Plugin 자체가 재시작됐다면 먼저 kubelet에 재등록한 뒤 장치 목록을 보고하며 Node 자원 정보가 갱신되어야 새 프로파일을 스케줄링할 수 있습니다.

7. 핵심 정리

NVIDIA Driver
→ 실제 GPU 제어

NVIDIA Container Toolkit
→ 컨테이너의 GPU 접근 경로 구성

NVIDIA Device Plugin
→ GPU와 MIG 장치를 Kubernetes 자원으로 등록

NVIDIA GPU Operator
→ NVIDIA 구성요소의 배포와 수명주기 관리

MIG Manager
→ Driver를 통해 실제 MIG 분할 형태 관리

Kubernetes Scheduler
→ 등록된 자원 종류와 개수를 기준으로 노드 선택

MIG 환경에서 GPU가 비어 있는데 Pod가 Pending된다면 GPU 사용률만 확인해서는 안 됩니다. Pod가 요청한 MIG 프로파일이 Node에 자원으로 등록되어 있는지 먼저 확인해야 합니다.

참고 자료

• NVIDIA Container Toolkit Architecture
• Kubernetes Device Plugins
• Kubernetes GPU Scheduling
• NVIDIA GPU Operator
• NVIDIA GPU Operator with MIG
• NVIDIA MIG Supported Profiles
• NVIDIA CUDA Driver and Toolkit Compatibility
• PyTorch
• 토스증권의 GPU 가상화(MIG) 도입기