타임슬라이싱·MPS·MIG

한 줄 요약

타임슬라이싱의 replicas: 5 는 GPU 를 다섯 조각으로 쪼개라는 뜻이 아니라 같은 장치를 다섯 번 등록하라는 뜻이다. 스케줄러에게 보이는 자리만 다섯 배가 되고, VRAM 은 여전히 나뉘지 않은 한 덩어리다.

왜 나눠 쓰고 싶어지나

GPU 를 사면 곧바로 이런 그래프를 보게 된다. 사용률이 하루 평균 8%. 그런데 대기열은 늘 차 있다. 이유는 단순하다 — 파드 하나가 GPU 한 장을 통째로 잡기 때문이다. 주피터 노트북을 켜 두고 코드를 읽는 사람도, 추론 요청을 초당 한 번 받는 서비스도, 실제로는 GPU 를 거의 안 쓰면서 한 장을 붙잡고 있다.

여기서 나오는 요구가 "한 장을 여럿이 쓰게 해 달라" 이고, 답이 세 가지다. 셋은 성격이 완전히 다른데 이름이 다 비슷해서 자주 섞인다.

흐름 강조 재생 · 다시 보려면 해제 후 선택

1. 1같은 장치를 다섯 번 등록한다device plugin 설정 한 장이 노드가 광고하는 nvidia.com/gpu 를 물리 장치 수 곱하기 5 로 만든다. 4장이면 20이다. 장치를 쪼개는 것이 아니다.
2. 2스케줄러가 20자리를 믿고 파드를 보낸다스케줄러가 보는 것은 광고된 숫자뿐이다. 자리를 준다고 했고 자리를 줬으니 스케줄러에게 잘못은 없다.
3. 3한 장에 파드 다섯이 같은 VRAM 을 겹쳐 쓴다슬롯에 보장된 메모리는 0이다. 한 파드가 큰 모델로 대부분을 잡으면 나머지는 Running 인 채로 CUDA OOM 을 맞는다.

여기서 구분할 것 자리가 다섯 배가 된 것이지 GPU 가 다섯 배가 된 것이 아니다. 슬롯 하나는 GPU 한 장 분량이 아니라 차례가 오는 자리 하나다.

잠깐, 예측해 보세요 한 장을 나눠 쓰는 다섯 파드 중 하나가 VRAM 40GiB 가운데 38GiB 를 잡았다. 나머지 네 파드의 STATUS 에는 무엇이 보일까?

설명 확인 · 채점 없는 자가 점검

Running 으로 보인다. 스케줄러는 자리만 약속했고 메모리는 약속하지 않았다. 파드 안에서 CUDA OOM 이 나도 STATUS 칸은 정상이라 컨테이너 로그와 OOM 발생 수를 따로 봐야 한다.

근거 문서

어떻게 동작하나

방식	무엇을 나누나	메모리 격리	오류 격리	필요 조건
타임슬라이싱	실행 시간만 (문맥 교환)	없음	없음	아무 GPU 나
MPS	시간 + 커널 동시 실행	상한 설정은 가능, 강제 격리는 아님	제한적	데몬 필요
MIG	하드웨어 파티션	있음	있음	A100·H100 급

타임슬라이싱은 device plugin 설정 한 장으로 켜진다.

sharing:
  timeSlicing:
    failRequestsGreaterThanOne: true
    resources:
      - name: nvidia.com/gpu
        replicas: 5

이러면 노드가 광고하는 nvidia.com/gpu 가 물리 장치 수 × 5 가 된다. 4장이면 20이다. 스케줄러는 20자리가 있다고 믿고 파드 20개를 보낸다. 그런데 그 20개가 실제로 만나는 것은 여전히 GPU 4장이고, 한 장에 붙은 다섯 파드는 같은 40GiB VRAM 을 두고 겹쳐 쓴다. 슬롯에 보장된 메모리는 0이다.

그래서 이런 일이 벌어진다. 다섯 명 중 한 명이 큰 모델을 올려 38GiB 를 잡으면, 나머지 넷은 파드가 Running 인 채로 CUDA OOM 을 맞는다. 스케줄러는 아무 잘못이 없다 — 자리를 준다고 했고 자리를 줬다. 메모리를 약속한 적이 없을 뿐이다.

failRequestsGreaterThanOne: true 는 이 오해를 조금이라도 줄이려는 스위치다. 파드가 nvidia.com/gpu: 2 를 요청하면 거부한다. 슬라이스 두 개를 받아도 그것이 "GPU 두 장 분량"을 뜻하지 않기 때문이다. 켜 두는 편이 낫다.

MPS 는 여러 프로세스의 CUDA 커널을 하나의 컨텍스트로 모아 진짜로 동시에 실행시킨다. 문맥 교환 비용이 사라져서 처리량이 올라가고, 프로세스별 메모리 상한을 걸 수도 있다. 다만 상한은 협조적인 제한에 가깝고, 한 프로세스가 죽을 때 다른 프로세스까지 영향을 받을 수 있다.

MIG 만이 하드웨어 수준의 분할이다. SM 과 메모리 컨트롤러를 물리적으로 갈라서, 인스턴스마다 자기 VRAM 을 갖는다. 옆에서 무슨 짓을 해도 내 인스턴스는 안전하다. 대신 지원 하드웨어가 필요하고, 프로파일이 정해져 있어 자유롭게 나눌 수 없으며, 프로파일을 바꾸려면 그 GPU 를 비워야 한다.

현장에서 만나는 모습

첫째, 판단 기준은 하나다. "이 워크로드가 서로를 죽여도 되는가." 개발용 노트북, 내부 실험, 데모라면 타임슬라이싱으로 충분하고 효과도 크다. 프로덕션 추론 서비스가 섞여 있다면 격리가 없는 공유는 언젠가 반드시 사고가 된다. 같은 클러스터에서도 노드 풀을 갈라 노드마다 다른 정책을 거는 것이 보통이다.

둘째, 사용률 그래프에 속지 않는다. 타임슬라이싱을 켜면 GPU 사용률 지표가 예쁘게 올라간다. 하지만 그 숫자는 "누군가 커널을 돌리고 있다" 는 뜻이지 "일이 빨리 끝난다" 는 뜻이 아니다. 다섯이 번갈아 쓰면 각자의 작업은 느려진다. 봐야 할 지표는 사용률이 아니라 작업 완료 시간과 OOM 발생 수다.

셋째, 사용자에게 무엇을 약속했는지 적어 둔다. 공유를 켜는 순간 nvidia.com/gpu: 1 이라는 요청의 의미가 바뀐다. 어제까지는 "GPU 한 장"이었고 오늘부터는 "차례가 오는 자리 하나"다. 이 변화를 공지하지 않으면, 사용자는 자기 잡이 왜 느려졌는지 영영 모른 채 인프라를 의심한다.

• 타임슬라이싱실행 시간만 나눈다. 메모리 격리도 오류 격리도 없고 아무 GPU 에서나 켠다. 개발용 노트북, 내부 실험, 데모에 맞다.
• MIG하드웨어 파티션이라 인스턴스마다 자기 VRAM 이 있고 옆의 문제가 내 인스턴스에 번지지 않는다. A100, H100 급의 지원 하드웨어가 필요하고 프로파일이 정해져 있으며 바꾸려면 그 GPU 를 비워야 한다.

여기서 구분할 것 MPS 는 둘 사이다. 프로세스별 메모리 상한을 걸 수 있지만 협조적인 제한에 가깝고 한 프로세스가 죽을 때 다른 프로세스가 영향을 받을 수 있다. 프로덕션 추론이 섞이면 격리 없는 공유는 언젠가 사고가 된다는 판단은 본문의 현장 지침이다.

잠깐, 예측해 보세요 타임슬라이싱을 켜자 GPU 사용률 그래프가 올라갔다. 일이 빨라졌다는 뜻일까?

설명 확인 · 채점 없는 자가 점검

아니다. 사용률은 누군가 커널을 돌리고 있다는 뜻일 뿐이다. 다섯이 번갈아 쓰면 각자의 작업은 느려진다. 봐야 할 것은 작업 완료 시간과 OOM 발생 수다.

근거 문서

이어지는 글에서 볼 것

이런 공유 설정은 결국 데몬셋 롤아웃으로 노드에 전달된다. 바로 뒤 글에서는 그 롤아웃이 한 노드에서 멈췄을 때 클러스터가 어떤 모양으로 남는지, 그리고 그 상태가 왜 버그가 아니라 설계대로의 동작인지를 본다.