MIG(Multi-Instance GPU) 는 A100 · H100 · H200 같은 데이터센터 GPU 한 장을 여러 개의 독립 인스턴스로 물리 분할한다. 추론이나 소규모 학습은 A100 한 장의 성능을 다 쓰지 못하므로 통째로 할당하면 SM · 메모리 대역폭 · L2 캐시가 논다. MPS 나 time-slicing 과 달리 MIG 는 SM · L2 캐시 · 메모리 컨트롤러 · 대역폭까지 하드웨어로 파티셔닝하므로 noisy neighbor 가 없고 QoS 와 보안 격리가 보장된다.
반대로 MIG 가 맞지 않는 경우도 있다. NVLink · P2P · 풀 메모리 대역폭이 필요한 대규모 LLM 학습은 쪼개면 손해이고, 단일 워크로드가 이미 활용률 90% 이상이면 의미가 없다. MIG 인스턴스 사이에는 NVLink/P2P 가 동작하지 않는다.
A100 이 최대 7개인 것은 소프트웨어 제한이 아니라 다이가 7개의 GPU Instance Slice 로 구성돼 있기 때문이다. A30 은 4개, H100 · H200 은 7개이고 A10 이나 RTX 30/40 계열은 MIG 를 지원하지 않는다.
| 방식 | 격리 | 특징 |
|---|---|---|
| MIG | 하드웨어 수준(SM · 캐시 · 메모리 완전 격리) | 멀티테넌트 · 강한 격리가 필요할 때 |
| MPS | 약함. 여러 CUDA 프로세스가 SM 을 공간 공유 | 같은 팀 · 같은 워크로드의 처리량 극대화. CUDA_MPS_ACTIVE_THREAD_PERCENTAGE 로 상한 제어 |
| Time-Slicing | 없음. 메모리 공유(OOM 위험) | MIG 미지원 GPU 또는 작은 잡을 많이 띄울 때. k8s device plugin 의 timeSlicing |
| vGPU | VM 단위 | NVIDIA AI Enterprise/vGPU 라이선스. A100 은 MIG-backed vGPU 도 지원 |
A100 40GB 프로필은 1g.5gb, 2g.10gb, 3g.20gb, 4g.20gb, 7g.40gb, 80GB 는 1g.10gb, 2g.20gb, 3g.40gb, 4g.40gb, 7g.80gb 다.
MIG 는 GPU Instance(GI, 메모리 · SM 파티션) 와 그 안의 Compute Instance(CI, 실제 CUDA 워크로드 단위) 2단계로 구성된다. 컨테이너 하나에 MIG 하나를 할당하려면 GI 와 CI 가 1:1 이어야 하므로 -C 옵션으로 CI 를 함께 만든다.
# Persistence Mode — MIG 운영 시 필수. idle 에 드라이버가 언로드되면 설정이 풀린다
systemctl enable --now nvidia-persistenced
nvidia-smi -pm 1
# MIG 모드 활성화
nvidia-smi -i 0,1 -mig 1
nvidia-smi # MIG M. 컬럼이 Enabled
# 지원 프로파일 확인
nvidia-smi mig -lgip
# GI + CI 를 한 번에 생성 (A100 80GB 를 1g.10gb 7개로)
nvidia-smi mig -i 0 -cgi 1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb -C
nvidia-smi mig -i 1 -cgi 1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb -C
Warning: MIG mode is in pending enable state 가 나오면 GPU 를 잡고 있는 프로세스가 있는 것이다. nvidia-smi --gpu-reset 을 시도하고 안 되면 재부팅한다. 점유 프로세스는 fuser -v /dev/nvidia* 나 lsof /dev/nvidia* 로 확인한다.
.run 파일로 드라이버를 설치하면 nvidia-persistenced.service 가 없을 수 있다. NVIDIA 가 제공하는 샘플로 설치한다.
find / -name "nvidia-persistenced-init.tar.bz2" 2>/dev/null
cp /usr/share/doc/NVIDIA_GLX-1.0/samples/nvidia-persistenced-init.tar.bz2 /tmp/
cd /tmp && tar -xjf nvidia-persistenced-init.tar.bz2 && cd nvidia-persistenced-init
./install.sh
systemctl daemon-reload && systemctl enable --now nvidia-persistenced
하드웨어 분할(어떻게 자를 것인가) 과 Kubernetes strategy(어떤 리소스 이름으로 보일 것인가) 는 별개다.
| 항목 | single | mixed |
|---|---|---|
| 노드 내 MIG 크기 | 모두 동일 | 혼합 가능(1g + 2g + 3g) |
| 리소스 이름 | nvidia.com/gpu 로 통일 |
nvidia.com/mig-1g.10gb 등 프로파일별 |
| Pod 이 크기 선택 | 불가 | 가능 |
| 기존 YAML 호환 | 수정 없이 동작 | 리소스 이름을 바꿔야 함 |
흔한 오해가 하나 있다. single 전략에서도 MIG 인스턴스는 각각 별도로 스케줄링된다. MIG 가 켜지면 nvidia.com/gpu 의 카운트가 물리 GPU 수가 아니라 MIG 인스턴스 수가 되기 때문이다. A100 한 장을 1g.5gb 7개로 나누면 nvidia.com/gpu: 7 이 되고, Pod 이 1을 요청하면 슬라이스 하나만 가져가며 나머지 6개는 다른 Pod 이 쓴다. single 의 실제 제약은 "같은 노드의 모든 슬라이스 크기가 같아야 한다" 는 것뿐이다.
MIG Manager 는 노드의 nvidia.com/mig.config 라벨 변경을 감시해 파티션을 적용한다.
| 라벨 | 구분 | 값 예 |
|---|---|---|
nvidia.com/mig.config |
사용자가 설정(입력) | all-disabled, all-1g.10gb, all-3g.40gb, all-balanced |
nvidia.com/mig.capable |
자동(상태) | MIG 지원 GPU 유무 |
nvidia.com/mig.strategy |
자동 | single / mixed / none |
nvidia.com/mig.config.state |
자동 | pending / rebooting / success / failed |
nvidia.com/gpu.product |
자동 | NVIDIA-A100-80GB-PCIe-MIG-1g.10gb |
nvidia.com/gpu.count |
자동 | single 전략에서 MIG 인스턴스 수 |
하드웨어 분할이 끝나도 다음 컴포넌트가 없으면 클러스터는 GPU 를 보지 못한다. 실제로 이 사례에서 Cloudera AI 가 라벨을 인식하지 못한 원인이 이것이었다.
| 레이어 | 필요 |
|---|---|
| 컨테이너 런타임 | NVIDIA Container Toolkit. 없으면 컨테이너에서 GPU 접근 불가 |
| K8s 리소스 광고 | device plugin |
| 노드 라벨 | GPU Feature Discovery(GFD) |
| MIG 자동 관리 | MIG Manager |
GPU Operator 를 설치하면 container-toolkit · device-plugin · gpu-feature-discovery · mig-manager · dcgm-exporter · operator-validator 가 DaemonSet 으로 배포돼 이 체인을 한 번에 채운다. 드라이버가 이미 노드에 설치돼 있으면 Operator 의 드라이버 설치는 끄고 쓴다.
Cloudera ECS 는 GPU 노드에 nvidia.com/gpu=true:NoSchedule taint 를 걸어 GPU 워크로드 전용으로 예약하며, CAI 는 노드 안의 GPU 구성이 동질적일 것을 전제한다.