GPU Virtualization: Passthrough, vGPU, and MIG

Summary

가상 머신에서 GPU를 사용하는 방법은 크게 GPU Passthrough, vGPU, MIG로 나눠 생각할 수 있다. 세 방식은 모두 가상화된 워크로드에 GPU 자원을 제공하지만, 무엇을 나누고 누가 장치를 관리하는지가 다르다.

이 차이를 이해하려면 먼저 GPU가 Linux에서 PCIe 장치로 보인다는 사실과, 장치 소유권을 VM에 넘길 때 사용하는 VFIO와 IOMMU를 이해해야 한다.

Context

물리 GPU는 비싸고 수량이 제한되어 있다. 하나의 큰 학습 작업은 GPU 전체를 필요로 할 수 있지만, 작은 추론 서버나 VDI 사용자는 GPU의 일부만 사용하기도 한다.

따라서 GPU 인프라를 설계할 때는 다음 질문에 답해야 한다.

• 한 워크로드가 GPU 전체를 독점해야 하는가?
• 여러 VM이 같은 GPU를 동시에 사용해야 하는가?
• 메모리와 연산 자원의 격리가 어느 정도 필요한가?
• 최대 성능과 자원 활용률 중 무엇이 더 중요한가?
• 사용하는 GPU, 하이퍼바이저, 드라이버, 라이선스가 원하는 방식을 지원하는가?

GPU Passthrough, vGPU, MIG는 서로의 완전한 대체재가 아니다. 워크로드 크기와 운영 요구사항에 따라 선택하거나 조합하는 기술이다.

Problem and Questions

GPU Passthrough와 vGPU는 어떻게 다르며, MIG는 어디에 위치하는가? VFIO는 NVIDIA 드라이버의 기능인가, 아니면 Linux가 제공하는 기능인가? OpenStack은 이 GPU 자원들을 어떻게 찾아 VM에 할당하는가?

Explanation

Start with PCIe

GPU는 CPU와 별도로 동작하는 가속기이지만, Linux 입장에서는 NIC, NVMe SSD, RAID 컨트롤러와 같은 PCIe 장치다. PCIe는 CPU와 주변 장치를 연결하는 표준 인터페이스다.

CPU / Memory
    │
PCIe Fabric
    ├── GPU
    ├── NIC
    └── NVMe SSD

Linux는 PCIe 장치를 도메인:버스:디바이스.함수 형식의 주소로 식별한다.

0000:81:00.0
│    │  │  └── Function
│    │  └───── Device
│    └──────── Bus
└───────────── Domain

GPU는 그래픽 기능과 오디오 기능처럼 여러 PCI Function으로 나타날 수 있다. Passthrough를 구성할 때는 GPU 본체뿐 아니라 같은 장치에 속한 다른 Function과 IOMMU Group도 함께 확인해야 한다.

Device Ownership and Drivers

하나의 PCI Function은 한 시점에 하나의 드라이버가 소유한다. 일반적인 호스트에서는 NVIDIA 또는 AMD 드라이버가 GPU를 제어한다.

Physical GPU
    │
Vendor Driver on Host
    │
CUDA / Graphics / Applications

GPU를 VM에 Passthrough하려면 호스트가 그 GPU를 직접 사용하지 않아야 한다. 호스트의 벤더 드라이버 대신 vfio-pci가 장치를 소유하고, QEMU가 VFIO를 통해 VM에 장치를 노출한다. VM 안에서는 다시 일반 GPU 드라이버를 설치한다.

Physical GPU
    │
vfio-pci on Host
    │
QEMU / KVM
    │
Guest VM
    │
NVIDIA or AMD Driver
    │
CUDA / AI Application

즉, VFIO와 GPU 드라이버의 역할은 다르다.

VFIO and IOMMU

VFIO는 NVIDIA가 제공하는 기능이 아니라 Linux 커널의 범용 장치 접근 프레임워크다. 이름은 Virtual Function I/O이지만 GPU 전용 기술은 아니며, GPU, NIC, NVMe SSD 같은 다양한 PCIe 장치를 VM에 직접 할당할 때 사용할 수 있다.

PCIe 장치는 DMA를 이용해 CPU를 거치지 않고 시스템 메모리를 읽고 쓸 수 있다. 성능에는 유리하지만, VM에 할당한 장치가 호스트나 다른 VM의 메모리에 접근하면 보안 문제가 된다.

IOMMU는 장치가 접근할 수 있는 메모리 범위를 변환하고 제한한다.

GPU DMA Request
      │
    IOMMU
      │
      ├── Allowed Guest Memory → Access
      └── Other Memory         → Block

VFIO는 이 IOMMU 보호 환경을 이용해 장치의 직접 접근을 제공한다. 시스템 토폴로지상 완전히 분리할 수 있는 장치 집합을 IOMMU Group이라고 하며, VFIO에서는 이 Group이 장치 소유권과 격리의 기본 단위가 된다.

따라서 Passthrough를 구성할 때는 장치 주소만 보는 것이 아니라 다음을 함께 확인해야 한다.

• BIOS에서 Intel VT-d 또는 AMD-Vi가 활성화되어 있는가?
• Linux에서 IOMMU가 활성화되어 있는가?
• GPU와 관련 Function이 어떤 IOMMU Group에 속하는가?
• Group 안의 다른 장치를 호스트가 사용하고 있지는 않은가?
• GPU와 CPU의 NUMA 위치가 워크로드 배치에 적절한가?

GPU Passthrough

GPU Passthrough는 하나의 물리 GPU 전체를 하나의 VM에 할당하는 방식이다. 게스트는 실제 PCIe GPU가 장착된 것처럼 장치를 인식하고 벤더 드라이버를 직접 사용한다.

Physical GPU
    │ exclusive assignment
    ▼
VM
├── Full GPU memory
├── GPU compute resources
└── Guest GPU driver

장점은 구조가 비교적 직접적이고, GPU 전체 자원과 기능을 한 VM이 사용한다는 점이다. 가상화 계층의 개입이 적어 네이티브에 가까운 성능을 기대할 수 있지만, 실제 성능과 지원 기능은 하드웨어와 하이퍼바이저 구성에 따라 달라진다.

단점은 공유가 어렵다는 것이다. VM이 GPU를 조금만 사용하더라도 다른 VM은 그 GPU를 사용할 수 없다. 또한 장치 리셋, IOMMU Group, NUMA 배치, 라이브 마이그레이션 같은 운영 제약을 함께 고려해야 한다.

주요 사용 사례는 다음과 같다.

• 큰 모델 학습처럼 GPU 전체 메모리와 대역폭이 필요한 작업
• HPC 또는 전용 연구 환경
• 특정 VM에 GPU를 장기간 전용 할당하는 환경
• 공유율보다 단일 워크로드 성능과 예측 가능성이 중요한 환경

vGPU

vGPU는 하나의 물리 GPU에서 여러 가상 GPU 장치를 만들어 여러 VM에 제공하는 방식이다. 각 VM은 정해진 vGPU 프로파일에 따라 메모리와 연산 자원을 할당받는다.

NVIDIA 환경을 단순화하면 다음과 같은 구조로 볼 수 있다.

Physical GPU
    │
NVIDIA vGPU Manager on Host
    │
    ├── vGPU Profile A → VM 1 → Guest vGPU Driver
    ├── vGPU Profile B → VM 2 → Guest vGPU Driver
    └── vGPU Profile C → VM 3 → Guest vGPU Driver

호스트의 vGPU 소프트웨어는 가상 GPU 장치를 만들고 물리 GPU 자원을 관리한다. 게스트에는 프로파일과 호스트 소프트웨어에 맞는 vGPU 드라이버가 필요하다. 구현 세부 사항은 GPU 세대와 벤더 스택에 따라 mediated device 또는 SR-IOV 기반 Virtual Function을 사용할 수 있다.

vGPU의 장점은 자원 활용률이다. GPU 전체가 필요하지 않은 여러 VM이 하나의 물리 GPU를 동시에 사용할 수 있다. VDI, 여러 소규모 추론 서비스, 공유형 개발 환경처럼 사용자 수가 많고 개별 사용량이 작은 환경에 적합하다.

대신 다음 요소가 운영 복잡도를 높인다.

• 지원되는 GPU와 하이퍼바이저 조합
• 호스트 vGPU Manager와 게스트 드라이버의 호환성
• vGPU 프로파일별 메모리와 기능 차이
• 벤더 라이선스
• 동시 사용 워크로드 사이의 경합
• 마이그레이션과 장애 복구 지원 범위

vGPU가 항상 Passthrough보다 느리다고 단정할 수는 없다. 성능 차이는 프로파일, 동시 사용자 수, 워크로드 특성, 드라이버와 GPU 모델에 따라 달라진다. 핵심 선택 기준은 단순한 성능 수치가 아니라 전용 자원과 공유 자원 중 무엇이 필요한가다.

MIG

MIG(Multi-Instance GPU)는 지원되는 NVIDIA GPU의 연산과 메모리 자원을 여러 GPU Instance로 분할하는 기능이다. vGPU가 소프트웨어 스택을 통해 여러 VM에 가상 GPU를 제공하는 개념이라면, MIG는 GPU 내부 자원을 하드웨어 단위로 나누어 더 강한 격리와 예측 가능한 QoS를 제공하는 데 초점이 있다.

MIG-capable GPU
├── GPU Instance 1
│   ├── Compute slices
│   ├── Memory slices
│   └── L2 cache / memory path
├── GPU Instance 2
└── GPU Instance 3

MIG Instance는 VM뿐 아니라 베어메탈 프로세스나 컨테이너에도 제공할 수 있다. 지원되는 환경에서는 MIG Instance를 Passthrough하거나 vGPU 구성과 결합할 수도 있다. 따라서 MIG와 vGPU는 서로 완전히 배타적인 개념이 아니다.

MIG를 사용할 때는 다음을 확인해야 한다.

• 해당 GPU가 MIG를 지원하는가?
• 필요한 MIG 프로파일이 충분한 메모리와 연산 자원을 제공하는가?
• 그래픽, P2P, 디버깅, 프로파일링 등 필요한 기능이 해당 구성에서 지원되는가?
• 오케스트레이터가 MIG Instance를 개별 자원으로 인식하고 스케줄링할 수 있는가?

MIG는 특히 하나의 대형 GPU에서 여러 CUDA 추론 작업이나 중간 규모 학습 작업을 격리해 실행할 때 유용하다. 다만 모든 NVIDIA GPU가 지원하는 것은 아니며, 세대와 모델별 프로파일 및 제약을 확인해야 한다.

Comparison

Passthrough, vGPU, MIG의 관계는 다음처럼 기억할 수 있다.

• Passthrough: GPU 한 대를 한 사용자에게 통째로 제공한다.
• vGPU: 관리 소프트웨어가 GPU 자원을 여러 VM에 가상 장치로 제공한다.
• MIG: 지원되는 GPU 내부를 여러 개의 격리된 GPU Instance로 나눈다.

OpenStack Integration

OpenStack Nova는 GPU를 직접 제어하는 드라이버가 아니다. Nova는 사용 가능한 PCI 또는 vGPU 자원을 추적하고, 요청한 Flavor에 맞는 Compute Node를 선택한 뒤 libvirt/QEMU가 장치를 VM에 연결하도록 조정한다.

GPU Passthrough의 전체 흐름은 다음과 같다.

Flavor requests PCI alias
        │
Nova Scheduler selects a host
        │
nova-compute / libvirt
        │
QEMU / VFIO
        │
Physical GPU assigned to VM
        │
Guest GPU Driver

운영자는 Compute Node에서 IOMMU와 Passthrough 대상 장치를 준비하고, Nova의 pci.device_spec과 pci.alias로 장치를 등록한다. 사용자는 Flavor의 pci_passthrough:alias를 통해 해당 장치를 요청한다. 물리 GPU 전체를 할당하므로 같은 GPU를 다른 VM과 공유할 수 없다.

vGPU의 흐름은 다음과 같다.

Physical GPU exposes vGPU types
        │
Nova reports VGPU inventory to Placement
        │
Flavor requests resources:VGPU=1
        │
Nova Scheduler selects available inventory
        │
libvirt attaches the virtual GPU to the VM

OpenStack의 구체적인 설정은 Nova 릴리스, libvirt/QEMU 버전, GPU 세대, vGPU 드라이버 방식에 따라 달라진다. 최신 GPU에서는 SR-IOV Virtual Function과 vGPU 타입 설정이 함께 필요할 수 있으므로 운영 환경의 OpenStack 및 벤더 문서를 기준으로 구성해야 한다.

MIG를 OpenStack에 제공하는 방식도 하나로 고정되어 있지 않다. MIG Instance를 Passthrough하거나, 벤더 vGPU 스택을 통해 VM에 노출하거나, 별도의 자원 모델로 관리할 수 있다. 설계할 때는 Nova가 어떤 단위를 자원으로 추적하는지 먼저 확인해야 한다.

Inspecting a Linux Host

다음 명령은 장치를 변경하지 않고 현재 상태를 학습할 때 사용할 수 있다.

PCIe GPU와 장치 ID를 확인한다.

lspci -nn | grep -Ei 'VGA|3D|NVIDIA|AMD'

특정 장치에 연결된 커널 드라이버를 확인한다.

lspci -nnk -s 81:00.0

장치의 IOMMU Group을 확인한다.

readlink /sys/bus/pci/devices/0000:81:00.0/iommu_group

시스템 전체의 IOMMU Group과 장치를 확인한다.

find /sys/kernel/iommu_groups/ -type l

NVIDIA GPU와 MIG 장치를 확인한다.

nvidia-smi -L
nvidia-smi mig -lgip

libvirt가 인식하는 PCI 장치를 확인한다.

virsh nodedev-list --cap pci

드라이버 unbind, vfio-pci bind, MIG 모드 변경은 실행 중인 GPU와 호스트 화면, 다른 워크로드에 영향을 줄 수 있다. 학습 단계에서는 먼저 읽기 전용 명령으로 장치 주소, 드라이버, IOMMU Group을 확인하는 것이 안전하다.

Decision Guide

다음 순서로 질문하면 방식을 선택하기 쉽다.

1. 한 VM이 GPU 전체 메모리와 연산 자원을 사용해야 하는가?
   • 그렇다면 Passthrough를 먼저 검토한다.
2. 여러 VM이 같은 GPU를 동시에 사용해야 하는가?
   • 그렇다면 vGPU 또는 MIG 기반 구성을 검토한다.
3. 워크로드 사이에 강한 메모리·연산 격리와 예측 가능한 성능이 필요한가?
   • MIG 지원 GPU라면 MIG 프로파일이 적합한지 확인한다.
4. VDI나 여러 소규모 VM처럼 유연한 가상 GPU 프로파일이 필요한가?
   • vGPU의 GPU·하이퍼바이저·라이선스 지원을 확인한다.
5. 라이브 마이그레이션, NUMA 최적화, 장애 복구가 중요한가?
   • 선택한 방식과 현재 소프트웨어 버전이 해당 기능을 지원하는지 별도로 검증한다.

Common Misconceptions

• VFIO는 NVIDIA 드라이버의 기능이다.
  • 아니다. VFIO는 Linux 커널의 범용 프레임워크이고 vfio-pci는 PCI 장치를 다룬다.
• VFIO는 GPU에만 사용한다.
  • 아니다. NIC, NVMe SSD, USB 컨트롤러 같은 다른 PCIe 장치도 대상이 될 수 있다.
• vGPU와 MIG는 같은 기술이다.
  • 아니다. vGPU는 가상 GPU를 VM에 제공하는 소프트웨어 스택이고, MIG는 지원 GPU의 자원을 하드웨어 단위로 분할한다.
• MIG를 켜면 자동으로 VM에서 사용할 수 있다.
  • 아니다. 생성한 Instance를 하이퍼바이저나 오케스트레이터가 인식하고 할당하도록 추가 구성이 필요하다.
• Passthrough는 항상 정확히 네이티브 성능과 같다.
  • 아니다. 가상화 오버헤드는 작을 수 있지만 NUMA, PCIe 토폴로지, CPU·메모리 배치, 드라이버 구성에 따라 결과가 달라진다.
• vGPU는 항상 Passthrough보다 느리다.
  • 단순 비교하기 어렵다. 워크로드, 프로파일, 동시 사용자 수, GPU 세대와 드라이버가 성능에 영향을 준다.

Learning Roadmap

나중에 실습까지 이어가려면 다음 순서로 학습하는 것이 좋다.

1. PCIe 기초: BDF 주소, Vendor ID, Device ID, PCI Function
2. Linux 드라이버 모델: 장치와 드라이버의 bind/unbind 관계
3. IOMMU: DMA 격리, 주소 변환, IOMMU Group
4. VFIO: VFIO Core와 vfio-pci, QEMU가 장치에 접근하는 방식
5. KVM/QEMU/libvirt: VM 생성과 PCI Host Device 연결
6. GPU Passthrough: 전용 GPU 할당, NUMA와 장치 리셋 문제
7. vGPU: 프로파일, 호스트 Manager, 게스트 드라이버, 라이선스
8. MIG: GPU Instance와 Compute Instance, 프로파일과 격리
9. OpenStack Nova: PCI inventory, alias, Flavor, Placement, 스케줄링

이 순서의 핵심은 GPU부터 시작하지 않는 것이다. 먼저 GPU가 PCIe 장치이고, Linux에서 특정 드라이버가 그 장치를 소유한다는 점을 이해하면 VFIO, Passthrough, vGPU, MIG의 차이가 자연스럽게 연결된다.

Limitations and Operational Checks

• 모든 GPU가 vGPU 또는 MIG를 지원하지 않는다.
• vGPU는 GPU, 하이퍼바이저, 호스트 Manager, 게스트 드라이버의 지원 조합과 라이선스를 확인해야 한다.
• Passthrough 장치는 일반 가상 장치보다 라이브 마이그레이션과 장치 리셋이 까다롭다.
• IOMMU Group이 원하는 장치 단위로 분리되지 않으면 안전한 Passthrough가 어려울 수 있다.
• GPU와 CPU가 서로 다른 NUMA Node에 있으면 메모리 접근 비용이 증가할 수 있다.
• MIG 프로파일은 GPU 모델과 드라이버 버전에 따라 다르며 일부 그래픽·P2P·프로파일링 기능에 제약이 있을 수 있다.
• OpenStack의 지원 범위와 설정 방식은 릴리스에 따라 바뀌므로 배포 버전의 문서를 확인해야 한다.

Key Takeaways

• GPU는 Linux에서 PCIe 장치로 보이며, Passthrough는 이 장치의 소유권을 호스트에서 VM으로 넘기는 과정이다.
• VFIO는 NVIDIA 기능이 아니라 Linux 커널의 범용 장치 접근 프레임워크다.
• IOMMU는 장치의 DMA 접근 범위를 제한하고, IOMMU Group은 VFIO 장치 격리와 소유권의 기본 단위가 된다.
• GPU Passthrough는 하나의 VM에 물리 GPU 전체를 제공하므로 전용 성능에는 유리하지만 공유 효율은 낮다.
• vGPU는 하나의 물리 GPU를 여러 VM이 사용할 수 있게 해 자원 활용률을 높이지만 호환성, 경합, 라이선스를 고려해야 한다.
• MIG는 지원되는 NVIDIA GPU의 연산과 메모리 자원을 하드웨어 단위로 나누며, Passthrough나 vGPU 구성과 함께 사용할 수 있다.
• OpenStack Nova는 GPU를 직접 제어하지 않고 PCI 또는 VGPU 자원을 추적하고 적절한 Compute Node에 VM을 스케줄링한다.
• 실제 설계에서는 성능뿐 아니라 격리, 활용률, NUMA, 마이그레이션, 드라이버 지원을 함께 판단해야 한다.

References

• Linux Kernel VFIO Documentation
• OpenStack Nova PCI Passthrough
• OpenStack Nova Virtual GPU
• NVIDIA vGPU Documentation
• NVIDIA MIG User Guide
• NVIDIA MIG Concepts