정보관리기술사 학습 노트
← 목록으로
인프라·클라우드
#GPU가상화#MIG#vGPU#MPS#타임슬라이싱
최종 업데이트 · 2026-10-14

GPU 가상화와 공유 기술(vGPU·MIG·MPS·타임슬라이싱)

1. 개요

GPU 가상화(GPU Virtualization)란 한 장의 물리 GPU를 여러 가상머신·컨테이너·프로세스가 안전하게 나누어 쓰거나, 반대로 여러 장의 GPU를 하나의 논리 자원처럼 묶어 쓰도록 추상화하는 기술의 총칭이다. 좁게는 "하나의 GPU를 여러 사용자가 공유(sharing)하는 분할" 기술을 가리키며, 시간 분할(temporal)·공간 분할(spatial)·하드웨어 분할(hardware partition)의 세 축으로 구현된다.

GPU 가상화가 부상한 배경은 가속기 수요와 자원 효율 사이의 구조적 괴리에 있다. 생성형 AI·딥러닝 학습·추론·HPC 수요가 폭증하면서 데이터센터의 GPU는 가장 비싸고 가장 공급이 빡빡한 자원이 되었다. NVIDIA H100 한 장의 도입가는 수천만 원대이고, 전력·냉각 비용까지 더하면 가동률 1%가 곧바로 비용으로 환산된다. 그런데 실제 현장에서 단일 워크로드가 GPU를 100% 채우는 경우는 드물다. 대화형 추론 서비스, 노트북 기반 데이터 분석, CI 파이프라인의 소규모 테스트 같은 워크로드는 GPU의 연산 유닛(SM)과 메모리의 10~30%만 쓰고 나머지를 놀리는 일이 흔하다. 이 "비싼 자원의 낮은 활용률"을 메우는 것이 GPU 공유 기술의 일차적 존재 이유다.

두 번째 배경은 멀티테넌시(multi-tenancy)와 격리 요구다. 퍼블릭 클라우드나 사내 공용 클러스터에서는 서로 다른 팀·고객이 같은 GPU를 나누어 쓰되, 한 테넌트의 작업이 다른 테넌트의 메모리를 넘보거나 성능을 잠식해서는 안 된다. 즉 "쪼개서 쓰되 서로 간섭하지 않는" 격리가 전제되어야 한다. GPU 가상화 기법들은 바로 이 활용률(utilization)과 격리(isolation)라는 상충하는 두 목표를, 어느 지점에서 타협하느냐에 따라 갈라진다. 시간 분할처럼 격리를 거의 포기하고 활용률만 노리는 방식부터, MIG처럼 하드웨어 수준으로 완전히 격리하되 분할 입도가 고정된 방식까지가 하나의 스펙트럼을 이룬다.

세 번째 배경은 CPU 가상화와의 비대칭이다. CPU는 수십 년간 가상화가 성숙해 하이퍼바이저가 코어·메모리를 자유롭게 분할·오버커밋(overcommit)할 수 있지만, GPU는 수천 개의 코어(SM)·전용 메모리·고유한 스케줄러를 가진 특수 장치여서 범용 하이퍼바이저가 그대로 다룰 수 없다. 그래서 GPU 벤더가 드라이버·펌웨어·하드웨어 계층에서 전용 가상화 수단을 제공하게 되었고, 그 결과물이 아래에서 다룰 타임슬라이싱·MPS·MIG·vGPU다.

이 괴리가 비용으로 얼마나 환산되는지는 간단한 산수로도 드러난다. 가령 도입·운영을 합쳐 연간 4천만 원이 드는 GPU 노드가 평균 활용률 20%에 머문다면, 실질적으로 연 3천2백만 원어치의 연산이 허공에 버려지는 셈이다. 같은 노드를 공유 기술로 네 작업에 나누어 평균 활용률을 70%로 끌어올리면, 추가 하드웨어 투자 없이 가용 연산이 3.5배로 늘어난다. 수백~수천 장 규모의 AI 클러스터에서는 이 활용률 격차가 수십억 원대의 자본·운영비 차이로 이어지므로, GPU 공유는 단순한 기술 선택이 아니라 재무적 의사결정의 성격을 띤다.

2. 공유 방식의 분류와 전체 구조

GPU 공유 기법을 이해하는 가장 좋은 틀은 "무엇을 기준으로 나누는가"다. GPU의 자원은 크게 연산 자원(SM, Streaming Multiprocessor)과 메모리 자원(VRAM·메모리 대역폭·L2 캐시)으로 나뉘며, 공유 기법은 이 둘을 시간으로 번갈아 쓰게 할지, 공간으로 쪼개 동시에 쓰게 할지에 따라 분류된다. 아래 그림은 네 가지 대표 기법을 시간/공간/하드웨어 분할 축 위에 배치한 전체 구조도다.

flowchart TB
  ROOT["GPU 공유 기술"]
  ROOT --> T["시간 분할(Temporal)"]
  ROOT --> S["공간 분할(Spatial)"]
  ROOT --> H["하드웨어 분할(Hardware)"]
  T --> TS["타임슬라이싱(Time-Slicing)<br/>문맥 교환으로 번갈아 실행"]
  T --> VG["vGPU(기본 모드)<br/>하이퍼바이저가 시간 분할"]
  S --> MPS["MPS(Multi-Process Service)<br/>여러 프로세스 커널 동시 실행"]
  H --> MIG["MIG(Multi-Instance GPU)<br/>SM·메모리·캐시를 물리 분할"]
  H --> VGM["MIG-backed vGPU<br/>하드웨어 격리 + VM 할당"]
  TS -.->|격리 약함·활용률 높음| G1["오버커밋 지향"]
  MIG -.->|격리 강함·입도 고정| G2["멀티테넌시 지향"]

시간 분할(temporal sharing)은 하나의 GPU를 여러 작업이 짧은 시간 단위로 번갈아 점유하는 방식이다. CPU의 라운드로빈 스케줄링과 원리가 같아, 특정 순간에는 한 작업만 GPU를 쓰지만 사람 눈에는 동시에 도는 것처럼 보인다. 전환할 때마다 문맥 교환(context switch) 비용이 들고, 한 작업이 GPU를 쥔 동안 다른 작업은 대기하므로 지연(latency)이 늘어난다. 또한 메모리는 물리적으로 나누어지지 않아 한 작업이 VRAM을 과도하게 점유하면 다른 작업이 OOM(Out of Memory)으로 실패할 수 있다. 격리가 약한 대신 구현이 간단하고 오버커밋이 자유로워, 활용률을 최우선하는 개발·테스트 환경에 적합하다.

공간 분할(spatial sharing)은 GPU의 연산 유닛을 같은 시점에 여러 작업이 나누어 쓰는 방식이다. 수천 개의 SM이 쉼 없이 노는 것을 막기 위해, 한 작업이 일부 SM만 쓸 때 남는 SM을 다른 작업의 커널(kernel)이 채우도록 한다. 대표 구현인 MPS가 여기에 속한다. 시간 분할보다 처리량(throughput)이 높지만, 여전히 메모리 공간과 오류가 완전히 분리되지는 않는다.

하드웨어 분할(hardware partition)은 GPU 내부를 물리적으로 쪼개어, 각 조각이 전용 SM·전용 메모리·전용 메모리 컨트롤러·전용 L2 캐시 슬라이스를 갖게 하는 방식이다. MIG가 대표적이며, 분할된 인스턴스는 사실상 작은 독립 GPU처럼 동작해 성능 간섭(noisy neighbor)과 메모리 침범이 원천 차단된다. 격리가 가장 강력하지만, 분할 경계가 하드웨어로 고정되어 유연성은 떨어진다.

3. 주요 기법의 원리와 아키텍처

네 기법은 "활용률과 격리를 어디서 타협하는가"라는 하나의 질문에 서로 다른 답을 내놓는다. 아래에서 격리가 약한 순서에서 강한 순서로 원리를 살펴본다. 각 기법은 제공하는 격리의 종류(메모리 격리·성능 격리·오류 격리)를 기준으로 비교할 때 차이가 분명해진다.

A. 타임슬라이싱(Time-Slicing)

타임슬라이싱은 GPU의 내장 스케줄러가 여러 CUDA 문맥(context)을 시간 단위로 번갈아 실행하게 하는 가장 기본적인 공유다. 한 작업의 커널 실행이 끝나거나 타임 슬라이스가 만료되면, GPU는 레지스터·프로그램 카운터 등 실행 상태를 저장하고 다음 작업의 상태를 복원한 뒤 실행을 이어 간다. 이 전환은 수 마이크로초~수십 마이크로초 수준이지만, 전환이 잦으면 누적 오버헤드가 커진다.

타임슬라이싱의 결정적 한계는 격리가 거의 없다는 점이다. 메모리가 물리적으로 분리되지 않으므로 두 작업이 같은 VRAM 풀을 공유하고, 한 작업의 메모리 누수나 과점유가 다른 작업의 실패로 번진다. 또한 한 작업이 긴 커널을 돌리면 다른 작업의 지연이 예측 불가능하게 늘어나는 성능 간섭이 발생한다. 쿠버네티스에서 타임슬라이싱을 설정하면 하나의 물리 GPU를 예컨대 4개의 "복제(replica)"로 광고(advertise)해 4개 파드에 할당할 수 있는데, 이는 메모리가 4등분된다는 뜻이 아니라 단지 스케줄링 슬롯이 4개라는 뜻이다. 따라서 메모리 총량을 넘겨 할당하면 그대로 OOM이 난다.

그럼에도 타임슬라이싱이 널리 쓰이는 이유는 하드웨어 제약이 전혀 없고(모든 GPU에서 가능) 설정이 단순하기 때문이다. 수십 명이 쓰는 사내 주피터 노트북 클러스터, GPU를 간헐적으로만 쓰는 CI 러너처럼 "격리보다 가용성과 비용"이 중요한 환경에서는 한 장의 GPU를 8~16개 작업에 과할당(oversubscribe)해 유휴 시간을 메우는 것이 오히려 합리적이다.

다만 과할당 배수를 정할 때는 작업의 동시 활성 비율을 근거로 삼아야 한다. 16명이 노트북을 열어 두어도 실제로 셀을 실행하는 사람은 평균 2~3명뿐이라면 8배 과할당이 안전하지만, 전원이 동시에 대형 학습을 돌리는 순간에는 문맥 교환이 폭증하고 VRAM이 즉시 고갈된다. 따라서 타임슬라이싱은 "피크 동시성이 낮고 재시도가 쉬운" 워크로드에 한정해 적용하고, 메모리 상한을 함께 거는 것이 실패를 줄이는 운영 원칙이다.

B. MPS(Multi-Process Service)

MPS는 여러 프로세스가 각자 보낸 CUDA 커널을 하나의 GPU 문맥 안에서 동시에(공간적으로) 실행하도록 하는 공유 방식이다. 타임슬라이싱이 "번갈아" 실행한다면 MPS는 "함께" 실행한다. 원래 CUDA는 서로 다른 프로세스의 커널을 동시에 돌리지 못하고 직렬화했는데, MPS는 프로세스들의 커널을 하나의 서버 문맥으로 합쳐 SM 레벨에서 동시 실행함으로써 단일 프로세스로는 GPU를 다 못 채우는 작은 워크로드들을 포개어 활용률을 끌어올린다.

MPS가 왜 처리량을 올리는지는 SM 점유의 산술로 설명된다. 어떤 추론 커널이 GPU의 SM을 30%만 쓴다면, 단독 실행 시 나머지 70%의 연산 유닛은 그 시간 동안 아무 일도 하지 않는다. 같은 커널을 세 프로세스가 MPS로 동시에 올리면 세 커널이 서로 다른 SM을 채워 이론상 90%까지 점유가 올라가고, 결과적으로 같은 하드웨어로 거의 세 배의 요청을 처리한다. 타임슬라이싱이었다면 세 작업이 번갈아 돌며 각 구간마다 70%를 비웠을 것이므로, "번갈아"가 아니라 "함께"가 주는 차이가 바로 이 유휴 SM의 회수에 있다.

MPS의 이점은 문맥 교환 비용이 없고, 작은 커널들이 남는 SM을 채워 처리량이 오른다는 점이다. 또한 Volta 세대 이후에는 각 클라이언트에 연산 자원 비율(예: GPU의 50%)을 상한으로 지정하는 기능과 일정 수준의 메모리 보호가 추가되었다. 그러나 근본적으로 MPS는 오류 격리가 약하다. 하나의 GPU 문맥을 공유하므로 한 프로세스가 치명적 오류(예: 메모리 접근 위반)를 일으키면 같은 MPS 서버에 묶인 다른 프로세스까지 영향을 받을 수 있다. 메모리 보호도 완전한 하드웨어 격리가 아니라 소프트웨어적 경계에 가깝다. 따라서 MPS는 서로 신뢰할 수 있는(같은 팀·같은 작업) 다중 프로세스 추론 서비스처럼, 격리보다 처리량이 중요한 단일 테넌트 환경에서 효과가 크다. 예컨대 지연에 민감한 소형 추론 모델 여러 개를 한 GPU에 올릴 때 MPS로 동시 실행하면 각 요청의 꼬리 지연(tail latency)을 낮추면서 전체 처리량을 높일 수 있다.

C. MIG(Multi-Instance GPU)

MIG는 NVIDIA Ampere(A100·A30) 세대에서 도입되어 Hopper(H100·H200)와 Blackwell(B200) 세대로 이어진 하드웨어 수준의 GPU 분할 기술이다. 한 장의 GPU를 최대 7개의 독립 인스턴스(GPU Instance)로 쪼개며, 각 인스턴스는 전용 SM 집합·전용 VRAM·전용 메모리 대역폭·전용 L2 캐시 슬라이스·전용 메모리 컨트롤러를 갖는다. 즉 분할선이 소프트웨어 스케줄러가 아니라 실리콘에 그어지므로, 한 인스턴스의 작업은 다른 인스턴스의 메모리나 성능에 물리적으로 접근할 수 없다. 이것이 MIG가 제공하는 완전한 메모리·성능·오류 격리의 근거다.

flowchart LR
  subgraph GPU["물리 GPU (예: H100 80GB)"]
    direction TB
    subgraph I1["GI 3g.40gb"]
      SM1["SM 슬라이스 x3"]
      M1["VRAM 40GB"]
    end
    subgraph I2["GI 2g.20gb"]
      SM2["SM 슬라이스 x2"]
      M2["VRAM 20GB"]
    end
    subgraph I3["GI 1g.10gb"]
      SM3["SM 슬라이스 x1"]
      M3["VRAM 10GB"]
    end
    L2["L2 캐시·메모리 컨트롤러도 슬라이스 단위로 분할"]
  end
  I1 --> T1["테넌트 A (학습)"]
  I2 --> T2["테넌트 B (추론)"]
  I3 --> T3["테넌트 C (노트북)"]

MIG의 분할 단위는 프로파일(profile)이라는 고정된 조합으로 제공된다. H100 80GB를 예로 들면 1g.10gb(가장 작은 조각, 최대 7개)부터 2g.20gb, 3g.40gb, 7g.80gb(GPU 전체)까지 정해진 크기만 선택할 수 있고, 조각 크기는 "컴퓨트 슬라이스 수(g)"와 "메모리 용량(gb)"의 조합으로 표기된다. 프로파일 이름과 가능한 조합은 SKU마다 다른데, 예컨대 H100 94GB 제품은 1g.12gb·7g.94gb처럼 메모리 표기가 달라진다. 이처럼 입도가 하드웨어로 고정되어 있어 "메모리 7.5GB짜리 인스턴스"처럼 임의 크기를 만들 수는 없으며, 분할 구성을 바꾸려면 해당 GPU의 작업을 모두 비우고 재구성해야 하는 제약이 있다.

MIG는 멀티테넌시 클라우드의 핵심 수단이다. 예를 들어 H100 한 장을 1g.10gb 7개로 쪼개면, 소규모 추론·실험 워크로드 7개를 서로 완전히 격리된 채로 올릴 수 있어, 한 테넌트의 폭주가 다른 테넌트에 영향을 주지 않는다. 클라우드 사업자가 "GPU 1/7"을 상품으로 판매하거나, 사내에서 팀별로 GPU 조각을 할당하는 과금·쿼터 체계를 세울 수 있는 것도 이 하드웨어 격리 덕분이다.

MIG의 또 다른 강점은 성능의 예측 가능성(predictability)이다. 분할된 인스턴스는 전용 메모리 대역폭과 캐시를 갖기 때문에, 이웃 인스턴스가 무엇을 하든 자기 몫의 성능이 일정하게 보장된다. 이는 SLA를 약속해야 하는 추론 서비스에서 특히 중요한데, 타임슬라이싱·MPS에서는 이웃 작업의 부하에 따라 지연이 출렁이지만 MIG에서는 꼬리 지연의 분산이 작아 과금·SLA 설계가 단순해진다. 반대로 분할 입도가 고정이라 "조각 하나가 남는데 그보다 큰 작업이 대기"하는 단편화(fragmentation)가 생길 수 있어, 프로파일 구성을 워크로드 분포에 맞게 사전 설계하는 용량 계획이 필요하다.

D. vGPU(가상 GPU)

vGPU는 하이퍼바이저 계층에서 물리 GPU를 여러 가상머신(VM)에 나누어 주는 기술로, VM 기반 가상화 환경(VMware vSphere, KVM, Citrix 등)과 VDI(가상 데스크톱)·클라우드 IaaS에서 주로 쓰인다. 각 VM에는 vGPU 드라이버가 설치되고, 물리 GPU에는 하이퍼바이저와 협력하는 매니저가 올라가 VM들의 GPU 요청을 중재한다. 기본 vGPU는 시간 분할로 VM들에 GPU를 번갈아 배정하되, 각 VM에 할당된 프레임버퍼(VRAM) 크기는 프로파일로 고정해 메모리 측면의 분리는 보장한다. vGPU는 라이선스가 필요한 상용 소프트웨어 스택이라는 점이 앞의 세 기법과 구별된다.

주목할 점은 vGPU와 MIG를 결합한 MIG-backed vGPU다. 이 구성에서는 MIG로 하드웨어 분할한 인스턴스를 각 VM에 vGPU로 할당하므로, 시간 분할 vGPU가 주지 못하는 연산 성능의 하드웨어 격리까지 VM 단위로 얻는다. 즉 "VM 가상화의 운영 편의 + MIG의 강한 격리"를 동시에 취하는 방식으로, 금융·공공처럼 테넌트 간 격리 요건이 엄격한 가상화 클라우드에서 선호된다.

4. 기법 비교와 선택 기준

네 기법의 차이는 결국 어떤 격리를 하드웨어로 보장하느냐, 그 대가로 유연성·범용성을 얼마나 포기하느냐로 귀결된다. 아래 표는 비교의 보조이며, "왜 그런 차이가 나는가"는 앞 절의 원리로 이해해야 한다.

구분 타임슬라이싱 MPS MIG vGPU(기본)
분할 축 시간 공간 하드웨어 시간(+MIG 결합 가능)
메모리 격리 없음 약함(SW) 강함(HW) 있음(프로파일)
성능 격리 없음 부분 강함(HW) 약함
오류 격리 없음 약함 강함 VM 단위
분할 입도 자유(슬롯 수) 자유 고정(프로파일) 고정(프로파일)
하드웨어 요건 모든 GPU 대부분 GPU A100~B200 등 지원 GPU+라이선스
대표 용도 개발·테스트 오버커밋 단일 테넌트 추론 멀티테넌시 과금 VDI·VM 클라우드

한 가지 흔한 오해는 "공유하면 무조건 전체 처리량이 올라간다"는 기대다. 실제로는 워크로드가 이미 GPU를 충분히 포화시키고 있다면 공유는 전환·경합 오버헤드만 추가해 오히려 느려진다. 공유가 이득을 내는 전제는 각 작업이 GPU를 다 채우지 못하고 SM·메모리에 여유를 남긴다는 점이며, 이 여유가 없으면 분할이 아니라 전용 할당이 정답이다. 따라서 공유 도입 전에는 대표 워크로드의 실제 SM 점유율과 VRAM 사용량을 프로파일링해, 공유 여지가 있는지부터 확인해야 한다.

이 표에서 읽어야 할 핵심은 세로로 "격리가 강해질수록 입도·범용성이 떨어진다"는 상충이다. 타임슬라이싱은 아무 GPU에서나 자유롭게 쪼개지만 격리가 전무하고, MIG는 격리가 완벽하지만 프로파일이라는 고정 틀과 특정 세대 하드웨어를 요구한다. 따라서 선택은 "내 워크로드가 신뢰 경계를 공유하는가, 아닌가"에서 출발한다. 같은 팀의 신뢰할 수 있는 작업이라면 타임슬라이싱·MPS로 활용률을 극대화하는 편이 낫고, 서로 다른 고객·팀이 섞이는 멀티테넌시라면 MIG(또는 MIG-backed vGPU)로 하드웨어 격리를 확보해야 한다.

실무에서는 이들을 계층적으로 조합하기도 한다. 예컨대 H100을 MIG로 3g.40gb 2개 + 1g.10gb 1개로 쪼갠 뒤, 그 중 추론용 MIG 인스턴스 위에 다시 MPS를 얹어 소형 모델 여러 개를 공간 분할로 돌리는 식이다. 이렇게 하면 바깥 경계는 하드웨어로 강하게 격리하면서, 신뢰 가능한 내부 워크로드끼리는 활용률을 다시 끌어올리는 "격리와 효율의 2단 구성"이 가능하다. 실제로 한 추론 플랫폼에서 단일 GPU 점유 방식 대비 MIG+MPS 조합으로 GPU 활용률을 수 배 끌어올렸다는 보고가 있을 만큼, 조합 설계는 비용 절감의 핵심 지렛대다.

5. 심화: 쿠버네티스 통합과 DRA로의 전환

GPU 공유가 실제로 운영되는 현장은 대부분 쿠버네티스다. 전통적으로 쿠버네티스는 디바이스 플러그인(Device Plugin) 모델로 GPU를 다루어 왔다. 노드의 NVIDIA 디바이스 플러그인이 nvidia.com/gpu 같은 확장 자원을 광고하면, 스케줄러가 파드의 자원 요청에 따라 GPU를 통째로 배정하는 방식이다. 여기에 타임슬라이싱 설정을 더하면 한 GPU를 여러 복제 슬롯으로 광고할 수 있고, MIG는 single(모든 인스턴스가 동일 프로파일)·mixed(서로 다른 프로파일 혼합) 전략으로 노출할 수 있다. 그러나 디바이스 플러그인 모델은 GPU를 "통짜 단위"로 다루도록 설계되어, 공유·워크로드별 세부 설정·토폴로지 요구·능력 제약을 네이티브하게 표현하지 못한다는 한계가 뚜렷했다.

이 한계를 넘기 위해 등장한 것이 DRA(Dynamic Resource Allocation, 동적 자원 할당)다. DRA는 워크로드가 ResourceClaim으로 "어떤 능력의 자원이 얼마나 필요한지"를 선언하면, 드라이버가 그 요구에 맞춰 GPU를 동적으로 할당·구성하는 모델로, 디바이스 플러그인의 후속 아키텍처로 자리매김하고 있다. 관련 API(resource.k8s.io/v1)는 쿠버네티스 1.34에서 정식(GA)이 되었으며, NVIDIA의 DRA 드라이버는 이 틀 위에서 타임슬라이싱·MPS 같은 공유 방식을 선언적으로 구성할 수 있게 한다(일부 기능은 아직 알파 단계의 기능 게이트로 제공). 다만 한 클러스터에서 DRA 스택과 기존 디바이스 플러그인 스택을 동시에 쓸 수는 없어, 운영자는 둘 중 하나를 선택해야 한다.

최신 동향의 또 다른 축은 가상 메모리 오버서브스크립션과 KV 캐시 공유다. 대규모 언어모델 추론에서는 모델 가중치와 KV 캐시가 VRAM을 잠식하므로, 통합 메모리(Unified Memory)·CUDA 가상 메모리 관리(VMM) API를 활용해 GPU 메모리를 오버커밋하거나, 여러 추론 요청이 KV 캐시 페이지를 공유하도록 하는 소프트웨어 계층(예: 페이지 단위 어텐션 캐시 관리)이 급속히 발전하고 있다. 즉 하드웨어 분할(MIG) 중심의 "정적 격리"와, 소프트웨어 중심의 "동적 공유·오버커밋"이 양방향으로 함께 성숙하는 중이며, DRA는 이 둘을 선언적 인터페이스로 통합하려는 시도로 볼 수 있다.

또한 vGPU 계층에서는 과금·라이선스 모델과 모드 선택(연산 중심 vCS, 워크스테이션용 vWS 등)이 운영 설계의 변수로 들어온다. 공유 기술을 평가할 때는 순수한 성능·격리 특성뿐 아니라 라이선스 비용, 지원 하드웨어 세대, 하이퍼바이저·쿠버네티스 통합 성숙도까지 함께 저울질해야 총소유비용(TCO) 관점의 최적해에 도달할 수 있다.

6. 고려사항 및 시사점

  • 적용 전략(워크로드 성격에 따른 분기): GPU 공유 설계의 출발점은 "신뢰 경계"다. 같은 팀의 신뢰 가능한 배치(batch)·개발 워크로드는 타임슬라이싱·MPS로 활용률을 극대화하고, 외부 고객·타 조직이 섞이는 멀티테넌시는 MIG로 하드웨어 격리를 확보해야 한다. 지연에 민감한 실시간 추론은 성능 간섭이 치명적이므로 타임슬라이싱을 피하고 MIG 전용 인스턴스나 MPS 상한 설정을 쓰는 것이 안전하다. 한 가지 기법을 전사 표준으로 삼기보다, 워크로드 유형별로 공유 정책을 차등 적용하는 것이 비용·안정성 모두에 유리하다. 실무에서는 노드 풀을 "MIG 격리 풀 / 타임슬라이싱 공유 풀 / 전용 풀"로 분리하고, 네임스페이스·레이블로 워크로드를 적절한 풀에 라우팅하는 방식이 운영을 단순하게 만든다.

  • 트레이드오프(격리 대 활용률 대 유연성): 세 목표는 동시에 극대화할 수 없다. MIG는 격리를 사지만 프로파일 고정과 재구성 비용(작업을 모두 비워야 함)이라는 유연성 손실을 치르고, 타임슬라이싱은 유연성과 활용률을 얻는 대신 격리를 포기한다. 조직은 "격리 실패 시 피해 규모(데이터 유출·SLA 위반)"와 "활용률 1%p의 비용 가치"를 정량화해 어느 지점에서 타협할지 명시적으로 정해야 한다. 특히 활용률만 좇아 과도하게 오버커밋하면 OOM·꼬리 지연 폭증으로 오히려 유효 처리량이 떨어지는 역설에 주의해야 한다.

  • 관측과 운영(공유 환경의 가시성): 공유가 늘수록 "어느 작업이 어느 조각에서 얼마를 쓰는지" 보이지 않으면 병목·간섭의 원인을 찾기 어렵다. GPU 활용률(SM 점유율)·VRAM 사용량·메모리 대역폭·인스턴스별 전력 등을 DCGM 같은 수단으로 조각 단위로 수집하고, 멀티테넌시에서는 테넌트별 쿼터·과금과 연결해야 한다. 단순 "GPU 사용률 90%"는 SM이 실제로 일하는지, 메모리만 점유하는지 구분하지 못하므로 공유 환경의 KPI는 더 세분화되어야 한다.

  • 전망과 연계 기술: 공유 기술은 쿠버네티스 DRA, CUDA 가상 메모리 관리, 추론 서버의 KV 캐시 공유, 그리고 GPU 상호연결(NVLink·NVSwitch)·CXL 같은 메모리 확장 기술과 맞물려 진화한다. 앞으로는 정적 하드웨어 분할과 동적 소프트웨어 오버커밋이 선언적 인터페이스(DRA) 아래로 수렴하면서, "요청한 능력대로 자동 분할·회수되는" 탄력적 GPU 풀이 보편화될 전망이다. 기술사 관점에서는 특정 벤더 기법에 종속되기보다, 격리·활용률·과금·관측을 아우르는 GPU 자원 관리 거버넌스를 설계하는 것이 핵심 역량이 된다.

참고자료

한 줄 요약: GPU 가상화는 비싼 GPU의 낮은 활용률과 멀티테넌시 격리라는 상충 목표를 시간 분할(타임슬라이싱)·공간 분할(MPS)·하드웨어 분할(MIG)·VM 분할(vGPU)로 타협하는 기술 스펙트럼으로, 격리가 강할수록 입도·유연성을 잃는 트레이드오프를 가지며, 쿠버네티스 DRA·CUDA 가상 메모리로 정적 격리와 동적 공유가 선언적으로 수렴하는 방향으로 진화한다.