CloudNet@팀의 EKS 스터디 AEWS 2기에 작성된 자료를 토대로 작성합니다.
- AI/ML 인프라의 GPU를 사용하는 워크로드들에 대해서 과거 사용하던 방식들에 대해 이해 하려 합니다.
- 컨테이너의 장점을 통해 GPU 사용을 용이하게 하는 방식에 대해 이해하려 합니다.
AI/ML 인프라에 대한 문제점
머신러닝과 딥러닝이 기업의 핵심 경쟁력으로 부상하면서, 데이터 과학자들은 점점 더 복잡하고 계산 집약적인 모델을 개발하고 있다. 이러한 모델을 효율적으로 학습하고 배포하기 위해서는 강력한 컴퓨팅 인프라가 필수적입니다. 특히 GPU를 사용하는 것은 병렬 처리 능력으로 딥러닝 워크로드를 가속화하는 데 있어 중요한 역할을 한다.
- 전통적으로 ML 엔지니어들은 베어메탈 서버에 직접 GPU 드라이버와 라이브러리를 설치하여 작업하였다.
- 이 접근 방식은 몇 가지 심각한 문제점을 가지고 있었다
- 환경 구성의 복잡성: CUDA, cuDNN 등 복잡한 드라이버 스택 설치 및 관리가 필요. 특히 버전 호환성 문제로 인해 특정 프레임워크(TensorFlow, PyTorch)가 특정 CUDA/cuDNN 버전만 지원하는 경우가 많았음.
- 재현성 부족: 동일한 실험 환경을 다른 시스템에서 재현하기 어려움. '내 컴퓨터에서는 잘 작동하는데요?.'와 같은 이야기를 많이 들을 수 있었음.
- 리소스 비효율성: 고가의 GPU 리소스가 특정 사용자나 프로젝트에 고정되어 활용도가 저하. (베어메탈 GPU 서버의 활용률은 30% 미만인 경우가 많았음)
- 확장성 제한: 대규모 분산 학습을 위한 인프라 확장이 어려웠음. 새로운 GPU 서버를 추가할 때마다 동일한 환경 구성 과정을 반복 필요.
AI/ML 인프라에 대한 문제점 -> 컨테이너의 장점 도입
컨테이너 기술은 주로 두 가지 핵심 Linux 커널 기능에 의존한다:
- Cgroups (Control Groups): 프로세스 그룹의 리소스 사용(CPU, 메모리, 디스크 I/O, 네트워크 등)을 제한하고 격리하는 메커니즘
- Namespaces: 프로세스가 시스템의 특정 리소스만 볼 수 있도록 격리하는 기능 Linux는 여러 유형의 네임스페이스(PID, 네트워크, 마운트, UTS, IPC, 사용자 등)를 제공
AI/ML 인프라에 대한 문제점 -> 컨테이너의 장점 도입-> 한계점
- 물리적으로 분할하기 어려운 GPU: CPU 코어나 메모리와 달리, 초기 GPU는 물리적으로 분할하여 여러 컨테이너에 할당하기 어려웠음 (최근에는 MIG 기술로 개선됨 - Nvidia GPU A100에서 새롭게 생긴 기능, 2020년 등장)
- GPU 드라이버 복잡성: GPU 접근은 복잡한 사용자 공간 라이브러리와 커널 드라이버를 통해 이루어짐
- 장치 파일 접근 제어: /dev/nvidia* 과 같은 장치 파일에 대한 접근을 안전하게 관리 필요
컨테이너 환경에서의 GPU 리소스 사용 진화 (단일 GPU)
✅ Passthrough 방식이란?
GPU Passthrough는 물리 서버(호스트)에 장착된 GPU를 하나의 가상 머신(또는 컨테이너)에 직접 할당하는 방식이에요.
이 방식에서는 GPU 리소스가 전용으로 할당되기 때문에, 해당 GPU는 다른 VM이나 컨테이너가 공유해서 사용할 수 없습니다.
✅ VMware 에서 Passthrough 방식 사용 예시 (Kubernetes 환경에서 단일 GPU 할당)


- 가상머신 또는 컨테이너 내부에 NVIDIA Device Plugin이 설치된 상태여야 함
- 가상머신 또는 pod가 단일 GPU를 전용으로 사용하도록 요청하는 예입니다.
- 이 경우, K8s는 GPU를 다른 파드와 공유하지 않고 하나의 pod 또는 VM 에만 할당합니다.
- 거의 native 수준의 성능을 보임
✅ 장점 vs 단점
장점
- 최고의 성능: 거의 로우 레벨 수준의 접근
- 드라이버 레벨 제어 가능: 특정 GPU 기능 활용 가능 (예: Tensor Core)
단점
- 자원 낭비 가능성: GPU가 해당 VM 또는 컨테이너 전용이기 때문에 미사용 시간에도 리소스를 점유
- 확장성 제한: GPU 자원을 여러 컨테이너에 유연하게 나누기 어려움
- 멀티 사용자 환경 비효율적
MIG와 vGPU 구분 하기
MIG (Multi-Instance GPU) vGPU (Virtual GPU)
기술 개념 | GPU를 하드웨어 수준에서 여러 인스턴스로 분할 | GPU를 소프트웨어 기반으로 시간 공유(time-sharing) 하여 가상화 |
지원 GPU | Ampere 아키텍처 이상 (예: A100) 에서만 지원 | 대부분의 NVIDIA GPU에서 지원 가능 |
격리 수준 | 메모리, 캐시, SM 등 완전 하드웨어 격리 | 메모리는 논리적으로 분리, 연산은 time-sharing |
리소스 공유 방식 | 고정된 물리 자원을 분리하여 각 인스턴스에 할당 | 동일한 물리 자원을 시간 분할하여 여러 VM이 공유 |
동시 사용 가능 인스턴스 | A100 기준 최대 7개 (구성 조절 가능) | 수십 개 이상의 vGPU 생성 가능 |
성능 예측 가능성 | 매우 높음 – 자원 격리로 인해 성능 일관성 보장 | 낮음 – 타 VM의 부하에 따라 성능 변동 가능 |
오버헤드 | 매우 낮음 – 하드웨어 분할 방식 | 상대적으로 높음 – context switching 등으로 인한 성능 손실 가능 |
동적 확장/변경 | 가능 – MIG 인스턴스를 실시간으로 조절 및 재구성 가능 | 불가 – VM 생성 시 설정한 vGPU 리소스는 고정 |
적합한 워크로드 | 고정된 성능이 필요한 AI 추론, MLOps, 멀티테넌트 환경 | 유연성이 필요한 데스크탑 가상화(VDI), 일반 연산용 VM 환경 |
대표 사용 사례 | 클라우드 서비스 제공자(CSP), 모델 호스팅 플랫폼 | 기업 내 VDI, GPU가 필요한 개발 테스트 환경 |
라이선스 요구 | MIG 사용 자체는 라이선스 필요 없음 (NVIDIA 드라이버 필요) | vGPU 소프트웨어 라이선스가 별도로 필요 |
'DevOps' 카테고리의 다른 글
[AWS EKS] (31) EKS 스터디 12주차 ( EKS 규모에 따른 네트워킹 구조 ) (0) | 2025.04.23 |
---|---|
[AWS EKS] (30) EKS 스터디 11주차 ( AWS EKS ML Infra(GPU) workshop ) (0) | 2025.04.17 |
[AWS EKS] (28) EKS 스터디 10주차 (Vault + ArgoCD Plugin 패턴) (0) | 2025.04.12 |
[AWS EKS] (27) EKS 스터디 10주차 ( Jenkins + Vault (AppRole) ) (0) | 2025.04.12 |
[AWS EKS] (26) EKS 스터디 10주차 ( Vault ) (0) | 2025.04.11 |