GPU 분할 스케줄링, AI 인프라 팀이 GPU 활용률과 간섭을 함께 측정하는 법
GPU 분할 스케줄링을 적용한 대시보드에서 사용률이 올라도, 같은 GPU를 쓰는 추론 서비스의 p95 지연과 오류가 함께 늘었다면 용량을 확보한 것이 아니다. AI 인프라 팀이 확인해야 할 결과는 GPU가 바빠진 정도가 아니라 서비스 수준 목표(SLO)를 지키며 끝낸 유효 작업량이다.
이 글은 2026년 9월 1일 기준 NVIDIA MIG·GPU Operator·MPS·DCGM 문서와 Kubernetes GPU 스케줄링 원문을 대조한 아키텍처 분석이다. GPU가 없는 조사 환경이라 부하 시험은 직접 수행하지 않았다. 대신 MIG, time-slicing, MPS의 책임 경계를 나누고 단독 실행과 동시 실행을 같은 조건에서 비교할 측정표를 만든다.
20초 핵심 요약
- 무엇: GPU 공유 정책부터 Kubernetes 배치, 실제 분할 방식, 서비스·장치 지표까지 한 타임라인으로 연결한다.
- 왜: 평균 활용률만 높이면 noisy neighbor가 만든 p95 지연, 큐 적체, OOM과 실패 증가를 숨길 수 있다.
- 어떻게: A 단독, B 단독, A+B 동시 실행을 같은 부하로 교차 비교해 유효 처리량과 워크로드별 간섭 패널티를 계산한다.
Kubernetes가 배치한 수량은 GPU 성능 보장량이 아니다
Kubernetes 기본 스케줄러는 GPU 내부의 SM이나 메모리 대역폭을 직접 나누지 않는다. NVIDIA device plugin이 nvidia.com/gpu, MIG profile 또는 shared resource를 확장 자원으로 광고하면, kube-scheduler는 Pod의 정수형 요청과 노드의 할당 가능 수량, label과 affinity를 보고 노드를 고른다. 이후 kubelet과 device plugin이 선택된 장치를 컨테이너에 할당한다. Kubernetes GPU 스케줄링
실제 실행을 어떻게 나눌지는 다음 계층이 맡는다. MIG 하드웨어, CUDA time-slicing 또는 MPS가 GPU 안에서 작업을 분할하거나 다중화한다. 따라서 time-slicing replica를 두 개 요청했다고 compute share가 두 배가 되지는 않는다. 스케줄러가 보는 자원 개수와 워크로드가 얻는 처리 성능은 서로 다른 값이다. NVIDIA GPU Operator의 GPU 공유
운영 책임에 따라 이 흐름을 풀어 쓰면 다음과 같다.
- 운영자가 MIG profile 또는 time-slicing·MPS 정책을 설정한다.
- NVIDIA device plugin이 해당 자원을 Kubernetes에 광고한다.
- kube-scheduler가 Pod 요청과 노드 용량을 맞춘다.
- kubelet과 device plugin이 장치를 컨테이너에 할당한다.
- GPU 하드웨어나 CUDA 런타임이 실제 실행을 나눈다.
- DCGM과 serving runtime이 각각 장치 상태와 서비스 결과를 기록한다.
이 흐름은 배치 성공에서 끝나지 않는다. 같은 실험 구간에서 장치 지표와 Pod·모델별 처리량 및 지연을 합쳐야 분할 정책의 결과를 판단할 수 있다.
MIG·time-slicing·MPS는 서로 다른 비용을 지불한다
세 방식은 모두 ‘GPU를 나눠 쓴다’고 말하지만 제공하는 격리와 용량의 의미가 다르다.
| 방식 | 스케줄러가 보는 자원 | 격리와 보장 | 비용과 실패 조건 | 우선 검토할 워크로드 |
|---|---|---|---|---|
| MIG | profile별 확장 자원 | 전용 compute·memory 자원과 memory/fault isolation | 지원 GPU와 고정 profile, 재구성 운영, 자원 조각화 | 예측 가능한 격리와 다중 테넌시가 우선인 서비스 |
| time-slicing | 물리 GPU에서 늘어난 replica 또는 shared resource | 공유 접근권이며 memory/fault isolation과 비례 compute 보장은 없음 | noisy neighbor, OOM·fault domain 공유, Pod별 지표 귀속 제한 | 신뢰 경계가 같고 짧고 bursty하며 SLO 여유가 있는 작업 |
| MPS | device plugin의 MPS 공유 자원 | 여러 CUDA process의 동시 실행과 compute·memory 상한 | active thread 제한은 예약이 아니며 process 간 간섭 검증이 필요 | 작은 kernel이 GPU를 충분히 채우지 못하는 협력적 CUDA 작업 |
MIG는 지원 GPU를 미리 정의된 GPU Instance와 Compute Instance로 나눠 전용 compute·memory 자원을 제공한다. 그렇다고 모든 간섭이 사라지는 것은 아니다. PCIe·NVLink, CPU, 스토리지, 전력과 열처럼 인스턴스 밖에서 공유하는 병목은 따로 재야 한다. 지원 GPU와 profile도 장치별로 달라 MIG 지원 구성을 배포 전에 확인해야 한다.
time-slicing은 접근 기회를 늘리는 방식이다. 메모리와 fault domain을 공유하므로 한 작업의 OOM이나 crash가 중요한 서비스라면 밀도보다 격리가 먼저다. MPS는 여러 CUDA context의 작업을 동시에 실행할 수 있지만 active thread percentage는 전용 SM 예약이 아니라 사용 상한이다. 이를 quota처럼 표시하면 운영자가 실제 QoS보다 강한 보장을 받았다고 오해할 수 있다. NVIDIA MPS 사용 조건
NVIDIA device plugin에서는 time-slicing과 MPS가 상호 배타적이며, 같은 sharing 방식이 노드의 모든 GPU에 적용돼 GPU별로 다르게 설정할 수 없다. MIG 위에 time-slicing을 더할 수도 있지만 하드웨어 인스턴스 안에서 다시 공유가 일어나므로 자원 수량과 지표의 의미가 더 복잡해진다. NVIDIA k8s-device-plugin
측정은 GPU 상태와 서비스 결과를 같은 시간축에 놓는다
DCGM의 SM activity나 DRAM activity는 GPU가 무엇을 하고 있었는지 보여준다. 하지만 이 값은 구간 평균이며 kernel trace가 아니다. 높은 activity나 occupancy만으로 compute-bound 상태나 효율 향상을 확정하지 말고 애플리케이션 처리량과 함께 해석해야 한다. DCGM profiling 지표
추론 서비스라면 Triton의 request count, success/failure, request·queue·compute duration을 워크로드별로 수집할 수 있다. 다른 serving runtime을 쓴다면 같은 의미의 지표에 매핑한다. 서비스 지표와 DCGM 지표를 같은 실험 구간에 놓아야 ‘GPU가 바빠졌다’와 ‘완료량이 늘었다’를 구별할 수 있다. Triton metrics
| 층 | 함께 기록할 값 | 판단할 질문 |
|---|---|---|
| 서비스 | A/B별 requests/s 또는 samples/s, p50/p95/p99, success/failure, timeout/OOM | 동시 실행이 어느 워크로드의 SLO를 훼손했나 |
| 큐·스케줄링 | Triton queue duration, Kubernetes Pending 시간, restart/eviction | 계산 전 대기와 실행 중 간섭을 구분할 수 있나 |
| GPU compute | DCGM SM activity, tensor/pipe activity | GPU 활동 증가와 완료량 증가가 같이 나타났나 |
| GPU memory·전송 | DRAM activity, framebuffer memory used, PCIe/NVLink bytes | 메모리 용량·대역폭이나 전송이 병목인가 |
| 안정성 | XID/ECC, thermal·power throttle, OOM, process/Pod failure | 공유 fault domain이나 제한 상태가 결과를 왜곡했나 |
| 비용·용량 | GPU-hours, 성공 요청당 GPU-second, SLO 내 최대 동시 workload 수 | 활용률 상승이 유효 용량과 비용 개선으로 이어졌나 |
관측 귀속에도 제한이 있다. GPU Operator 26.3 문서는 time-slicing에서 DCGM-Exporter가 metric을 container에 연결하는 기능을 지원하지 않는다고 명시한다. 물리 GPU 전체 지표를 time-sliced Pod마다 복제해 각 Pod의 사용량처럼 표시해서는 안 된다. 모델·Pod별 서비스 지표와 실험 구간을 별도로 기록하고, process metric이나 profiler가 필요하다면 실제 배포 버전의 지원 여부를 검증해야 한다. 최신 dcgm-exporter의 변경이 이 제한을 모든 조합에서 해소한다고 단정할 수 없다.
단독 A·단독 B·동시 실행을 같은 조건으로 비교한다
분할 방식만 바꾸려면 GPU 모델, 클럭과 전력 정책, driver·CUDA·container image, 모델 version, precision, batch size를 고정한다. warm-up 구간은 제외하고 같은 요청 trace나 고정 도착률을 재생한다. open-loop 부하에서는 overload 때 queue 증가가 보이게 하고, closed-loop라면 concurrency와 think time을 고정한다.
실행은 A 단독, B 단독, A+B 동시를 여러 차례 교차한다. MIG는 profile, time-slicing은 replica와 실제 동시 process 수, MPS는 active thread·memory limit를 함께 남긴다. 입력과 관측 창이 달라지면 분할 방식의 효과와 부하 차이를 분리할 수 없다.
다음 두 계산 결과를 나란히 둔다.
유효 처리량 증가율
= 동시 실행에서 SLO와 오류 한도를 만족한 A+B 처리량
/ 명시한 단독 기준 처리량
워크로드 A 간섭 패널티
= (동시 실행 A p95 - 단독 실행 A p95)
/ 단독 실행 A p95
유효 처리량의 분모에는 단독 합계인지 순차 실행 시간인지 명시한다. 간섭 패널티 옆에는 처리량 감소율과 오류 증가도 둔다. 평균 지연만 비교하면 일부 요청이 오래 기다리는 tail latency 피해를 가릴 수 있다.
통과 기준은 실험 전에 정한다. p95 증가 상한, 오류·OOM 허용치, 각 워크로드의 최소 처리량, 성공 요청당 GPU-second 개선을 동시에 통과하도록 설계한다. 이 항목들은 공통 형식이며 보편적인 숫자 문턱은 아니다. 팀의 SLO와 오류 비용에 맞춰 값을 넣어야 한다.
격리 요구를 먼저 정하고 밀도 실험은 그다음에 한다
서로 다른 팀이나 고객이 GPU를 공유하거나, OOM 영향이 큰 장기 서비스와 엄격한 tail-latency SLO가 있다면 MIG 또는 물리 분리를 먼저 검토한다. 같은 신뢰 경계에 있는 bursty 개발·배치 작업은 time-slicing으로 대기시간을 줄일 여지가 있다. 낮은 occupancy의 협력적 CUDA process는 MPS 후보가 된다.
롤백 조건도 분명히 정해야 한다. 활용률이 올라도 p95·p99나 queue duration이 계속 증가하면 oversubscription을 줄이거나 격리 profile로 옮긴다. time-slicing에서 OOM과 crash의 공동 fault domain이 문제가 되면 MIG나 별도 GPU로 전환한다. MIG profile의 남는 memory·compute 조각 때문에 queue가 길어지면 작은 profile을 더 늘리지 말고 profile mix와 bin-packing을 다시 본다.
국내 보도가 전한 아크릴 GPUBase의 0.001장 분할과 활용률 두 배는 업체 발언이다. 아크릴 공식 뉴스룸도 7종 이기종 GPU와 수천 건 스케줄링, 특정 고부하 조건의 학습 시간 단축을 주장하지만, 공개 자료만으로 두 발표의 baseline·부하·p95·오류·반복 조건을 같은 시험으로 연결할 수 없다. GPUBase의 내부 방식이 MIG, time-slicing, MPS 또는 독자 방식 중 무엇과 같은지도 확인되지 않았다. 이 숫자를 일반적인 GPU 분할 성능으로 확대하기보다, 도입 PoC에서 같은 측정표를 요구하는 계기로 삼는 편이 안전하다. 매일경제 인터뷰, 아크릴 공식 뉴스룸
분할 정책을 채택하는 최소 조건은 replica나 profile 수가 늘어난 사실이 아니다. 단독 기준선보다 유효 처리량이 늘고, 각 워크로드가 정한 p95·오류·격리 문턱을 함께 통과해야 한다. 그 측정표를 채운 다음 도입비까지 판단해야 한다면 NVIDIA AI 인프라 TCO에서 전체 경로를 계산하는 법으로 이어서 확인할 수 있다.
참고 링크
- NVIDIA MIG User Guide
- NVIDIA GPU Operator — GPU Sharing
- Kubernetes — Schedule GPUs
- NVIDIA DCGM — Profiling
- NVIDIA — When to Use MPS
- NVIDIA Triton Inference Server — Metrics
제휴·협찬은 없다.
