본문으로 건너뛰기
r/MLOps조회 3

Kubernetes 환경에서 GPU 공유 전략 비교: time-slicing, MPS, MIG의 선택 기준

이 게시물은 Kubernetes에서 GPU를 공유할 때 팀 신뢰 경계를 기준으로 time-slicing, MPS, MIG 중 어떤 방식을 선택해야 하는지 실무적 기준과 장단점을 제시한다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Kubernetes에서 GPU 공유 문제는 단일 파드가 물리적 GPU를 전체 할당받아 다른 파드가 Pending 상태가 되는 상황에서 자주 발생했으며 이 글은 워크로드 간 신뢰 경계를 기준으로 세 가지 접근법을 권한다. 타임슬라이싱은 설정이 쉽고 모든 NVIDIA GPU에서 동작하지만 메모리와 장애 격리가 없어 동일 팀 내 개발·테스트 용도로 적합하다고 판단된다. MPS는 CUDA 커널을 중앙에서 병렬 스케줄링하고 프로세스별 메모리 제한을 제공해 동시성 향상에 유리하나 MPS 데몬이 단일 실패 지점이 될 수 있다는 한계가 있다. MIG는 Ampere 이상에서 하드웨어 수준의 분할로 강한 격리를 제공하므로 멀티팀 멀티테넌시 환경에서 권장되지만 프로파일 제한과 재구성 시 드레이닝이라는 운영적 제약이 수반된다.

실용적 조언

  • 워크로드 간 신뢰 경계를 먼저 정의한 뒤 그 경계에 따라 정책을 선택해야 한다; 같은 팀 혹은 개발·테스트 용도라면 타임슬라이싱으로 빠르게 Pending 문제를 해소할 수 있다.
  • 동일 신뢰 경계에서 동시 실행과 메모리 제한이 필요하면 MPS를 사용해 커널 병렬화를 통해 활용률을 개선하되 MPS 데몬이 장애 시 파급될 수 있음을 고려해 모니터링과 복구 절차를 준비해야 한다.
  • 다른 팀이나 테넌트가 동일 물리 GPU를 공유해야 하고 오류 격리를 강하게 요구하면 Ampere 이상(GPU 예: A100, H100)에서 MIG를 구성해 하드웨어 레벨 격리를 확보하되 프로파일 고정과 재구성 시 드레이닝이 필요함을 운영 정책에 반영해야 한다.
  • 구형 GPU(T4, V100)에서는 MIG를 사용할 수 없으므로 물리적 분리나 팀별 전용 GPU 할당 같은 운영적 선택지를 검토해야 한다.

섹션별 상세

01
작업 스케줄링 문제는 예시 수치로 드러난다; FP16 형식의 7B 모델이 약 14GB VRAM을 사용하나 Kubernetes에서 A100 같은 80GB GPU를 전체 할당으로 처리하면 device plugin은 자원 전부가 할당된 것으로 보고 다른 파드가 Pending 상태로 머무르게 된다. 이 현상은 노드에 66GB가 유휴로 남아 있음에도 스케줄러가 해당 용량을 인식하지 못하는 자원 추상화의 불일치에서 발생한다. 결과적으로 하나의 파드가 물리적 GPU를 독점하는 방식은 멀티테넌시 환경에서 자원 낭비와 가용성 저하로 이어진다.
02
타임슬라이싱은 모든 NVIDIA GPU에서 적용 가능한 가장 간단한 해결책으로, GPU를 소프트웨어적으로 한 프로세스에게 할당한 뒤 실행 시간을 분할해 여러 워크로드가 번갈아 사용하도록 한다. 구현 관점에서는 별도의 하드웨어 요구가 없고 설정 난이도가 낮아 dev/test 또는 동일 팀 내 신뢰 경계에서 빠르게 파드를 Pending에서 해소할 수 있다. 그러나 메모리와 페일오버 격리가 제공되지 않아 한 프로세스의 CUDA 오류가 전체 GPU에서 실행 중인 다른 워크로드에 영향을 줄 수 있다는 점이 실무상 큰 위험 요소로 남는다.
03
MPS는 CUDA 커널 스케줄링을 중앙에서 조정해 컨텍스트 전환 대신 커널을 병렬로 실행하도록 하고, 프로세스별 메모리 제한을 설정할 수 있어 동일 신뢰 경계 내에서 동시성 요구를 해결하는 데 유리하다. 작동 원리는 각 프로세스의 커널을 MPS 데몬이 받아 스케줄링하고 GPU 리소스를 배분하는 방식이며 이로 인해 스루풋이 개선되고 레이턴시는 줄어들 수 있다. 그러나 MPS는 소프트웨어 계층이므로 개별 프로세스의 치명적 오류가 MPS 데몬을 통해 다른 프로세스에 전이될 수 있어 완전한 장애 격리를 보장하지는 못한다.
04
MIG는 Ampere 이상 아키텍처에서 제공하는 하드웨어 수준의 분할로, GPU를 고정 크기의 프로파일로 나누어 각 인스턴스에 전용 메모리와 연산 유닛을 할당해 실질적인 격리를 제공한다. 구현 관점에서는 각 MIG 인스턴스가 독립 장치처럼 동작하므로 하나의 인스턴스에서 발생한 크래시가 다른 인스턴스에 영향을 주지 않으며 멀티팀 환경에서 안전한 공유 전략이 된다. 단점은 프로파일이 미리 정의된 고정 크기이고 프로파일 변경이나 재구성 시에는 해당 GPU에서 워크로드를 드레인해야 하므로 유연성이 떨어진다는 점이다.

용어 해설

NVIDIA MPS(MPS)
NVIDIA MPS는 CUDA 커널을 프로세스 간에 병렬로 실행하도록 중개하는 런타임 서비스로, 컨텍스트 전환 대신 스케줄링을 통해 GPU 활용률을 높이고 프로세스별 메모리 제한을 설정할 수 있어 동일 신뢰 경계 내의 다중 워크로드 동시 실행에 유리하다. MPS는 커널 스케줄링을 중앙에서 처리하므로 개별 프로세스의 메모리 접근을 완전 분리하지 못해 프로세스 오류가 MPS 데몬을 통해 다른 작업에 영향을 줄 수 있다는 점이 중요하다.
Multi-Instance GPU(MIG)
MIG는 Ampere 및 이후 아키텍처에서 지원하는 하드웨어 수준의 GPU 분할 기능으로, GPU를 독립적인 인스턴스로 나누어 각 인스턴스에 전용 메모리와 컴퓨트 리소스를 할당해 소프트웨어적 충돌이나 메모리 오염으로부터 격리된 환경을 제공한다. 프로파일이 고정 크기이고 재구성 시 워크로드 드레이닝이 필요하므로 멀티테넌시에서 강력한 격리와 예측 가능한 성능을 필요로 할 때 선택된다.
Kubernetes 디바이스 플러그인(Kubernetes device plugin)
Kubernetes device plugin은 노드의 특수 하드웨어 리소스(GPU 등)를 스케줄러와 연동해 노드에서 파드로 노출하는 드라이버 계층으로, GPU가 전부 할당된 것으로 표시되면 다른 파드가 Pending 상태에 빠질 수 있는 리소스 할당 문제의 원인이 된다. 이 플러그인은 리소스 광고와 할당 정책을 제어하므로 GPU 공유 전략과 밀접하게 연관된다.
타임슬라이싱(Time-slicing)
타임슬라이싱은 GPU를 단일 컨텍스트로 전부 할당한 뒤 운영체제 또는 드라이버 레벨에서 실행 시간을 분할해 여러 워크로드가 번갈아 GPU를 사용하는 방식으로, 설정이 간단해 모든 NVIDIA GPU에서 동작하지만 메모리와 오류 격리가 제공되지 않아 한 프로세스의 CUDA 오류가 전체에 영향을 줄 수 있다. 신뢰 경계가 좁고 오류 격리가 필요하지 않은 개발/테스트 환경에서 경제적인 선택이다.

언급된 도구

MPS추천

CUDA 커널을 중앙에서 스케줄링해 동시 실행과 프로세스별 메모리 제한을 제공

MIG추천

GPU를 하드웨어 수준에서 분할해 각 인스턴스에 전용 메모리·컴퓨트 제공으로 장애 격리

Kubernetes device plugin중립

노드의 GPU 리소스를 스케줄러에 광고하고 파드에 노출하는 역할

AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 07. 14.수집 2026. 07. 14.출처 타입 REDDIT

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.