Article
GPU 한 장을 여러 GPU처럼
NVIDIA MIG 이해와 운영
GPU 한 장을 여러 워크로드가 안전하고 효율적으로 나눠 쓰려면 어떤 기술이 필요할까요? 먼저 MIG의 기본 개념과 동작 방식을 쉽게 이해한 뒤, 프로파일 구성과 운영 제약, 가상화·Kubernetes 적용, GPU 네트워크, 모니터링과 장애 분석, AI 기반 최적화까지 차근차근 살펴보겠습니다.
왜 GPU를 나눠서 쓰려는가?
GPU는 AI 인프라에서 가장 비싼 자원 중 하나입니다. 그런데 실제 현장에서는 모든 워크로드가 GPU 전체 성능을 항상 다 쓰는 것은 아닙니다. 추론, 임베딩, 개발·검증 환경은 일부 연산 자원과 일부 메모리만 필요할 때가 많습니다. 이 때문에 하나의 GPU를 여러 사용자가 나눠 쓰는 기술이 중요해졌습니다.
방식 | 핵심 개념 | 적합한 환경 |
PCI Passthrough | GPU 카드 전체를 VM이 독점 | 대규모 학습, 최대 성능 |
Time-Sliced vGPU | GPU 연산 시간을 여러 VM이 공유 | 버스티한 개발/VDI/경량 추론 |
MPS | 동일 GPU에서 여러 CUDA 프로세스가 연산 자원을 효율적으로 공유 | 동일 GPU의 다중 프로세스 |
MIG | GPU 내부 자원을 하드웨어 파티션으로 분할 | 멀티테넌트 추론, SLA·격리가 중요한 서비스 |
MIG를 가장 쉽게 이해하기
MIG(Multi-Instance GPU)는 하나의 GPU를 여러 개의 작은 독립 GPU처럼 나누어 쓰는 기술입니다. 단순히 메모리만 잘라 주는 것이 아니라, GPU 모델과 프로파일에 따라 연산 자원과 메모리 자원을 함께 구획합니다.
비유하자면 Passthrough는 큰 사무실 전체를 한 팀이 쓰는 방식이고, Time-Slicing은 하나의 회의실을 시간표에 따라 번갈아 쓰는 방식이며, MIG는 큰 사무실을 실제 칸막이로 나누고 팀마다 고정 공간을 배정하는 방식에 가깝습니다.
여기까지의 TL;DR ① MIG는 하드웨어 자원 분할로 격리와 예측성을 높입니다. ② 대신 Profile이 고정되고 재구성에 운영 중단이 필요할 수 있습니다. ③ 실제 운영에서는 GPU·VRAM·PCIe·NVLink·Fabric·Health와 VM/Pod 할당 관계를 함께 봐야 합니다. |
MIG Profile은 어떻게 이해하면 되는가?
MIG는 임의 크기로 자유롭게 자르는 방식이 아니라, GPU 모델별로 정해진 Profile을 사용합니다. 예를 들어 1g.10gb, 2g.20gb, 3g.40gb처럼 표현합니다. 어떤 Profile을 선택하느냐에 따라 개수와 용도가 달라집니다.
실제 배치는 완전히 자유로운 것이 아니라 지원되는 Placement 조합을 따릅니다. 또한 일부 GPU 세대는 Compute 7, Memory 8 구조처럼 비대칭적인 자원 구조를 가지므로, 잘게 쪼갤수록 일부 메모리가 남는 경우도 생깁니다.
실무에서 꼭 알아야 할 제약과 트레이드오프
MIG는 매우 유용하지만 만능 기술은 아닙니다. MIG 모드 활성화나 레이아웃 변경은 워크로드 중단, GPU reset 또는 노드 재기동이 필요한 작업이 될 수 있습니다. 또한 한 Instance가 놀고 있어도 다른 Instance가 그 자원을 즉시 빌려 쓰는 구조는 아닙니다.
MIG를 쓰지 않는 편이 나은 경우: ① 대규모 멀티 GPU 학습 ② 버스티한 워크로드 ③ 단일 MIG Profile 메모리에 들어가지 않는 큰 모델 |
항목 | 왜 중요한가 |
재구성 시 운영 중단 | MIG 모드/레이아웃 변경은 GPU reset 또는 노드 재시작, Pod 중단을 동반할 수 있습니다. |
유휴 자원 회수 한계 | 다른 MIG가 놀고 있어도 즉시 빌려 쓰지 못하므로, 버스티한 부하에는 Time-Slicing이 더 효율적일 수 있습니다. |
성능은 단순 비례가 아님 | Profile별 연산·메모리·캐시 구성 차이 때문에 성능을 단순 비례로 계산하면 안 됩니다. |
큰 모델 한계 | 모델/캐시가 단일 Profile 메모리에 들어가지 않으면 MIG보다 전체 GPU 또는 다른 방식이 적합합니다. |
지원 GPU와 라이선스에서 확인할 점
A100/A30, H100/H200, B200 등 데이터센터 GPU와 일부 RTX PRO Blackwell 제품이 MIG를 지원합니다. 반면 L40S, L4, A10, 일반 GeForce 계열은 MIG와 구분해야 합니다. L40S를 여러 VM이 함께 쓰는 구조는 일반적으로 MIG가 아니라 Time-Sliced vGPU로 이해하는 것이 맞습니다.
또한 MIG 자체는 GPU 기능이지만, VMware/KVM에서 MIG-backed vGPU로 VM에 제공하려면 NVIDIA vGPU for Compute 구성과 NVIDIA AI Enterprise 라이선스가 필요한 환경이 있습니다.
vCenter에서 MIG가 VM에 어떻게 할당되는가?
운영 관점에서 가장 중요한 것은 어느 물리 GPU의 어느 MIG가 어느 VM에 연결되어 있는지 추적하는 것입니다. 할당된 MIG뿐 아니라 미할당 MIG도 함께 보여야 실제 남은 Capacity를 판단할 수 있습니다.
VM 내부에서는 nvidia-smi와 NVML로 자신에게 할당된 GPU/vGPU/MIG 범위의 사용률과 VRAM 사용량을 확인할 수 있습니다. 반면 전체 인프라 관계는 vCenter/ESXi의 구성 정보와 NVIDIA 측 수집 데이터를 함께 조합해야 합니다.
Kubernetes까지 확장하면?
VM 위에 Kubernetes가 올라가면 Physical GPU → MIG → VM → Kubernetes Node → Pod로 관계가 확장됩니다. NVIDIA GPU Operator, Device Plugin, MIG Manager 등을 통해 MIG를 Kubernetes Resource로 노출할 수 있습니다. 이때 MIG 재구성은 Pod 중단과 노드 재시작 설계까지 함께 고려해야 합니다.
MIG와 GPU 네트워크는 역할이 다르다
MIG는 한 장을 나눠 쓰는 기술이고, NVLink·InfiniBand·RoCE는 여러 GPU 또는 여러 서버를 연결하는 기술입니다. 따라서 두 축을 같은 기능처럼 보면 안 됩니다.
특히 MIG는 CUDA 차원의 NVLink P2P를 전통적인 방식으로 쓰는 구조와는 목적이 다릅니다. 최신 NCCL에서는 여러 MIG Instance를 사용하는 실험적 지원이 추가됐지만 제약이 많고, 대규모 분산 학습 노드와 멀티테넌트 추론 노드는 일반적으로 설계 방향이 달라집니다.
GPU 모니터링에서 반드시 봐야 하는 항목
GPU 관제는 GPU Utilization 하나로 끝나지 않습니다. GPU/VRAM, NVLink, PCIe, 온도·팬, 전력, XID/ECC, MIG 할당 정보를 함께 봐야 병목과 장애 원인을 설명할 수 있습니다.
관점 | 주요 지표 | 운영 의미 |
GPU | GPU Utilization, SM/Tensor Activity | 병렬 연산 장치 사용률 확인 |
VRAM | Memory Allocation, Used/Total, Utilization | 모델·캐시·데이터가 차지하는 메모리와 실제 사용률 확인 |
NVLink | TX/RX, Bandwidth, Link State, Error | GPU 간 병렬 통신 상태 확인 |
PCIe Bus | TX/RX, Link Gen/Width, Replay/Error | CPU/Storage/NIC와 GPU 사이 데이터 이동 병목 확인 |
Temperature & Fan | GPU/Memory Temperature, Fan Speed, Throttling | 발열·냉각 및 Thermal Throttling 확인 |
Power | Power Draw, Power Limit, Energy | 실시간 전력과 Power Throttling 확인 |
XID / ECC | XID, Correctable/Uncorrectable ECC, Row Remapping | GPU·Driver·Memory 장애 징후 확인 |
MIG | Profile, Allocated/Free, VM Mapping, Utilization | 가상 GPU Capacity와 실제 활용도 확인 |
왜 수집 설계가 중요한가?
GPU 운영 데이터는 한 소스에서 다 보이지 않습니다. vCenter API는 '누가 무엇을 받았는가'를 잘 보여주지만 실제 사용률과 Health는 부족합니다. 반대로 NVML/DCGM은 실제 GPU 상태를 잘 보여주지만, VM/ESXi 인벤토리 관계는 알기 어렵습니다. Fabric은 또 별도의 수집 체계가 필요합니다.
수집 소스 | 잘 보는 것 | 보완이 필요한 것 |
vCenter API | ESXi·VM·GPU/vGPU 구성 관계와 인벤토리 | 실제 GPU/VRAM 사용량, Health 상세 |
NVML / nvidia-smi | GPU·MIG 사용량, VRAM, Process, 일부 상태 | 가상화 인벤토리와 상위 오브젝트 관계 |
DCGM / DCGM Exporter | GPU Performance, Health, ECC, NVLink, Kubernetes 메트릭 | vCenter 기반 가상화 매핑 정보 |
Fabric Telemetry | InfiniBand/RoCE Port, Bandwidth, Congestion, Error | GPU 내부 자원과의 직접 매핑 |
장애 분석은 어떻게 이어지는가?
장애 분석에서는 단순 알람보다 문맥이 중요합니다. 예를 들어 GPU Utilization이 떨어졌다고 해서 반드시 GPU 자체가 문제인 것은 아닙니다. PCIe 병목일 수도 있고, NVLink 에러일 수도 있으며, Fabric 혼잡 때문에 처리량이 떨어질 수도 있습니다. 또한 XID 31/48/74/79, 그리고 XID 94/95 같은 최신 데이터센터 GPU 관련 오류는 장애 원인 분석에서 중요한 단서가 됩니다.
모니터링을 넘어 AI 이상탐지와 최적화로
최종 목표는 현재 몇 % 쓰고 있다를 보여주는 데 그치지 않습니다. GPU, MIG, VM, Fabric의 시계열 데이터를 묶으면 이상징후 탐지, 병목 원인 분석, 수요 예측, 장애 예방과 FinOps까지 확장할 수 있습니다.
확장 방향 | 의미 |
Capacity Planning | GPU가 정말 부족한지, 유휴/과다할당인지 구분하고 향후 수요를 예측 |
Predictive Health | 온도·전력·ECC·XID 패턴에서 장애 전 징후를 감지 |
GPU FinOps | 미사용 GPU, 저활용 MIG, 과다할당 VM을 찾아 재배치·회수 |
통합 대시보드에서는 무엇을 보여줘야 하는가?
대시보드는 Capacity → Allocation → Performance → Fabric → Health → AI Insight가 연결되는 구조가 적합합니다. 상단에는 전체 GPU/MIG, 할당·미할당, 평균 GPU/VRAM 사용률, Alarm을 보여주고, 중앙에는 vCenter → ESXi → VM ↔ MIG → GPU → Physical Server 관계를 직접 표현합니다.
VM에는 OS, 할당량과 실제 사용량을, GPU에는 Utilization·VRAM·Temperature·Power·NVLink를, MIG에는 Profile·할당/미할당·VM Mapping을 표시하면 운영자가 자원 구조와 사용량을 한 번에 이해할 수 있습니다.
<Polestar 10 GPU 대시보드 예시>
마무리
MIG는 GPU 한 장을 여러 조각으로 나누는 것 이상의 기술입니다. 하지만 모든 워크로드에 정답은 아닙니다. 워크로드 특성에 따라 Passthrough·Time-Slicing·MPS·MIG를 선택하고, GPU·VRAM·PCIe·NVLink·InfiniBand/RoCE·XID/ECC를 하나의 Resource Topology로 연결해 보는 것이 중요합니다.
그리고 그 데이터를 이상탐지·예측·최적화로 확장할 때 GPU 모니터링은 단순한 모니터링을 넘어 AI 인프라 운영 플랫폼으로 발전할 수 있습니다.
참 고
• NVIDIA Multi-Instance GPU User Guide — MIG 개념, 지원 GPU/Profile 및 배포 고려사항
• NVIDIA AI Enterprise vGPU for Compute — Time-Sliced vGPU, MIG-backed vGPU 및 라이선스
• NVIDIA NCCL User Guide — MIG Instance 사용의 최신 실험적 지원과 NVLink 관련 제약
작성자 : DW Jang | 엔키아 연구소
