GPU 분할 공유의 트레이드오프 — 격리, 간섭, 단편화로 고르는 MIG·MPS·타임슬라이싱
추론 서비스 하나가 GPU 한 장을 통째로 받았지만 요청이 몰리는 시간대를 빼면 SM(Streaming Multiprocessor) 대부분이 유휴 상태로 남는다. 운영자가 같은 GPU에 배치 작업을 하나 더 올리자 두 파드는 정상적으로 스케줄링됐지만 추론 서비스의 꼬리 지연(tail latency)은 조금씩 늘어났다. 두 작업은 서로 다른 SM에서 실행됐어도 같은 L2 캐시와 메모리 대역폭을 나눠 썼고, 이 경합은 스케줄러와 모니터링 지표 어디에도 드러나지 않았다. GPU 공유로 높인 활용률의 대가는 이처럼 보이지 않는 곳에서 치러진다.
이 글은 다중 테넌트 GPU 공유 기법이 격리를 얼마나 내주고 활용률을 얼마나 얻는지 살펴본다. 먼저 공유가 설계 과제가 된 흐름과 기법을 고르는 세 기준을 정리하고, MIG, MPS와 타임슬라이싱, vGPU와 쿠버네티스의 디바이스 할당이 어떻게 동작하는지 설명한다. 끝으로 간섭 측정과 메모리 초과 할당처럼 아직 풀리지 않은 과제를 다룬다.
늘어나는 GPU와 정체된 활용률
GPU는 장치 한 장 단위로 할당되지만 워크로드가 실제로 쓰는 자원은 그보다 작은 경우가 많다. HKUST 등의 연구진은 NSDI 2022에 발표한 **MLaaS in the Wild**에서 1,300명이 넘는 사용자가 두 달 동안 GPU 6,742개 규모의 운영 클러스터에 제출한 학습·추론 작업의 트레이스를 분석했다. 주요 문제는 낮은 GPU 활용률과 긴 대기 시간이었고, 작업 인스턴스의 대부분은 GPU 한 장에 못 미치는 양을 요청했다. ETH 취리히와 토론토 대학 연구진의 **Understanding GPU Resource Interference One Level Deeper**도 자원을 많이 쓰는 AI 애플리케이션조차 GPU의 상당 부분을 유휴 상태로 남긴다는 관찰에서 출발한다. 할당 단위가 사용량보다 크면 GPU가 늘수록 남는 자원도 함께 늘어난다.
스케줄러의 구조도 이 간극을 만든다. 미시간 대학 등의 연구진은 NSDI 2019에 발표한 **Tiresias**에서 분산 학습 클러스터 관리의 어려움으로 요청한 GPU를 한꺼번에 받아야 실행되는 all-or-nothing 특성, 예측하기 어려운 학습 시간, 선점과 재개에 기댄 GPU 공유의 경직성을 들었다. Tiresias는 작업이 사용한 GPU 수와 시간을 함께 반영한 2차원 우선순위로 작업을 정렬하지만, 공유의 단위는 시간이고 GPU 한 장은 여전히 한 작업이 독점한다. 쿠버네티스의 디바이스 플러그인 프레임워크에서도 확장 리소스(extended resource)는 정수로만 다뤄지고, 초과 할당되지 않으며, 컨테이너 사이에 공유되지 않는다. 스케줄러가 장치 한 장을 쪼개 주지 않으므로 공유 방식은 클러스터를 설계할 때 먼저 정해야 한다.
공유 기법 선택의 세 기준
첫째 기준은 워크로드가 메모리 바운드(memory-bound)인가 연산 바운드(compute-bound)인가다. SM을 나눠도 메모리 경로의 경합은 사라지지 않기 때문이다. 앞의 간섭 연구는 CUDA Green Context로 SM을 서로 겹치지 않는 집합으로 나눈 뒤 두 커널을 실행했는데, 이 조건에서도 L2 캐시 용량과 L2·전역 메모리 대역폭의 경합은 남았다. 서로 다른 SM 집합에 올린 두 복사 커널은 입력 크기에 따라 서로를 두 배 넘게 늦췄다. 감속의 크기는 실험에 쓴 GPU의 L2 용량과 메모리 구성에 묶여 있지만, SM 분할이 L2와 메모리 경로를 나누지 않는다는 구조는 세대가 바뀌어도 남는다. 슬라이스의 크기를 정할 때도 함정이 있다. 달성 점유율(achieved occupancy)이 6.25%인 커널을 그 비율만큼의 SM으로 제한하자 지연이 8.57배 늘었다. 프로파일러의 점유율만 보고 슬라이스를 정하면 필요한 자원을 과소평가하게 된다.
둘째 기준은 테넌트 간 격리 요구이고, 셋째는 단편화(fragmentation) 위험이다. 공유 메커니즘 가운데 메모리 보호, SM 성능 격리, 메모리 대역폭 QoS, 오류 격리를 모두 갖춘 것은 MIG뿐이고, CUDA 스트림과 MPS에는 오류 격리가 없다. 따라서 격리 기준에서 물어야 할 것은 한 테넌트의 치명적 오류가 다른 테넌트의 프로세스를 종료시켜도 되는가이다. 단편화는 반대 방향의 비용이다. 크기가 정해진 슬라이스로 자를수록 격리는 강해지지만 어떤 요청에도 맞지 않는 슬라이스가 남는다. 메모리 대역폭을 다투면서 격리도 필요한 워크로드에는 메모리 컨트롤러까지 나누는 하드웨어 분할이 맞지만 단편화가 남는다. 단편화를 피하려고 소프트웨어 공유를 고르면 간섭과 오류 전파가 따라온다. 세 기준을 따지지 않고 익숙한 기법을 고르면 무엇을 내주었는지 모르는 채로 간섭이 쌓인다.
하드웨어 분할: MIG의 고정 프로파일과 단편화
MIG(Multi-Instance GPU)는 GPU의 메모리 경로와 SM을 하드웨어 수준에서 나눈다. 할당의 기본 단위는 메모리 컨트롤러와 캐시를 포함해 전체 메모리 용량과 대역폭의 약 1/8인 메모리 슬라이스와, MIG 모드에서 SM의 약 1/7인 SM 슬라이스다. 둘을 하나씩 묶은 것이 GPU 슬라이스이고, GPU 슬라이스에 복사 엔진 같은 엔진을 더한 것이 GPU 인스턴스(GI)다. GI 아래에 두는 컴퓨트 인스턴스(CI)는 부모 GI의 SM 슬라이스 일부를 전용으로 갖지만 메모리와 엔진은 같은 GI의 다른 CI와 공유한다. 따라서 메모리 대역폭 QoS와 오류 격리의 경계는 GI이고, CI는 GI 안에서 SM만 나누는 단위다.
단편화는 프로파일 표에서 바로 드러난다. 프로파일은 GPU 모델마다 다르며, Supported MIG Profiles 표의 Blackwell 세대 B200(180GB) 항목을 예로 들면 다음과 같다. 1g.23gb는 메모리 1/8과 SM 1/7로 최대 7개, 1g.45gb는 메모리 2/8과 SM 1/7로 최대 4개, 2g.45gb는 메모리 2/8과 SM 2/7로 최대 3개를 만들 수 있다. 3g.90gb는 메모리 4/8과 SM 3/7로 최대 2개이고, 4g.90gb는 메모리 4/8과 SM 4/7을 가지며, 7g.180gb는 GPU 전체를 차지한다.
이 조합에서 남는 자원은 메모리 1/8과 SM 1/7이라는 할당 단위에서 생긴다. 2g.45gb 세 개를 만들면 메모리 2/8과 SM 1/7이 어느 인스턴스에도 속하지 않고, 1g.23gb 일곱 개를 만들면 메모리 1/8이 남는다. 메모리 바운드 워크로드를 위한 1g.45gb는 네 개를 만들면 메모리를 모두 쓰는 대신 SM 3/7이 남는다. 배치 위치도 단편화를 만든다. 프로파일은 서로 겹치지 않게 배치되어야 하고 한 GI의 물리적 위치가 그 옆에 놓일 수 있는 GI를 결정하므로, 남은 슬라이스의 위치에 따라 새 인스턴스를 만들지 못할 수 있다. 결국 MIG는 가장 강한 격리를 주는 대신 워크로드의 크기를 몇 가지 고정 프로파일에 맞추도록 요구하고, 맞지 않는 만큼이 단편화로 남는다.
연산 공유: MPS와 타임슬라이싱의 오류 격리
MPS(Multi-Process Service)는 여러 프로세스의 작업을 같은 GPU에서 동시에 실행한다. MPS가 없으면 각 프로세스는 GPU 전체의 타임슬라이스를 차례로 받고, 서로 다른 컨텍스트의 작업은 동시에 실행되지 않는다. MPS에서는 제어 데몬(nvidia-cuda-mps-control)이 서버의 수명주기를 관리하고, 서버(nvidia-cuda-mps-server)가 클라이언트들이 공유하는 GPU 연결과 스케줄링 자원을 소유한다. Volta 이후 각 클라이언트는 별도의 GPU 주소 공간을 갖고 GPU에 작업을 직접 제출한다. 자원 제한은 SM 사용 비율의 상한인 CUDA_MPS_ACTIVE_THREAD_PERCENTAGE와 장치 메모리의 상한인 CUDA_MPS_PINNED_DEVICE_MEM_LIMIT로 둔다. 그런데 이 비율은 전용 자원을 예약하지 않으므로 경합이 생기면 최소 연산량이 보장되지 않고, 다른 클라이언트의 커널이 같은 SM에서 실행될 수도 있다.
Ampere 이후 GPU에서는 정적 SM 분할(static SM partitioning)로 이 빈틈을 메울 수 있다. 운영자가 클라이언트마다 접근할 SM을 명시적으로 지정하면 클라이언트 사이에 공간적 격리가 생긴다. 분할 단위인 청크(chunk)는 외장 GPU의 Hopper 이후 세대에서 SM 8개이고, 그 이전 세대에서는 Legacy MPS v2가 SM 4개, MPS v3가 SM 2개다. MPS v3는 나누고 남은 SM을 자동으로 배분하지 않는다. MPS도 SM을 전용으로 나눌 수 있게 됐지만 고정 단위에서 남는 SM이 생기고, L2와 메모리 대역폭의 격리는 여전히 보장 범위 밖에 있다.
오류 격리는 더 약하다. 한 클라이언트의 치명적 오류는 원인이 어느 클라이언트인지 밝히지 않은 채 같은 GPU를 공유하는 모든 클라이언트에 보고된다. 서버는 FAULT 상태에 들어가 새 요청을 CUDA_ERROR_MPS_SERVER_NOT_READY로 거부하고, 영향을 받은 클라이언트가 모두 종료된 뒤에야 ACTIVE로 돌아온다. 타임슬라이싱을 켜면 NVIDIA/k8s-device-plugin은 GPU 하나를 여러 복제본(replica)으로 광고하고 작업을 CUDA 타임슬라이싱으로 교대로 실행한다. 같은 GPU의 복제본을 받은 워크로드는 각자 GPU 메모리 전체에 접근하고 같은 장애 도메인에서 실행되므로, 하나가 비정상 종료되면 모두 종료된다. 복제본을 둘 이상 요청해도 그만큼의 연산은 보장되지 않는다. 소프트웨어 공유는 단편화를 거의 만들지 않는 대신 간섭과 장애 도메인을 테넌트 전체가 함께 진다.
가상화와 스케줄러: vGPU, 디바이스 플러그인, DRA
vGPU는 GPU를 가상머신 단위로 나눈다. 가상머신 사이의 격리는 CPU의 하드웨어 가상화 확장이 게스트의 민감한 명령을 VM Exit으로 하이퍼바이저에 넘기는 구조에서 나온다. 타임슬라이스 방식의 vGPU는 세 스케줄러 가운데 하나로 연산 사이클을 나눈다. 기본값인 best effort는 다른 vGPU가 쓰지 않는 사이클을 추가로 쓰게 하고, equal share는 실행 중인 vGPU에 사이클을 균등하게 나눠 vGPU가 늘고 줄 때마다 각자의 몫이 바뀐다. fixed share는 고정된 몫을 주어 다른 vGPU의 시작과 종료에 성능이 흔들리지 않게 한다. 뒤의 두 스케줄러는 엄격한 라운드 로빈을 적용하며, vGPU가 8개 이하이면 기본 타임슬라이스는 2ms다. MIG가 켜진 GPU에서는 GI마다 스케줄러를 따로 정해 MIG 위에 타임슬라이스 vGPU를 올릴 수 있다. vGPU는 하드웨어 분할과 시간 분할을 겹쳐 쓰는 계층이고, 활용률과 예측 가능성 가운데 무엇을 우선할지는 스케줄러 선택으로 정해진다.
쿠버네티스에서 GPU가 파드에 붙는 경로는 디바이스 플러그인이다. 플러그인은 kubelet의 Registration gRPC 서비스에 nvidia.com/gpu 같은 ResourceName을 등록하고, ListAndWatch로 장치 목록과 상태 변화를 알리며, 컨테이너가 생성될 때 Allocate로 장치를 노출한다. MIG 인스턴스는 nvidia.com/mig-3g.90gb 같은 별도 리소스로, 타임슬라이싱과 MPS의 GPU는 여러 개로 광고되지만 스케줄러가 보는 것은 어느 경우든 정수 개수다. 그래서 하드웨어의 배치 제약과 실제 사용량은 빈 패킹(bin packing)의 입력에 들어가지 않는다. HKUST 등의 연구진은 USENIX ATC 2023에 발표한 **Beware of Fragmentation**에서 그 결과를 보였다. GPU 일부만 요청하는 작업을 허용하자 대규모 클러스터에서 할당할 수 없는 GPU가 수백 개 생겼고, 기존 패킹 휴리스틱은 이를 잘 다루지 못했다. 연구진이 쿠버네티스 스케줄러로 구현한 FGD(Fragmentation Gradient Descent)는 작업 분포에 대한 기대 단편화를 통계적 척도로 정의하고, 그 값이 가장 적게 늘어나는 곳에 작업을 배치한다. GPU 6,200개 이상을 운영 트레이스로 에뮬레이션한 실험에서 FGD는 할당되지 않은 GPU를 기존 패킹 방식보다 최대 49% 줄였다.
쿠버네티스는 이 간극을 v1.35에서 Stable이 된 DRA(Dynamic Resource Allocation)로 좁히고 있다. 드라이버가 ResourceSlice로 장치와 속성을 알리면, 워크로드는 DeviceClass를 참조하는 ResourceClaim으로 장치를 요청하고 CEL 표현식으로 속성을 필터링한다. v1.36에서 베타가 된 KEP-4815 DRA Partitionable Devices는 GPU의 메모리 슬라이스 같은 자원을 SharedCounters로 선언하고, 각 파티션이 ConsumesCounters로 그 카운터를 소비하게 한다. 그래서 서로 다른 메모리 슬라이스에 놓인 1g 파티션 두 개는 함께 할당되지만, 같은 메모리 슬라이스를 다투는 1g 파티션과 2g 파티션은 함께 할당되지 않는다. 다만 ResourceSlice에 나열된 파티션만 할당할 수 있어 임의 분할은 범위 밖이다. DRA로 하드웨어의 배치 제약은 스케줄러가 보는 정보가 됐지만, 어느 위치에 어떤 크기를 먼저 잘라 둘지는 여전히 드라이버와 운영자가 정해야 한다.
간섭 측정과 메모리 초과 할당의 과제
공유 기법을 실제 클러스터에 도입하면 다음 과제가 남는다.
첫째, 테넌트 간 간섭의 측정이다. 프로파일러가 결정론적인 커널 재실행(kernel replay)에 기대기 때문에 함께 실행되는 커널은 프로파일링하기 어렵고, 앞의 간섭 연구도 커널 단위 간섭 추정기를 첫 단계로 제안하는 데 그쳤다. MIG에서는 공유 자원의 프로파일링이 지원되지 않고, 타임슬라이싱을 켜면 DCGM-Exporter가 지표를 컨테이너에 연결하지 못한다. 간섭을 겪는 테넌트는 있어도 그 원인을 테넌트 단위로 나눠 보여 주는 계측 경로는 없다. 하버드, 노스이스턴, UC 샌디에이고 연구진은 **Predictable LLM Serving on GPU Clusters**에서 계측의 공백을 하나 더 보였다. MIG는 연산과 HBM을 격리해도 공유 PCIe 경로는 격리하지 않고, 일부 클라우드 환경에서는 PCIe 토폴로지가 드러나지 않아 카운터로 경합을 추정해야 한다.
둘째, 메모리 초과 할당과 QoS 보장이다. 쿠버네티스의 확장 리소스는 초과 할당되지 않지만 타임슬라이싱의 복제본은 각자 GPU 메모리 전체에 접근하므로, 스케줄러의 정수 회계와 실제 메모리 사용이 어긋난다. KEP-5075 DRA Consumable Capacity는 서로 다른 클레임이 한 장치의 용량을 나눠 받게 하지만, 같은 요청을 참조하는 파드들은 격리 보장 없이 자원을 공유하고 버스트 처리는 각 드라이버의 몫으로 남는다. 런타임 쪽에서는 CUDA 13.4부터 MIG가 꺼진 장치에서 MPS v3 메모리 분할로 cgroup v2마다 하드 한도와 소프트 한도를 둘 수 있다. 하드 한도를 넘는 할당은 CUDA_ERROR_OUT_OF_MEMORY로 실패한다. 소프트 한도를 넘은 클라이언트는 축출 후보가 될 뿐이고, 실제 메모리 압박이 생겨야 MPS가 그런 클라이언트를 강제 종료한다. 이 처리는 사후 대응(reactive)이어서 메모리 초과 할당의 비용은 한도를 넘긴 테넌트의 프로세스 종료로 치러진다. 스케줄러의 용량 회계와 런타임의 강제가 서로 다른 계층에 있는 한 QoS는 스케줄링 시점의 약속에 그친다.
셋째, 동적 워크로드 변동에 따른 재분할이다. MIG Manager는 구성할 GPU에서 사용자 워크로드가 실행되지 않을 것을 요구하므로, 새 구성을 적용하기 전에 디바이스 플러그인을 포함한 GPU 파드를 모두 멈추고 적용이 끝나면 다시 시작한다. 프로파일 하나를 바꾸는 일이 그 노드의 GPU 워크로드 전체를 멈추는 작업이 된다. PCIe 경합을 다룬 연구진도 같은 한계를 인정했다. 프로파일을 바꿀 때는 테넌트를 잠시 멈추고 모델 상태를 다시 적재해야 할 수 있고, 버스트가 큰 워크로드는 이 짧은 중단을 체감할 수 있다. 쿠버네티스 스케줄러는 DRA 자원에 대한 선점도 지원하지 않아 우선순위가 높은 파드도 장치가 비기를 기다려야 한다. 부하가 바뀔 때마다 파티션을 다시 자르는 비용이 단편화를 줄여 얻는 이득보다 작은 구간이 어디인지는 아직 정리되지 않았다.
정리 및 요약
GPU의 할당 단위가 실제 사용량보다 크다는 간극은 운영 트레이스와 간섭 연구에서 거듭 확인되고, GPU를 정수 개의 확장 리소스로만 다뤄 온 스케줄러가 그 간극을 키웠다. MIG는 메모리 대역폭 QoS와 오류 격리를 주지만 고정 프로파일의 조합에서 단편화를 남긴다. MPS는 SM과 메모리 용량을 나눌 수 있게 됐어도 L2와 메모리 대역폭을 격리하지 않고 치명적 오류를 모든 클라이언트에 전파하며, 타임슬라이싱은 격리 없이 시간을 나눈다. FGD와 DRA의 Partitionable Devices는 단편화를 스케줄러가 다루는 문제로 만들었지만 간섭과 런타임 QoS는 여전히 스케줄러 밖에 있다.
결국 GPU 공유 기법의 선택은 세 질문에 차례로 답하는 설계의 문제다. 함께 올릴 워크로드가 같은 L2와 메모리 대역폭을 다투는지에 답하면 SM만 나누는 기법으로 충분한지가 정해진다. 한 테넌트의 치명적 오류가 다른 테넌트의 프로세스를 끝내도 되는지에 답하면 MPS와 타임슬라이싱을 쓸 수 있는 범위가 정해진다. 요청 크기의 분포가 고정 프로파일에 맞는지에 답하면 MIG가 남길 단편화의 크기가 정해진다. 그리고 그 선택을 클러스터 전체에서 지키려면 스케줄러가 보는 단위와 하드웨어가 실제로 자르는 단위가 일치해야 한다.
참고 자료
- MLaaS in the Wild: Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters
- Understanding GPU Resource Interference One Level Deeper
- Tiresias: A GPU Cluster Manager for Distributed Deep Learning
- Device Plugins
- NVIDIA Multi-Instance GPU User Guide
- Concepts
- Supported MIG Profiles
- Multi-Process Service
- When to Use MPS
- NVIDIA/k8s-device-plugin
- Time-Slicing GPUs in Kubernetes
- Changing Scheduling Behavior for Time-Sliced vGPUs and MIG-Backed, Time-Sliced vGPUs
- Beware of Fragmentation: Scheduling GPU-Sharing Workloads with Fragmentation Gradient Descent
- Dynamic Resource Allocation
- KEP-4815: DRA Partitionable Devices
- Predictable LLM Serving on GPU Clusters
- KEP-5075: DRA Consumable Capacity
- MPS v3 Memory Partitioning
- GPU Operator with MIG