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

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

TL;DR

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

주요 논점

01중립다수

time-slicing은 설정이 가장 쉽고 모든 NVIDIA GPU에서 동작하므로 빠른 해결책으로 채택되는 경우가 많다. 실제 동작 방식은 한 프로세스가 GPU를 점유하되 스케줄러가 실행 시간을 분할해 여러 컨테이너가 번갈아 GPU를 사용하게 하는 것이며 이 때문에 단일 CUDA 오류가 전체 서비스에 파급될 위험이 남아 있다. 실무적 판단은 동일 팀 수준의 신뢰 경계에서 비용 대비 효용이 높을 때 time-slicing을 선택하는 것이다.

02찬성다수

MPS는 동시 실행이 필요하고 워크로드들이 동일 신뢰 경계에 있을 때 성능과 활용률을 개선하는 합리적 선택이다. 커널을 병렬로 스케줄링하고 프로세스별 메모리 제한을 통해 자원 경쟁을 완화하므로 A100 같은 대형 GPU에서 효율을 끌어내기에 적합하다. 다만 MPS 데몬이 단일 실패 지점이 될 수 있어 완전한 장애 격리를 요구하는 환경에서는 주의가 필요하다.

03찬성다수

MIG는 서로 다른 팀이나 테넌트가 동일 물리 GPU를 공유해야 하고 소프트웨어적 장애가 파급되는 것을 방지해야 할 때 필요한 해결책이다. 하드웨어 차원에서 메모리와 연산 자원을 분리해 각 인스턴스의 충돌이 타 인스턴스에 영향하지 않도록 보장하며 이로 인해 멀티테넌시의 안정성이 확보된다. 트레이드오프는 프로파일 고정과 재구성 시 워크로드 드레이닝이 필요해 운영 복잡도가 증가한다는 점이다.

합의점 vs 논쟁점

합의점

GPU 공유 전략 선택은 기술적 특징뿐 아니라 워크로드 간 신뢰 경계에 따라 달라진다는 점이 공통된 견해이다.
MIG는 하드웨어 수준의 격리를 제공하므로 멀티팀 환경에서 가장 안전한 옵션이라는 점에 대부분이 동의한다.
타임슬라이싱은 구현이 간단하고 구형 GPU에서도 동작하지만 메모리·오류 격리가 없다는 한계 때문에 운영 리스크가 존재한다.

논쟁점

운영상 편의성 때문에 모든 환경에서 기본적으로 타임슬라이싱을 적용하는 관행이 안전한가에 대한 의견이 갈린다.
MPS가 충분한 격리 수준을 제공하는지, 특히 프로덕션 멀티테넌시에서 허용 가능한지에 대한 평가가 분열되어 있다.

실용적 조언

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

섹션별 상세

작업 스케줄링 문제는 예시 수치로 드러난다; FP16 형식의 7B 모델이 약 14GB VRAM을 사용하나 Kubernetes에서 A100 같은 80GB GPU를 전체 할당으로 처리하면 device plugin은 자원 전부가 할당된 것으로 보고 다른 파드가 Pending 상태로 머무르게 된다. 이 현상은 노드에 66GB가 유휴로 남아 있음에도 스케줄러가 해당 용량을 인식하지 못하는 자원 추상화의 불일치에서 발생한다. 결과적으로 하나의 파드가 물리적 GPU를 독점하는 방식은 멀티테넌시 환경에서 자원 낭비와 가용성 저하로 이어진다.

타임슬라이싱은 모든 NVIDIA GPU에서 적용 가능한 가장 간단한 해결책으로, GPU를 소프트웨어적으로 한 프로세스에게 할당한 뒤 실행 시간을 분할해 여러 워크로드가 번갈아 사용하도록 한다. 구현 관점에서는 별도의 하드웨어 요구가 없고 설정 난이도가 낮아 dev/test 또는 동일 팀 내 신뢰 경계에서 빠르게 파드를 Pending에서 해소할 수 있다. 그러나 메모리와 페일오버 격리가 제공되지 않아 한 프로세스의 CUDA 오류가 전체 GPU에서 실행 중인 다른 워크로드에 영향을 줄 수 있다는 점이 실무상 큰 위험 요소로 남는다.

MPS는 CUDA 커널 스케줄링을 중앙에서 조정해 컨텍스트 전환 대신 커널을 병렬로 실행하도록 하고, 프로세스별 메모리 제한을 설정할 수 있어 동일 신뢰 경계 내에서 동시성 요구를 해결하는 데 유리하다. 작동 원리는 각 프로세스의 커널을 MPS 데몬이 받아 스케줄링하고 GPU 리소스를 배분하는 방식이며 이로 인해 스루풋이 개선되고 레이턴시는 줄어들 수 있다. 그러나 MPS는 소프트웨어 계층이므로 개별 프로세스의 치명적 오류가 MPS 데몬을 통해 다른 프로세스에 전이될 수 있어 완전한 장애 격리를 보장하지는 못한다.

MIG는 Ampere 이상 아키텍처에서 제공하는 하드웨어 수준의 분할로, GPU를 고정 크기의 프로파일로 나누어 각 인스턴스에 전용 메모리와 연산 유닛을 할당해 실질적인 격리를 제공한다. 구현 관점에서는 각 MIG 인스턴스가 독립 장치처럼 동작하므로 하나의 인스턴스에서 발생한 크래시가 다른 인스턴스에 영향을 주지 않으며 멀티팀 환경에서 안전한 공유 전략이 된다. 단점은 프로파일이 미리 정의된 고정 크기이고 프로파일 변경이나 재구성 시에는 해당 GPU에서 워크로드를 드레인해야 하므로 유연성이 떨어진다는 점이다.

용어 해설

MPS: — NVIDIA MPS는 CUDA 커널을 프로세스 간에 병렬로 실행하도록 중개하는 런타임 서비스로, 컨텍스트 전환 대신 스케줄링을 통해 GPU 활용률을 높이고 프로세스별 메모리 제한을 설정할 수 있어 동일 신뢰 경계 내의 다중 워크로드 동시 실행에 유리하다. MPS는 커널 스케줄링을 중앙에서 처리하므로 개별 프로세스의 메모리 접근을 완전 분리하지 못해 프로세스 오류가 MPS 데몬을 통해 다른 작업에 영향을 줄 수 있다는 점이 중요하다.
MIG: — MIG는 Ampere 및 이후 아키텍처에서 지원하는 하드웨어 수준의 GPU 분할 기능으로, GPU를 독립적인 인스턴스로 나누어 각 인스턴스에 전용 메모리와 컴퓨트 리소스를 할당해 소프트웨어적 충돌이나 메모리 오염으로부터 격리된 환경을 제공한다. 프로파일이 고정 크기이고 재구성 시 워크로드 드레이닝이 필요하므로 멀티테넌시에서 강력한 격리와 예측 가능한 성능을 필요로 할 때 선택된다.
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 리소스를 스케줄러에 광고하고 파드에 노출하는 역할

언급된 리소스

문서GPU sharing in production: Kubernetes — when MIG and MPS actually matter and when time-slicing is