제4부 데이터센터와 스케일

4.10 MIG와 GPU 공유

4.10.1 이 장에서 배우는 것 / 선수 지식

4.5~4.9은 여러 GPU를 하나처럼 키우는(스케일업) 방향이었다. 이 장은 반대 — 한 GPU를 여러 개로 나누는 방향이다. 큰 데이터센터 GPU 한 장은 작은 추론·실험 워크로드엔 과하다(활용률 낭비). MIG(Multi-Instance GPU) 는 GPU를 하드웨어 수준에서 격리된 여러 인스턴스로 분할해, 각 인스턴스가 독립된 작은 GPU처럼 동작하게 한다 — 멀티테넌시·QoS·장애 격리. MPS·타임슬라이싱과의 차이(공유 vs 격리)도 짚는다(본격 비교는 7.4~7.5).

배우는 것:

• MIG가 GPU를 SM·HBM·L2·메모리 대역까지 하드웨어로 분할해 인스턴스 간 격리(QoS·장애) 를 보장하는 원리.
• GPU Instance(GI)·Compute Instance(CI)·프로파일(예 1g, 2g, 7g) 구조와 분할 방법.
• MIG(하드 분할) vs MPS(공간 공유, 격리 없음) vs 타임슬라이싱(시분할, 격리 없음)의 차이.
• nvidia-smi mig로 인스턴스를 만들고 워크로드를 배치하며, 언제 MIG가 맞고 언제 아닌지 판단.

선수 지식: 1.3(GPC·SM — MIG가 분할하는 단위), 1.6(점유율 — 작은 워크로드의 낭비), 1.9(HBM — 메모리 슬라이스), 4.1(데이터센터 GPU·추론 갈래), 7.2(쿠버네티스 GPU Operator — MIG 운영 상세)·7.5(vGPU·MPS 비교). 환경은 0.3. MIG 지원 GPU·인스턴스 개수·프로파일은 세대·모델 의존(예 A100·H100급에서 최대 7 인스턴스, 시점 의존) → 확인 필요.

4.10.2 동기 — 큰 GPU를 작은 작업이 낭비한다

데이터센터 GPU는 거대하다(수십~백+ SM, 대용량 HBM, 1.3·1.9). 그런데 많은 워크로드는 그것을 다 못 쓴다:

원하는 것: 한 GPU를 여러 작은 GPU처럼 나누되, 서로 간섭·장애가 격리되게. 세 가지 방법이 있고(MIG·MPS·타임슬라이싱) 격리 수준이 다르다. MIG는 그 중 하드웨어 격리가 가장 강하다.

4.10.3 MIG 메커니즘 — 하드웨어 분할

MIG는 GPU의 물리 자원을 고정 배분해 격리된 인스턴스를 만든다. 핵심은 "공유"가 아니라 "분할"이다 — 각 인스턴스가 전용 SM·HBM·L2·메모리 대역을 가진다.

각 인스턴스는 독립된 작은 GPU처럼 보이며, A·B·C는 SM·메모리·대역이 분리돼 서로 간섭·장애가 격리된다.

격리의 의미:

• 성능 격리(QoS): 인스턴스 A가 바빠도 B의 SM·대역을 못 뺏는다 — B의 성능이 예측 가능(노이즈 이웃 없음).
• 메모리 격리: 각 인스턴스가 자기 HBM 슬라이스만. A의 OOM이 B에 영향 없음.
• 장애 격리: 한 인스턴스의 오류가 다른 인스턴스로 번지지 않음(대체로).

이것이 MPS·타임슬라이싱과 결정적으로 다른 점 — 그들은 자원을 공유해 간섭·격리 약함, MIG는 분할해 하드 격리. 대가는 유연성(고정 배분이라 동적 재배분이 제한, 4.10.7).

4.10.4 GI·CI·프로파일

MIG 분할은 두 단계 객체로 구성된다:

프로파일. 분할 크기는 사전 정의된 프로파일로 표현한다(이름은 세대 의존, 예시):

숫자(1g·2g·…)가 컴퓨트·메모리 몫이며, 그 합이 GPU 총량을 넘을 수 없다.

예: 한 GPU를 $7 \times1g$(작은 7개), 또는 1g + 2g + 4g(혼합), 또는 7g(전체) 등으로. 프로파일 조합이 분할 레이아웃이고, 워크로드 크기에 맞춰 고른다. (가능한 조합·메모리 단위는 세대별로 정해져 있음, 확인 필요.)

4.10.5 워크스루 — MIG 설정·사용

nvidia-smi mig로 분할한다(명령·출력은 개략, 버전 의존):

# 1) MIG 모드 켜기 (GPU가 idle이어야, 드라이버 리셋 필요할 수 있음)
sudo nvidia-smi -i 0 -mig 1
# 2) 가능한 GI 프로파일 목록 보기
nvidia-smi mig -lgip
#  ID  Name        Memory   ... (예: 1g.10gb, 2g.20gb, 3g.40gb, 7g.80gb — 세대 의존)
# 3) GPU 인스턴스(GI) 생성 — 예: 3g + 2g + 2g
sudo nvidia-smi mig -cgi 3g.40gb,2g.20gb,2g.20gb -C    # -C: 기본 CI도 함께 생성
# 4) 분할 결과 확인
nvidia-smi -L
#  GPU 0: ... (UUID GPU-...)
#    MIG 3g.40gb Device 0: (UUID MIG-...)
#    MIG 2g.20gb Device 1: (UUID MIG-...)
#    MIG 2g.20gb Device 2: (UUID MIG-...)

# 5) 특정 MIG 인스턴스에 워크로드 배치 — MIG UUID로 지정
CUDA_VISIBLE_DEVICES=MIG-<uuid> python serve_model.py   # 이 프로세스는 그 인스턴스만 봄
# 또는 컨테이너에 인스턴스 할당(쿠버네티스는 device plugin, 7.2)

읽는 법:

• MIG 모드는 GPU가 idle일 때만 켜고, 분할 변경도 워크로드를 비우고. 동적 재분할 비용이 작지 않다(함정).
• 각 MIG 인스턴스가 독립 디바이스(MIG UUID) 로 보인다 — CUDA_VISIBLE_DEVICES로 프로세스·컨테이너에 격리 할당.
• 쿠버네티스에선 MIG 인스턴스가 스케줄 가능한 자원이 된다(GPU Operator·device plugin, 7.2~7.3).

관찰. 3g 인스턴스에서 고부하 추론을 실행해도 2g 인스턴스의 지연은 영향받지 않는다(격리). 같은 일을 MPS·타임슬라이싱으로 하면 서로 간섭한다 — 그것이 MIG의 QoS 가치.

4.10.6 중간 점검 (체크포인트)

• [ ] MIG가 SM·HBM·L2·대역을 분할(공유 아님) 해 성능·메모리·장애를 격리함을 설명한다.
• [ ] GI·CI·프로파일(1g·2g·7g) 구조로 분할 레이아웃을 구성할 줄 안다.
• [ ] MIG(하드 격리) vs MPS(공간 공유, 약한 격리) vs 타임슬라이싱(시분할, 격리 없음)을 구분한다.
• [ ] nvidia-smi mig로 인스턴스를 만들고 CUDA_VISIBLE_DEVICES로 격리 배치할 줄 안다.

증상→의심: 한 워크로드가 다른 것의 지연을 흔듦 → MPS/타임슬라이싱(격리 없음), QoS 필요하면 MIG. MIG 인스턴스가 기대보다 느림 → 작은 프로파일(자원 적음, 정상) 또는 단일 큰 작업엔 분할이 손해. 분할 변경이 안 됨 → 워크로드가 인스턴스를 점유 중(idle 필요). 큰 모델이 한 인스턴스에 안 들어감 → 더 큰 프로파일·분할 안 함(7g)·다GPU 필요.

4.10.7 트레이드오프 — MIG vs MPS vs 타임슬라이싱, 언제 무엇

견해: 격리가 필요하면 MIG(여러 테넌트·SLA·예측 가능 지연·보안 경계). 같은 사용자의 신뢰 워크로드 처리량이면 MPS가 자원 공유로 더 나을 수 있다(격리 불필요). 단일 큰 학습은 분할하지 말고 GPU 전체(또는 다GPU). 핵심 질문: "격리(QoS·장애)가 가치 있나, 아니면 공유로 처리량을 극대화해야 하나?" — 추론 멀티테넌시는 보통 MIG, 단일 대형 학습은 분할 금지. (상세 비교·선택은 7.4~7.5.)

비NVIDIA 정직: GPU/가속기 분할·멀티테넌시는 NVIDIA만의 과제가 아니다 — 클라우드의 vGPU·시분할, 다른 가속기의 파티셔닝, 쿠버네티스 수준의 공유 스케줄링이 같은 문제를 푼다. MIG의 차별점은 하드웨어 수준 강한 격리(메모리·대역·장애)다. 단순 시분할·소프트웨어 공유로 충분하면 MIG가 필요 없을 수도 — 격리 요구 수준으로 판단.

4.10.8 흔한 함정

• 단일 큰 작업에 MIG. 큰 학습은 GPU 전체 자원이 필요한데 분할하면 한 인스턴스가 일부만 써 느려진다. MIG는 여러 작은 워크로드 격리용 — 단일 대형엔 분할 금지(7g 또는 분할 off).
• 동적 재분할을 경량으로 봄. MIG 모드 토글·프로파일 변경은 GPU/인스턴스가 idle이어야 하고 즉시·빈번히 바꾸기 어렵다. 정적 파티션에 가깝다 — 워크로드 믹스가 자주 변하면 운영 부담.
• MIG를 공유로 오해. MIG는 자원을 나눠 각자 전용으로 준다(공유 아님). 한 인스턴스가 유휴여도 그 자원을 옆이 못 쓴다 — 활용률 vs 격리의 교환.
• 인스턴스가 다 같다고 가정. 일부 기능(예 특정 인터커넥트·인코더·기능)이 인스턴스별로 제한되거나 분할 시 일부 자원이 분배에서 빠질 수 있다(세대 의존). 워크로드 요구 기능이 인스턴스에서 되는지 확인.
• MIG 인스턴스 간 NVLink 통신을 기대. MIG는 한 GPU를 여러 격리 슬라이스로 나누는 것이지, 슬라이스끼리(또는 다른 GPU의 인스턴스와) NVLink로 묶어 하나의 큰 작업처럼 쓸 수 있게 해주지 않는다 — 인스턴스 간 통신·NVLink 접근도 제약된다(세대·구성 의존, 확인 필요). 인스턴스를 넘나드는 통신이 필요하면 애초에 MIG가 아니라 GPU 전체 + 스케일업(4.5~4.7)이 맞는 도구.
• 메모리 프로파일 초과. 모델이 인스턴스 HBM 슬라이스를 넘으면 OOM — 프로파일 메모리에 맞게 모델·배치 조정하거나 더 큰 프로파일.
• 격리를 무한 신뢰. MIG 격리는 강하지만 보안 경계로 쓸 땐 그 시점 보안 모델·문서를 확인(완전성은 구현·세대 의존).

4.10.9 연습문제

연습 1 (세 방식 구분). MIG·MPS·타임슬라이싱을 "격리·동시성" 두 축으로 한 줄씩 구분하고, "여러 고객의 추론을 한 GPU에서 SLA 보장하며" 실행할 때 무엇을 고를지와 이유.

연습 2 (프로파일 설계). 80GB·7-슬라이스 분할 가능 GPU(가정)에서 (a) 작은 모델 추론 7개, (b) 큰 추론 1개 + 작은 것 3개를 실행하려 한다. 각각 프로파일 조합을 제안하라.

연습 3 (MIG 부적합). 405B 모델 사전학습 팀이 "GPU 활용률을 높이자"며 MIG로 GPU를 분할하려 한다. 왜 부적합한지, 올바른 접근은?

연습 4 (정적 분할의 운영). MIG의 "동적 재분할 비용이 작지 않다"가 운영에 주는 제약을 설명하고, 워크로드 믹스가 시간대별로 크게 변하는 환경에서의 대응을 제안하라.

4.10.10 요약 · 다음 장

• MIG는 스케일업의 반대 — 한 GPU를 하드웨어로 분할해 격리된 여러 작은 GPU(인스턴스)로. 각 인스턴스가 전용 SM·HBM·L2·대역을 가져 성능(QoS)·메모리·장애가 격리된다.
• 구조: GI·CI·프로파일(1g·2g·7g)로 분할 레이아웃 구성. nvidia-smi mig로 만들고 MIG UUID로 격리 배치.
• MIG(하드 격리) vs MPS(공유·처리량) vs 타임슬라이싱(시분할·간단) — 멀티테넌시·SLA·보안엔 MIG, 단일 대형 작업엔 분할 금지. 동적 재분할은 부하가 커 정적 파티션에 가깝다.
• 활용률을 높이되 격리가 필요한 추론 멀티테넌시가 본령. 단일 대형 학습은 분할이 아니라 전체·다GPU로.

다음 장: 4.11 스케일아웃 네트워킹 I — InfiniBand·Spectrum-X. NVLink 도메인(노드/랙)을 넘어서는 통신이다. 노드·랙을 잇는 클러스터 패브릭(InfiniBand·이더넷 기반 Spectrum-X)의 구조와, 그것이 왜 대규모 학습의 다음 병목인지 본다.